Why no JNDI de-ser killswitch

[Bernd Eckenfels]

That policy to not comment on security issues is really frustrating. Or even worse are there other reasons I get ignored?

Anyway, i got a note on Twitter that 17 and 8(April) backport has a specific system property already:

➜<https://www.oracle.com/java/technologies/javase/8u291-relnotes.html#JDK-8244473> New System and Security Properties to Control Reconstruction of Remote Objects by JDK's Built-in JNDI RMI and LDAP Implementations

jdk.jndi.object.factoriesFilter

com.sun.jndi.ldap.object.trustSerialData

Those seem to be an important fix, not sure how I could miss them and why nobody mentioned them in the log4shell discussions yet.

Gruss
Bernd


--
http://bernd.eckenfels.net
________________________________
Von: security-dev <security-dev-retn at openjdk.java.net> im Auftrag von Bernd Eckenfels <ecki at zusammenkunft.net>
Gesendet: Monday, December 13, 2021 7:28:53 AM
An: security-dev at openjdk.java.net <security-dev at openjdk.java.net>
Betreff: Why no JNDI de-ser killswitch

Hello,

I can understand that ldapcontext.lookup() still has to use unsafe deserialisation for legacy reasons (JMS factories etc). But it would be really good if there would be a bit more infra like a killswitch or url-prefix filter JNDI for those who don’t need that.

It was a rather damaging move to claim that there is a fix when the actual rce with JNDI is still present.

I tink the new ObjectInputStream filters (jep290) are a good thing, but they are not easy to set globally on a bigger app server,especially not with 8 and 11 without jep415. So I think that’s not sufficient

Gruss
Bernd


--
http://bernd.eckenfels.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20211214/8b45e2ce/attachment.htm>