Re: Fuzzing the Java core libs

[Fabian Meumertzheim]

On Thu, May 13, 2021 at 1:22 PM Alan Bateman 
wrote:

> The workflow is shown on the Vulnerability Group page [1]. There isn't a
> repo that you can test commits on before the publication date.
>
> -Alan
>
> [1] https://openjdk.java.net/groups/vulnerability/
>

Based on the information on that page, there should be no conflict between
the OpenJDK and the OSS-Fuzz policies regarding disclosures (
https://google.github.io/oss-fuzz/getting-started/bug-disclosure-guidelines/
).

Is there anyone who would volunteer to receive the finding reports? Every
report comes with a stack trace and the exact input that reproduces the
finding with the fuzzer, i.e., is immediately actionable.

Examples of such reports for fixed bugs can be found at
https://bugs.chromium.org/p/oss-fuzz/issues/list?q=proj%3A%22json-sanitizer%22%20OR%20proj%3A%22fastjson2%22%20OR%20proj%3A%22jackson-core%22%20OR%20proj%3A%22jackson-dataformats-binary%22%20or%20proj%3A%22apache-commons%22=1

Re: Fuzzing the Java core libs

[Alan Bateman]

On 13/05/2021 10:37, Fabian Meumertzheim wrote:
OSS-Fuzz files bugs in a Monorail instance (of 
https://bugs.chromium.org 
 
fame), which can be used to discuss the issues, but of course doesn't 
have to be. Authentication to that Monorail instance as well as to 
oss-fuzz.com 
, 
which provides additional information on findings and fuzzer 
performance, is tied to Google accounts.


All findings (security or not) remain confidential for 90 days (+ a 
possibility for a grace period) or until OSS-Fuzz determines that the 
finding no longer reproduces against the source repository (i.e., a 
fix has been committed).


Does the OpenJDK security workflow rely on commits with purposefully 
innocuous messages to the main branch for embargoed security issues? 
If that's the case, we should ensure that the OSS-Fuzz policies don't 
conflict with the OoenJDK security policies before performing the 
integration.


The workflow is shown on the Vulnerability Group page [1]. There isn't a 
repo that you can test commits on before the publication date.


-Alan

[1] https://openjdk.java.net/groups/vulnerability/

Re: Fuzzing the Java core libs

[Fabian Meumertzheim]

OSS-Fuzz files bugs in a Monorail instance (of https://bugs.chromium.org
fame), which can be used to discuss the issues, but of course doesn't have
to be. Authentication to that Monorail instance as well as to oss-fuzz.com,
which provides additional information on findings and fuzzer performance,
is tied to Google accounts.

All findings (security or not) remain confidential for 90 days (+ a
possibility for a grace period) or until OSS-Fuzz determines that the
finding no longer reproduces against the source repository (i.e., a fix has
been committed).

Does the OpenJDK security workflow rely on commits with purposefully
innocuous messages to the main branch for embargoed security issues? If
that's the case, we should ensure that the OSS-Fuzz policies don't conflict
with the OoenJDK security policies before performing the integration.

On Thu, May 13, 2021, 10:51 Alan Bateman  wrote:

