NOW LIVE! Adobe ColdFusion 2023 and 2021 March 2024 security updates

[Saurav_Ghosh]

Revision history

• 13 Mar 2024: Added the impacted scopes and related code samples to both the tech notes.
• 14 Mar 2024: Add the Docker image locations of the updates.

We are pleased to announce that we have released security updates to ColdFusion (2023 release) Update 7 and ColdFusion (2021 release) Update 13.

This update includes several security fixes to ensure the safety and security of our systems. These changes address potential vulnerabilities and threats and are part of our ongoing commitment to protecting your data and privacy.

For more information, view the security bulletin,  APSB24-14.

Where do I download the updates from

Download the updates from the following locations:

• ColdFusion (2023 release) Updates
• ColdFusion (2021 release) Updates

These updates address some significant changes in variable scope and cfdocument. In addition, we've updated a few libraries and packages.

For more information, view the following tech notes:

• ColdFusion (2023 release) Update 7
• ColdFusion (2021 release) Update 13

Are the Docker images available

The images are available on the Docker hub and ECR.

Please update your ColdFusion versions and provide us with your valuable feedback.

[Charlie Arehart]

Saurav, thanks for that update to the technotes today, with the key affected scopes and code sample. For any wanting more clarification, see the comments in this thread from yesterday.

I'd also done a blog post last night sharing similar info and more, for any interested.

[Saurav_Ghosh]

Thank you, Charlie. We wanted to add more context to the change.

[Sergei L.]

The hash for Update 7 at the link below does not seem to match the JAR file.  Is the file still good to use?

• ColdFusion (2023 release) Updates

[megha1997]

@Sergei L. This is the correct checksum - 2b0f5588a81851f1e7bf874dd60bae8e

We are getting this updated in ColdFusion (2023 release) Updates

[Sergei L.]

@megha1997 Thank you.  Anther question: hotfix-packages-cf2023-007-330663.zip contains updateinstallers/hotfix-007-330658.jar.  Is that intentional or should it have been replaced with the latest 007-330663. jar?

[megha1997]

This is not intentional. It is being corrected to have the correct jar (007-330663.jar). Thanks for pointing this out

[DevScreen]

This makes <cfparam> much less useful if using with FORM and URL scope.  For example, <cfparam name="step" default="1">  Then mypage.cfm?step=2 would have changed that "step" to 2 automatically, but not anymore.  Now you need to add <cfif isDefined("url.step")><cfset step=url.step></cfif>   So what is the need for <cfparam> in this case after this update?  I could have <cfset step=1>  instead and have the same effective with isDefined() check.   This change takes away my main use for <cfparam>.  

[Charlie Arehart]

Devscreen, your cfparam will still work: you simply need to use name="url.step", which is also beneficial to anyone viewing your code. Of course, subsequent references to step need also to be changed to url.step, but if you're already doing that I'm saying this one cfparam line is all that needs to change, not your logic. 

[DevScreen]

Thanks Charlie.  I will definitely look into using name="url.step".

[DevScreen]

I noted that updating your JVM file is one of the solutions but will be deprecated in the next major release.  How about updating the application.CFC file?  Will that CFC fix continue to work in the next major release?  We have a lot of code that will need updating and maybe done by next release, but it would still be nice to know if Application.cfc change will continue to work.  Thanks!

[hannah18]

@DevScreen Yes. The application.cfc workaround will continue to work with the next release.

[DevScreen]

Thank you!

[Sergei L.]

Saurav, Can you tell us if Adobe support discourage us from using the flag -Dcoldfusion.searchimplicitscopes=true (whether in the application scope or in the JVM) because doing so will negate Adobe's fix for CVE-2024-20767 "Arbitrary file system read" (re-opening that vulnerability) or will only make code not compatible with future CF versions?

This is in reference to footnote at ColdFusion (2023 release) Update 7 (adobe.com) which reads *This option is highly discouraged and should be considered only as a temporary workaround, until all application code is fixed.

[Charlie Arehart]

slysenko, while you await an answer from Adobe, let me note that adding that jvm arg will NOT "make code not compatible with future CF versions". You've misread things (but you're not alone).

It's that the arg will not DO ANYTHING in the next release.. It will be ignored. The change of searchimplicitscopes defaulting to false will remain, but you will not be able to use this jvm arg to override that.

You WILL still be able to use the application level configuration of searchimplicitscopes to control any individual app. 

And as for the note saying that setting true for either is discouraged (a note newly added by them overnight), that's telling folks that the whole point of the change is to prevent code (using unscoped variables) from finding resolution (implicitly searching) unexpectedly in those scopes which are now also listed in the technote (or in my comment here yesterday).

