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

[Saurav_Ghosh]

Update (6/12):

• Minor edits in the default algorithm section.
• Added links to Docker images.

Update (6/13):

• CFFiddle is updated with the updates.
• Removed extra space in -Dcoldfusion.encryption.useCFMX_COMPATAsDefault=TRUE

Update (6/21):

• Changed the checksum of the CF 2023 packages. Thank you @Legorol 

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

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-41.

Where do I download the updates from

Download the updates from the following locations:

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

What do these updates contain

Change in default algorithm

• The default encryption algorithm in ColdFusion changes from CFMX_COMPAT to another algorithm for seven encryption functions. 
• Use the new JVM argument -Dcoldfusion.encryption.useCFMX_COMPATAsDefault=TRUE to revert the change. By default, the value is False,
• The flag -Dcoldfusion.encryption.useCFMX_COMPATAsDefault will be supported in future security updates for the 2023 and 2021 releases of Adobe ColdFusion.

CFdocument access control issues

We've introduced a new JVM flag: -Dcfdocument.metahttpequivrefresh.localfile=TRUE. This flag allows you to call the URL or location passed in the HTML meta tag. By default, the value is FALSE.

However, in the next major release of ColdFusion, we WILL remove the flag.

Package updates

The following packages have been updated:

• document
• htmltopdf
• presentation
• pdf
• print
• report

Solr upgrade

If you manually upgraded Solr to version 8.11.2 using the instructions in Upgrade SOLR to mitigate security risks in ColdFusion, then after installing Update 8, SOLR will not downgrade to version 7.9.

For more information, view the following tech notes:

• ColdFusion (2023 release) Update 8
• ColdFusion (2021 release) Update 14

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.

[Saurav_Ghosh]

Thank you, Charlie and Charles. I've made the changes. Never realized an extra space could cause havoc! Thanks once again.

[Charlie Arehart]

Thanks, Saurav.

And yep, it's especially unfortunate that such a simple mistake (that anyone could make in editing their jvm.config also) would not only keep CF from starting, but when CF is run as a Windows service there is no info shown about the error in that services UI, nor any useful detail in the Windows Event Logs, and there's no info at all in the coldfusion-out.log or coldfusion-error.log. One only sees the actual error details if they think to start CF from the command line (such as using the cfstart script in CF's cfusion/bin).

[default8vn6shtsmayn]

Running on Windows 2019 with CF2021 Update 13, running Java 11.0.22.
Install from fadmin reports failure. 
Manual install
<jdk>\bin\java.exe -Djdk.util.zip.disableZip64ExtraFieldValidation=true -jar E:\ColdFusion\bundles\updateinstallers\hotfix-014-330296.jar
install fails with:
Error: Could not find or load main class .util.zip.disableZip64ExtraFieldValidation=true
Caused by: java.lang.ClassNotFoundException: /util/zip/disableZip64ExtraFieldValidation=true

[hannah18]

@default8vn6shtsmayn Does your setup have lockdown installed? Also, Can you please check and send the update installation logs for any errors? 

Location : <cfhome>/hf-updates\hf-2021-00014-330296

[default8vn6shtsmayn]

Yes, we tried to hew to the CF2021 Hardening Guide as closely as we could.
Log file is below.

[Charlie Arehart]

Again, to be clear the error was not related to lockdown. See the comment below, to which default8vn6shtsmayn has since replied. (Just offering this for those who see this thread before that one.) 

[Charlie Arehart]

default8vn6shtsmayn, I can explain the problem you're seeing and can offer a solution. I also offer a bit more to try to clear away confusion many may have about this zip argument.

1) First, the only way you'd get that error is if you ran the command line in a way that misled Java to think that the program it was to run was indeed that .util.zip.disableZip64ExtraFieldValidation=true (note the missing -Djdk in front of it) which was mentioned in the error. For instance, if you mistakenly ran the command (using your nomenclature) as either of these, you'd get that error:

<jdk>\bin\java.exe -Djdk .util.zip.disableZip64ExtraFieldValidation=true -jar E:\ColdFusion\bundles\updateinstallers\hotfix-014-330296.jar

or

<jdk>\bin\java.exe .util.zip.disableZip64ExtraFieldValidation=true -jar E:\ColdFusion\bundles\updateinstallers\hotfix-014-330296.jar

Note how the first case shows you could have mistakenly put a space between the -Djdk and the rest of the .util.zip... In the second case, you could have somehow simply forgot to include that -Djdk in front of it. As you note in your comment, the correct way (for you, in your setup with CF on the E drive in a folder called ColdFusion) is:

<jdk>\bin\java.exe -Djdk.util.zip.disableZip64ExtraFieldValidation=true -jar E:\ColdFusion\bundles\updateinstallers\hotfix-014-330296.jar

