On Thu, Dec 14, 2023 at 8:31 AM Arnout Engelen <enge...@apache.org> wrote:
> 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? > > To this question specifically, I try to think about what we would expect a reasonable user to do. If we tell users that they need to check their inputs to prevent something like this, then the natural next question is “how?” If I was using an imaging or compression library that told me I needed to use an additional library to protect myself against malicious (just example) png or zip, then I’d wonder about the value of this library in the first place. The image library is supposed to know better how to handle png than I can. I guess I don’t have a solution or delineation but simply saying that you must validate your inputs before seems like mostly a hand wave approach that doesn’t reflect reality > 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 >