So yes, people CAN use either approach to change the default TO ALLOW that implicit searching, but they SHOULD NOT, for the sake of security. They should INSTEAD change their code--where unscoped variables could resolve to such scopes, so that they NAME the scope in which the variable should be found.

Again, it's NOT that ALL unscoped variables need to be changed.  See my comments here from yesterday or my blog post. 

Hope that helps. But again, ensure, let's hear what Adobe may have to say. 

[megha1997]

@Sergei L. By "*This option is highly discouraged and should be considered only as a temporary workaround, until all application code is fixed." we mean this - Implicit searching of unscoped variables (list of affected scopes is added in the technote) poses a significant threat, and due to the internally discovered vulnerabilities associated with it, we have set this to false by default. As this is a major change that could break existing code, the jvm flag/setting to true at application level will aid in easing into the fix.

This is "highly discouraged" as the fix will be reverted while you are setting it to true, which we do not recommend from security standpoint, and this is "temporary" as the jvm flag will be removed in the next release and would no longer have the capability to revert the fix

[DevScreen]

@megha1997 Can doing below be considered safe?

<cfparam name ="step" default="">

<cfif isDefined("form.step")>
<cfset step=form.step>
</cfif>

<cfif isDefined("url.step")>
<cfset step=url.step>
</cfif>

Doing that will greatly help fix our code faster. But does that still pose significant threat? Or is it acceptable?

[DevScreen]

@Charlie Arehart Do you have any input on the above workaround I posted? Thanks!

[Charlie Arehart]

There's absolutely nothing I can see to be concerned about with that code. What is your fear? I sincerely want to understand how people are taking in what's being said.

Do you fear some line there is "vulnerable"? Which one? Line 1? And what is the vulnerability you fear? Or what compatibility issue?

Is that you feel it's somehow vulnerable to have any unscoped variable, after the update, with searchimplicitscooes false? No. You're less vulnerable. Cf can't look to resolve that line 1 check for step in any of those scopes which can be populated "from the outside", as it were, such as cookie. Before the update, or with searchimplicitscopes true, it could. 

[DevScreen]

Thanks for your input. The only reason I thought of that is because before this update, CFPARAM did exactly what my logic is doing - if Form or URL scope exists, then the cfparam variable will be assigned that value. So by replicating that same behavior, instead of adding scope everywhere, I wondered if I am still continuing the said unsafe behavior.   If I just do those isDefined checks, then I don't need to add scope to the rest of my code and everything will just work. And I wondered if that's an OK way to proceed.

[megha1997]

@DevScreen The code you added looks good to me. 

[DevScreen]

Thanks Megha!

[EddieLotter]

A further refinement, that I would recommend, is to use StructKeyExists() rather than isDefined().

[megha1997]

As there seems to be confusion around the CVE that is shown in the ColdFusion Security Bulletin (https://helpx.adobe.com/security/products/coldfusion/apsb24-14.html), I would like to clarify this - The Scope vulnerability was internally identified, and hence, does not contain a CVE and cannot be disclosed. CVEs are only present for those vulnerabilities that are publicly disclosed. The vulnerability "Arbitrary file system read" that you see in the bulletin is different from the one in Implicit searching of unscoped variables.

[Charlie Arehart]

Thanks very much for that clarification. There is indeed a lot of confusion on this and other matters related to this significant update. 

[Sireex]

We are testing Update 13 and it seems that cfhtmltopdf has changed or is broken in this release. We are generating receipts for our customers, and this no longer works, still worked ok with Update 12.

Now we get this error (partial log from coldfusion-error.log):

SEVERE: Servlet.service() for servlet [CfmServlet] in context with path [] threw exception [ROOT CAUSE:
coldfusion.runtime.EventHandlerException: Event handler exception.

Caused by: java.lang.NoClassDefFoundError: coldfusion/image/Image
at coldfusion.pdf.PDFServiceImpl.applyExtraAttributesForWebkit(PDFServiceImpl.java:172)
at coldfusion.tagext.htmltopdf.HtmlToPdfTag.applyExtraAttributesForWebkit(HtmlToPdfTag.java:1351)
at coldfusion.tagext.htmltopdf.HtmlToPdfTag.handlePDFgConversionRequest(HtmlToPdfTag.java:1316)
at coldfusion.tagext.htmltopdf.HtmlToPdfTag.convertToPDF(HtmlToPdfTag.java:1236)
at coldfusion.tagext.htmltopdf.HtmlToPdfTag.doEndTag(HtmlToPdfTag.java:1414)