Fixing the Java Serialization mess (Pierre Ernst)

Fixing the Java Serialization mess
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.

Biography
Pierre Ernst worked 10 years as a software developer in France, Belgium and Canada, in the telecom and biometric sector.

He spent the following 6 years working for IBM Canada where he was responsible for finding security vulnerabilities in 60 IBM products, mostly Java Web applications. Using a combination of manual testing and secure code review, he found more than 800 vulnerabilities.

More recently, Pierre Ernst had worked remotely for VMware (Palo Alto) focusing on attacking Java and Open Source and 3rd party Java components. He is currently employed by Salesforce (San Francisco, remote)