It's Time for "Hardned Java"

With the new Java vulnerability making the rounds I think it's time for an OpenJDK vendor to pick up the glove and release a "Hardened OpenJDK". A version that will be resistant to exploits even if a vulnerability exists!

Here's how this will look...

I want to preface this by saying: I'm not a security expert. But the general problem with Java is the HUGE surface area.

Removing some "problematic" features and disabling their default behaviors can address most issues before they even begin.

To be clear this will break compatibility for some apps so every feature will need to be togglable by configuration. It can't be called Java but it can be based on an OpenJDK fork and adapting your code should be trivial. It can still be pretty compatible by passing a TCK with whitelisted features required by the TCK. Still the whitelisting process is effectively an incompatible requirement.

Every time a check blocks something it should throw an exception so we can fix/whitelist this if necessary by our apps.

This is similar to the SecurityManager that can be leveraged for this purpose. However, that class was designed for client-side code.

Read Only Filesystem

This will block many exploits like the recent Spring4Shell. You need to write to a file you MUST whitelist it. You can't rename files or change executable properties etc. without explicitly whitelisting this.

No Execution

This would outright block most common exploits. Runtime.exec, Process etc. will require whitelisting specific commands.

No native libraries that aren't whitelisted obviously.

No "Problematic APIs"

JNDI and similar APIs that have been used in exploits in the past.

Serialization

Serialization would have a filter on by default that would block all classes except for explicitly whitelisted classes.

Sanitized Logging

All logged data will be sanitized by default. Since most logs go through JUL this can be done relatively easily although will include some performance overhead.

Certificate Pinning

All outgoing network connections should use pinned certificates or be explicitly whitelisted. This is a tough one...

But we need a way to mitigate potential forgeries.

I'm guessing this is a feature many will turn off.

Final Word

I understand why Oracle can't do that. Java's "thing" is compatibility and that's great!

This seems like a place where an OpenJDK vendor can make a difference.

Thoughts? Improvements? Corrections?