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 <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
