Yep, and thanks, Pete. Glad I worded things as I did, saying that we’d have to see how that assertion of theirs panned out.
Bummer to see them just remove it rather than strike it out, with a brief explanation. (And thanks for the updates you’ve shared to Hackmycf customers.)
Just joining on this one. We are looking for confirmation that this is not an issue in Lucee standard install as well.
To anyone using the Spreadsheet CFML library (formerly Lucee Spreadsheet) version 3.1.0, there’s a new 3.2.0 release which replaces the vulnerable log4j jar with the 2.15.0 patch. Log4j was only introduced in the 3.1.0 release (via POI 5.1.0) so if you hadn’t upgraded to that version it’s not urgent.
Yea I thought we would be safe initially, but Lucee does use log4j. This is also an interesting article:
I added “-Dlog4j2.formatMsgNoLookups=true” in the lucee options just to be sure.
I’m getting lots of questions about log4j v1.2.17 being bundled into Lucee (we have v5.2.8.189 in production) and whether this presents a vulnerability. The criteria apparently being whether there is an ‘appender’ using JDNI present.
And the follow-up question being, is a version of Lucee planned with log4j v2.15?
Cheers,
B)
So grateful for this Zackster! Thank you!
I’m grateful for that too - but how do I explain that to people looking at the jar files in Lucee and see Apache Log4j 1.2 loaded and active?
sorry - I see the comment from Zacster is actually link. Thank you!
Yeah - Zackster addressed that at the bottom.
what file did you add that line in?
@DrunkenMoose I second @kevco’s question, where did you make the change for Lucee?
I was looking around C:\lucee\jre\bin and C:\lucee\jre\conf directories, but not seeing it there.
EDIT: I found C:\lucee\jre\lib\jvm.cfg which is possibly what we’re looking for, although a default install only seems to have “-server KNOWN -client KNOWN” entries, but the syntax with the leading -'s appears correct. Can anyone confirm?
For some of our ACF 10 servers, adding the “-Dlog4j2.formatMsgNoLookups=true” was easy under ACF Admin Panel > Settings > Java and JVM, had a text field to paste config options there, but not finding similar in Lucee.
Note that according to lucasec,
the ‘formatMsgNoLookups’ property was added in version 2.10.0, per the JIRA Issue LOG4J2-2109 [1] that proposed it. Therefore the ‘formatMsgNoLookups=true’ mitigation strategy is available in version 2.10.0 and higher
source: https://www.lunasec.io/docs/blog/log4j-zero-day/
I’m on lucee 5.3.8.206 and it sadly comes with log4j 1.2.17 . This setting has no effect.
Well I think that you can put it in the lucee JVM options, see: Updating Memory Settings :: Lucee Documentation. So I haven’t put it in any file, but the program itself (that is being used to startup lucee)
But as stated this option only is useable if you actually use a log4j version above 2.0, and lucee has a lower version so it ignores this option. I also tried deleting the jar file all together, but lucee just remakes this jar on startup. I don’t use any log4j functions, but perhaps in underlying jar files it is used. So I hope Zackster is correct when stating lucee isn’t effected ^^
JVM args are really a concern of the servlet container. Adobe bundles their engine with a hacked up version of Tomcat, which allows them a tighter integration with it. Lucee, on the other hand, ships a vanilla Tomcat version in their installer, but can be installed on any servlet container you like. So really, the question is what servlet container you’re using and how does that software allow you to configure JVM args. On Tomcat/Linux, it’s usually in the setenv.sh file. On Tomcat/Windows, it’s in the properties of the service control like the link above says. If you’re using CommandBox, you can put in the jvm.args property of your server.json.
Yes, version 2.10.x specifically 
This is worth noting since Adobe ColdFusion 2018 update 10, for example, ships with Log4j 2.9 which means it’s potentially vulnerable, but the JVM args will not work on it.
Yes, log4j is a required bundle for Lucee, so it’s not an option to remove it if you want Lucee to work! It is re-downloading or re-extracting it since it’s required for Lucee to run.
Yes, it’s used internally for different things. Lucee has its own logging system so I’m not entirely sure if Lucee’s core uses it or if it’s most a dependency for other Apache libs.
The version of Log4j Lucee bundles automatically is not vulnerable. The question really is whether you have any custom jars you’ve dropped in or custom extensions you’ve installed that use a later version of log4j. In which case, the JVM arg may be an effective method of mitigating them (depending on the exact version in use) If you’re not sure if any of your third party libraries use log4j, I posted a scanning tool I wrapped in a Task Runner in the thread Zac linked to above. You can have it scan the entire Lucee home dir and it will recursively check every jar to see if any of them are vulnerable.
Yes, but to be clear it’s not really “sad” because the JNDI exploit does not exist in Log4j 1.2.17 So there’s really no use for the JVM arg there. The Log4j versions you need to be wary of are 2.0 to 2.14.1.
Thanks for your detailed explanation! I know we use a jar file that contains a lot of jar files inside of it, so not really sure if it’s being used inside of that. But looking at it from a different perspective is: what outside people can call what functions? We make internal applications and thus most calls are only for authorized users. So a cfspreadsheet call somewhere inside isn’t really making me nervous. And perhaps a firewall rule for ‘${jndi:ldap://’ could also help if people are still unsure.
WAF rules are more or less useless/provide a false sense of security, because most attacks are now splitting the strings up
You can recursively scan jar files for vulnerable versions of log4j with this tool
what outside people can call what functions?
It’s not that users of your app can directly invoke Java methods. It would be a matter of tricking your application into logging a message that contained the special string and hoping that message was logged via a vulnerable version of Log4j.
Hey guys, I’m looking into this right now for a client and it’s been a while since I worked with Lucee. I’m basically a newbie now. The server is running on Ubuntu 18 with Lucee 4.5.5.0.15 final. I checked the log4j which is located at “/opt/lucee/lib/apache-logging-log4j.jar” on the server and it seems to be version 1.2.16. I have a few questions if someone could kindly help me with:
Will this vulnerability affect this server if I don’t do anything?
If this log4j version is an issue, can I just update it with the patched log4j jar file and it will be ok or do I have to do something more to fix this? If yes, where do I find the log4j patched file?
Should I upgrade Lucee to the latest version? If so, which one and will it fix this log4j vulnerability?
Any help is appreciated as it’s been a long time since I worked with Lucee.
Thank you,
Mike