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

Andrew36147034g3jm

Participant

Ive reattempted my live upgrade this morning with the same issue as yesterday. Applying it via the CFAdmin console results in Core being updated fine BUT the packages flagged by Adobe for update being uninstalled, I'll attach a snip of before and after from CFPM.

I firmly believe this is because of an issue with the bundlesdependency.json file. The installer log shows the version 13 packages being downloaded which I can see in the bundles folder - the .zip and .jar for each one are there. However, the bundles\bundlesdependency.json file has no reference to the version 13 packages in it, even though its date modified timestamp shows its been updated.

Ive tried clearing cache's before running the update, Ive tried deleting the felix-cache folder all with the same result. Plus, Im still having issues browsing to https://cfmodules.adobe.com/bundlesdependency.json and seeing the references to update 13 packages. This is on multiple devices after clearing caches etc. Im in the UK if that makes any difference. The does seem to be a rabbit off with the version of bundlesdependency.json you are offering at the moment.

Lastly, I restored our dev environment to before the update on the 13th (which ran without issue). When I apply the the update to it today it has exactly the same package problems as our Live above.

Ive updated my cfsup case with this mornings finding.

Thanks.

Having exactly the same issue here. If I navigate to https://cfmodules.adobe.com/bundlesdependency.json directly in my browser, I see lots of mentions of "2021.0.13". However, if I do a wget from my server for that same file and look at the contents, there are no mentions of "2021.0.13".

This meant that when doing the update via coldfusion administrator, the main update worked but packages were removed/uninstalled and the CF admin stopped working.

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.

Charlie Arehart

Community Expert

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.

/Charlie (troubleshooter, carehart. org)

M

megha1997

Adobe Employee

@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

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