Pete Freitag Pete Freitag

Recent Comments

Firefox Hosts File Not Working?

Posted on 01:48 PM Wednesday August 31, 2022 by Pete Freitag
Thanks James - my example was run on Mac, so I appreciate you adding some windows tips. Not sure why 1.1.1.1 wouldn't be responding though, perhaps your ISP blocks it?

Log4j CVE-2021-44228 Log4Shell Vulnerability on ColdFusion / Lucee

Posted on 05:57 PM Friday August 19, 2022 by Peter Asher
A further follow up on the QOQ problem. The fix hf202100-4212383 works for most queries. However, we found a problem with the order by statement, if we use the numeric value of the field, it fails. If we use the field name, it works. Ie: if we have order by set to ‘5 DESC,fieldb,fieldc’ - it fails If we have order by set to ‘fielda DESC, fieldb, fieldc’ - it works

How to Run SQL Server on a Mac

Posted on 02:55 PM Thursday August 04, 2022 by Paul Stewart
Quality! Thanks (:

Firefox Hosts File Not Working?

Posted on 10:18 PM Friday July 15, 2022 by James Moberg
I couldn't get the sample CURL to work with the single quotes when using CURL on Windows. (I had to use double quotes.) 1.1.1.1 also wasn't responding. This worked though: curl -H "accept: application/dns-json" "https://cloudflare-dns.com/dns-query?name=firefox.com&type=A"

Minibox - a tiny commandbox docker image

Posted on 03:03 PM Wednesday July 13, 2022 by Pete Freitag
@Mark - thanks, I am still using it and updating it frequently. I haven't looked into arm builds, it relies on the Azul Zulu JVM as the base image, so if that supported it then it would probably be possible.

Log4j CVE-2021-44228 Log4Shell Vulnerability on ColdFusion / Lucee

Posted on 11:06 PM Thursday June 16, 2022 by Charlie Arehart
Hey, John, do your last comment, I will note that someone else finally brought it up as a tracker ticket. I have shared an extended comment there which may help you if you're still having to deal with the issue. There's no solution, but info (including more from Pete that I point to) which may at least give people the proper understanding of the situation (and why it may not likely change for some time, if at all). See: https://tracker.adobe.com/#/view/CF-4213568 I'm certainly open to feedback, there or here, from Pete or anyone. As always, I'm just trying to help.

How to run Oracle DB on a Mac with Docker

Posted on 03:10 PM Monday June 13, 2022 by Mike
This seems like an outdated method, although I am not a computer expert. You can get it directly from Oracle with this command: docker pull container-registry.oracle.com/database/enterprise:latest. Is there any advantage of this method versus the "docker pull" from the registry?

How to run Oracle DB on a Mac with Docker

Posted on 06:06 AM Wednesday June 08, 2022 by Anonymous
Hi. The build failed for me. This is my directory > dockerfiles % ls 1.0.1 12.1.0.2 18.3.0 19.3.0 buildContainerImage.sh 11.2.0.2 12.2.0.1 18.4.0 21.3.0 I ran BuildContainer 21.3.0 (most recent version) ./buildContainerImage.sh -x -v 21.3.0 and then I got this prompt telling me the image was not created ERROR: Oracle Database container image was NOT successfully created. ERROR: Check the output and correct any reported problems with the build operation.

Minibox - a tiny commandbox docker image

Posted on 03:35 PM Friday May 27, 2022 by Mark Drew
I just spotted this image! Looks amazing. How much are you still using it? Also, do you think you can do ARM builds of it?

Replacing Twitter Share / Follow Widget Buttons with CSS

Posted on 11:21 AM Tuesday May 10, 2022 by Jan
Better performance is only a side effect, by not loading 3rd party code you improved the our privacy, your sites visitors, thank you!

Log4j 1.x Vulnerability Mitigation Guide

Posted on 04:03 PM Tuesday April 26, 2022 by Mike
Hi Pete - I noticed a possible mistake you made. Please correct in your blog post if so. The first is the path to JDBCAppender.class. It should be under the /jdbc folder vs. /net folder. At least that is where I found mine. Secondly, /net/JMSSink.class was notincluded in your list at the bottom. Was that an oversight? It should be included for removal, right?

SessionInvalidate for JEE Sessions

Posted on 10:28 PM Thursday April 14, 2022 by Andrew Kretzer
I've been using this for a while without issue, but now noticing that error logs are piling up. It seems that getPageContext().getSession() returns a struct? Is there another way to invalidate() a JEE session n Lucee?

Not authorized to perform: ssm:GetParameters

Posted on 05:01 PM Monday April 11, 2022 by hassan
Thank you so much, i exactly had "kms:Decrypt" issue. Aws should have thrown exception regarding this policy but it kept on throwing exception "GetParametersByPath" is not assigned.

Spring4Shell and ColdFusion

Posted on 10:36 PM Wednesday April 06, 2022 by Charlie Arehart
Wonderful, thanks so much, Pete.

CloudFlare Authenticated Origin Pulls on Nginx or Apache

Posted on 12:16 AM Monday March 28, 2022 by TJ
The Cloudflare "How To" for this has been largely removed from the web. Do you have a tutorial of your own for Apache/LightSpeed WS?

Burst Throttling on AWS API Gateway Explained

Posted on 07:12 PM Monday March 21, 2022 by Alex
Great article! "The Rate is a little easier to understand, it is the maximum number of requests that can occurs within one second." ^This sentence seems a bit confusing to me. My understanding is that if the burst is 200 and the rate is 100, there can be 200 requests occurring within the first second if the service had not been taking any request for sometime.

How to run Oracle DB on a Mac with Docker

Posted on 11:44 PM Wednesday March 16, 2022 by Mallesham Manchala
Thank you very much, this is great. One small comment, for me i did not see ./buildDockerImage.sh script. i used this buildContainerImage.sh and worked fine. Thank you again.

Setting Lucee Admin Password with CommandBox

Posted on 10:50 PM Wednesday March 02, 2022 by Tom
Working with Brad Wood, I discovered my environment is pretty messed up so my previous comment is due to my environment rather than some update made to CFConfig.

Setting Lucee Admin Password with CommandBox

Posted on 07:26 PM Wednesday March 02, 2022 by Tom
I've noticing the same behavior as Jonas as of 5.4.x.

Writing a GitHub Actions Workflow that Uses a Docker Image

Posted on 02:23 PM Wednesday March 02, 2022 by Issam
Hi Gopi You can use a private dockerhub image, you just have to add under secrets your docker username and password, the code is like this : container: image: id/img:version credentials: username: ${{ secrets.DOCKERHUB_USERNAME }} password: ${{ secrets.DOCKERHUB_PASSWORD }} steps: ...

How to run Oracle DB on a Mac with Docker

Posted on 06:11 PM Wednesday February 23, 2022 by AGNERO
Good evening, this tutorial was really useful and thanks. But I can't execute the sqlplus command from my terminal since it is not recognized... also I don't know how to open Oracle Net Manager. Can anyone help me? Thank you.

How to run Oracle DB on a Mac with Docker

Posted on 06:10 PM Wednesday February 23, 2022 by AGNERO
Good evening, this tutorial was really useful and thanks. But I can't execute the sqlplus command from my terminal since it is not recognized... also I don't know how to open Oracle Net Manager. Can anyone help me? Thank you.

Log4j CVE-2021-44228 Log4Shell Vulnerability on ColdFusion / Lucee

Posted on 08:49 PM Wednesday February 09, 2022 by John
I've noticed that recently scans are showing 'cf-logging.jar' as containing log4j version 1.2.15, and removing this jar appears to break the entire CF application. Do you know if there is a way to remove this old log4j safely, or update CF to stop using it? Even with the 2.17 log4j installed it seems to still rely heavily on this massively out of date version. Thanks!

Replacing Twitter Share / Follow Widget Buttons with CSS

Posted on 04:54 PM Wednesday February 09, 2022 by Andrea
Great, thanks!

Log4j 1.x Vulnerability Mitigation Guide

Posted on 12:29 AM Tuesday February 08, 2022 by Bruce Bading
log4j v1.x reached EOL on Aug. 5, 2015 and in the blog, Apache stated "Users are encouraged to upgrade to Log4j 2". That was almost 7 years ago. As we know in cybersecurity EOL means unsupported and will never fix vulnerabilities after the EOL date. The 3 CVEs associated with v1.x had workarounds, but after the Dec. 9, 2021 announcement, it was less than 30 days before 3 critical CVEs with no mitigation were found in v1.x. Using 1.x more than 6.5 years after EOL was a ticking time bomb and we have detected several new attacks. Future suggestions, when a vendor releases EOL statements, upgrade ASAP. If you are vulnerable, time to remediate is today. If you've been breached, time to remediate was yesterday.

Writing a GitHub Actions Workflow that Uses a Docker Image

Posted on 07:25 AM Friday February 04, 2022 by Gopi
Hi Pete, while using docker in a step should the image be a public docker image. Can i use an image from local repostiory or private repostiory if yes , how do I pass the auth info? also is there any way that we can use a local image that is already pulled, in case we cannot pull the image from the private CR.

Log4j 1.x Vulnerability Mitigation Guide

Posted on 08:36 PM Tuesday February 01, 2022 by Pete Freitag
@George - yes, planning on updating it once I've had a chance to review them properly.

Log4j 1.x Vulnerability Mitigation Guide

Posted on 08:21 PM Tuesday February 01, 2022 by George
Thanks for this great page, Pete. Did you have plans to update it for the the new JMSSink, JDBCAppender, or Chainsaw vulnerabilities for Log4j 1.2? (CVE-2022-23302, CVE-2022-23303, and CVE-2022-23305, respectively)

How to get Log4j Version at Runtime in Java

Posted on 08:50 AM Friday January 21, 2022 by java99
FYI Java Code to Get the Log4j Version at Runtime is not working for Log4j 2.12.4 something like this: LOGGER.info("Log4j Ver: "+ org.apache.logging.log4j.util.PropertiesUtil.class.getPackage().getImplementationVersion());

Passing Environment Variables to Sudo Command

Posted on 09:02 PM Tuesday January 18, 2022 by lad
This was exactly what i was looking for. Thank you so much for posting this. sudo -E was exactly what i was looking for

Log4j CVE-2021-44228 Log4Shell Vulnerability on ColdFusion / Lucee

Posted on 02:20 PM Monday January 17, 2022 by Sven
Hi Pete, I have just freshly installed CF2021 on a server and brought it to update 3. When I went to swap the Log4J 2.16 components for 2.17, I noticed that there is another log4j.jar there as well. This one contains version 1.2.15. Why does Adobe leave these old versions here in parallel (or a third one if you count the one in Jetty?) Did I miss a hint? How do you handle these old versions? Thanks a lot!

Log4j CVE-2021-44228 Log4Shell Vulnerability on ColdFusion / Lucee

Posted on 03:26 AM Thursday January 13, 2022 by David
Hi Pete, I have installed the CF2021 patch, and copied log4j 2.17.1 version files to C:\ColdFusion2021\cfusion\lib folder. However, I found that in C:\ColdFusion2021\cfusion\jetty\lib\ext there are old versions of log4j files, including log4j-1.2.17.jar and log4j-1.2.17.zip. Should/can I remove them as well?

How to get Log4j Version at Runtime in Java

Posted on 04:04 PM Wednesday January 12, 2022 by Jason
Is there any particular reason you chose the PropertiesUtil class to get the version information, as opposed to some other class? My first inclination would have been Logger since it's imported into the source file anyway.

Log4j CVE-2021-44228 Log4Shell Vulnerability on ColdFusion / Lucee

Posted on 11:36 PM Thursday December 30, 2021 by Michael
FYI: I have successfully started my development ACF2018 server under CommandBox by converting log4j.properties to log4j.xml using: java org.apache.log4j.config.Log4j1ConfigurationConverter --in=cfusion/lib/log4j.properties --out=cfusion/lib/log4j.xml --verbose I then removed log4j.properties and replaced all Log4j JARs with log4j-core-2.17.1.jar, log4j-api-2.17.1.jar, and log4j-to-slf4j-2.17.1.jar. It seems be working fine so far. This does not work with a standalone ACF2018 install(Unable to initialise Logging service: java.lang.NoClassDefFoundError: org/apache/log4j/Layout).

How to get Log4j Version at Runtime in Java

Posted on 10:05 AM Friday December 24, 2021 by XYZTST
Where to write this line and in which file? "org.apache.logging.log4j.util.PropertiesUtil.class.getPackage().getImplementationVersion()"

Log4j 1.x Vulnerability Mitigation Guide

Posted on 08:40 PM Thursday December 23, 2021 by Pete Freitag
@Andrew - I haven't seen any problems on Lucee with removing the vulnerable classes.

Log4j 1.x Vulnerability Mitigation Guide

Posted on 07:56 PM Thursday December 23, 2021 by Andrew
Does Lucee have any problems if we we remove those classes?

How to get Log4j Version at Runtime in Java

Posted on 05:42 PM Thursday December 23, 2021 by Pete Freitag
@Simranjit - That means the LOG4J_FORMAT_MSG_NO_LOOKUPS environment var / log4j2.formatMsgNoLookups system property is not set. You don't necessarily need to add it, it would only provide protection if you had a vulnerable jar somewhere that you didn't realize. The best solution is to make sure you have updated to log4j 2.17.0, because that fixes some issues that this environment variable / system property do not protect against.

How to get Log4j Version at Runtime in Java

Posted on 09:37 AM Thursday December 23, 2021 by Simranjit Singh
Thank you Pete, as always. I ran above code for CF and it displays "System Property / Env Var Not Defined". does that mean that LOG4J_FORMAT_MSG_NO_LOOKUPS is not used at all? If so, do I still need to add Dlog4j2.formatMsgNoLookups=true in jvm.config

Log4Shell Vulnerability Timeline

Posted on 08:14 PM Tuesday December 21, 2021 by Calvin
Sir, Thanks for the info. I replaced the the api,core and slf4j files. However I also see a log4j.jar file in the cfusion/lib directory. I do not see its replacement in apache-log4j-2.17.0-bin.zip file I received from the apache site. Am I missing something. Again excuse my ignorance.

Log4Shell Vulnerability Timeline

Posted on 06:21 PM Tuesday December 21, 2021 by Pete Freitag
@Calvin - Adobe have posted a KB saying that you can update the jars yourself, look in here for the link / latest info: https://www.petefreitag.com/item/923.cfm

Log4j CVE-2021-44228 Log4Shell Vulnerability on ColdFusion / Lucee

Posted on 05:22 PM Tuesday December 21, 2021 by Peter
Email Adobe support at [email protected] for the QOQ patches.

Log4Shell Vulnerability Timeline

Posted on 12:16 PM Tuesday December 21, 2021 by Calvin
Sir. Do you have insight when a patch might be out for log4j 2.17 for CF2021. Also my googlefu is lacking and I haven't found any simple directions on how to manually install log4j on CF. Any suggestions/direction would be greatly appreciated.

Log4Shell Vulnerability Timeline

Posted on 01:18 AM Tuesday December 21, 2021 by Charlie Arehart
Scott, it's that the updates for CF (3 for CF2021 and 13 for CF2018) DO in fact update those older log4j 1.2* jars. They modified them to remove the vulnerable jmsappender class. So yes, the old log4j 1.x jars are there, but not the ORIGINAL ones. If you or your folks run a scan, you will see it lacks the vulnerable class.

Log4j CVE-2021-44228 Log4Shell Vulnerability on ColdFusion / Lucee

Posted on 12:11 AM Tuesday December 21, 2021 by Dave Cordes
Hey Pete, Where are those hotfixes located for the QoQ issue?

Log4j CVE-2021-44228 Log4Shell Vulnerability on ColdFusion / Lucee

Posted on 06:45 PM Monday December 20, 2021 by Mike K
I just applied update 3 for CF 2021 to my dev box and the query of queries hotfix after update 2 stopped working. I had to re-copy the hotfix jar file and restart the server.

Log4j CVE-2021-44228 Log4Shell Vulnerability on ColdFusion / Lucee

Posted on 06:42 PM Monday December 20, 2021 by Peter
There is a minor update on the Adobe patches. If you applied the QOQ one-off hot fixes, they will have to be reapplied, hf201800-4212383 and hf202100-4212383.

Log4Shell Vulnerability Timeline

Posted on 02:13 PM Monday December 20, 2021 by Scott Kroyer
Hi Pete, I'm wondering if you would have any insight into why Adobe hasn't commented on or addressed the existence of log4j 1.2.15 in /{ColdFusion2018}/{cfusion}/lib and log4j 1.2.17 in /{ColdFusion2018}/{cfusion}/jetty/lib/ext. Both of those are also now considered to have severe vulnerabilities discussed in CVE-2021-4104 and CVE-2019-17571. Thanks!

Log4j CVE-2021-44228 Log4Shell Vulnerability on ColdFusion / Lucee

Posted on 01:27 AM Thursday December 16, 2021 by Nicole SMith
@Pete Freitag this is very exciting news please keep us up to date on the FuseGuard filter.

Log4j CVE-2021-44228 Log4Shell Vulnerability on ColdFusion / Lucee

Posted on 07:02 PM Wednesday December 15, 2021 by Pete Freitag
@Jim - depends how good your pattern is. The general consensus seems to be that it is very hard to protect 100% using patterns, but you may be able to get close. It certainly doesn't hurt as an extra layer of defense though, so go for it, but don't only rely on a WAF. I am actually working on a filter for FuseGuard that should be ready soon.

Log4j CVE-2021-44228 Log4Shell Vulnerability on ColdFusion / Lucee

Posted on 06:49 PM Wednesday December 15, 2021 by Jim
Can this be mitigated by using application firewall (WebKnight) to block multiple : or $ or {}?

Log4j CVE-2021-44228 Log4Shell Vulnerability on ColdFusion / Lucee

Posted on 05:32 PM Wednesday December 15, 2021 by Pete Freitag
@Tim - thanks, I added the link to their KB article to this blog entry yesterday. @Jeff - check the logs ;-) In all seriousness, that's a great question, and is outside of my area of expertise. I did see Microsoft has published some detection methods here: https://www.microsoft.com/security/blog/2021/12/11/guidance-for-preventing-detecting-and-hunting-for-cve-2021-44228-log4j-2-exploitation/ this page has a ton of info, take a look under "Detecting exploitation attempts" https://www.techsolvency.com/story-so-far/cve-2021-44228-log4j-log4shell/#detection-testers

