search

bcgit / bc-java

Bouncy Castle Java Distribution (Mirror)
https://www.bouncycastle.org/java.html
MIT License
2.29k stars 1.13k forks source link

LDAP Entry Poisoning in JndiDANEFetcherFactory #239

Open dkwakkel opened 6 years ago

dkwakkel commented 6 years ago

At line 114: bindings = ctx.listBindings("_smimecert." + domainName);

If not using LDAP to store Java objects, do not perform object-returning searches just for the benefit of getting a DirContext wrapper representing the result entry. Fetch the attributes using a regular search.

There are certain APIs that always enforce the usage of object-returning searches such as, for example, the Spring LdapTemplate.search() methods taking ContextMapper instances as arguments. There is no secure usage of these APIs and they should be avoided. Consider using an AttributesMapper instead to avoid decoding returned attributes as Java objects.

References:

[1] Introducing JNDI Injection and LDAP Entry Poisoning, HPE, https://community.hpe.com/t5/Security-Research/Introducing-JNDI-Injection-and-LDAP-Entry-Poisoning/ba-p/6885118

[2] A Journey from JNDI/LDAP manipulation to remote code execution dream land, BlackHat, https://www.blackhat.com/docs/us-16/materials/us-16-Munoz-A-Journey-From-JNDI-LDAP-Manipulation-To-RCE-wp.pdf

bcgit commented 6 years ago

I'm not 100% clear on this one. If I read correctly this is about preventing the API from falling foul of a poor implementation based on Spring LDAP, is that correct?

I think NameClassPair would probably help here (although the getNameInNamespace() isn't supported pre-1.5). I'll need to find/setup a decent test server before I can confirm this though.