Careful applying CF11u16, CF2016u8, CF2018u2

by Pete Freitag

Update: Adobe has released CF11 Update 17 and ColdFusion 2016 Update 9 to address problems outlined in this blog entry.

Adobe released new security updates and bug fixes for ColdFusion 11, 2016 and 2018 this week. Normally these things go pretty smooth and any issue introduced by an update is typically minimal, but I can't say that has been the case for this update.

You definitely want to test before applying this update.

Here are the issues I have been tracking:

I will update this list if any other issues are found in ColdFusion 2018 Update 2, ColdFusion 2016 Update 8 or ColdFusion 11 Update 16.

The Fixinator Code Security Scanner for ColdFusion & CFML is an easy to use security tool that every CF developer can use. It can also easily integrate into CI for automatic scanning on every commit.

Comments

Joe

Hi Pete -- This is incredibly frustrating. Do we have any idea what the critical security issue was, and if there is any workaround for it? i.e. the one last year was to remove the FCKeditor or whatever it was called. Do we have a simple band-aid fix for the new security issues that we can put on until this patch is reliable? It appears to be connector related?

Ben Reid

Hey Pete, There is also an issue in these updates (CF11 U16/17/18 and CF2016 U8/9/10) with SSL encrypted datasources using a wildcard certificate to MS SQL Server (Connection String = EncryptionMethod=SSL; CryptoProtocolVersion=TLSv1.2; ValidateServerCertificate=0;). The HotFixes include an updated macromedia_drivers.jar file, which causes the issue. The Adobe team are aware and investigating. The official workaround is to copy the backed-up original macromedia_drivers.jar file from the hfudpates directory back into cfusion/lib. You may want to add this to your list.

MattW

@Ben Reid We ran into the same issue today when upgrading CF2016 Update 7 to Update 12. We use SSL DSN's connecting to Azure SQL and it broke them for the same wildcard certificate issue you mentioned. Since you reported this on Update 9 and it's now Update 12 and it's still not fixed I am wondering what's going on. Have you heard or read anymore about this issue. I don't mind just loading up the old macromedia_drivers.jar file but I have to wonder if some of the security fixes they implemented are "undone" by using the old JDBC drivers.

RandalB

@Ben @Pete - We are running into this same issue with a new install of CF2018. We applied the update before doing our first datasource connection. We have followed instructions for adding the SQL server's SSL certificate to the CF2018 \jre\lib\security\cacerts file, but still cannot get CF to use SSL to make its connection to SQL. Now wondering if it is related to the update and the issues you pointed out. Not sure how to "load up" the old macromedia_drivers.jar file or reverting to pre-update drivers.

Pete Freitag

@RandalB - not sure what update the latest installer has by default, but if it is less than update 2, you could try looking in the hf-updates folder, and then in the backup subfolder.

RandalB

@Pete - thanks for the suggestion. Before implementing we did some further testing and found where the server address in ColdFusion was just the IP address (internal server, no DNS) and the name in the exported SSL cert was the server's FQDN, which did not match. Adding hostNameInCertificate=xxxxxfqdn; to the connection string did the trick and we now have successful connection, despite the CF2018 u5.

MattW

I was able to get it working with the following connection string.... EncryptionMethod=SSL;Encrypt=yes;ValidateServerCertificate=false; I couldn't use the hostNameInCertificate parameter as suggested above. This is because Azure SQL uses a CNAME and then multiple redirects before landing on one of their clustered machines. I had to set hostNameInCertificate to the actual endpoint to get it working. However, that endpoint could change from time to time depending on which back-end server in the cluster we get routed to. Specifying one of the those endpoints in that parameter would amount to a single point of failure on an otherwise redundant setup.