Recently, I found that one of Adobe ColdFusion’s patches (APSB11-29) doesn’t resolve a cross-site scripting (XSS) vulnerability completely. In a specific case, the vulnerability can be replayed. This can be exploited to execute arbitrary HTML and script code in a user’s browser session in the context of a vulnerable site. Adobe has updated its advisory to warn users about this potential risk.
From the advisory APSB11-29, we can see that Adobe fixed a cross-site scripting vulnerability in the CFForm tag (CVE-2011-2463). And, as you know, Adobe ColdFusion Server is based on Java. So, in this article, I’ll analyze the patch with a Java decompiler tool to reveal the issue and the potential risk in the patch itself. Now let’s go further into it.
One Feature of the CFForm Tag
In ColdFusion, the tag “cfform” is used to build a form with CFML custom control tags to provide more functionality than standard HTML form input elements. It also has an “action” attribute like a common html form tag to present the name of the ColdFusion page to execute when the form is submitted for processing. A special feature here is that if you omit this attribute and the “method” attribute is GET, the form posts to the page identified by the CGI.SCRIPT_NAME variable, which contains the requested page that resulted in displaying the form. If the “method” attribute is POST, the form posts to the page identified by the CGI.QUERY_STRING variables. This means if the developer doesn’t set an “action” attribute, or sets it with an empty value for a form, then the ColdFusion Server will generate it automatically.
The mentioned feature is flexible, but created a cross-site scripting vulnerability. The patch in APSB11-29 fixed it, but not completely. Now let’s analyze the patch.
I installed Adobe ColdFusion 9.0 on Windows for testing. The patch for the issue is “hf900-000004.jar”. Open it with Java Decompiler and we can see what this patch is meant to do, including package and class information. Since this Adobe ColdFusion patch is a cumulative hotfix, many of the changes are only relevant to past vulnerabilities. We will only focus on the CFForm tag issue mentioned in APSB11-29. From Fig.1, we see one class that seems to be relevant to the “cfform” tag, it is called “FormTag” in package “coldfusion.tagext.html.form”.
Yes, it does modify the code in cfusion.jar. Using WinMerge, we can compare the modification with the old code. We will see the following difference:
The content at left is the patched code, at right, the old code. Now we see the weak code. Once ColdFusion Server finds the form’s “action” attribute is empty or has a length of zero, then it will add an “action” attribute to that form.
For testing, we deploy a file called “XSS.cfm” in ColdFusion Server with the following content:
<cfform action="" method="POST"> <cfinput type="text"required="yes" name="filename"/> <cfinput type="submit"value="Submit" name="fileQuery" /> </cfform>
Note: you may also omit the “action” attribute on line 1.
Then we can access the page at the following URL:
And we will receive the following generated HTML code:
<form name="CFForm_1" id="CFForm_1" action="/XSS.cfm" method="POST" onsubmit="return _CF_checkCFForm_1(this)"> <input name="filename" id="filename" type="text" /> <input name="fileQuery" id="fileQuery" type="submit" value="Submit" /> </form>
So ColdFusion Server has added the value “/XSS.cfm” to the “action” attribute. This behavior is very dangerous. The XSS vulnerability will appear if you use the URL below:
The result would be:
And the generated HTML code is:
<form name="CFForm_1" id="CFForm_1" action="/XSS.cfm?filename="> <script>alert('QUALYS_XSS')</script>" method="POST" onsubmit="return _CF_checkCFForm_1(this)"> <input name="filename" id="filename" type="text" /> <input name="fileQuery" id="fileQuery" type="submit" value="Submit" /> </form>
As you see, the malicious code is directly injected into the page by Adobe ColdFusion Server and executed.
Now, let’s turn to the patched code. In Fig.2, we could see that before generating the attribute, it uses a variable called “generateFormAction” to do a condition judgment. The called function “populateAction” just does the same thing as the old code at right with it’s background colored yellow. From the definition of class FormTag, we know that the variable “generateFormAction” is set to “false” by default. See it in Java Decompiler again.
So, the intention of the patch is obvious: to disable the feature of autogenerating an “action” attribute for a form tag which doesn’t define it or defines it with an empty value. So, the cross-site scripting vulnerability seems to be fixed, meanwhile, that feature gets used less.
Unfortunately,the XSS could come back again. The key point here is whether it’s possible to set the variable to “true”. And the answer is “yes”. See the comparing result:
The value of variable “generateFormAction” is determined by another variable called “GENERATE_FORMACTION”, which has a default value of “coldfusion.generateformaction”. Generally, “generateFormAction” is initialized to “false” by Boolean.getBoolean(“coldfusion.generateformaction”). However, the function will return “true” if a user sets “-Dcoldfusion.generateformaction=true” in the JVM arguments and restarts the ColdFusion Server.
If so, the patched code would not take effect to protect applications, and the feature of generating the “action” attribute would be enabled again. As a result, the XSS vulnerability would be replayed and users would be at risk.
Adobe has updated its advisory to warn this potential risk on ColdFusion 9.0.1, 9.0, 8.0.1 and 8.0 for Windows, Macintosh and UNIX. It recommends that developers always specify an action attribute for the CFFORM tag, and also prompts the risk if user set “-Dcoldfusion.generateformaction=true” in JVM arguments. Adobe ColdFusion users can refer to APSB11-29 to obtain the updated information.