This might not be the best place to discuss this (?), but I do have a
follow-up on the agent-approuch to mitigating deserialization attacks:
I think it would be safer to whitelist expected uses of deserialization
instead of trying to blacklist the "bad" ones.
Of course, maintaining a list of safely deserialised classes by hand can be
quite a challenge. I think a possibly workable solution would be to record
actual uses of deserialisation on the running application. Then that list
could be used later as a whitelist.
Anything not whitelisted would then fail on deserialisation (not on
instanceof checks, but on actual readObject calls)
Here's a rough implementation of this "deserialization firewall" idea:
https://github.com/kantega/invoker-defender/tree/whitelist
The recording option could be useful in itself for anyone who wants to know
what and when their application is deserializing objects.
Cheers,
Eirik.
On Mon, Nov 9, 2015 at 12:34 PM, Eirik Bjørsnøs wrote:
>
> Hi,
>
> Following the "recent" "news" about Java deserialization security issues,
> I decided to create:
>
> https://github.com/kantega/invoker-defender/
>
> This is a Java Agent which removes java.io.Serializable from classes known
> to be vulnerable to deserialization attacks. (Including InvokerTransformer)
>
> I do not in any way consider this a complete solution to the problem since
> it only "fixes" a few well known classes.
>
> But it might be something people could consider as a mitigation effort
> while vendors/projects work on more long-term fixes.
>
> Feedback is welcome.
>
> Cheers,
> Eirik.
>
