On Thu, Dec 14, 2023 at 2:00 PM Elliotte Rusty Harold <elh...@ibiblio.org> wrote:
> On Thu, Dec 14, 2023 at 6:09 AM Arnout Engelen <enge...@apache.org> wrote: > > * I'd say parsing/decompression/decoding should never allow malicious > input > > to trigger arbitrary code execution(?) > > Do any of these products include native libraries/C code? To the > extent it's pure Java, arbitrary code execution indicates a bug in the > JDK. > Beyond that, I do not think Apache Commons (or anyone else) should > expect *any* input to be correctly validated/sanitized. All products > should be robust against arbitrary byte streams. Malformed input > should be detected and an appropriate exception thrown. > Examples of what I referred to as arbitrary code execution would be unbounded deserialization of untrusted data (via techniques like those described in the motivation for https://docs.oracle.com/en/java/javase/17/core/serialization-filtering1.html ) or (directly or indirectly) passing untrusted input to functions such as "Runtime.exec()". I guess we can debate the word 'arbitrary', but it sounds like you're saying *none* of the Apache Commons libraries should allow triggering those? > Excessive resource usage is a separate question since it can be > triggered by valid input without escaping the VM protections. Proper > input validation protects against some but not all resource exhaustion > attacks. > I agree completely avoiding all exhaustion attacks is probably unfeasible - framing it as "'disproportionate' resource usage" was intended to give us some wiggle room to treat clearly-problematic behaviour as a bug/vulnerability while not taking it to extremes. -- Arnout Engelen ASF Security Response Committer on Apache Pekko Committer on NixOS Independent Open Source consultant