Log4j CVE-2021-44228 Log4Shell Vulnerability on ColdFusion / Lucee

Posted on 05:21 PM Wednesday December 15, 2021 by Jeff
Hi Pete, thanks for the great info. Once we are patched (setting in place and 2.16 jars in my case), is there a way to determine if a server had been previously compromised?

Log4j CVE-2021-44228 Log4Shell Vulnerability on ColdFusion / Lucee

Posted on 03:44 PM Wednesday December 15, 2021 by Tim Fitzpatrick
Adobe did (finally) address this: https://helpx.adobe.com/coldfusion/kb/log4j-vulnerability-coldfusion.html

Log4j CVE-2021-44228 Log4Shell Vulnerability on ColdFusion / Lucee

Posted on 09:46 PM Tuesday December 14, 2021 by James Weishaar
Thank you for providing this examination of the problem/solution. I appreciate it.

Log4j CVE-2021-44228 Log4Shell Vulnerability on ColdFusion / Lucee

Posted on 09:08 PM Tuesday December 14, 2021 by CN
@Pete - But of course, we had to throw more gasoline on the fire. Again, many thanks on the continued coverage of this whole thing.

Log4j CVE-2021-44228 Log4Shell Vulnerability on ColdFusion / Lucee

Posted on 08:46 PM Tuesday December 14, 2021 by Pete Freitag
@CN - since you last blinked there is yet another wrinkle, you'll want to use 2.16.0 now instead of 2.15.0, there is a DOS issue. I think Adobe will probably provide the update in their hotfix on the 17th, you can try doing it yourself before then, I think some have and found it worked ok on ColdFusion 2018 / ColdFusion 2021.

