Community Manager

Question

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

Forum|Forum|1 year ago
March 12, 2024
11 replies
21769 views

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:

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:

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.

This topic has been closed for replies.

Charlie Arehart

Community Expert

Saurav (or others at Adobe), please change the update technote, which has very unfortunate erroneous wording in its introduction of the change regarding implicit scope searching. It says:

Starting with this update, ColdFusion will default to searchimplicitscopes=FALSE and if a variable name is not prefixed with a scope identifier, an error is returned.

That last phrase is NOT true. It's not that ANY unscoped variable will fail.

Instead, it's that an unscoped variable will fail if can ONLY be resolved by one of the scopes now blocked by the change (such as form, url, cookie, and such, which can be modified from outside the request). But if such an unscoped variable CAN be resolved by a scope that's local to the request (like variables, local, arguments, the query scope, and such), then it will NOT error (and does NOT "need" to be scoped, though it can be useful if it is.)

The wording above (on both technotes for CF2023 and 2021) should be changed to NOT say that "if a variable name is not prefixed with a scope identifier, an error is returned". That's not accurate.

/Charlie (troubleshooter, carehart. org)

S

Saurav_Ghosh

Author

Community Manager

Thank you, Charlie. I've made the changes.

Charlie Arehart

Community Expert

Saurav, thanks of course for the quick response. But I'm afraid the word choice is still incorrect. It now says:

Starting with this update, ColdFusion will default to searchimplicitscopes=FALSE and if a variable name is not prefixed with a scope identifier, it can only be resolved by one of the impacted scopes (see below), which can be modified from outside the request.

It's definitely NOT that with the change, the default is that an unscoped variable "can only be resolved by one of the impacted scopes (see below).". It's that they CANNOT., which is what must be conveyed.

And yes, the REASON the change was made is that scopes in that list (including form, url, etc) "can be modified from outside the request".

I realize you want to be succinct. The challenge seems to be in saying things in as few words as possible, yet still accurately.

I'll add that it doesn't help that the searchimplicitscopes attribute (created 8 years ago) was named as it was. The more accurate name might have been searchremotescopes, which might better have conveyed its intent. Even if false, SOME scopes ARE searched "implicitly" (only ones local to a request, like variables, arguments, query, etc). But I realize that name won't be changed. It just adds to the challenge in explaining this new changing of its default.

/Charlie (troubleshooter, carehart. org)

I

Ian2511417122lu

Participant

We have installed ColdFusion 2021 Update 13 from command line (as server cannot access the internet).

The ColdFusion services are running using a service account (XXX). The commands are run from PowerShell running as the service account. We have used this method for the last few updates.

After the installation is completed we see the following warning in the hotfix log:

Move Folder:              Destination: C:\Users\XXX\109052.tmp\dist\cfusion
                          Status: WARNING
                          Additional Notes: WARNING - There was a problem copying C:\Users\XXX\109052.tmp\dist\cfusion

We have done a quick check of the application and CF Admin and it seems to be working but are concerned there may still be an issue. Before running installer, we stop ColdFusion services and IIS website.

What could be causing this warning?

H

hannah18

Adobe Employee

Hi,

If FatalErrors or NonFatalErrors in the hotfix log is 0, the installation is successful. Nothing to worry there.

We will still look into the warning and find the root cause for the same. We will work on fixing that in the upcoming updates.

-Rochelle

A

Adam36099131ak4s

Participating Frequently

Currently, as of 10:13 GMT the URL 'cfmodules.adobe.com/bundlesdependency.json' is missing the update 13 packages. The update of my live system to 13 this morning via CFAdmin applied the core update but none of the packages, it removed the existing packages which have been flagged for update by Adobe. After re-installing the Administrator package via CFPM I noticed it installed version 11 and not 13, this is when I checked the packagesurl and noticed its missing any reference to update 13. This worked fine in my Dev environment on Wednesday (13th). For whatever reason it looks like the online version of bundlesdependency.json is incorrect.

I also noticed when viewing the Update 13 URL from any other region than US (uk for example), the links to the hotfix installer and zip repository go to hotfix version 12.

H

hannah18

Adobe Employee

Hi @Adam36099131ak4s,

I am able to see the update 13 packages in https://cfmodules.adobe.com/bundlesdependency.json

Few things you could check:

1. Was the core update applied successfully? You can check the hotfix logs in <cfhome>/cfusion/hf-updates/hf-2021-00013-330286 for the same.

2. Clearing the browser cache.

3. Delete the felix-cache folder in <cfhome>/bin and restarting server.

Also, when you said you viewed Update 13 URL from UK region which shows hotfix version 12, which url were you specifying? Is it the updates url or packages url?

Thanks,

Rochelle

A

Adam36099131ak4s

Participating Frequently

Hi, earlier I did clear my cache a number of times and tried the URL from other non-CF devices, each time the 13 package updates did not show. Although more recently I have tried again and I was able to see them occasionally, but more often they are still missing when browsing to the URL (and clearing my cache between attempts). Is the URL load balanced by any chance? If so perhaps the json file has been updated on some but not all servers? Can you try clearing your cache and trying again?

