Re: CVE-2021-4104: Deserialization of untrusted data in JMSAppender in Apache Log4j 1.2

[Moritz Bechler <mbechler () eenterphace org>]

Hello,

> JMSAppender in Log4j 1.2 is vulnerable to deserialization of untrusted data when the attacker has write access to the 
> Log4j configuration. The attacker can provide TopicBindingName and TopicConnectionFactoryBindingName configurations 
> causing JMSAppender to perform JNDI requests that result in remote code execution in a similar fashion to 
> CVE-2021-44228.
>
> Note this issue only affects Log4j 1.2 when specifically configured to use JMSAppender, which is not the default.

Pretty sure someone was pushing for this, sorry to be nagging again, but 
I don't think adding that to the overall panic and confusion is really 
helping.

To emphasize again: this needs write access to the Log4j configuration.

This is in no way even coming close to CVE-2021-44228 - log4j 1.2 is 
absolutely unaffected by that bug.

Only for people allowing untrusted parties to modify logger 
configuration this could be considered to cross a trust boundary. 
Allowing that, in my opinion, already would require very careful 
consideration on the caller/user side and cannot be assumed to be safe.

If one can modify the logger configuration, one might as well 
(re)configure a FileAppender and write to files with the process 
privileges - most likely also resulting in code execution.

Everybody else should probably forget about this - expect for the fact 
that they still might be using software that has been unsupported for 
many years.

Configuring e.g. DataSources via JNDI name lookups is not that uncommon 
in Java applications and application servers, these all suffer from the 
same "vulnerability". JNDI is a overly complex mess of bad surprises 
(and in my opinion absolutely should go away), but that is really not 
log4j's fault.



Moritz