Log4j CVE-2021-44228 Log4Shell Vulnerability on ColdFusion / Lucee

Posted on 08:27 PM Tuesday December 14, 2021 by CN
Hi Pete, On the forums there are lots of references to just swapping out the log4j libraries for the 2.15.0 updates. Do you have any thoughts on this since Adobe didn't seem to reply to any of the questions surrounding that? Thanks for all your hard work on this cavalcade of suck that surrounds this vulnerability.

Log4j CVE-2021-44228 Log4Shell Vulnerability on ColdFusion / Lucee

Posted on 06:00 PM Tuesday December 14, 2021 by chris
@Eric @Pete You most definitely can not just go from 1.x to 2.x (google it - the apache page mentions this). @Eric - you might not be vulnerable to this but CF11 has not been patched in a long while and in particular there was a critical security flaw fixed in march but only back to CF2016 - if your CF11 server is on the internet it's only a matter of time (and it might already be) until it's compromised. I highly suggest you update - which sucks because going from CF11 to CF2018/2021 is almost definitely going to break at least some code. We had issues just going from 2016 to 2018... You should really update java too - that should be painless - just requires installing it and pointing CF to the new JVM path in the admin. There are definitely existing vulnerabilities in 8u130...quite a few.

Log4j CVE-2021-44228 Log4Shell Vulnerability on ColdFusion / Lucee

