https://blogs.apache.org/foundation/entry/apache_commons_statement_to_widespread
Building on Frohoff's tool ysoserial<https://github.com/frohoff/ysoserial>, Stephen Breen (@breenmachine<https://twitter.com/breenmachine>) of Foxglove Security inspected various products like WebSphere, JBoss, Jenkins, WebLogic, and OpenNMS and describes (http://foxglovesecurity.com/2015/11/06/what-do-weblogic-websphere-jboss-jenkins-opennms-and-your-application-have-in-common-this-vulnerability/) for each of them various attack scenarios. Both research works show that developers put too much trust in Java Object Serialization. Some even de-serialize objects pre-authentication. When deserializing an Object in Java you typically cast it to an expected type, and therefore Java's strict type system will ensure you only get valid object trees. Unfortunately, by the time the type checking happens, platform code has already created and executed significant logic. So, before the final type is checked a lot of code is executed from the readObject() methods of various objects, all of which is out of the developer's control. By combining the readObject() methods of various classes which are available on the classpath of the vulnerable application an attacker can execute functions (including calling Runtime.exec() to execute local OS commands). The best protection against this, is to avoid using a complex serialization protocol with untrusted peers. It is possible to limit the impact when using a custom ObjectInputStream which overridesresolveClass<http://docs.oracle.com/javase/7/docs/api/java/io/ObjectInputStream.html#resolveClass%28java.io.ObjectStreamClass%29> to implement a whitelist approach http://www.ibm.com/developerworks/library/se-lookahead/. This might however not always be possible, such as when a framework or application server provides the endpoint. This is rather bad news, as there is no easy fix and applications need to revisit their client-server protocols and overall architecture. ... Is this truly impacting Jenkins? Our IT suggests the following Jenkins version to upgrade before the end of year shut-down. I want to know the impact of this bug, and its vulnerability. Remediation: * Jenkins main line users should update to 1.638 * Jenkins LTS users should update to 1.625.2 Thank you -Indra -- You received this message because you are subscribed to the Google Groups "Jenkins Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/D28B6AAB.3D25B%25ingunawa%40cisco.com. For more options, visit https://groups.google.com/d/optout.