This sounds very silimar to the issue Maxwell was having on the 14th. His applications look to have been removed also.

Thanks.

S

Sireex

Participating Frequently

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)

S

Sireex

Participating Frequently

Well, it's working now. I reinstalled the update, and it seems to be working now. Very strange, there were no errors when I checked the update logs.

Charlie Arehart

Community Expert

Sireex, FWIW I'll note that this update (like some, but not all others) includes updates to the underlying modules/packages. As such, we can no longer rely solely on looking at the update's log (within hf-updates) to find issues the update might have caused.

The issue is that the module/package updates are finalized in the first startup of cf that happens AFTER the update. And so we need to look at the cf logs instead, both coldfusion-out.log and coldfusion-error.log, and specifically at the log lines during that first startup after such an update. There you may see that something went amiss related to the pdf package.

Of course, the good news for you is that a reinstall (or perhaps just a cf restart) seems to have solved the problem for you. You might see something tracked about that in the log lines after that next restart.

But maybe you won't. Again, I add this info as a POSSIBLE help, and one which may help still other readers. We have a lot of balls to juggle in managing a cf server, and sometimes they slip in oddly-sized ones--or even a milk jug instead. But juggle them we need to, as the show must go on. 🙂

/Charlie (troubleshooter, carehart. org)

S

Sergei L.

Participant

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.

M

megha1997

Adobe Employee

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

Community Expert

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

/Charlie (troubleshooter, carehart. org)

DevScreen

Inspiring

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!

H

hannah18

Adobe Employee

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

DevScreen

Inspiring

Thank you!

DevScreen

Inspiring

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

Community Expert

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.

/Charlie (troubleshooter, carehart. org)

DevScreen

Inspiring

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

S

Sergei L.

Participant

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

M

megha1997

Adobe Employee

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

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

S

Sergei L.

Participant

@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?

Charlie Arehart

Community Expert

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.

/Charlie (troubleshooter, carehart. org)

S

Saurav_Ghosh

Author

Community Manager

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

S

sdsinc_pmascari

Legend

I feel some better explanation of the scope change is needed. Are we now required to scope all variables, even those declared in the same script? Realizing scoping is best practice, many may have some older code that lacks some variable scopes.

For instance, will the following code throw an error when searchimplicitscopes=FALSE?

<cfoutput>
<cfloop from="1" to="5" index="i">
    #i#
</cfloop>
</cfoutput>

If the above code errors, does the above code need be rewritten to be?

<cfoutput>
<cfloop from="1" to="5" index="i">
    #variables.i#
</cfloop>
</cfoutput>

Charlie Arehart

Community Expert

Paul (sdsinc_pmascari, and everyone else who will of course be quite concerned about this change), I can report that:

that code runs fine even after the update. No need to add the variables scope there
better still: you need not wait for applying this update to determine such things. The searchimplicitscopes was added as an app-level configurable setting in CF2016.
- So one could create a test app in which they set this.searchimplicitscopes=false in your application.cfc (or add searchimplicitscopes=false as an attribute to cfapplication in application.cfm), and then test such code
- Or of course, just change it in their existing apps to test its impact on their apps
Here is just one example of some code that DOES fail, as of the change:
- ```
<cfset url.test=1>
<cfoutput>#test#</cfoutput>
```
- I've never found any good single resource that clarifies what will and won't fail per the change (of that app setting, let alone this change today of its default)
Most important: changing that searchimplicitscopes to true (in your application or per that new jvm arg) will revert the behavior, before or after today's update

/Charlie (troubleshooter, carehart. org)

Charlie Arehart

Community Expert

OK, I can add more clarity on the implicit search matter.

Sadly, neither of the two pages linked to in the release notes clarify it as well as they could (neither this one about variable scopes nor the other one about application variables). But instead this one on the cfapplication tag does better. As it notes about the searchimplicitscopes (from when it was added in CF2016):

This attribute covers look-up in the following implicit scopes:

CGI

URL

Form

Cookie

File

Client

So that's why it does NOT affect CF code finding a variable in the variables scope (like shown in Paul's example above) but DOES affect finding the URL scope in the example I showed.

That may still leave questions, so I can also confirm that having searchimplicitscopes set to false (or off) does NOT affect code:

referring to "unscoped" query column names within a query loop
referring to "unscoped" variable names which were defined using var (or the local scope) within a CFC method or UDF
referring to "unscoped" variable names which were themselves created without any scope in a CFC method or UDF (which end up in the variables scope)
referring to "unscoped" variable names of arguments in a CFC method or UDF

As I/the community may gather more/refine knowledge on this, I hope to come back and update this comment. In the meantime, hope it's helpful.

Bottom line: if you have code that has unscoped variables where the variable is found (implicitly) in the above-named scopes (CGI, URL, form, cookie, file/cffile, client), you will need to attend to this matter with either of the 3 approaches in my first comment.

/Charlie (troubleshooter, carehart. org)

Show more replies

Sign up

To post, reply, or follow discussions, please sign in with your Adobe ID.

Sign in to Adobe Community

To post, reply, or follow discussions, please sign in with your Adobe ID.

Scanning file for viruses.

This file cannot be downloaded