NOW LIVE! ColdFusion 2023.4 and ColdFusion 2021.10 August updates

[Saurav_Ghosh]

We are pleased to announce the availability of ColdFusion (2023 release) Update 4 and ColdFusion (2021 release) Update 10. These updates introduce the ColdFusion serial filter that can be used to allow or disallow Java classes or packages for the deserialization of Wddx packets.

What is ColdFusion serial filter? 

The cfserialfilter.txt file ensures protection against insecure Wddx deserialization attacks. On the other hand, the already existing serialfilter.txt blocks Java deserialization by disallowing certain Java classes or packages.

How do I download the updates?

Head over to the update pages to download the updates:

• ColdFusion (2023 release) updates
• ColdFusion (2021 release) updates

What do these updates contain?

Learn more about these updates from the following tech notes:

• ColdFusion (2023 release) Update 4
• ColdFusion (2021 release) Update 10

What else?

• Docker images for ColdFusion 2021 and 2023 will be pushed to AWS ECR and Docker Hub shortly.
• CFFiddle will be updated with ColdFusion 2021 Update 10 and ColdFusion 2023 Update 4 shortly.

Please install these updates and provide us with your feedback.

[Charlie Arehart]

While this update doesn't link to any Adobe product security bulletin (apsb), it is indeed a very important security update, offering a more complete resolution to some of the vulns addressed in the 3 CF security updates last month. For more details, see the update technote linked to above, especially how you can modify things related to the new protection. Thanks for trying to better address the issues here, Adobe. (Time will tell how things go for folks, of course.)

Sadly for those using cf2018, its end of life was last month, so it seems this update will not be made available to them. Another reason to consider moving up to cf2023, the only version currently sold by Adobe. 

[sdsinc_pmascari]

Disappointed to see no mention of fixing https://tracker.adobe.com/#/view/CF-4218035

I emailed CF support and was told this fix may not be released until Q4?!

Why wait to fix such a major bug when you've, supposedly, already developed the fix?

Can't move many servers off CF2018 until this fix is released.

[Charlie Arehart]

Paul, this update was ONLY a security update, no bug fixes. And to be fair, in that tracker ticket of yours Adobe DID specifically indicate last week that your fix would be in an hf5 (meaning a planned update 5, which would follow what I anticipated there would be a sec-only update, which proved to be this one released today).

I get it: you want the bug fixed, and you want to vent about it publicly. I'm just saying for the record here that this is not "new" information, that this update would not include that fix.

Your mention of "q4" may be news to some, but there's consolation in that q4 starts in about 6 weeks. I realize that may not be soon enough for your preference, but it does seem to take the team a long time to create an update with bug fixes (whereas sec updates seem to get expedited). And of course some people grumble when there are TOO many updates, so they'd rather NOT have an update released for each bug fix, however urgent it may be for some.

You should certainly lobby Adobe to create a hotfix for that bug, which then would allow you to apply that BEFORE then. They do that often. 

Heck, if any complaints would be justifiable, it would be from those those facing bugs which were INTRODUCED with the update in Sep 2021 (update 2 of CF2021 and update 12 of cf2018) and had hotfixes within days or weeks--yet those hotfixes were NOT bundled with the last cf updates which DID include bug fixes in Oct 2022 (updates 5 and 15), nor have they been in the cf updates since. One example is a cfreport bug.) such folks have had to carry their hotfix forward on each update, for a couple of years. They'd love to hear their fix would be incorporated in an update in coming weeks/months.

Not criticizing or castigating you. Just offering the info for those interested. Let's hope things improve on these matters. 

[neochad]

I am confused by this statement:

"cfserialfilter.txt file ensures protection against insecure Wddx deserialization attacks. On the other hand, the already existing serialfilter.txt blocks Java deserialization by disallowing certain Java classes or packages."

Does this mean that the serialfilter.txt will not stop those java classes from being invoked if they are on the list? Or is the cfserialfilter.txt an extra layer of protection from blocking wddx deserialization, using cfwddx for example, from even being processed if it contains any classes listed there?

[Charlie Arehart]

