[Looking for Charlie's main web site?]

ColdFusion updates for CF2023 and CF2021 released Aug 17 2023: resources and thoughts

Adobe has released today an important security update for each of ColdFusion 2023 and 2021. (Since CF2018 is end of life since July, there is no update for that version.) Note that while the technotes for the updates don't mention/link to any Adobe product security bulletin (APSB), this update is indeed an update that provides important security protections, as I discuss further below.

For more resources as well as some additional thoughts on the updates (including what security matter it entails as well as some lessons learned in applying the update--especially if you may update your Java to the JVM released last month), read on.

(FWIW, I posted messages on social media first thing this morning when I woke to the news that these updates had been released. I didn't post this blog entry until several hours later, as I wanted to see how things sorted out as I and others proceeded with implementing the update.)

Resources for more on each update

As for resources on the update, note that there were two announcements about it, each of which already have some commentary from myself and others:

And both of those point readers to the technotes for each update:

While most people may be satisfied with the information above, there are some other matters related to the update that I wanted to share.

The security aspect of these Aug 2023 CF updates

As I noted at the outset, you could be forgiven for not seeing these updates as being especially important, since the technotes make no mention of any related Adobe product security bulletin (APSB) that this update addresses. But again it is an update that provides important security protections. Even the blog post and support forum thread don't convey much (which has led to some questions on the latter).

While the technotes for each update offer a bit more, some readers may still not quite understand what's going on with this update. All this relates to the spate of vulnerabilities found and fixed in the July CF updates, where bad actors were sending in specially crafted http requests into CF, in such a way that a long-existing wddx-deserialization feature allows those requests to perform operations that made CF very vulnerable to attack.

And whereas those July updates closed the door on attacks of this sort that were very specific, my understanding of the intention of this update is to implement a new form of protection by instead blocking all incoming wddx-based deserialization requests unless they involve only a very limited set of whitelisted underlying java classes. These are listed in the newly provided cfserialfilter.txt file (which is now found in the cfusion/lib folder--or [instancename]\lib--alongside the serialfilter.txt file which has existed at least since CF11.

While the technote does not show it, here are the contents of that cfserialfilter.txt file, as implemented by this update:

java.util.Locale;java.util.Collections$EmptySet;java.util.HashMap;
The update technotes indicate how one can add new classes to that list, if you have need to allow them to be deserialized. It also indicates an available wddx.log file (in the CF logs folder) that will report when some java classes will be blocked on attempts to deserialize them this way. And though it also offers a means to indicate classes to be BLOCKED, the implication of the rest of the update seems to be that classes NOT in the list can NOT be deserialized--though this is not stated explicitly in the technote as of this writing. (I'd love if it Adobe might clarify that, here, there or anywhere.)

At least one thing they HAVE done is offer a bit more clarification in an extended comment today by CF Evangelist Mark Takata on the CFML Slack channel, as quoted today in an email from Pete Freitag's wonderful HackMyCF service (which I discuss further below):

"This update is a proactive fix for our supported versions which locks out future potential vectors for exploitation of CF. Basically we fixed [in July] the security issues that came up in a targeted fashion when they arrived. But then we spent a great deal of time with internal Adobe security people (not just in CF) to think of the potential for future-proofing (as best we can) the generalized ways CF could be exploited, as it related to that smattering of bugs earlier.

This fix is a hardening, not a repair. It should also be noted that, due to the wide-ranging potential effects this work might have, we enlisted the help of several trusted community members to test the work on real workloads prior to releasing it into the wild. I want to thank those customers and community partners for their hard work in making sure this update did not negatively affect performance or introduce any bugs. You folks know who you are and we appreciate you." https://cfml.linen.dev/t/14154059/so-regarding-the-new-update-i-wanted-to-clarify-something-be#49269a03-90e7-410a-bc4b-4226d413fdc7

Before leaving this topic of the security aspect of this update, I want to add that some folks have been confused about the wording in the update technotes and Adobe's posts regarding this mention of wddx, as some folks use the very old CFWDDX tag (and related features) to manage serializing/deserializing CFML objects into and out of WDDX-formatted XML. To be clear, this new security control mechanism is unrelated to such CFWDDX processing of CFML objects. Again, it's focused on a far less-commonly used aspect of deserializing incoming http requests, formatted in a specially crafted way.

As is often the case with security matters, there's not much more detail being shared, lest it be used by bad actors to evolve their attacks.

One last thing related to all this: on the Adobe CF community forum thread, a suggestion was offered by another CF community security maven, Brian Reilly, wondering whether Adobe should instead just recommend people block ALL incoming HTTP requests for CFCs, at least for those who don't use them for intentional purposes such as APIs, since those have been anotehr key aspect to the payload delivery for these wddx-deserialization vulnerabilities. See a subsequent couple of comments that I and he offered there, if this topic interests you.

Beware a problem installing this or any CF update, using the JVM update released in July 203

If you may update your JVM to the update released by Oracle last month (as I blogged about then), read on for a negative impact you will experience trying to install the update (and what you can do to work around it).

Just a few days after the release of that JVM update, I shared news of a new problem for those using it with CF, affecting first the ability to download and then the ability to install CF updates--again, if using that updated JVM.

Good news: CF update download in the Admin now works, with the new JVM

First some good news: as I explained in that second post, those who obtained that July Java update (Java 11.0.20 for use with CF2021, 17.0.8 for use with CF2023) and configured CF to use it found that if they then tried to download the CF updates via the CF Admin, the download would fail. I offered a workaround of a JVM arg that Oracle provided with that July update, which WOULD then allow the CF Admin download of CF updates to work.

Well, the "good news" is that I've confirmed Adobe did something so that the special JVM argument is no longer needed to download the CF updates successfully from the CF Admin. Yay.

Bad news: installing CF update still fails, with the new JVM

But sadly the bad news remains (and it's quite bad): installing a CF update will fail if using that updated JVM--and this is whether you use the CF admin to do the install or use the command line (java -jar command).

Sadly, you may find that the install "seems to work" but then something's wrong: you may find that the CF update/packages page will be blank, or if you look closely you may find that there are both fatalerrors and nonfatalerrors in the CF update log (note that I did a blog post some years ago on how to find and understand errors reported in that CF update log file).

There ARE workarounds for this problem, also:

  • If you are trying to use the CF Admin updates page, you simply won't be able to install the update, as long as you are using this new JVM. Adding the JVM arg (I discuss in the July blog post) to CF will NOT fix the problem--because when you click the update button in the Admin, it kicks off a Java process that does NOT use the JVM args that CF is configured to use.
  • If you install the update from the command line, using this updated JVM, it's CRITICAL that you add the new JVM argument, -Djdk.util.zip.disableZip64ExtraFieldValidation=true (before the -jar arg). THAT will allow the install of the update to run successfully. Again, see my July blog post about the problem for more specific details and command examples. And see the update technotes for more on manually installing the update from the command line, which entails running a "java -jar" command against the downloaded hotfix jar file, which you will find in CFs bundles/updateinstallers folder. Be sure to run the commandline "as admin" in Windows, or as root in Linux/MacOS.
  • And as I note in that blog post, you could also just use a previous JVM update to perform the install.

Finally, let me note that if you may have attempted the CF update from the CF admin and had it fail, you will likely NOT be able to use the "uninstall" button in the CF Admin. In that case, proceed with the manually install of the CF update from the command line, as I discuss above. FWIW, I have always found I could run the installer again (even "over top of" a failed update)

Again, yes, frustrating that this issue is happening. Don't shoot me: I'm just the messenger, or the fireman/paramedic as it were.:-)

Some additional points to note

Before wrapping up, here are a few other points to note related to the update, some of which I or others elaborate on elsewhere:

  • Note that this update (like the last 4, in fact) does not incorporate any bug fixes. It is ONLY a security update. As such, if there are bugs that you know have been "fixed" by available "hotfixes" which you've been "waiting " to be incorporated fully into a CF update instead, you will have to keep waiting. Adobe rarely conveys what any next update will include, let alone when it may be released
  • For those using the Adobe container images, they are not yet updated (as of this writing) but should be soon (hours or days), as available at either the Dockerhub CF repo or the Amazon ECR CF repoAs for the Ortus Commandbox CF container images, and the Commandbox CF engines, those now offer this update.
  • If you may find that you "don't see today's update" in your CF Admin, it's just a caching issue. I had noticed the same earlier today. and when I checked the update feed URL it did not yet have today's update listed. But later in the morning it did appear (some hours after Adobe had posted those resources above). My guess is that this has to do with caching somewhere between our own computers and Adobeso just be patient. Or as the technotes offer, you COULD download and apply the update manually.
  • As for the section at the bottom of the technotes, labelled "ColdFusion JDK Flag requirements", please note that this section is NOT talking to you if you installed CF either with the full/GUI installer or the zip installer (new since CF2021). Instead, that discussion is ONLY for those who have deployed CF as a WAR or EAR on a JEE server, like the Tomcat, WebLogic, or Wildfly as it goes on to mention. I have a bit more to say on this matter as discussed in my post on the first CF update last month. But I want to stress it all the more here because it goes on to indicate a need to add a JVM arg called -Djdk.serialFilter, which some readers might think it's unique to this update since it refers to the serialfilter expanded upon by this update. Again, this flag/arg is always and only needed by those deploying CF as a WAR or EAR file.
  • One more time, for those who may have missed it at the outset: it's not a "mistake" that there's no update for CF2018, is it's reached its end of life last month.. This is yet another reason folks should consider moving up to cf2023, the only version currently sold by Adobe (or CF2021 if they may have a license for that).
  • If you need help keeping up on when updates are released for CF or the JVM that CF supports, note that besides my blog posts here, there is also an excellent service called HackMyCF offered (commercially) by Pete Freitag (who wrote the CF Lockdown Guide and offers other wonderful CF/CFML security tools like Fixinator and FuseGuard., which are discussed also at his site). Subscribers to that service not only get customized checking of the state of CF-related security configuration for their specific servers, but Pete also sends out note whenever there is a new release, as he did later today.
  • Finally if you are interested in more information about keeping CF updated, as well as the JVM, the CF web server connector, the CF PMT, FusionReactor, CF Builder, Lucee, and more, I keep such info in a CF update metaresource I have.

Conclusion

So phew, again a lot of info to consider for what may seem to some a "simple" CF update. And while it is indeed unfortunate that this has been the 4th update (for CF2023 and 2021) in the past 4 weeks, the good news is that this update is meant to better address some of the key vulnerabilities that had led to the 3 updates in July.

If you need help considering or performing these or any CF updates, I am available to help via my short-term, remote consulting.

For more content like this from Charlie Arehart: Need more help with problems?
  • If you may prefer direct help, rather than digging around here/elsewhere or via comments, he can help via his online consulting services
  • See that page for more on how he can help a) over the web, safely and securely, b) usually very quickly, c) teaching you along the way, and d) with satisfaction guaranteed
Comments
So is the recommendation to stay on Java version 11.0.19 until we hear back from Adobe?
# Posted By Dave Cordes | 8/18/23 9:52 AM
No. It's AN option. I listed a few. There are certainly arguments some would make to ensure CF 2021 IS running on 11.0.20, as the latest java 11 version (and same for CF2023 with regard to Java 17).

See both my section on this above and my earlier post that I point to, for more on that debate.
Thank you for the informative post! One minor typo: the label on the link for the "Technote for CF2023 update 10" should be "Technote for CF2021 update 10".
# Posted By Carl Von Stetten | 8/18/23 11:31 AM
Thanks so much, Carl. Corrected. :-)
Copyright ©2024 Charlie Arehart
Carehart Logo
BlogCFC was created by Raymond Camden. This blog is running version 5.005.
(Want to validate the html in this page?)

Managed Hosting Services provided by
Managed Dedicated Hosting