Scriban - CraftedSignal Threat Feed

Scriban TemplateContext MemberFilter Bypass Vulnerability

hello@craftedsignal.io — Thu, 02 May 2024 12:00:00 +0000

Scriban, a .NET templating engine, is vulnerable to a sandbox escape vulnerability affecting versions prior to 7.0.0. This vulnerability arises from the TemplateContext caching type accessors without clearing them upon reset. Specifically, the TemplateContext caches accessors based on Type, but these accessors are created using the MemberFilter and MemberRenamer active at the time. When a TemplateContext is reused with a tightened filter for subsequent renders, Scriban reuses the old accessor, potentially exposing members that should be hidden. This bypass allows unauthorized access or modification of filtered properties or fields, leading to policy bypass across requests, users, or tenants when contexts are pooled. The vulnerability is present in src/Scriban/TemplateContext.cs and src/Scriban/Runtime/Accessors/TypedObjectAccessor.cs.

Attack Chain

An application initializes a TemplateContext with a permissive MemberFilter, allowing access to a wide range of object members.
The application renders a template using the TemplateContext, creating a TypedObjectAccessor for a specific type and caching it within the _memberAccessors dictionary using the Type as the key.
The application calls TemplateContext.Reset(), which clears most of the context but crucially does not clear the _memberAccessors cache.
The application modifies the MemberFilter to be more restrictive, aiming to limit access to specific members.
The application renders another template using the same (reused) TemplateContext.
When the application attempts to access members of the same type as in step 2, Scriban retrieves the cached TypedObjectAccessor from _memberAccessors.
The cached TypedObjectAccessor still uses the original, permissive MemberFilter, bypassing the newly configured restrictive filter.
Sensitive data, which should have been filtered, is exposed or modified, leading to unauthorized access or policy bypass.

Impact

Successful exploitation of this vulnerability allows unauthorized read or write access to properties and fields that should have been filtered by the MemberFilter. This can lead to the exposure of sensitive data, unauthorized modification of application state, and policy bypass across requests, users, or tenants. Applications that rely on TemplateContext.MemberFilter for sandboxing or object-exposure policy are particularly vulnerable. The vulnerability affects Scriban versions prior to 7.0.0.

Recommendation

Upgrade to Scriban version 7.0.0 or later to remediate the vulnerability (Affected Packages: nuget/scriban (vulnerable: < 7.0.0)).
Avoid reusing TemplateContext instances with different MemberFilter configurations. Create a new TemplateContext for each rendering operation with a distinct MemberFilter.
Implement server-side checks to validate and sanitize data before rendering it with Scriban to mitigate the impact of potential sandbox escapes.
Monitor Scriban template rendering for unexpected data access patterns to detect potential exploitation attempts.

Scriban `object.to_json` Uncontrolled Recursion DoS

hello@craftedsignal.io — Mon, 29 Jan 2024 12:00:00 +0000

Scriban versions prior to 7.0.0 are susceptible to a denial-of-service vulnerability due to uncontrolled recursion in the object.to_json function. This function, used for recursive JSON serialization, lacks depth limits, circular reference detection, and stack overflow guards. A malicious Scriban template containing a self-referencing object, when processed by object.to_json, triggers unbounded recursion, leading to a StackOverflowException that terminates the hosting .NET process. This vulnerability poses a significant risk to applications embedding Scriban for user-provided templates, such as CMS platforms, email template engines, and static site generators. The vulnerability is easily exploitable, requiring only a single line of template code, and does not require authentication.

Attack Chain

An attacker crafts a malicious Scriban template containing a self-referencing object. For example: {{ x = {}; x.self = x; x | object.to_json }}.
The template is submitted to an application that uses Scriban for template processing.
The Scriban engine parses the template and encounters the object.to_json function call.
The ToJson() function in ObjectFunctions.cs calls the vulnerable WriteValue() function.
WriteValue() attempts to serialize the self-referencing object without proper recursion checks.
Due to the self-reference, WriteValue() enters an infinite recursion loop.
Each recursive call consumes stack space, eventually leading to a StackOverflowException.
The StackOverflowException terminates the entire .NET process hosting the Scriban engine, resulting in a denial of service.

Impact

Successful exploitation of this vulnerability leads to a denial-of-service condition, crashing the entire .NET process hosting the Scriban engine. Any application embedding Scriban for user-provided templates is vulnerable. Because StackOverflowException cannot be caught by application code, the hosting application cannot implement try/catch to survive this. This allows an unauthenticated attacker to trivially crash services using Scriban.

Recommendation

Upgrade to Scriban version 7.0.0 or later, which includes the fix for this vulnerability.
If upgrading is not immediately feasible, consider implementing input validation and sanitization to prevent the use of self-referencing objects in Scriban templates.
Monitor application logs for signs of StackOverflowException errors originating from Scriban template processing.
Deploy the Sigma rules in this brief to your SIEM and tune for your environment.

Scriban Template Engine LoopLimit Bypass Vulnerability

hello@craftedsignal.io — Sat, 27 Jan 2024 12:00:00 +0000

