Follow-up on June 2024 CF update: more on change of default algorithm from CFMX_COMPAT
As another case where Adobe is opting to sacrifice compatibility for security, the update changes from using the very old default of CFMX_COMPAT (as the default) to using either of a couple different alternatives, depending on the function. And if you're not careful/paying attention, you could break some critical part of your app by applying this update.
TLDR; In this post, I want to share a bit more to help you understand the impact of this update (which I blogged about in June), whether you're a developer or an administrator--and whether you've applied or not yet applied the update. Even if you HAVE done it and "all seems well" (in test or even in prod), do beware there may be nasty problems waiting to bite you that could take time to crop up. I'll explain the issues, and help you find the code using these functions, then help you determine if that code is or IS NOT affected by this change. I'll also discuss some real-world scenarios and challenges, with solutions.
Finally, I'll explain an available JVM arg (-Dcoldfusion.encryption.useCFMX_COMPATAsDefault=TRUE) that can be used to revert this behavior, for those who may feel they need to sacrifice security for compatibility, so as to get to this June update and take their time to address this change in the encryption default. I also explain how the CFMX_COMPAT algorithm DOES still remain available as an option, despite what some have asserted, which may be an acceptable option to use. Then I wrap up with some thoughts on how it may not be so bad that I'm only getting this post out a few weeks after the June update.
For more, read on.
Now if you do fix this by adding the CFMX_COMPAT algorithm to your encrypt or decrypt calls, Fixinator will still mark that as an issue, since it is not considered a secure algorithm.
Great post as always Charlie!
So while it will indeed help find "any" use of cfmx_compat (explicit or implicit), folks who seek a way to find ONLY the implicit uses will have to consider what I offered. Or they can use fixinator, but realizing it will identify code that would not "break" before the update (or without the new jvm arg set to true). As you say they should consider changing the algorithm...or at least setting it to "cfmx_compat" to maintain compatibility (at the cost of security).
Then later runs of fixinator can remind them they've left it set explicitly. :-)
When you say
"Change your code (that does the hash without specifying an algorithm) to go ahead and specify CFMX_COMPAT as the algorithm. Some might argue that it's perhaps not quite AS important to change to a more secure algorithm for hashing. You need to study and decide that for yourself"
Should this be MD5 which was the default?
As for your question, you feel md5 was "the default" when? I'm referring to it had been cfmx_compat BEFORE the update, which is the crux of the article.
I know it's a lot of info to keep track of. :-) If you see something I could/should improve, do let me know.
hash("something", "CFMX_COMPAT") - in other words you are both right.
But to you AND Tony I would point out that the technote for the June updates does clearly say that "the default encryption algorithm of Hash function has changed from CFMX_COMPAT to SHA-256 hashing algorithm".
Note that makes no mention of MD5 (neither the technote for CF2021 update 14 nor CF2021 update 8, which are those June updates.) More on that in a moment.
First, when I replied to Tony asking if he was referring to before or after the update, it's just that I knew the default HAD changed: I didn't recall what it changed TO. :-) But after confirming the above, I have also now updated both this blog post AND my one from June to quote what Adobe says in the technote about what the defaults WERE and now ARE.
But that still leaves this confusion about MD5. And I think I may see where it's coming from. I notice that the current CFML Reference for hash (https://helpx.adobe....) has its table of arguments/parameters, with the "algorithm" arg's available values, and it does indeed show among those "MD5: (default)", which might suggest that IS (or WAS at some point) the default.
But beyond what the technote says, I'll also note how the top of that same CFML Reference page for Hash in the "history" section says again clearly: "ColdFusion (2023 release) Update 8 and ColdFusion (2021 release) Update 14: Changed the default algorithm from CFMX_COMPAT to SHA-256."
So I appreciate Tony's confusion now. And indeed now I'm confused. :-)
Either it's that the top of that page and the technote are right (and the parameters indication of MD5 as the default is wrong), or it's the other way around. Again, I was just going on what the technote said. :-)
Pete, have you done any closer analysis of this? Or Tony, or anyone? If anyone can prove that either NOW or (especially) BEFORE the update, the default algorithm IS or WAS MD5, we'd need to get them to correct that page AND the technote (and then my blog posts).
I know what would need to be done to do it. I just can't commit to doing it right now. But since you both are interested in this, perhaps you will or have, or again perhaps Pete or anyone has more to share.
Take a look at this code example: https://trycf.com/gi...
1) First, thanks for the example to prove that indeed if one DID use cfmx_compat then that WOULD indeed be an identical result to using MD5. And fair enough. That was valuable to learn.
2) But your example doesn't show using NO argument, nor using the SHA-256 option.
And indeed if you modify the code to add those (I have, below), you will see that indeed BEFORE the update (or such as on CF2018, which that trycf.com site does permit), the resulting hash (if done WITHOUT any argument) is indeed the same as either CFMX_COMPAT or MD5.
But if run AFTER the update, the resulting hash (if done WITHOUT any argument) is indeed the same as SHA-256 .
That means the technote and history section (and my blog posts) have it right.
3) But the parameters section is wrong to still indicate that MD5 is the default (and it's CONFUSING also as it did not clarify that CFMX_COMPAT was the same as specifying MD5). I'll bring that to their attention.
In any case, to Tony's question, yes you COULD change the code to use MD5 (which happens to be the same as CFMX_COMPAT, in the case of hash alone), to remain "backward-compatible". Again, thanks for clarifying THAT point, Pete.
4) Even so, to your final point, "if you say MD5 is the default or you say CFMX_COMPAT is the default they both are technically correct", well, that is in fact NOT technically correct. :-) Again the default HAS changed per this update to SHA-256.
In case anyone needs proof, I offer the two additional hash examples (with no arg and with sha-256) AND I also print out the CF version (and update level) in my slight modification to Pete's code, here:
https://trycf.com/gi...
First, beware that on trycf.com, the CF2021 version offered there is from update 12--BEFORE the update 13 in June. So it shows the same result as CF2018, not CF2023.
But if you try the same code at Adobe's cffiddle.org, you'll see both CF2021 and 2023 showing the same hash results--as they updated both to the latest CF versions, and no jvm args.
Indeed, the one thing that is NOT easy to reflect in that code is whether the new jvm arg (to revert the cfmx_compat default) has been used. If it has (or if testing against CF2023 or 2021 BEFORE the JUNE updates, or CF2018 or earlier), then the 3rd line (no arg) will be the same as the first 2 (cfmx_compat/md5).
AFTER the update (and without the JVM arg reverting things) the 3rd line will be the same as the 4th (sha256).
And apologies to any who's heads are spinning or feel that all this all "too much". But I think for some readers the clarifications will be useful.
1) Great
2) I didn't show using no argument in my example because it is now SHA-256, I was just trying to show that MD5 and CFMX_COMPAT are the same thing for the hash algorithm.
3) Yes, I don't know why the ever called it CFMX_COMPAT because it is just MD5. For encrypt/decrypt it makes sense that they call it CFMX_COMPAT because they made up their own algorithm so it is not a standard algorithm, but for the hash they used a standard algorithm.
4) Ah, I think this is where you thought I was disputing that it changed. I was just trying to point out that the hashing algorithm used when you specify CFMX_COMPAT is the MD5 algorithm, so the result is equivalent. I should have said: "if you say MD5 was the PREVIOUS default or CFMX_COMPAT was the PREVIOUS default they are both technically correct".
Also, I corrected a couple of minor mistakes in my last comment where I once wrote sha256 for sha-256, and another time I mistakenly referred to aes256. They should both be sha-256, and now are.