Posted on 05:48 PM Tuesday December 14, 2021 by Pete Freitag
@chris - thanks I updated the blog entry already @pmascari - version 2.13.3 is vulnerable, but the JVM argument does protect that version. So I don't think you want to use the patched log4j 2.9.0 file in that case. You can remove the JndiLookup.class from the 2.13.3 jar if you want though.

Log4j CVE-2021-44228 Log4Shell Vulnerability on ColdFusion / Lucee

Posted on 05:33 PM Tuesday December 14, 2021 by pmascari
Thanks, Pete. Love your services! Adobe's mitigation steps are mentioning only version 2.9.0 of this JAR file. Our CF servers look to be using 2.13.3. Sorry, but I'm not clear if this affects us (CF2018) and if we should replace the file as Adobe suggests? Can you clarify? We HAVE put in the JVM arguments.

Log4j CVE-2021-44228 Log4Shell Vulnerability on ColdFusion / Lucee

Posted on 05:23 PM Tuesday December 14, 2021 by Chris
Adobe has officially released mitigation steps for each version of ColdFusion. This until if/when they release a patch themselves. https://helpx.adobe.com/coldfusion/kb/log4j-vulnerability-coldfusion.html

Log4j CVE-2021-44228 Log4Shell Vulnerability on ColdFusion / Lucee