Neochad, you may find things to be clarified a bit better in the technote for the update, rather than the brief paragraph in this post above. In the technote, it discusses more about both seralization protection mechanisms--and how each allows EITHER for allowing or disallowing the respective serialization. The two mechanisms are indeed different, and the new one supplements the original one, with its focus specifically on deserialization via wddx.

I don't disagree that the real point of this update is not made as clear here as it could be--but Adobe has to walk a line between giving away info that would allow hackers to leverage the vuln, and giving away info to help people be able to tweak the new feature if its default protection does not work for some situations Adobe didn't anticipate or perhaps can't themselves control. That's my take, at least.

[Charlie Arehart]

Oh, and to be clear, the issue is not with cfwddx. That's just one way that wddx serialization and deserialization can be done via code. Instead, this whole matter of wddx deserialization (as addressed by this update and the last 3 in July) is instead about some inherent capabilities CF has in processing of incoming http REQUESTS that were being leveraged by bad guys to call upon CF to execute things remotely that should not have been allowed. Again, see my last comment on my guess as to why Adobe is not sharing more details here. I expect we'll see more info from folks in the community (perhaps myself included) in time.

[neochad]

I have read the tech notes I am not seeing a lot of clarity there to be honest. Since 2021 and 2023 are being patched only, does that mean that if you do wddx deserialization within your code you are vulnerable on the latest available patch on 2018?

[Charlie Arehart]

Chad, again, this is not about you doing wddx in your code. It's about incoming http requests doing mostly UNEXPECTED AND UNINTENDED NEFARIOUS THINGS that leverage built-in wddx deserialiation that CF performs WITHOUT RESPECT TO WHETHER THE CFML ON ANY PAGE ITSELF DOES ANY WDDX PROCESSING.

Again, we will not likely hear more clarity from Adobe here, and what the rest of us can offer is based on what info we may know or have heard--all couched in an overriding concern not to share info that would help attackers.

To your question about cf2018 specifically, it reached its end of life last month. As such, it appears it will not get updates from this one forward, as I noted in my first comment here.

[Charlie Arehart]

If any readers here find "the update is not showing up in my CF Admin", I'll note that this happened for me also at first. I had even checked the feed URL and it did not yet have today's update.

But within the last half hour it showed up, for me at least. This could have do with caching anywhere between where our CF is installed and Adobe's servers--so if you may find it's "not there", do just be patient. Or as the technotes offer, you COULD download and apply the update manually--though it's not something everyone is familiar or comfortable with.

[rickmaz]

can anyone version the version i should be on after upgrading 2021 to 10?

mine is showing 2021.0.09.330148 in the admin

but in the /updates folder the 10 jar is there i did it from the admin 

[Charlie Arehart]

Rick, there are two issues here.

First, the update technotes always indicate what version number you should see, and the one for cf2021 has a box near the bottom that says:

"After applying this update, the ColdFusion build number should be 2021.0.10.330161."

As for your seeing the chf jar for 10, it would seem your update had a error. There is a log created after each update, stored in the f cfusion/hf-updates folder for the update after it completes. That log tracks a count of fatalerrors and nonfatalerrors, both of which should be 0. What are your counts? FWIW, I have a blog post with more on checking and dealing with update errors. 

Finally, there's one NEW problem I'm applying updates, if you have updated your java with the version that came out last month. I have a blog post on that as well.

Let us know of any of this does or doesn't help you. 

[rickmaz]

so on CF page it says update 9:

Build Number: 2021,0,9,330148

Update 10

Build Number: 2021,0,10,330161

mine is showing 

2021.0.09.330161 so like a combination of both

I did check your doc you linked to and i did run it from command line and stopped CF service first and it ran like a champ thanks!

[MrFelna]

Thank you, Charlie, for highlighting the issue with JVM 11.0.20 and ColdFusion. The update wasn't fully successful for me via the Administrator so I had to reapply it manually following your blog post.

[Charlie Arehart]

Rick and MrFelna, glad to have been able to help you both. 

[BKBK]

can anyone version the version i should be on after upgrading 2021 to 10?

