ceki edited a comment on pull request #608: URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-991730650
Thank you for the detailed references. **If the attacker can modify the config file on some system S, then S can be assumed to be already penetrated to a large extent.** If the attacker can modify log4j.properties (log4j 1.x), she does not need to download malicious code, she can just as easily place malicious class files in the classpath and have them executed. So, in a very strict sense there is a vulnerability in log4j 1.x but nothing close to log parameter induced RCE. > @ceki @remkop - it is not exactly true that it doesn't suffer from lookup issue though. > > If you look at how jndi works in 1.x you will find that there are two places where lookups are done - that is JMSAppender.java:207 and JMSAppender.java:222 - if you set TopicBindingName or TopicConnectionFactoryBindingName to something that JNDI can handle - for example "ldap://host:port/a"; JNDI will do exactly the same thing it does for 2.x - so 1.x is vulnerable, just attack vector is "safer" as it depends on configuration rather than user input -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: notifications-unsubscr...@logging.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
