Deserializing untrusted input with Java has been known to be a risky proposition for at least 10 years. More recently, several vulnerabilities exploiting this flaw have been published. These deserialization vulnerabilities can be divided into 2 groups: endpoints allowing deserialization of arbitrary classes known to the application, or serialization "gadgets" allowing to weaponize malicious input for these endpoints. When it comes to fixing this class of vulnerabilities, it is hard to reach a consensus: some library maintainers consider that there is no point fixing the "gadgets" and that all application should simply stop accepting serialized input. Easier said than done…
While the root cause of the issue lies with a lenient Java API (not allowing to specify which class is to be deserialized), we need an immediate fix. This is why I came up with the seminal "Look-ahead Java deserialization" concept in 2013.
During this talk, the look-ahead mitigation will be bypassed with a live demo, and a more robust white-listing technique will be presented
Bonus: CVE-2016-3427 will be presented for the 1st time.