Zero Day attack due to Apache Commons statement to widespread Java object de-serialisation vulnerability
89 views
Skip to first unread message
Indra Gunawan (ingunawa)
Dec 7, 2015, 7:56:28 PM12/7/15
to jenkins...@googlegroups.com
Building on Frohoff's tool ysoserial, Stephen Breen (@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 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
Mark Waite
Dec 7, 2015, 8:09:58 PM12/7/15
to jenkins...@googlegroups.com
Yes, based on https://jenkins-ci.org/content/mitigating-unauthenticated-remote-code-execution-0-day-jenkins-cli , that is impacting Jenkins.
The link you posted states that Jenkins is affected. It includes the link to the above Jenkins blog posting which describes a remediation you can take with your existing Jenkins version, and a statement that 1.625.2 includes the fix. If you read those two postings, you'll be able to answer your own questions, including describing the bug and its vulnerability (whatever that means to you).
Never waste a crisis. In this case, use it as the opportunity to upgrade your environment to Java 8 (or at least to Java 7), and to install the latest Jenkins long term support release (1.625.2).
Mark Waite
--
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-use...@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.
Christopher Orr
Dec 8, 2015, 2:53:13 AM12/8/15
to jenkins...@googlegroups.com
Also note that, if you're planning a Jenkins upgrade anyway, there's
another Jenkins release coming out tomorrow (1.625.3) to fix one or more
new security issues:
https://groups.google.com/forum/#!topic/jenkinsci-advisories/UbJeKl4Vxbw
So, you may want to apply the CLI workaround from the blog post that
Mark linked to just now, and do a full upgrade tomorrow (or more likely
Thursday, as releases seem to be done in US West Coast working hours).
Regards,
Chris
On 08/12/15 02:09, Mark Waite wrote:
> Yes, based
> on https://jenkins-ci.org/content/mitigating-unauthenticated-remote-code-execution-0-day-jenkins-cli ,
> that is impacting Jenkins.
>
> The link you posted states that Jenkins is affected. It includes the
> link to the above Jenkins blog posting which describes a remediation you
> can take with your existing Jenkins version, and a statement that
> 1.625.2 includes the fix. If you read those two postings, you'll be
> able to answer your own questions, including describing the bug and its
> vulnerability (whatever that means to you).
>
> Never waste a crisis. In this case, use it as the opportunity to
> upgrade your environment to Java 8 (or at least to Java 7), and to
> install the latest Jenkins long term support release (1.625.2).
>
> Mark Waite
>
> On Mon, Dec 7, 2015 at 5:56 PM Indra Gunawan (ingunawa)
> <ingu...@cisco.com <mailto:ingu...@cisco.com>> wrote:
>
> 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
> * Jenkins LTS users should update to 1.625.2
> <https://groups.google.com/d/msgid/jenkinsci-users/CAO49JtF%3D%2BmqQAdL-5wMUJKPrhAZwaQocdyLmyqh9h%3D81MO8Dvg%40mail.gmail.com?utm_medium=email&utm_source=footer>.
another Jenkins release coming out tomorrow (1.625.3) to fix one or more
new security issues:
https://groups.google.com/forum/#!topic/jenkinsci-advisories/UbJeKl4Vxbw
So, you may want to apply the CLI workaround from the blog post that
Mark linked to just now, and do a full upgrade tomorrow (or more likely
Thursday, as releases seem to be done in US West Coast working hours).
Regards,
Chris
On 08/12/15 02:09, Mark Waite wrote:
> Yes, based
> on https://jenkins-ci.org/content/mitigating-unauthenticated-remote-code-execution-0-day-jenkins-cli ,
> that is impacting Jenkins.
>
> The link you posted states that Jenkins is affected. It includes the
> link to the above Jenkins blog posting which describes a remediation you
> can take with your existing Jenkins version, and a statement that
> 1.625.2 includes the fix. If you read those two postings, you'll be
> able to answer your own questions, including describing the bug and its
> vulnerability (whatever that means to you).
>
> Never waste a crisis. In this case, use it as the opportunity to
> upgrade your environment to Java 8 (or at least to Java 7), and to
> install the latest Jenkins long term support release (1.625.2).
>
> Mark Waite
>
> On Mon, Dec 7, 2015 at 5:56 PM Indra Gunawan (ingunawa)
> <ingu...@cisco.com <mailto:ingu...@cisco.com>> wrote:
>
> https://blogs.apache.org/foundation/entry/apache_commons_statement_to_widespread
>
> Building on Frohoff's tool ysoserial
> <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
> 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
> 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
> 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 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-use...@googlegroups.com
> <mailto:jenkinsci-use...@googlegroups.com>.
>
> 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-use...@googlegroups.com
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-users/D28B6AAB.3D25B%25ingunawa%40cisco.com
> <https://groups.google.com/d/msgid/jenkinsci-users/D28B6AAB.3D25B%25ingunawa%40cisco.com?utm_medium=email&utm_source=footer>.
> https://groups.google.com/d/msgid/jenkinsci-users/D28B6AAB.3D25B%25ingunawa%40cisco.com
> --
> 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-use...@googlegroups.com
> <mailto:jenkinsci-use...@googlegroups.com>.
> 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-use...@googlegroups.com
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-users/CAO49JtF%3D%2BmqQAdL-5wMUJKPrhAZwaQocdyLmyqh9h%3D81MO8Dvg%40mail.gmail.com
> <https://groups.google.com/d/msgid/jenkinsci-users/CAO49JtF%3D%2BmqQAdL-5wMUJKPrhAZwaQocdyLmyqh9h%3D81MO8Dvg%40mail.gmail.com?utm_medium=email&utm_source=footer>.
Stephen Connolly
Dec 8, 2015, 5:09:58 AM12/8/15
to jenkins...@googlegroups.com
As somebody on the jenkins-cert list, I highly recommend upgrading to 1.625.3
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-use...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/5666899D.7020708%40orr.me.uk.
Indra Gunawan (ingunawa)
Dec 12, 2015, 12:44:48 PM12/12/15
to jenkins...@googlegroups.com
Starting from 1.625.1:
1.625.1 is the first Jenkins LTS release that requires Java 7 to run. If
you're using the Maven Project type, please note that it needs to use a
JDK capable of running Jenkins, i.e. JDK 7 or up. If you configure an
older JDK in a Maven Project, Jenkins will attempt to find a newer JDK and
use that automatically. If your SSH Slaves fail to start and you have the
plugin install the JRE to run them, make sure to update SSH Slaves Plugin
to at least version 1.10.
With the Java 7 to run requirement, I want to confirm the following:
1. Jenkins master and all its slave needs to run JDK 7 or above (JDK7 or
above to run Jenkins master process and SSH slave to connect needs to run
JDK 7 or above).
2. Maven type job then should work because SSH slave already runs JDK 7 or
above.
3. However, if the maven project still needs JDK 6, I can still set the
JDK in the job configuration or Injecting JAVA_HOME to JDK 6 and it will
use JDK 6 to build the pom.xml and project right?
Should I try to setup JDK 8 in master and all slaves for 1 & 2.
Thank you
-Indra
On 12/7/15, 11:41 PM, "jenkins...@googlegroups.com on behalf of
Christopher Orr" <jenkins...@googlegroups.com on behalf of
>> Š
>email to jenkinsci-use...@googlegroups.com.
>e.uk.
1.625.1 is the first Jenkins LTS release that requires Java 7 to run. If
you're using the Maven Project type, please note that it needs to use a
JDK capable of running Jenkins, i.e. JDK 7 or up. If you configure an
older JDK in a Maven Project, Jenkins will attempt to find a newer JDK and
use that automatically. If your SSH Slaves fail to start and you have the
plugin install the JRE to run them, make sure to update SSH Slaves Plugin
to at least version 1.10.
With the Java 7 to run requirement, I want to confirm the following:
1. Jenkins master and all its slave needs to run JDK 7 or above (JDK7 or
above to run Jenkins master process and SSH slave to connect needs to run
JDK 7 or above).
2. Maven type job then should work because SSH slave already runs JDK 7 or
above.
3. However, if the maven project still needs JDK 6, I can still set the
JDK in the job configuration or Injecting JAVA_HOME to JDK 6 and it will
use JDK 6 to build the pom.xml and project right?
Should I try to setup JDK 8 in master and all slaves for 1 & 2.
Thank you
-Indra
On 12/7/15, 11:41 PM, "jenkins...@googlegroups.com on behalf of
Christopher Orr" <jenkins...@googlegroups.com on behalf of
>To view this discussion on the web visit
>https://groups.google.com/d/msgid/jenkinsci-users/5666899D.7020708%40orr.m
>e.uk.
Daniel Beck
Dec 16, 2015, 3:07:42 PM12/16/15
to jenkins...@googlegroups.com
On 12.12.2015, at 18:44, Indra Gunawan (ingunawa) <ingu...@cisco.com> wrote:
> With the Java 7 to run requirement, I want to confirm the following:
> 1. Jenkins master and all its slave needs to run JDK 7 or above (JDK7 or
> above to run Jenkins master process and SSH slave to connect needs to run
> JDK 7 or above).
> 2. Maven type job then should work because SSH slave already runs JDK 7 or
> above.
> 3. However, if the maven project still needs JDK 6, I can still set the
> JDK in the job configuration or Injecting JAVA_HOME to JDK 6 and it will
> use JDK 6 to build the pom.xml and project right?
Indra Gunawan (ingunawa)
Dec 16, 2015, 8:28:07 PM12/16/15
to jenkins...@googlegroups.com
Point #3 is not possible because of this new change in 1.625.1?
1.625.1 is the first Jenkins LTS release that requires Java 7 to run. If
you're using the Maven Project type, please note that it needs to use a
JDK capable of running Jenkins, i.e. JDK 7 or up. If you configure an
older JDK in a Maven Project, Jenkins will attempt to find a newer JDK and
use that automatically. If your SSH Slaves fail to start and you have the
plugin install the JRE to run them, make sure to update SSH Slaves Plugin
to at least version 1.10.
If we patch the Jenkins to run 1.625.3, maven 2 type project using JDK 6
won¹t work anymore?
Thank you
-Indra
On 12/16/15, 12:07 PM, "jenkins...@googlegroups.com on behalf of
Daniel Beck" <jenkins...@googlegroups.com on behalf of
>53BE75776FDF%40beckweb.net.
1.625.1 is the first Jenkins LTS release that requires Java 7 to run. If
you're using the Maven Project type, please note that it needs to use a
JDK capable of running Jenkins, i.e. JDK 7 or up. If you configure an
older JDK in a Maven Project, Jenkins will attempt to find a newer JDK and
use that automatically. If your SSH Slaves fail to start and you have the
plugin install the JRE to run them, make sure to update SSH Slaves Plugin
to at least version 1.10.
won¹t work anymore?
Thank you
-Indra
On 12/16/15, 12:07 PM, "jenkins...@googlegroups.com on behalf of
Daniel Beck" <jenkins...@googlegroups.com on behalf of
>--
>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-use...@googlegroups.com.
>To view this discussion on the web visit
>https://groups.google.com/d/msgid/jenkinsci-users/30EE23F8-7344-4C15-8C04-
>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-use...@googlegroups.com.
>To view this discussion on the web visit
>53BE75776FDF%40beckweb.net.
Stephen Connolly
Dec 17, 2015, 7:34:49 AM12/17/15
to jenkins...@googlegroups.com
Correct... the evil job type is... evil...
Freestyle will work just fine
You also should be able to make toolchains work, i.e. that Maven can use Java 7 or 8 to run and Java 6 to compile.
Keep in mind that JDK 9 or JDK 10 will have a lower bound on the -target so that you will probably be only allowed to have your -target at 1.8 or higher so you would need to switch to toolchains if you still want to keep building for a Java version that was end-of-life in Feb 2013
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/D2974ECC.3E7D5%25ingunawa%40cisco.com.
Reply all
Reply to author
Forward
0 new messages