The Scriban template engine is vulnerable to a denial-of-service attack due to a bypass in its LoopLimit functionality. This vulnerability, affecting Scriban versions prior to 7.0.0, allows attackers to craft template expressions that bypass the configured loop limits, leading to excessive CPU or memory consumption. The issue stems from the fact that LoopLimit only applies to script loop statements and not to expensive iteration performed inside operators and built-in functions such as array.size and string multiplication. An attacker can exploit this by submitting a single expression, like {{ 1..1000000 | array.size }} for CPU exhaustion or {{ 'A' * 200000000 }} for memory amplification, even when LoopLimit is set to a small value. This vulnerability impacts applications using Scriban with untrusted template content, including template-as-a-service systems, CMS, and email rendering systems.

Attack Chain

An attacker crafts a malicious Scriban template containing an expression designed to bypass LoopLimit. Example: {{ 1..1000000 | array.size }} or {{ 'A' * 200000000 }}.
The attacker submits the malicious template to a vulnerable application that uses Scriban for template processing.
The application parses the template using Template.Parse().
The application renders the template using template.Render(context) with a specified LoopLimit in TemplateContext.
The array.size function (or string multiplication) is invoked, leading to a large number of iterations or memory allocations without respecting the LoopLimit.
The application's CPU or memory resources are exhausted due to the uncontrolled iteration or allocation.
The application becomes unresponsive or crashes, resulting in a denial-of-service condition.

Impact

The vulnerability allows for uncontrolled resource consumption, leading to denial-of-service conditions. Any application that accepts attacker-controlled templates and relies on LoopLimit is vulnerable. Observed damage includes CPU exhaustion and memory amplification. Vulnerable systems could include template-as-a-service platforms, content management systems (CMS), and email rendering systems. A successful attack can cause application downtime, impacting availability and potentially leading to data loss or corruption if the system crashes during critical operations.

Recommendation

Upgrade Scriban to version 7.0.0 or later to address the vulnerability.
Implement additional safeguards to limit the resources available to template rendering, such as setting CPU and memory limits.
Implement input validation on templates to detect and reject potentially malicious expressions. Specifically, look for large ranges used in conjunction with array.size, or excessively large string multiplications. Deploy the Sigma rules in this brief to your SIEM and tune for your environment.
Monitor application resource usage (CPU, memory) for unusual spikes during template rendering. Enable process monitoring and alerting to detect processes consuming excessive resources.

Scriban TemplateContext Reset Authorization Bypass Vulnerability

hello@craftedsignal.io — Tue, 09 Jan 2024 18:23:00 +0000

Scriban, a .NET templating engine, is vulnerable to an authorization bypass issue affecting applications that reuse TemplateContext objects. Specifically, versions prior to 7.0.0 do not properly clear the CachedTemplates collection when TemplateContext.Reset() is called. This can lead to a situation where an ITemplateLoader that resolves content based on request-specific state (e.g., user identity, tenant context) serves a stale, previously authorized template to subsequent renders, even after the context is reset. This bypass occurs because the include function retrieves templates from the cache without re-evaluating authorization, potentially leaking sensitive data across requests or tenants. This vulnerability could be exploited in multi-tenant or permission-sensitive applications using Scriban templates.

Attack Chain

An application initializes a TemplateContext object and configures an ITemplateLoader that resolves template content based on the current request or user context.
A user (e.g., an administrator) makes a request that causes the ITemplateLoader to load a privileged template (e.g., "admin_profile.scriban") into the TemplateContext.
The include function is used within the main template to load the privileged template. The compiled template is then cached in CachedTemplates.
The application calls TemplateContext.Reset() in an attempt to clear the context for reuse. However, CachedTemplates is not cleared during this reset operation.
A different user (e.g., a regular user) makes a subsequent request that reuses the same TemplateContext object.
The include function is called again, attempting to load a template.
The TemplateContext retrieves the previously cached, privileged template from CachedTemplates without calling ITemplateLoader.Load() again, bypassing the intended authorization check.
The regular user is served the content of the administrator's template, leading to information disclosure.

Impact

Successful exploitation of this vulnerability allows unauthorized access to sensitive information or functionality in applications using Scriban templating. The primary impact is cross-render data isolation issues, where previously authorized template content can be leaked across different requests, users, or tenants. This can lead to the exposure of sensitive data, privilege escalation, or other security breaches, depending on the content of the leaked templates. Applications that pool or reuse TemplateContext objects, call Reset() between requests, use include for template inclusion, and resolve included content based on request-specific state are vulnerable.

Recommendation

Upgrade to Scriban version 7.0.0 or later, where this vulnerability is resolved.
If upgrading is not immediately feasible, avoid reusing TemplateContext objects across different requests or user sessions. Create a new TemplateContext for each request.
Review and audit existing Scriban templates and ITemplateLoader implementations to ensure that sensitive data is not inadvertently exposed through template inclusion.
Implement additional authorization checks within the templates themselves to verify user permissions before displaying sensitive data, even if the TemplateLoader is compromised.
Monitor the usage of TemplateContext.Reset() in your application and ensure that it is used correctly and does not lead to unintended data leakage.