You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@logging.apache.org by "Volkan Yazici (Jira)" <ji...@apache.org> on 2021/12/13 08:48:00 UTC

[jira] [Commented] (LOG4J2-3210) Not effective deserialisation controls

    [ https://issues.apache.org/jira/browse/LOG4J2-3210?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17458212#comment-17458212 ] 

Volkan Yazici commented on LOG4J2-3210:
---------------------------------------

Thanks so much for your kind interest and help [~b.eckenfels], much appreciated! I think, it is highly likely that the next release will ship two things:
 # JNDI lookup is disabled by default.
 # Message lookups feature is completely removed, not disabled!

If I am not mistaken, this limits the impact surface of JNDI-related potential vulnerabilities to the configuration level. That is, those will only be exploitable if the attacker has rights to tamper the configuration, which is a whole different thing than a simple unpriviledged attack.

{_}I think{_}, JNDI lookup shouldn't be fixed at all. That effort has been proved to be futile, that feature is a dangerous, and anybody who is still willing to use it takes a huge risk that they better workaround its security implications.

If you disagree, please feel free to comment. Otherwise, I'd appreciate it if you can close the ticket, granted your points are addressed.

> Not effective deserialisation controls
> --------------------------------------
>
>                 Key: LOG4J2-3210
>                 URL: https://issues.apache.org/jira/browse/LOG4J2-3210
>             Project: Log4j 2
>          Issue Type: Bug
>          Components: Core
>    Affects Versions: 2.15.0
>            Reporter: Bernd Eckenfels
>            Priority: Major
>              Labels: SECURITY, jndi
>
> The new JNDILookup protection by disabling the lookups and by disabling JNDI is effective. However, since you still keep the JNDI Lookup Code around I had a look at the new restrictions, and I don’t think they are affective:
> a) there is no protection (allowed host/port) for the RMI protocol. It should probably use the same allowed hosts than LDAP does
> b) when checking the allowed class in the LDAP case you asume the class Attribute is actually the class which is serialized. This must not be true, an attacker can pretend their object is a java.lang.Stringˋ which will pass your filter. Later on when you use lookup the JNDI code will try to deserialize the object - and then it is too late.
> My suggesting would be to not use context.lookup() if not needed and/or disallow all forms of serialized data (which might not work for the JMSManager case?). Anyway, for the `${jndi:`-lookup case I can imagine only string attributes are needed anyway?
> Is it safe to allow the whole java: context and how would you restrict absolute /… names without an prefix? (At the moment I guess they will get the java:env prefix since there is no logic to skip that with leading slash?)
> Sidenote: there is also a osgi: scheme which could be useful, but also dangerous.
> BTW the disabled JNDIManager with the context==null, it should have a comment what it’s meaning is „// create unusable JNDIManager with context == null“ and I am also not sure if it is only created with this code path.. maybe better to check the the isJndiEnabled also in the constructor? (I sent a pull request with a minor rename of the isIs.. method as well).



--
This message was sent by Atlassian Jira
(v8.20.1#820001)