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 <[email protected]> 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. >
