| Gói / sản phẩm | Phiên bản bị ảnh hưởng | Phiên bản đã vá |
|---|---|---|
| Scriban | < 7.0.0 | 7.0.0 |
| Scriban.Signed | < 7.0.0 | 7.0.0 |
The LimitToString safety limit (default 1MB since commit b5ac4bf) can be bypassed to allocate approximately 1GB of memory by exploiting the per-call reset of _currentToStringLength in ObjectToString. Each template expression rendered through TemplateContext.Write(SourceSpan, object) triggers a separate top-level ObjectToString call that resets the length counter to zero, and the underlying StringBuilderOutput has no cumulative output size limit. An attacker who can supply a template can cause an out-of-memory condition in the host application.
The root cause is in TemplateContext.Helpers.cs, in the ObjectToString method:
// src/Scriban/TemplateContext.Helpers.cs:89-111
public virtual string ObjectToString(object value, bool nested = false)
{
if (_objectToStringLevel == 0)
{
_currentToStringLength = 0; // <-- resets on every top-level call
}
try
{
_objectToStringLevel++;
// ...
var result = ObjectToStringImpl(value, nested);
if (LimitToString > 0 && _objectToStringLevel == 1 && result != null && result.Length >= LimitToString)
{
return result + "...";
}
return result;
}
// ...
}
Each time a template expression is rendered, TemplateContext.Write(SourceSpan, object) calls ObjectToString:
// src/Scriban/TemplateContext.cs:693-701
public virtual TemplateContext Write(SourceSpan span, object textAsObject)
{
if (textAsObject != null)
{
var text = ObjectToString(textAsObject); // fresh _currentToStringLength = 0
Write(text);
}
return this;
}
The StringBuilderOutput.Write method appends unconditionally with no size check:
// src/Scriban/Runtime/StringBuilderOutput.cs:47-50
public void Write(string text, int offset, int count)
{
Builder.Append(text, offset, count); // no cumulative limit
}
Execution flow:
LimitToString default)for loop iterates up to LoopLimit (default 1000) timesWrite(span, x) → ObjectToString(x)ObjectToString resets _currentToStringLength = 0 since Bạn đang dùng một trong các sản phẩm này? Quét site để biết có đang lộ phiên bản có lỗ hổng không.
Quét site miễn phí_objectToStringLevel == 0LimitToString check (1,048,575 < 1,048,576)StringBuilder — no cumulative trackingusing Scriban;
// Uses only default TemplateContext settings (LoopLimit=1000, LimitToString=1048576)
var template = Template.Parse("{{ x = \"\" | string.pad_left 1048575 }}{{ for i in 1..1000 }}{{ x }}{{ end }}");
// This will allocate ~1GB in the StringBuilder, likely causing OOM
var result = template.Render();
Equivalent Scriban template:
{{ x = "" | string.pad_left 1048575 }}{{ for i in 1..1000 }}{{ x }}{{ end }}
Each of the 1000 loop iterations outputs a 1,048,575-character string. Each passes the per-call LimitToString check independently. Total output: ~1,000,000,000 characters (~1GB) allocated in the StringBuilder.
LimitToString limit was specifically introduced to prevent resource exhaustion, but the per-call reset makes it ineffective against cumulative abuseAdd a cumulative output size counter to TemplateContext that tracks total bytes written across all Write calls, independent of the per-object LimitToString:
// In TemplateContext.cs — add new property and field
private long _totalOutputLength;
/// <summary>
/// Gets or sets the maximum total output length in characters. Default is 10485760 (10 MB). 0 means no limit.
/// </summary>
public int OutputLimit { get; set; } = 10485760;
// In TemplateContext.Write(string, int, int) — add check before writing
public TemplateContext Write(string text, int startIndex, int count)
{
if (text != null)
{
if (OutputLimit > 0)
{
_totalOutputLength += count;
if (_totalOutputLength > OutputLimit)
{
throw new ScriptRuntimeException(CurrentSpan,
$"The output limit of {OutputLimit} characters was reached.");
}
}
// ... existing indent/write logic
}
return this;
}
This provides defense-in-depth: LimitToString caps individual object serialization, while OutputLimit caps total template output.