[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <564C9260.5070505@eenterphace.org>
Date: Wed, 18 Nov 2015 15:59:44 +0100
From: Moritz Bechler <mbechler@...terphace.org>
To: oss-security@...ts.openwall.com
Subject: Re: Re: CVE request: Jenkins remote code execution
vulnerability due to unsafe deserialization
Hi,
the question that remains is, what do we do about this vulnerability
class in general. To whom do I report these?
The options I see right now:
a) If we say that performing deserialization of data crossing a
privilege boundary is a vulnerability per se we can probably assign a
CVE for almost every single piece of java software out there, as this
includes:
- every product with an, even optional, JMX listener.
- any other use of RMI/JRMP
- use of JMS ObjectMessage, with an implementation that has no further
checks.
- use of JPA to store Serializable properties in databases, with an
implementation that has no further checks.
- custom deserialization stuff
- potentially many more...
b) We go back to the start and say that these are vulnerabilities in the
libraries, that deserialization should be safe.
c) If we say that we need both the deserialization and a useable item on
the classpath (so that we have an actual exploitable vulnerability)
things get rather complicated as we have to identify both the "gadgets"
from b) and the products from a) using them.
d) Consider specifications/protocols "vulnerable", either in a way that
they allow the deserialization of untrusted inputs, or going deeper the
java deserialization mechanism itself.
In any case, both a) and c) lead to a rather big amount (one might even
call unmanagable) of vulnerability instances.
So, let us assume for a moment I went looking for other gadgets and
found instances in other widely used libraries, what do I do with them:
1) report them to the library vendor
or
2) search for projects using them, see if they use something mentioned
in a), and report to maybe hundreds of projects. Non OS projects would
propably never notice these. And I really can't spend the rest of the
year with this.
This is quite a mess.
Moritz
PS: If you are trying to fix these in your products. Don't, i repeat ,
DON'T, try to do it by blacklisting.
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
