Time for some vulnerability archaeology! I'm sure you're as excited as I am. In a previous post I covered a technique to generate precompiled Java bytecode to bypass Sandbox Security restrictions in Adobe ColdFusion (CVE-2025-30288). And Sandbox Security was first released with ColdFusion 4 in November 1998, so it's been around for quite some time. Perhaps reading that post made you wonder about historical sandbox escapes in ColdFusion. If it did, then consider this post an early Christmas present. 🎁
Let's go find some old vulnerabilities by searching the CVE database for coldfusion and sandbox:
This will admittedly give us an incomplete list. In fact, our search misses CVE-2005-4344, but fortunately we found it because it's included along with CVE-2005-4342 in MPSB05-14. And Adobe PSIRT now uses broad CWE categories when cataloging new vulnerabilities, so we won't have detailed descriptions to rely on for many more recent CVEs. For example, CVE-2025-30288 is described as "Improper Access Control / Security feature bypass." Know of a ColdFusion sandbox escape that I missed? Leave a comment below!
CVE-2001-1514
We're starting off with a pretty basic one. The sky is blue, water is wet, and <CFEXECUTE> (and <CFOBJECT>) can be dangerous in multi-tenant environments. Child processes grow up so quickly these days and don't retain the restrictions of the security sandbox. 😢
And it may be a Macromedia Product Security Bulletin, but with ColdFusion 4.5 we're going waaaay back to when it was Allaire product. Before the transition to Java!
CVE-2004-2331
We're now talking Java with this ColdFusion MX 6 vulnerability. (Write Java code, win Java vulnerabilities?) I didn't take the time to fully recreate an exploit, but the gist is that you can use Java reflection to create Java objects and bypass expected sandbox controls.
CVE-2005-4342 and CVE-2005-4344
We get two sandbox bypasses fixed in this security bulletin. CVE-2005-4342 involves being able to bypass the expected sandbox controls by disabling Java Security Manager on a JRun cluster member. (Later versions of ColdFusion throw an exception if the Java SecurityManager is disabled.)
And from the sound of it, CVE-2005-4344 addressed the issue that in the initial release of ColdFusion MX 7, the <CFOBJECT> and CreateObject(Java) sandbox restriction settings did absolutely nothing. Just like your VCR's tracking knob. Or the elevator "Close Door" button in a pre-war building.
CVE-2006-4725
This vulnerability pertains to code within a sandbox being able to access CFCs outside of the sandbox. The
tech note states "
Webservices are accessed using simple HTTP calls. Protecting webservices using file protection or sandboxes is of limited value since you are allowing outside HTTP access to the same code." So it sounds like they're talking about remote CFCs and webservices. But almost twenty years later,
you're not using remote CFCs anyway, right?
CVE-2008-4831
This CVE is described as an "[u]nspecified vulnerability in Adobe ColdFusion 8 and 8.0.1 and ColdFusion MX 7.0.2 [that] allows local users to bypass sandbox restrictions, and obtain sensitive information or possibly gain privileges, via unknown vectors." With a quick diff of coldfusion.security.SecurityManager.class in the patch we can see that the following change was made:
743,744c745,746
< String libPath = this.rootDir + File.separatorChar + "lib" + File.separatorChar + "-";
< c.add(new FilePermission(libPath, "read"));
---
> String cfusionJarPath = this.rootDir + File.separatorChar + "lib" + File.separatorChar + "cfusion.jar";
> c.add(new FilePermission(cfusionJarPath, "read"));
The vulnerable releases assign sandbox read permissions to $CF_ROOT/lib/- , inclusive of all files and subdirectories. This presumably allows processes within the sandbox to read sensitive configuration files in this directory, which could allow for privilege escalation and bootstrapping further access. The patched version only grants read permissions to $CF_ROOT/lib/cfusion.jar, the primary JAR for the ColdFusion runtime environment.
CVE-2012-5675
Here we have another "unspecified vector" for a sandbox bypass. In the patch we can see that a permission object for the
GetPageContext() function has been added in
coldfusion.security.SecurityManager.class:
264a265
> public static final Permission GET_PAGE_CONTEXT = (Permission)new FunctionPermission("getpagecontext");
And a corresponding permissions check has been added in coldfusion.runtime.CFPage.class:
public final NeoPageContext GetPageContext() {
getSecurityService().checkPermission(SecurityManager.GET_PAGE_CONTEXT);
return this.pageContext;
}
I didn't set up a vulnerable environment to reproduce this vulnerability, but I suspect that the issue here is that you can potentially access sensitive values available in the PageContext object, and read files and execute code via
GetPageContext().include() , among other risky behavior.
And To All a Good Night
With that, we're now done with our quick look back at six old vulnerabilities affecting ColdFusion Sandbox Security. Did I miss one? Leave a comment! To my readers -- Merry Christmas, Happy Holidays, and onward to a prosperous New Year!
No comments:
Post a Comment