Hello, Am Mo., 24. Mai 2021 um 20:46 Uhr schrieb Matt Sicker <boa...@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 > <meumertzh...@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 <bode...@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-unsubscr...@commons.apache.org > > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
