4 ms·
The linked article says "No such safe method is available for Java serialization, so your best bet in Java is not to use Java serialization unless you absolutel
by matt_heimer 11y ago
The linked article says "No such safe method is available for Java serialization, so your best bet in Java is not to use Java serialization unless you absolutely trust whoever is producing the data".
This is wrong. It is trivial to mitigate this issue and it only takes a couple of lines of code. For a step-by-step guide from 2013 see http://www.ibm.com/developerworks/library/se-lookahead/ http://www.ibm.com/developerworks/library/se-lookahead/
- pron 11y agoAnother way to solve this it is to only call readResolve/readObject(ObjectInputStream) under a different security policy (a different AccessControlContext from the caller). The problem is that both approaches (lookahead or security policy) require you to use a custom ObjectInputStream class.
- matt_heimer 11y agoThe article has been updated to include subclassing ObjectInputStream as a possible mitigation.
- wsargent 11y agoThere's two problems with the lookahead approach: 1) It only applies to the code you write. Libraries can still use insecure object serialization under the hood i.e. you can't apply this to an built in app server running JMX. 2) It doesn't account for pathological objects, i.e. a billion laughs attack: https://gist.github.com/coekie/a27cc406fc9f3dc7a70d https://gist.github.com/coekie/a27cc406fc9f3dc7a70d More details here: https://tersesystems.com/2015/11/08/closing-the-open-door-of-java-object-serialization/ https://tersesystems.com/2015/11/08/closing-the-open-door-of...