Let us know if you may confirm this. And while you could just run the final command to get the update in place, I hope you'll take a moment to try either of the first two variations, to see that indeed they lead to the error you reported here.

2) Second, to be clear, this jvm arg related to zip validation is ONLY needed for those who are a) on CF2021 AND running Java 11.0.20 or higher AND coming from earlier than CF2021 update 12, or b) on CF2023 AND running Java 17.0.8 or higher AND coming from earlier than CF2023 update 6. (A change in those CF updates from Nov 2023 fixed the need to use this arg, as was mentioned briefly only in the preceding technotes for update 11 and 5, respectively.)

3) Note also that the NEED to run the CF update from the command line (vs the CF Admin), which started after one would move to those JVM updates I just listed (which came out in July 2023), has now also been lifted once one moved to beyond the CF updates I just listed (from Nov 2023).  You CAN go back to running the CF updates from the CF Admin, without worry about this JVM zip issue. That said, some people may still have OTHER reasons to prefer or need to run the CF updates from the command line.

I just mention this because you said you had some "failure" in doing the update from the CF admin. Again, if you WERE on CF2021 update 11 or earlier before doing this update (or if one is on CF2023 update 5 or earlier before doing this latest update), then again you DO NEED to do the update from the command line--at least until you get to or past that update 12 (or update 6 on CF2023).

4) Finally, though both the most recent CF update technotes (8 and 14, respectively) say regarding this zip argument that "if you are applying the update from the Administrator, you do not require any flag", I can confirm that you also do not "require any flag" if running this update from the command line, again as long as you are starting from either CF2023 update 6 or CF2021 update 12, which resolved the problem.

This was all a very unfortunate cause of confusion this past year--caused initially by Oracle not Adobe--and it may go on for a while as people deal with it, coming from different CF updates and having different JVM versions.

Hope this gets you going and perhaps helps others who see this. (No need to mark this as "an answer", since it would only be an answer to your comment, not an answer to the topic of the blog post.)

[default8vn6shtsmayn]

Howdy,

We'll go back and check our command line invocation. Thanks for the help!

[Legorol]

