On Thu, Dec 14, 2023 at 9:31 AM Arnout Engelen <enge...@apache.org> wrote:
> > 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? Passing untrusted input to Runtime.exec() or equivalent is definitely something we should fix (if we do that; I don't know that we do). I put that in the same category as bugs in native code commons itself ships. OTOH if we were to shell out to something like ImageMagick or ffmpeg and a malicious input file could trigger a security issue in the external tool, I wouldn't consider that our issue to filter or fix. In a worst case scenario, it would require us to replace a buggy and unmaintained dependency with something better. Object serialization I hope we don't use, but if we do it might be worth a look. This falls under the category of validating and not trusting any input you receive. The problem here is that a lot of developers don't do that when object serialization is used. They just assume the jDK does that for them and it very much does not. What I was thinking of for arbitrary code execution from pure Java code would be buffer overflow or rowhammer type attacks. That shouldn't be possible in Java, and when it is, it is almost by definition a JDK bug. There've been a few of these over the years. There've also been some zero days caused by flaws in the JDK libraries leading to arbitrary code execution. Again, these are JDK bugs. Mostly I want to avoid taking responsibility for things we don't own and can't fix: the JDK and native libraries from other projects. There's way too much noise in security reporting from random IT folk who've run some security scanner without really understanding what it's saying. -- Elliotte Rusty Harold elh...@ibiblio.org --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