mine is showing 2021.0.09.330148 in the admin

but in the /updates folder the 10 jar is there i did it from the admin 

By @rickmaz

To be sure, run a CFM page consisting of the following code:

<cfscript>
    writedump(server.coldfusion.productversion);
</cfscript>

[Brian__]

Ever since CVE-2023-26360 in APSB23-25, I've spent *a lot* of time looking at how CFCs work from a security point-of-view.  The attack surface (all of the different points where an attacker could breach a system; and the entry points, sources, and sinks for user-controlled data) for CFCs is significant.

While the new controls here are an improvement that will provide significant protection, my gut recommednation is to prevent untrusted access to *all* CFCs -- which  would apply to any CFCs that are web-accessible even if they provide no remote methods.  

Extreme?  Maybe.  Uninformed in terms of "...but that's necessary part of xyz crucial CF innerworkings" ?  Maybe too.  But I'd bet that approach is very likely to provide automatic, immediate defense against the next (unknown) future attack path related to CFCs.

[Charlie Arehart]

Sure. If someone doesn't use cfc's via http requests, such as for incoming api's, incoming Ajax calls, etc., they COULD just block ALL calls INTO cf for such http requests to cfc's.

That could be done either in the external web server (iis or Apache via their config), or via the web server connector (such as in the uriworkermap.properties file), or internally within cf via the web.xml file.

To be clear, lest readers overreact to this, NONE of what we are discussing relates to your using cfc's as called from within cfml--only calls to cfc's via incoming http requests. 

Finally, I'm not aware of any aspect of the cf admin that requires calls in via cfc's. But if there ARE any, those could be provided as a white list of what CAN be called.

As with so much about security, it's a constant battle between bad guys/attackers and good guys/defenders. Folks should follow Brian's blog, for still more on cf security, along with Pete Freitag's blog, products, and services.

Let's see if others may have more on this idea Brian is proposing.

[Brian__]

Yup.  Thank you, Charlie,  for explicitly calling that out, in case my original comment was unclear.  My thoughts on this relate only to inbound HTTP requests directly to CFCs (and are not related to calling functions in CFCs internally, from within other CFML code.)

But I'd also go as far as to say if you *are* using direct HTTP access to CFCs today for incoming APIs, AJAX calls, etc., the longterm security benefits of moving to a different approach may very well be worth the effort required to do so.  (And if you're really unable to do that, inbound requests should be strictly validated to ensure the format is *exactly* what you are expecting / have verified is "good" traffic, in addition to the ColdFusion server security controls that are available.)

[Charlie Arehart]

Yep, more good ideas, and food for thought. 🙂 

[wtlaughlin]

The instructions for JEE deployments call for Java flags to be set in Tomcat's Catalina.bat file. I'm deploying to an Azure environment where we do not have access to any of the Tomcat configuration files. Is it possible to set these flags elsewhere within ColdFusion? And what happens to the application if the hotfix is applied without these flags being set?

Thanks!

[Charlie Arehart]

Wt, I'm assuming you mean Azure App Service. If so, note that you can setup such env vars (for the app as to be deployed that way) via either portal, the CLI or powershell.. For more, see that discussed here. Let us know how that goes for you.

As for what happens if you don't, it's not really about this update. These have been pointed out in aodb security bulletins (not always the update technotes) since 2018, the first being https://helpx.adobe.com/security/products/coldfusion/apsb18-14.html and covering even cf 11.  And they are related to a form of protection/filtering against certain Java deserialization attacks. (In fact, this last cf update brings the same CONCEPT to wddx deserialization attacks, with the filtering done through other than jvm args/env vars.)

Someone from Adobe may have more to share, of course. 

Finally, you had raised issues about getting cf working on Azure App Service in another thread back in Jan. It seems perhaps you ended up resolving things. If so, folks finding that thread would really appreciate hearing the resolution. 🙂 

[wtlaughlin]

Thank you.

I've asked to be alerted by email when replies are made to my posts, but I've never received any notifications; not even in my Spam folder. Consequently I get absorbed in my troubles and forget to check back in. Sorry.