Posted on 02:59 PM Tuesday December 14, 2021 by Pete Freitag
@Eric - I don't think it is possible to update log4j 1.x libraries to 2.x simply by replacing the jar file, but I haven't tested this out yet. Otherwise see the section on log4j 1.x in my entry.

Log4j CVE-2021-44228 Log4Shell Vulnerability on ColdFusion / Lucee

Posted on 01:02 PM Tuesday December 14, 2021 by Mohammed
Pete, thank you for pulling this together, it’s most helpful. FYI, I noticed yesterday that LunaSec’s recommendation to modify message patterns, %m{nolookups}, has been redacted as bad practice and is no longer a recommended mitigation.

Log4j CVE-2021-44228 Log4Shell Vulnerability on ColdFusion / Lucee

Posted on 10:24 AM Tuesday December 14, 2021 by Raffaele
Has anybody been able to reproduce a POC of this issue on Coldfusion?

Log4j CVE-2021-44228 Log4Shell Vulnerability on ColdFusion / Lucee

Posted on 07:09 PM Monday December 13, 2021 by Richard
Thanks! I'm primarily operations - but have what's probably a question with an obvious answer. With respect to this - is there any difference in placing -Dlog4j2.formatMsgNoLookups=true in: 1) placing iot in CFadmin window under JVM Arguments, or, 2) in the actual JVM.config? My understanding is that they are one and the same for this purpose - but wanted to make sure on this one.

Log4j CVE-2021-44228 Log4Shell Vulnerability on ColdFusion / Lucee

Posted on 05:38 PM Monday December 13, 2021 by eric belair
hi pete, i'm primarily a developer but have been tasked with handling this issue by a client because the "ColdFusion" guy. we're running CF11 with Java 1.8.0_130. it seems to me that we should not be affected or, at least there's nothing we can really do here outside of a full CF upgrade. is it possible to update the existing Log4j 1.2.15 libraries used by CF to the new version (2.15.0) with the fix? thanks, eric

Log4j CVE-2021-44228 Log4Shell Vulnerability on ColdFusion / Lucee

