You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Tero Saarni <te...@est.tech> on 2021/05/24 16:20:21 UTC
OSS-Fuzz issues are being reported as vulnerabilities
Hi,
We are getting reports from JFrog Xray vulnerability scanner that seem to be
related to recently fixed OSS-Fuzz issues:
* Summary: Apache Commons Compress archivers/zip/ZipFile.java
ZipFile::readCentralDirectoryEntry() Function Uncaught Exception DoS
Severity: High
* Summary: Apache Commons Compress archivers/tar/TarArchiveEntry.java
TarArchiveEntry::processPaxHeader() Function Uncaught Runtime Exception DoS
Severity: High
In previous thread it was said that none of the fuzzer findings was deemed
security issues. Were these incorrectly flagged by the vulnerability scanner?
I'd be curious to know if there is planned date for commons-compress 1.21?
Best regards
Tero
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: OSS-Fuzz issues are being reported as vulnerabilities
Posted by Tero Saarni <te...@est.tech>.
On Tuesday, May 25, 2021 00:04 Bernd wrote:
> BTW: I was not Aware that JFrog has its own vulnerability feed, is that the
> Snyk Knowledge Base or do they have their own analysts?
They used to use Snyk, but since few years ago they say it is based on
VulnDB from Risk Based Security.
--
Tero
[1] https://jfrog.com/xray/
[2] https://vulndb.cyberriskanalytics.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: OSS-Fuzz issues are being reported as vulnerabilities
Posted by Stefan Bodewig <bo...@apache.org>.
On 2021-05-24, Bernd wrote:
> Am Mo., 24. Mai 2021 um 20:46 Uhr schrieb Matt Sicker <bo...@gmail.com>:
>> There's also a bit of an issue of fixing these types of
>> vulnerabilities at the library level. The library itself typically
>> won't have much in the way of a security model until you integrate it
>> into an application.
> That is true in general, but we have for the found issues (which are not
> OOM) two possibilities, catch the runtime exceptions and rethrow them as a
> IOException (Maybe a new subtype like MalformedArchiveException extends
> IOException) or document in javadoc that the runtime exceptions dealing
> with Out of Bounds and maybe NullPointers might be thrown. Do you think
> this is a good idea?
So far we've preferred the "throw an IOException" approach in
Compress. In some areas like handling of ZIP extra fields we're simply
catching all RuntimeExcepiton and rethrow them as IOExceptions, in most
other cases we try to identify the cases where a RuntimeException would
occur and throw an IOException prior to that.
> - I can prepare a patch for it, would prefer a new specific sub
> exception.
My changes so far have focussed on avoiding the exception alltogether
rather than "catch everything at the API entry point" as I was hoping to
catch errors early and avoid OOMs and infinite loops by more aggressive
bounds checks.
Some of Compress' packages have got a big public API for historic
reasons. The tar package is probably the worst offender with TarUtils
having lots of methods that are public for no good reason, some of which
don't even declare any checked exceptions to be thrown. Here "document
the exception" is the only thing you can do - and catch/rethrow inside
of the other code parts that call them.
> Having said that, it is not uncommon that a size field is used to allocate
> Buffers, in that case an OOM is possible and a Limit Manager would be
> helpful. This does not only help against malicious files. Not sure if the
> fuzzer wil find that in the future...
Some of our packages support a custom option that says "don't use more
than X MB", but this is limited to a few algorithms that do provide
estimates like LZMA and XZ. So far OSS Fuzz is not setting this option
for anything (I believe this only applies to the 7z case currently) so
OSS Fuzz could run into OOMs that users could avoid by setting the given
option - something we could change if we wanted to.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: OSS-Fuzz issues are being reported as vulnerabilities
Posted by Bernd <ec...@zusammenkunft.net>.
Hello,
Am Mo., 24. Mai 2021 um 20:46 Uhr schrieb Matt Sicker <bo...@gmail.com>:
> There's also a bit of an issue of fixing these types of
> vulnerabilities at the library level. The library itself typically
> won't have much in the way of a security model until you integrate it
> into an application.
That is true in general, but we have for the found issues (which are not
OOM) two possibilities, catch the runtime exceptions and rethrow them as a
IOException (Maybe a new subtype like MalformedArchiveException extends
IOException) or document in javadoc that the runtime exceptions dealing
with Out of Bounds and maybe NullPointers might be thrown. Do you think
this is a good idea? - I can prepare a patch for it, would prefer a new
specific sub exception.
Having said that, it is not uncommon that a size field is used to allocate
Buffers, in that case an OOM is possible and a Limit Manager would be
helpful. This does not only help against malicious files. Not sure if the
fuzzer wil find that in the future...
BTW: I was not Aware that JFrog has its own vulnerability feed, is that the
Snyk Knowledge Base or do they have their own analysts?
Gruss
Bernd
> For example, if you only use commons-compress on
> trusted input, then even high availability impact vulnerabilities can
> be mitigated by not exercising that code. On the other hand, a more
> generic file upload service or media manager or similar application
> might not be resilient to its libraries having these types of input
> bugs which could potentially crash the JVM (like an OutOfMemoryError
> if not handled).
>
> I'd be far more concerned about fuzzing any libraries here that make
> JNI calls or use any of the Unsafe APIs. Java's basic memory safety
> helps avoid most of the common horrifying CVEs that similar C/C++
> libraries suffer from, but linking into native code can break that.
> This can also apply to any classes in the standard library which
> invoke native code themselves (think things like AWT).
>
> On Mon, 24 May 2021 at 12:56, Fabian Meumertzheim
> <me...@code-intelligence.com> wrote:
> >
> > The JFrog reports seem to reference the following two OSS-Fuzz findings,
> > which have not been classified as security issues:
> >
> > https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=34437
> > https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=33959
> >
> > OSS-Fuzz and Jazzer, its Java fuzzer, never mark uncaught exceptions as
> > security issues, but simply as ordinary bugs. Only things like
> > OutOfMemoryErrors on relatively small inputs are marked as potential
> > security issues, albeit with a severity rating of "Low". Of course, the
> > rating can always be adjusted manually if it doesn't fit the program
> > policies. For example, some projects seem to consider OutOfMemoryError
> > caused by overly large allocations to be just bugs and reserve
> > the "security issue" label for e.g. those caused by infinite loops.
> >
> > If JFrog decides to report the issues above as security issues and even
> > assigns an unreasonably high severity rating, the fault (and
> fearmongering)
> > is entirely on them.
> >
> > Fabian
> >
> >
> >
> > On Mon, May 24, 2021 at 7:03 PM Stefan Bodewig <bo...@apache.org>
> wrote:
> >
> > > On 2021-05-24, Tero Saarni wrote:
> > >
> > > > We are getting reports from JFrog Xray vulnerability scanner that
> seem
> > > > to be related to recently fixed OSS-Fuzz issues:
> > >
> > > I wasn't aware of this effect. This is very unfortunate.
> > >
> > > > * Summary: Apache Commons Compress archivers/zip/ZipFile.java
> > > > ZipFile::readCentralDirectoryEntry() Function Uncaught Exception
> DoS
> > > > Severity: High
> > >
> > > > * Summary: Apache Commons Compress archivers/tar/TarArchiveEntry.java
> > > > TarArchiveEntry::processPaxHeader() Function Uncaught Runtime
> > > Exception DoS
> > > > Severity: High
> > >
> > >
> > > > In previous thread it was said that none of the fuzzer findings was
> > > > deemed security issues. Were these incorrectly flagged by the
> > > > vulnerability scanner?
> > >
> > > Historically we have never considered uncaught runtime exceptions to be
> > > security issues. We've fixed similar issues in the past and still do.
> > >
> > > So when I said nothing had been a deemed a security issue I meant
> > > "deemed by us". Unfortunately the OSS Fuzz classification doesn't match
> > > ours.
> > >
> > > There are a few more cases around 7z that have not been flagged as
> > > security issues - I have no idea why not.
> > >
> > > In all cases corrupt archives may cause RuntimeExceptions
> > > (ArrayIndexOutOfBounds, IllegalArgument, BufferUnderflow, ...) rather
> > > than IOExceptions. If you try to read archives from untrusted sources,
> > > this may lead to unexpected exceptions.
> > >
> > > > I'd be curious to know if there is planned date for commons-compress
> > > > 1.21?
> > >
> > > There is no planned date I was aware of.
> > >
> > > Stefan
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > > For additional commands, e-mail: dev-help@commons.apache.org
> > >
> > >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
Re: OSS-Fuzz issues are being reported as vulnerabilities
Posted by Matt Sicker <bo...@gmail.com>.
There's also a bit of an issue of fixing these types of
vulnerabilities at the library level. The library itself typically
won't have much in the way of a security model until you integrate it
into an application. For example, if you only use commons-compress on
trusted input, then even high availability impact vulnerabilities can
be mitigated by not exercising that code. On the other hand, a more
generic file upload service or media manager or similar application
might not be resilient to its libraries having these types of input
bugs which could potentially crash the JVM (like an OutOfMemoryError
if not handled).
I'd be far more concerned about fuzzing any libraries here that make
JNI calls or use any of the Unsafe APIs. Java's basic memory safety
helps avoid most of the common horrifying CVEs that similar C/C++
libraries suffer from, but linking into native code can break that.
This can also apply to any classes in the standard library which
invoke native code themselves (think things like AWT).
On Mon, 24 May 2021 at 12:56, Fabian Meumertzheim
<me...@code-intelligence.com> wrote:
>
> The JFrog reports seem to reference the following two OSS-Fuzz findings,
> which have not been classified as security issues:
>
> https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=34437
> https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=33959
>
> OSS-Fuzz and Jazzer, its Java fuzzer, never mark uncaught exceptions as
> security issues, but simply as ordinary bugs. Only things like
> OutOfMemoryErrors on relatively small inputs are marked as potential
> security issues, albeit with a severity rating of "Low". Of course, the
> rating can always be adjusted manually if it doesn't fit the program
> policies. For example, some projects seem to consider OutOfMemoryError
> caused by overly large allocations to be just bugs and reserve
> the "security issue" label for e.g. those caused by infinite loops.
>
> If JFrog decides to report the issues above as security issues and even
> assigns an unreasonably high severity rating, the fault (and fearmongering)
> is entirely on them.
>
> Fabian
>
>
>
> On Mon, May 24, 2021 at 7:03 PM Stefan Bodewig <bo...@apache.org> wrote:
>
> > On 2021-05-24, Tero Saarni wrote:
> >
> > > We are getting reports from JFrog Xray vulnerability scanner that seem
> > > to be related to recently fixed OSS-Fuzz issues:
> >
> > I wasn't aware of this effect. This is very unfortunate.
> >
> > > * Summary: Apache Commons Compress archivers/zip/ZipFile.java
> > > ZipFile::readCentralDirectoryEntry() Function Uncaught Exception DoS
> > > Severity: High
> >
> > > * Summary: Apache Commons Compress archivers/tar/TarArchiveEntry.java
> > > TarArchiveEntry::processPaxHeader() Function Uncaught Runtime
> > Exception DoS
> > > Severity: High
> >
> >
> > > In previous thread it was said that none of the fuzzer findings was
> > > deemed security issues. Were these incorrectly flagged by the
> > > vulnerability scanner?
> >
> > Historically we have never considered uncaught runtime exceptions to be
> > security issues. We've fixed similar issues in the past and still do.
> >
> > So when I said nothing had been a deemed a security issue I meant
> > "deemed by us". Unfortunately the OSS Fuzz classification doesn't match
> > ours.
> >
> > There are a few more cases around 7z that have not been flagged as
> > security issues - I have no idea why not.
> >
> > In all cases corrupt archives may cause RuntimeExceptions
> > (ArrayIndexOutOfBounds, IllegalArgument, BufferUnderflow, ...) rather
> > than IOExceptions. If you try to read archives from untrusted sources,
> > this may lead to unexpected exceptions.
> >
> > > I'd be curious to know if there is planned date for commons-compress
> > > 1.21?
> >
> > There is no planned date I was aware of.
> >
> > Stefan
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
> >
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: OSS-Fuzz issues are being reported as vulnerabilities
Posted by Fabian Meumertzheim <me...@code-intelligence.com>.
The JFrog reports seem to reference the following two OSS-Fuzz findings,
which have not been classified as security issues:
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=34437
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=33959
OSS-Fuzz and Jazzer, its Java fuzzer, never mark uncaught exceptions as
security issues, but simply as ordinary bugs. Only things like
OutOfMemoryErrors on relatively small inputs are marked as potential
security issues, albeit with a severity rating of "Low". Of course, the
rating can always be adjusted manually if it doesn't fit the program
policies. For example, some projects seem to consider OutOfMemoryError
caused by overly large allocations to be just bugs and reserve
the "security issue" label for e.g. those caused by infinite loops.
If JFrog decides to report the issues above as security issues and even
assigns an unreasonably high severity rating, the fault (and fearmongering)
is entirely on them.
Fabian
On Mon, May 24, 2021 at 7:03 PM Stefan Bodewig <bo...@apache.org> wrote:
> On 2021-05-24, Tero Saarni wrote:
>
> > We are getting reports from JFrog Xray vulnerability scanner that seem
> > to be related to recently fixed OSS-Fuzz issues:
>
> I wasn't aware of this effect. This is very unfortunate.
>
> > * Summary: Apache Commons Compress archivers/zip/ZipFile.java
> > ZipFile::readCentralDirectoryEntry() Function Uncaught Exception DoS
> > Severity: High
>
> > * Summary: Apache Commons Compress archivers/tar/TarArchiveEntry.java
> > TarArchiveEntry::processPaxHeader() Function Uncaught Runtime
> Exception DoS
> > Severity: High
>
>
> > In previous thread it was said that none of the fuzzer findings was
> > deemed security issues. Were these incorrectly flagged by the
> > vulnerability scanner?
>
> Historically we have never considered uncaught runtime exceptions to be
> security issues. We've fixed similar issues in the past and still do.
>
> So when I said nothing had been a deemed a security issue I meant
> "deemed by us". Unfortunately the OSS Fuzz classification doesn't match
> ours.
>
> There are a few more cases around 7z that have not been flagged as
> security issues - I have no idea why not.
>
> In all cases corrupt archives may cause RuntimeExceptions
> (ArrayIndexOutOfBounds, IllegalArgument, BufferUnderflow, ...) rather
> than IOExceptions. If you try to read archives from untrusted sources,
> this may lead to unexpected exceptions.
>
> > I'd be curious to know if there is planned date for commons-compress
> > 1.21?
>
> There is no planned date I was aware of.
>
> Stefan
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
Re: OSS-Fuzz issues are being reported as vulnerabilities
Posted by Stefan Bodewig <bo...@apache.org>.
On 2021-05-24, Tero Saarni wrote:
> We are getting reports from JFrog Xray vulnerability scanner that seem
> to be related to recently fixed OSS-Fuzz issues:
I wasn't aware of this effect. This is very unfortunate.
> * Summary: Apache Commons Compress archivers/zip/ZipFile.java
> ZipFile::readCentralDirectoryEntry() Function Uncaught Exception DoS
> Severity: High
> * Summary: Apache Commons Compress archivers/tar/TarArchiveEntry.java
> TarArchiveEntry::processPaxHeader() Function Uncaught Runtime Exception DoS
> Severity: High
> In previous thread it was said that none of the fuzzer findings was
> deemed security issues. Were these incorrectly flagged by the
> vulnerability scanner?
Historically we have never considered uncaught runtime exceptions to be
security issues. We've fixed similar issues in the past and still do.
So when I said nothing had been a deemed a security issue I meant
"deemed by us". Unfortunately the OSS Fuzz classification doesn't match
ours.
There are a few more cases around 7z that have not been flagged as
security issues - I have no idea why not.
In all cases corrupt archives may cause RuntimeExceptions
(ArrayIndexOutOfBounds, IllegalArgument, BufferUnderflow, ...) rather
than IOExceptions. If you try to read archives from untrusted sources,
this may lead to unexpected exceptions.
> I'd be curious to know if there is planned date for commons-compress
> 1.21?
There is no planned date I was aware of.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org