log4j vulnerability via logback-classic?

[kannes]

Hi you lovely people!

Sorry for abusing the bug tracker for something that is more like a question but I think this is where others might search for "log4j" in the context of OpenTripPlanner.

Is OTP affected by the log4j vulnerability?

From what I found it uses logback-classic and jul-to-slf4j (https://github.com/opentripplanner/OpenTripPlanner/blob/dev-2.x/pom.xml#L390-L400).

logback 1.2.5 as used by OTP seems to be affected: https://jira.qos.ch/browse/LOGBACK-1591

I have no idea what the difference for logback-classic could be and I really have no idea about Java logging at all, so please excuse me if this is a stupid question. I am just a user. Thank you! :)

[leonardehrenfried]

OTP 1 or 2 doesn't use log4j at all. You can verify this by running mvn depdency:tree and inspect the output.

The linked exploit for logback (https://github.com/cn-panda/logbackRceDemo) exists, however you have to allow two things for this to be triggered:

• arbitrary file uploads which overwrite the logback config file
• set scan=true in the logback.xml file

Neither is true for OTP. It doesn't have file uploads at all.

So, in my view this is a low priority item. Sure, we should update logback now but I don't see the need to urgently deploy new versions.

Can you confirm this?

[kannes]

That is great to hear, thank you very for the quick response! Feel free to close it :)