Posted on 05:13 PM Monday December 13, 2021 by Tim
Any thoughts on people still using CF 9 and earlier? seems like we are using ColdFusion9/runtime/../lib/log4j-1.2.15.jar scary times

Log4j CVE-2021-44228 Log4Shell Vulnerability on ColdFusion / Lucee

Posted on 04:17 PM Monday December 13, 2021 by Miguel-F
Thanks for the information Pete!

Log4j CVE-2021-44228 Log4Shell Vulnerability on ColdFusion / Lucee

Posted on 02:56 PM Monday December 13, 2021 by Matthew Clemente
Pete, you are the greatest. I really appreciate the time and insight you're sharing with everyone on this. Many thanks!

Log4j CVE-2021-44228 Log4Shell Vulnerability on ColdFusion / Lucee

Posted on 02:54 PM Monday December 13, 2021 by Pete Freitag
You're welcome @Ben it is crazy!! @Matthew - that's a good question, my understanding (and I could be wrong because I haven't spent adequate time investigating it), is that CVE-2019-17571 exists in the SocketServer, which you have to turn on and it has to be listening to untrusted traffic. According to this post (https://stackoverflow.com/questions/11759196/log4j-how-to-use-socketappender), you'd start the server in another process like this: java -classpath log4j.jar org.apache.log4j.net.SimpleSocketServer 4712 log4j-server.properties Then use the SocketAppender to write logs to the server. So based on that it doesn't look like something Lucee would be vulnerable to by default, but if you configured it to use the SocketAppender or the JMSAppender then you might have a concern.

Log4j CVE-2021-44228 Log4Shell Vulnerability on ColdFusion / Lucee

Posted on 02:45 PM Monday December 13, 2021 by Nik Y
Would this apply to CF on Linux and Windows? Where do you find the current version of log4j being used? Thanks for this info!

Log4j CVE-2021-44228 Log4Shell Vulnerability on ColdFusion / Lucee

Posted on 02:37 PM Monday December 13, 2021 by Matthew Clemente
Hey Pete, thanks so much for this. Any thoughts on this older CVE that does appear to impact Lucee? https://www.cvedetails.com/cve/CVE-2019-17571/ Thanks!

Log4j CVE-2021-44228 Log4Shell Vulnerability on ColdFusion / Lucee

Posted on 01:58 PM Monday December 13, 2021 by Ben Nadel
Thanks for putting this together, Pete! This is such crazy stuff!

Java LTS Version Roadmap and Guide

Posted on 06:48 PM Tuesday December 07, 2021 by B.H.
It would be nice if this information was officially published on openjdk.java.net.

Setting Lucee Admin Password with CommandBox

Posted on 04:16 PM Wednesday November 10, 2021 by Jonas Eriksson
And just a note, if you run several servers, I believe you need to tell it which server it applies to, such as: cfconfig set adminPassword=123password! to=myServerA

How to run Oracle DB on a Mac with Docker

Posted on 11:46 AM Wednesday October 13, 2021 by Antonio Gil
#7 14.77 sed: can't read /etc/security/limits.d/oracle-database-preinstall-18c.conf: No such file or directory This error happens on a Mac M1

Updating Java on ColdFusion or Lucee

Posted on 10:51 PM Tuesday September 14, 2021 by Andre Mascak
Hello, We've been trying to update Tomcat (tested both 9.0.52 and 10.0.10) on Lucee 5.3.8.201, but its seems like the update has been either stopping Tomcat from starting up properly, or causes the sites to kick out 404s when Tomcat would load (this was achieved by pulling mod_cfml related lines from the server.xml). We even tried a fresh Lucee install and encountered similar issues. Have you heard of any similar troubles?

Writing a GitHub Actions Workflow that Uses a Docker Image

Posted on 08:53 PM Thursday July 29, 2021 by Pete Freitag
Jason - you should have different output, eg when running in the container the java version will contain: "Zulu" when running without a container the default java would be "AdoptOpenJDK"

TLSv1 and TLSv1.1 Disabled by Default in Java after April 2021

Posted on 04:15 PM Wednesday June 02, 2021 by Pete Freitag
@Adam - changing jdk.tls.disabledAlgorithms should not require an OS reboot, but you will need to restart whatever java processes you have running.

TLSv1 and TLSv1.1 Disabled by Default in Java after April 2021

Posted on 08:14 PM Friday May 28, 2021 by Adam
Does anyone know if changing the jdk.tls.disabledAlgorithms security property requires a reboot of the operating system?

Java versions supporting TLS 1.3

Posted on 04:34 PM Tuesday May 11, 2021 by James Moberg
Thanks for the update. I removed the akamai host from my unit test as I didn't want to have to additionally inspect the content. https://tls13.1d.pw/ is a TLS1.3-ONLY server which means you can only connect to it using TLS1.3. (Connection failure = the HTTP request didn't use TLS1.3.)

Java versions supporting TLS 1.3

