[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Jenkins and DWF assignment

The general thought was this is an intersection flaw, xstream has a safe option, it's just not the default, so until an actual app uses it unsafely, there's no flaw per se (much like SSL/TLS libs that don't check hostnames by default, but have a switch to do so). 

On Thu, Apr 27, 2017 at 10:10 PM, jericho <jericho@attrition.org> wrote:


Jenkins assigned a series of IDs using DWF-format yesterday. In the middle of them is an assignment for an issue that impacts them, but is in a third-party library.

   XStream: Java crash when trying to instantiate void/Void  SECURITY-503
   / CVE-2017-1000355 Jenkins uses the XStream library to serialize and
   deserialize XML. Its maintainer recently published a security
   vulnerability that allows anyone able to provide XML to Jenkins for
   processing using XStream to crash the Java process. In Jenkins this
   typically applies to users with permission to create or configure items
   (jobs), views, or agents.  Jenkins now prohibits the attempted
   deserialization of void / Void that results in a crash.

Can you clarify if this assignment was made by DWF, with the knowledge that one of the IDs was for a third-party library, or if Jenkins requested a block and assigned it themselves?



Kurt Seifried

Page Last Updated or Reviewed: May 15, 2017