The US version of the ColdFusion 2023 updates page (https://helpx.adobe.com/coldfusion/kb/coldfusion-2023-updates.html) shows an incorrect MD5 checksum for the hotfix file on this line:

  File: ColdFusion (2023 release) Update 8 (MD5: b83e37a682f02ad9ba8e4cfddb32b13)

Note how the MD5 has 31 characters instead of 32.

However, the UK version of the same page (https://helpx.adobe.com/uk/coldfusion/kb/coldfusion-2023-updates.html) shows the correct checksum:

  File: ColdFusion (2023 release) Update 8 (MD5: eb83e37a682f02ad9ba8e4cfddb32b13)

Note the "e" at the beginning of the checksum.

Could you please correct the US page?

[Legorol]

The editor included the closing bracket in the US link. The correct US link is:

https://helpx.adobe.com/coldfusion/kb/coldfusion-2023-updates.html

[Legorol]

Actually things are even worse. The two pages have different MD5 checksums for the package repository.

US: Hotfix and packages repository: Link (MD5: 0a643cc62929976f6cc880ed2c3ccbf5)
UK: Hotfix and packages repository: Link (MD5: 0fd13166f31a19d3fda5f4302855794c)

and both links are the same:

https://cfdownload.adobe.com/pub/adobe/coldfusion/2023/packages/hotfix-packages-cf2023-008-330668.zi...

Can you please fix the MD5 checksums on these pages, and can you please take more care about these matters in general? This is not the first time that the posted MD5s are wrong. As these MD5s are meant to be the way to verify the integrity of the downloads, it is quite disconcerting that the wrong values are getting posted.

[Saurav_Ghosh]

Thank you for raising this. We have fixed the checksum issues. Due to a localization glitch, the UK page displays incorrect MD5. It should be fixed by tomorrow.

[Legorol]

Saurav, I rechecked the download pages, and something weird happened.

On the US download page (https://helpx.adobe.com/coldfusion/kb/coldfusion-2023-updates.html) the checksum for the repository download has changed, and indeed the file itself has changed significantly. It now shows:

  Hotfix and packages repository: Link (MD5: 1b2c8711197f932a994b5280492ccb7d)

The new checksum is correct. The downloaded file (hotfix-packages-cf2023-008-330668.zip) is now  significantly bigger than what it was a couple of days ago.

What changed? And if you have changed the download like this, could you please put an update notice on the page pointing out that it has changed and what date it has changed on? Someone who downloaded it earlier wouldn't otherwise know that they should redownload it.

[Saurav_Ghosh]

Thank you for pointing this out. Added the change at the beginning of the post.

[Legorol]

@Saurav_Ghosh thanks for the update to the post here on the forum, but that is not what I meant.

The hotfix and package repository file (hotfix-packages-cf2023-008-330668.zip) itself has changed over the last few days, so I now have two different copies of it. The first one is about 430 Mb in size and has MD5 checksum 0a643cc62929976f6cc880ed2c3ccbf5, the second one (currently available for download) is 660 Mb with checksum 1b2c8711197f932a994b5280492ccb7d.

What I was asking is, what changed in the content of the file?

[Priyank Shrivastava.]

@Legorol  You are right, we updated the packages as there was some issue while uploading them and it got corrupted. You can use the 660 MB package for your server update.

[Hiding on the Backstreets]

I updated to ColdFusion (2021 release) Update 14 from Update 13 and now most, but not all, of my Scheduled Tasks are missing. Plus, when I check the Scheduler log to see what has actually run, besides confirming that most of my tasks haven't run, I see that the daily default task to check for new CF updates hasn't run.

When I check the update log to see what files were modified, it doesn't report modifying neo-cron.xml. However, the neo-cron.xml file, and the backup, are showing a modified datestamp the same as the date I did the update.

This is the Standard Edition running on Windows Server 2019.

[Charlie Arehart]

While I've not seen or heard of that problem in any of the many (dozens) of updates from cf2021 u13 to 14 I've been a party to, I'll offer this.

First, the date modified of that neo-cron.xml (and the creation of a .bak file for it) does happen far more often that most would expect. So I'm not sure I'd put much stock in that having been modified at the time of the update. (And sadly only one bak is created. Both of those are issues for which I've created bug reports/feature requests in the past.)

Second, if the update did truly change the file, it should be reflected in a copy of it being kept in the backups/lib folder under the folder created for your update 14 in the cfusion/hf-updates folder. Do you see one? If so, you could copy that back in place in the cfusion/lib folder (I'd make a copy of the current one first, not relying on the .bak, which is overwritten on any change that Cf causes.)

If you have no such file in the update's backups folder, then you'll need to recover a good working file from any other backups you take on the server. 

Let's hear what you or others may say on this. 

[Hiding on the Backstreets]

Thank you for such a quick reply. There was no neo-cron.xml in the update backup folder. I was only missing about 15 tasks, so for me the easiest thing to do in this case was just recreate them. However, I am concerned that it's no longer checking for CF updates. I'd love to be able to recreate or restore that task.

[Charlie Arehart]

Good news on that: you can restore that task you're asking about. 

It's created by you (or someone) going to that Cf admin package manager page, then choosing "settings" at the top, then checking the option to get notified by email about new updates ("check for updates every").

To be clear, the first setting on that page, labeled "automatically check for updates", is the feature which causes cf to check for updates on each login to the admin, which is the far more typical way most keep an eye on updates. That option is asked about during install of cf, while the other option is never noticed by most people. So again the scheduled you refer to (called "CHECK FOR COLDFUSION UPDATES") is created by cf ONLY if one enables that "notification" option.

See also the comment I was writing about the same time you replied to my first response here, especially if you may still find tasks not to be running. 

[Charlie Arehart]

Looking at the problem a different way, are ANY tasks running since the update? If not, then it's possible that what's happened is that the update (or something, perhaps related to it) has instead REMOVED THE SCHEDULER PACKAGE from cf. That would also keep tasks from running. 

As you may know, since cf2021, cf is now modular with about 50 packages controlling nearly all aspects of cf. Some packages get updated when cf itself is updated. And actually, it's on the restart which takes place AFTER that update where updated packages are un-installed and then installed as new versions.

You should look first at the cf admin "package manager" page (used to perform updates in the cf admin), to see if "scheduler" is listed under either the "installed packages " or "available packages" sections of that page. If un-installed, try installing it, from right there.

(Note as well that packages can be viewed, updated, added, or removed also via the cfpm command line tool that was also added in cf2021.)

Let us know how this goes. I'd try it before what I shared earlier today. 

[Hiding on the Backstreets]

Thank you again!

Regarding the check-for-updates task, I was able to recreate it as you suggested. I'd completely forgotten about that setting. Interestingly, the box for "Check every..." was already checked. So I unchecked it, submitted the form, then checked it and submitted the form again, and then the task showed up in Scheduled Tasks. I feel much better now.

As to your question/suggestion about the Scheduler package being missing, that wasn't the case. There were still two running tasks in the list, which were in fact running, plus three paused tasks. But about 15 tasks were missing.

Thank you again for all the help.

[Charlie Arehart]

Thanks for the update. The only question remaining then would have been the state of the neo-cron.xml when you first found the problem: was it there or not, missing tasks if there, or somehow corrupted? Since you just manually recreated the tasks, we won't likely know the answer. But I realize that was the easier solution for you at the time. 

At least we have record now of your experiencing this, should something like it happen to someone else. Again, I'd not heard of this update having any such effect on tasks, but time will tell.