Posted on 04:19 PM Tuesday May 11, 2021 by Pete Freitag
James - thanks that's a nice test, I use those badssl.com hosts for testing as well, but they don't have one for TLS 1.3 yet. One thing about using tls13.akamai.io in a test like this is that it also responds to other protocols, so you'd have to inspect the fileContent to see if it really supports TLSv1.3. I probably should have made that more clear in the blog entry.

Java versions supporting TLS 1.3

Posted on 04:09 PM Tuesday May 11, 2021 by James Moberg
Another host that supports TLS 1.3 for testing purposes is https://tls13.1d.pw/ Here's a TestBox unit test if you wish to test and compare CFHTTP to modern Chrome browser behavior. (I've added akamai as the default TLS 1.3 host.) https://dev.to/gamesover/cfml-unit-tests-for-cfhttp-and-badssl-1lfa

URL Safe Base64 Encoding / Decoding in CFML

Posted on 05:18 PM Saturday May 08, 2021 by Linda Miles
How would you decode it in Javascript? When I try doing the regular base64Decode I get "\u0000\u0000" characters added to the back.

How to Resolve Java HTTPS Exceptions

Posted on 09:36 PM Friday May 07, 2021 by Charlie Arehart
Tim, sorry for the delay in replying since last week. I had been doing some digging. So has it really been that changing that keystore.type to jks was alone the solution for you? If so, that will be very interesting to hear, as I will explain. If it has not, I have another idea, in addition to the JVM debug logging option I'd mentioned. First, let's note for any following along that there has been variation over time (and over JVM versions) regarding that keystore.type (and its default) as found in that java.security file. And the availability of that keystore.type.compat option seems to have been added in about 1.8.0_60. (Note also that the location of that java.security file has also changed. In Java 8 it was indeed jre/lib/security, but in Java 11 it's now jre/conf/security). FWIW, CF2021 and 2018 come with Java 11 by default, and it's had those defaulted to pkcs12 and true since 11.0.1. And I see that for CF2016, and the JVM it came with by default (1.8.0_112), it has the default keystore.type set to jks and the compat=true, while CF11's default jvm (1.0.0_25) also had the keystore.type default of jks and no keystore.type.compat. Of course, if anyone changed the jvm that CF uses (which is indeed wise, as is the focus of this very post), then they need to pay attention to what version they are using, of course, and what their settings are. But second, you say that you had keystore.type.compat set to true, and in that case it seems it shouldn't have mattered what the keystore.type was, given how that compat works (from the comments in that java.security file, "When set to 'true', both JKS and PKCS12 keystore types support loading keystore files in either JKS or PKCS12 format.") So it's just very interesting to hear that changing it made any difference at all. If that was indeed really the solution for you, it seems there is more to this than is indicated by the comments in that file (and the java resources I have found so far). Now, moving on, what if you might confirm that changing it in fact did not really help (and it was just a matter of time before it started failing again)? I will say, third, if it is still happening for you and since you refer to how the problem had been coming and going, that is itself a key point. And I would wonder if it could be instead that somehow the ip address for which that domain is responding may be changing over time--but the JVM may be caching the DNS lookup (even if only breifly), and thus having it wrong. What's not clear is if that would lead to what seems a java security error, rather than just a general failure to connect. Pete may be able to confirm, if he's observed anything about this. And finally, if you or anyone ever needs to do debugging of the ssl/tls handshake that goes on between CF (java) and any outgoing https calls (whether from cfhttp or otherwise), that can be enabled via a jvm arg like this: -Djavax.net.debug=all There are other options besides all. One could set that (carefully) in the CF jvm.config file (in cfusion/bin, or your instancename/bin), but do be sure to save a copy in case CF won't start due to a mistake you may make. Then this https handshake debug loggind will appear either in the coldfusion-out.log (if you run CF as a service) or on the console (if you start CF from the console). Hope that's heplful.

Burst Throttling on AWS API Gateway Explained

Posted on 02:54 PM Friday April 30, 2021 by Pete Freitag
Thanks all! Glad to hear this is still useful. I know I've had to come back here and reference this myself a few times.

Burst Throttling on AWS API Gateway Explained

Posted on 02:39 PM Friday April 30, 2021 by Richard
The best explanation I've seen. I still find it difficult to know what is a reasonable balance between the rate, burst and lambda concurrency. At least I know what it all means now. Thank you!

How to Resolve Java HTTPS Exceptions

Posted on 06:11 PM Thursday April 29, 2021 by Tim Boonstra
I was not pointing a feature to a different keystore. This was just an cfhttp (https://production.shippingapis.com). This URL was the only URL that was causing issue. We could replicate it on multiple machines. It wouldn't work periodically, it would stop working until we reboot, restart CF, change JVM versions. But it would always stop working. The keystore in the /bin is coming back as type JKS so I changed the keystore.type to match. There is a setting for keystore.type.compat which is set to 'true' that looks like it will translate either JKS or PKCS12. This may be where the issue is with CF2021. Again, I am not pointing to any other keystore than the on listed in the 'Java Virtual Machine Path' If you want, tell me how to get the JVM debug you are looking for and I will get you that info.

How to Resolve Java HTTPS Exceptions

Posted on 05:32 PM Thursday April 29, 2021 by Charlie Arehart
Tim, that is of course very interesting to hear. But can you clarify: were using taht sort of keystore? The default is indeed a jks (the cacerts). Were you perhaps pointing some feature in CF (like a datasource's connectionstring, or a cfhttp, etc.) at some alternative keystore? If so, wouldn't it be true than that this change you propose is only suited to someone else in that same situation? I press the point because if everyone just did this, I'm wondering what the implications would be. It is indeed very interesting that you say your problem was that https requests would "coma and go", breaking for "no apparent reason", if by that you mean the same URL in the same CF tag or feature would sometimes work and then sometimes fail, like within minutes with no other change. I have indeed heard of some other people reporting that, and have not been able to help them solve that (since it's such an odd situation). I have suspected that jvm debug output of the ssl/tls handshake would help, but people are often either unable to do that (a jvm argument, requiring a restart), or the find the debug output to be voluminous and hard to get value from. So if your proposal here may well really be a solution that "about anyone should do", even if NOT pointing to some keystore other than the built-in lib/security/cacerts that the JVM uses by default, that is VERY interesting to hear. And I will look forward very much to any more that you, Pete, or others may have to offer about this. Thanks.

How to Resolve Java HTTPS Exceptions

Posted on 04:42 PM Thursday April 29, 2021 by Tim Boonstra
We've been plagued with 'nosuchalgorithmexception' on some HTTPS requests after updating to CF2021 on our dev boxes. It would come and go and break for no apparent reason. These articles got me doing more searching and I found a setting in the /bin/java.security file that seemed to fix our problem. We changed the line to 'keystore.type=jks' it was set to PKCS12. Tim

TLSv1 and TLSv1.1 Disabled by Default in Java after April 2021

Posted on 08:54 PM Wednesday April 28, 2021 by Charlie Arehart
And now we can report that yep, a week after this post, Oracle DID create a new JVM version, and in it they DO confirm that they added those TLS versions to the java.security file, and that "If you encounter issues, you can, at your own risk, re-enable the versions by removing "TLSv1" and/or "TLSv1.1" from the jdk.tls.disabledAlgorithms security property in the java.security configuration file." For more on the JVM updates (especially from the perspective of CF users), see a post I did: https://www.carehart.org/blog/client/index.cfm/2021/4/26/new_java_updates_for_Java_8_and_11_as_of_Apr_2021

Blocking .svn and .git Directories on Apache or IIS

Posted on 01:32 PM Tuesday April 27, 2021 by Chris
@Pete, thanks yes I added slashes today, just commenting here because the rule I pasted was auto generated by the lockdown tool, in case anyone else has the same problem.

Blocking .svn and .git Directories on Apache or IIS

Posted on 01:12 PM Tuesday April 27, 2021 by Pete Freitag
@Chris - looks like they are not escaping to dot in the pattern, which makes the dot behave like a wildcard and not a literal dot/period. Take a look at my blog entry above and notice mine has a slash before the dot.

Blocking .svn and .git Directories on Apache or IIS

Posted on 08:07 AM Tuesday April 27, 2021 by Chris
Working on some new CF2018 servers that had the lockdown tool run on them, noticed the redirect matches for git and svn were blocking any file or path containing those strings, so RedirectMatch 404 (?i).*.git.* was 404 redirecting for /digital.gif or /digital/index.htm for example, just FYI.

Docker Container exited with code 137

Posted on 06:37 PM Friday April 23, 2021 by Vishal
Thanks you. It worked and saved lot of time and effort.

TLSv1 and TLSv1.1 Disabled by Default in Java after April 2021

Posted on 10:40 PM Thursday April 15, 2021 by Charlie Arehart
Thanks as always, Pete. And lest any miss the point, this will "be disabled...by default" only in releases CREATED "after April 20, 2021". (It's my experience with news like this that some readers could miss such a point and be fearing that this change might "just happen" to them, even without updating the JVM version.) So to be clear: folks using Java 11.0.10 or Java 1.8.0_281 or earlier (the current Java "long term support releases") are unaffected, until those are updated and one implements that update. But great point about how to go about "trying" the change before a subsequent update forces the change.

How to Resolve Java HTTPS Exceptions

Posted on 06:02 PM Wednesday April 14, 2021 by Charlie Arehart
Great stuff as always, Pete. And reinforcing your first and last points (about how updating the JVM is nearly always the solution), I'll share for readers that I have a blog post discussing that in more detail: https://coldfusion.adobe.com/2019/06/error-calling-cf-via-https-solved-updating-jvm/ I will add a comment there pointing to this newer post of yours.

Using Hashicorp Vault with ColdFusion

Posted on 05:36 PM Wednesday April 14, 2021 by Joe
This is really helpful. Thanks, Pete. Just curious if I should have any security concerns with having the vault token stored as plain text as a system environment variables?

Docker Container exited with code 137

Posted on 02:28 AM Friday April 02, 2021 by Trung Vu
Thank you so much. My problem was solved.