> The underlying bug in log4j is having a deserialization mechanism that can automatically deserialize to any class in the system
Getting objects out of a directory services is what JNDI is all about, I'm hesitant to call it a bug.
The bug is that Java is way too keen on dynamically loading code at runtime. Probably because it was created in the 90s, where doing that was kinda all the rage. I think retrospectively the conclusion is that it may be the easiest way to make things extensible short-term, but also the worst way for long-term maintenance. Just ask Microsoft about that.
"Getting objects out of a directory services is what JNDI is all about, I'm hesitant to call it a bug."
I didn't call it a bug. I called it a bit of functionality that makes the security problem possible. There are many things that result in security issues that come from some programmer making something just too darned convenient, but are otherwise "features", not some mistake or something.
It's the underlying problem. You should have to declare what classes are able to be deserialized. To the extent that it's inconvenient, well, so was the log4j issue.
Getting objects out of a directory services is what JNDI is all about, I'm hesitant to call it a bug.
The bug is that Java is way too keen on dynamically loading code at runtime. Probably because it was created in the 90s, where doing that was kinda all the rage. I think retrospectively the conclusion is that it may be the easiest way to make things extensible short-term, but also the worst way for long-term maintenance. Just ask Microsoft about that.