Announcing ColdFusion updates released June 11 2024: another possible breaking change
In this case, it's about if you use CF encryption-related functions, the default encryption algorithm is changing--and that means that those who encrypt/decrypt (or hash or randomize) data in their apps MUST take steps before applying this updates. For more, read on.
Update: As a heads-up, a few weeks after this post ANNOUNCING the update and its key change, I created another that address confusion many still seem to have after reading the Adobe technote on the update (links below).You may want to skip to reading that post first, On handling the June 2024 CF update change of default algorithm from CFMX_COMPAT.Otherwise, read on for what I wrote originally.
Please don't apply the update before reading the update technote
Please folks: it's imperative that before applying the update, you read either (the update technote for CF2023 or the update technote for CF2021).
These technotes explain important details related to the update, and especially about this security change.
Other thoughts
Besides the helpful detail in the technote, as far as trying to determine whether this change will impact your apps, consider that you could use a search tool (or multi-file search capability in your editor) to look for occurrences of the affected functions across your code base. These are encrypt, encryptbinary, decrypt, decryptbinary, hash, rand, randomize, and randrange. You can search for just these 4 strings:
- encrypt (which will also find occurrences of encryptbinary)
- decrypt (which will also find occurrences of decryptbinary)
- hash
- rand (which will also find occurrences of randomize and randrange)
Granted, sometimes you will find references to these strings that are NOT about the CFML functions with those names, or which may be commented out. You'll need to assess them, but it really may not take long given that these might be used rather infrequently, if at all.
Finally, the key thing to look for (if you DO find these as existing CFML functions in use) is whether the functions DO or DO NOT specify the argument for the encryption algorithm. See the technotes as well as their links to the CFML Reference for each function, to know what argument would specify the algorithm.
Again, the key to the update's change only affects code where you DO NOT specify the algorithm, in which case the default is changing per this update. In brief, after that update the default encryption algorithm for the encrypt/decrypt functions is changing from CFMX_COMPAT to AES/CBC/PKCS5Padding. And for the hash function it is changing from CFMX_COMPAT to SHA-256 hashing algorithm, while finally for the rand* functions it is changing from CFMX_COMPAT to SHA1PRNG.
For many people, the "simple solution" may be to use the available JVM arg to revert the default (see the technote), which will no longer work starting with CF2025.
The next simplest solution would be to change such code to specify "cfmx_compat" as the algorithm, wherever they don't specify any (again, trading compatibility for security, but more targeted). See the technote for more on these options.
And follow the useful Adobe community forum message announcing the update
Also, there's (as always) a useful Adobe community forum message announcing the update, but note that it does not (currently) offer the level of detail about the issue that the technote does.
You should also keep an eye on that forum thread as there will surely be more discussion of this update there.
Indeed, you'll see I've already added the first comment there, pointing out this matter that the technotes currently offer important detail that that forum message does not.
Then I also ask there for confirmation that this has nothing to do with passwords stored/encrypted and retrieved/decrypted by the ColdFusion Admin itself. See my comment for more. I look forward to folks offering clarification there.
Finally, I explain there why I am unable to test this new update (as I normally would, before writing this sort of post), because I am traveling and just have time to have gotten that note and this blog post out. I will update things as warranted. If I add anything substantial, I'll both mark it clearly as an update here and will point it out in a comment--for the sake of those who read this before I would offer such an update.
Update: beware a breaking typo in the technote
Where they offer the JVM arg (for reverting the behavior), they mistakenly have a space before the "=", which if you implement it (with that space) in your JVM args for CF will keep it from starting! The arg (if used, such as to set to TRUE) should be:
The mistaken space before the "=" is also in the forum post from Adobe below. I have raised both concerns there, so perhaps in time this will be addressed by Adobe in both places. Until then, I wanted to get this word out.
On getting help with the update(s)
Finally, if you may want help with considering, installing, or troubleshooting anything related to these updates (or indeed anything related to ColdFusion, or Lucee), I'm available for online remote consulting (though with restricted hours this week while I'm in Germany, Jun 11-16). More at carehart.org/consulting.
Or you can certainly reach out to the CF community for help (I list several of the online CF communities here.)
For more content like this from Charlie Arehart:Need more help with problems?
- Signup to get his blog posts by email:
- Follow his blog RSS feed
- View the rest of his blog posts
- View his blog posts on the Adobe CF portal
- 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
So I've added an update to my post above about this.
And if you are the person who sent me word, please send it again. It was early in my day here at cfcamp in Germany, and I can't recall how you had sent it. I looked through several places before writing this! :-)
Error below:
errorError editing/creating this dsn (dsn-name)
An error occurred while trying to encrypt or decrypt your input string: Given final block not properly padded. Such issues can arise if a bad key is used during decryption..
local.result = encrypt(arguments.fromString, getKey(arguments.algorithm), local.algorithm, local.encoding );
However, that does not appear to be the case. The encryption actually works, but not without the "...error occurred while trying to encrypt or decrypt your input string: '' Can not decode string..." warning.
Has anyone else encountered this?
But more specifically, here is code that will demonstrate that things work if (as you propose) one DOES set the 3rd arg (for encrypt or decrypt) to "cfmx_compat", and this works whether you set the jvm arg true or false or if you leave it off. Notice how my code outputs whether that's so, as well as the CF version and update level.
<cfscript>
msg="test msg"
algo="cfmx_compat"
key="123"
writeoutput("Message to encrypt:" & msg & '<hr>')
encryptedMsg = encrypt(msg,key, algo)
decryptedMsg = decrypt(encryptedMsg,key, algo)
writeoutput("Decrypted message:" & decryptedMsg & "<hr>")
writeoutput("CF version: " & server.coldfusion.productversion & "<hr>")
writeOutput("JVM arg -Dcoldfusion.encryption.useCFMX_COMPATAsDefault")
if (not structKeyExists(server.system.properties,"coldfusion.encryption.useCFMX_COMPATAsDefault")) {
writeoutput(" <u>is not set</u>")
}
else {
writeoutput("=" & server.system.properties["coldfusion.encryption.useCFMX_COMPATAsDefault"])
}
</cfscript>
Please let us know how things go.