> On 13/05/2021 09:14, Fabian Meumertzheim wrote:
> > I'm one of the maintainers of Jazzer (
> > https://github.com/CodeIntelligenceTesting/jazzer), a new open-source
> > fuzzer for the JVM platform. Jazzer has recently been integrated into
> > Google's OSS-Fuzz (https://google.github.io/oss-fuzz/) to allow for free
> > continuous fuzzing of important open-source Java projects. Jazzer has
> > already found over a hundred bugs and eight security issues in libraries
> > such as Apache Commons, PDFBox and the OWASP json-sanitizer.
> >
> > Jazzer finds unexpected exceptions and infinite loops by default, but can
> > also be used to check domain-specific properties such as
> > decrypt(encrypt(data)) == data. Since it tracks the coverage it achieves
> > using instrumentation applied by a Java agent, it can synthesize
> > interesting test data from scratch.
> >
> > If there is interest from your side, I could set up the Java core
> libraries
> > themselves for fuzzing in OSS-Fuzz. Especially the parts that are
> > frequently applied to untrusted input, such as java.security.* and
> > javax.imageio.*, would benefit from fuzz tests. I have prepared basic
> fuzz
> > tests for some of the classes in these packages at
> >
> https://github.com/CodeIntelligenceTesting/oss-fuzz/tree/openjdk/projects/openjdk
> ,
> > which has already resulted in the first bug report (JDK-8267086).
> >
> > All I would need from you is:
> >
> > * a list of email addresses to which the fuzzer findings should be sent
> > (ideally associated with Google accounts for authentication to full
> reports
> > on oss-fuzz.com),
> > * ideas for additional fuzz tests, in particular those where there are
> > interesting properties to verify.
> >
> > The technical questions about setting up the OpenJDK in OSS-Fuzz have
> > already been resolved (see also
> > https://github.com/google/oss-fuzz/issues/5757).
> >
> > If you need more information on OSS-Fuzz or fuzzing in general, I am
> happy
> > to help.
> I have one ask. As you mention, sometimes fuzzing will report issues
> issues that may be security issues. It often requires experts in
> particular areas to look at an issue and decide if it a functional or
> security issue. If there is any question mark over an issue then the
> assumption is that it is a security issue until determined otherwise. In
> that context it may not be possible to engage on the mailing lists here
> about these issues. Oracle engineers are strictly prohibited from
> engaging in any discussions on mailing lists about potential
> vulnerability issues. I suspect many other contributors are somewhat
> restricted too but I think everyone is very responsible and knows not to
> discuss sensitive issues that may need patching. So all I ask is that if
> the fuzzer finds issues that may be security issues that they should be
> reported to the vunl-report list [1] and not discussed on the mailing
> list. I'm not suggesting to sign up the vunl-report list for
> notifications of course, but whoever is triaging these issues should
> know how to report issues.
>
> -Alan
>
> [1] https://openjdk.java.net/groups/vulnerability/report
>

Re: Fuzzing the Java core libs

[Alan Bateman]

On 13/05/2021 09:14, Fabian Meumertzheim wrote:

I'm one of the maintainers of Jazzer (
https://github.com/CodeIntelligenceTesting/jazzer), a new open-source
fuzzer for the JVM platform. Jazzer has recently been integrated into
Google's OSS-Fuzz (https://google.github.io/oss-fuzz/) to allow for free
continuous fuzzing of important open-source Java projects. Jazzer has
already found over a hundred bugs and eight security issues in libraries
such as Apache Commons, PDFBox and the OWASP json-sanitizer.

Jazzer finds unexpected exceptions and infinite loops by default, but can
also be used to check domain-specific properties such as
decrypt(encrypt(data)) == data. Since it tracks the coverage it achieves
using instrumentation applied by a Java agent, it can synthesize
interesting test data from scratch.

If there is interest from your side, I could set up the Java core libraries
themselves for fuzzing in OSS-Fuzz. Especially the parts that are
frequently applied to untrusted input, such as java.security.* and
javax.imageio.*, would benefit from fuzz tests. I have prepared basic fuzz
tests for some of the classes in these packages at
https://github.com/CodeIntelligenceTesting/oss-fuzz/tree/openjdk/projects/openjdk,
which has already resulted in the first bug report (JDK-8267086).

All I would need from you is:

* a list of email addresses to which the fuzzer findings should be sent
(ideally associated with Google accounts for authentication to full reports
on oss-fuzz.com),
* ideas for additional fuzz tests, in particular those where there are
interesting properties to verify.

The technical questions about setting up the OpenJDK in OSS-Fuzz have
already been resolved (see also
https://github.com/google/oss-fuzz/issues/5757).

If you need more information on OSS-Fuzz or fuzzing in general, I am happy
to help.
I have one ask. As you mention, sometimes fuzzing will report issues 
issues that may be security issues. It often requires experts in 
particular areas to look at an issue and decide if it a functional or 
security issue. If there is any question mark over an issue then the 
assumption is that it is a security issue until determined otherwise. In 
that context it may not be possible to engage on the mailing lists here 
about these issues. Oracle engineers are strictly prohibited from 
engaging in any discussions on mailing lists about potential 
vulnerability issues. I suspect many other contributors are somewhat 
restricted too but I think everyone is very responsible and knows not to 
discuss sensitive issues that may need patching. So all I ask is that if 
the fuzzer finds issues that may be security issues that they should be 
reported to the vunl-report list [1] and not discussed on the mailing 
list. I'm not suggesting to sign up the vunl-report list for 
notifications of course, but whoever is triaging these issues should 
know how to report issues.


-Alan

[1] https://openjdk.java.net/groups/vulnerability/report

Fuzzing the Java core libs

[Fabian Meumertzheim]

I'm one of the maintainers of Jazzer (
https://github.com/CodeIntelligenceTesting/jazzer), a new open-source
fuzzer for the JVM platform. Jazzer has recently been integrated into
Google's OSS-Fuzz (https://google.github.io/oss-fuzz/) to allow for free
continuous fuzzing of important open-source Java projects. Jazzer has
already found over a hundred bugs and eight security issues in libraries
such as Apache Commons, PDFBox and the OWASP json-sanitizer.

Jazzer finds unexpected exceptions and infinite loops by default, but can
also be used to check domain-specific properties such as
decrypt(encrypt(data)) == data. Since it tracks the coverage it achieves
using instrumentation applied by a Java agent, it can synthesize
interesting test data from scratch.

If there is interest from your side, I could set up the Java core libraries
themselves for fuzzing in OSS-Fuzz. Especially the parts that are
frequently applied to untrusted input, such as java.security.* and
javax.imageio.*, would benefit from fuzz tests. I have prepared basic fuzz
tests for some of the classes in these packages at
https://github.com/CodeIntelligenceTesting/oss-fuzz/tree/openjdk/projects/openjdk,
which has already resulted in the first bug report (JDK-8267086).

All I would need from you is:

* a list of email addresses to which the fuzzer findings should be sent
(ideally associated with Google accounts for authentication to full reports
on oss-fuzz.com),
* ideas for additional fuzz tests, in particular those where there are
interesting properties to verify.

The technical questions about setting up the OpenJDK in OSS-Fuzz have
already been resolved (see also
https://github.com/google/oss-fuzz/issues/5757).

If you need more information on OSS-Fuzz or fuzzing in general, I am happy
to help.

Fabian (@fmeum on GitHub)