Apache Commons Threat Model (summary) version 0.1.0
The model in brief
Apache Commons components are small, reusable Java libraries
that run inside the host application's JVM
and are invoked in-process through their public Java API.
The caller is trusted:
the API is an interface, not a trust boundary,
and validating untrusted data is the host application's job,
at the host's own perimeter.
Calls to the Commons API come with the same caveat as calls to the JDK:
they will usually do what the caller asks,
and a behavior that would be legitimate for the JDK
is not a Commons vulnerability.
Components do not sanitize output:
malicious input can produce malicious output,
and output derived from untrusted input is itself untrusted.
A component can explicitly claim a “secure parsing” guarantee
from a documented version onward;
where none is claimed (currently: no component claims one,
although for the current security scan
all parser and interpolation/expression components
are experimentally treated as claiming it, see below),
harm from malicious input is not a Commons vulnerability.
User types
- Trusted users: application developers and operators/administrators.
They have unrestricted access to the component and its environment;
an attacker who controls either role has won at a layer below Commons.
- Untrusted users: everyone else,
in particular whoever authors the content a host may pass to a component
(archives, images, CSV files, multipart request bodies, templates).
It is generally unsafe to pass their data to Commons APIs.
In some cases the host can validate or sanitize the data
before passing it to Commons.
If this is not possible, unless otherwise specified,
it is not possible to securely process this data with Commons libraries.
What Commons guarantees
- Memory safety of its own code:
managed Java under the JVM,
plus Commons's own JNI and native glue in Crypto and Daemon
(defects inside underlying native libraries such as OpenSSL go upstream).
- Expected resource use for the requested operation on in-contract input
(a correctness expectation, chiefly for the numeric components;
excessive use on malicious input is only a security finding
under a “secure parsing” guarantee;
this property is under discussion and may be revised).
- “Secure parsing” where a component's threat model claims it,
with a “since” version:
malicious input cannot cause excessive CPU consumption,
excessive memory allocation,
code execution,
or reads from and connections to anything the caller did not designate
(for the current security scan,
experimentally treated as claimed by all parser
and interpolation/expression components, to maximize findings;
a scan-harness setting, not a final commitment).
- The JEXL sandbox (
JexlPermissions), since JEXL 3.7.0.
- Daemon privilege transitions:
jsvc and procrun must not leave the managed child
with unintended privileges.
What Commons does not guarantee
One rule covers it all:
no safety against untrusted or malicious input, by default.
Recurring instances:
- CWE-502
(deserialization):
Commons never deserializes anything;
its
readObject code assumes trusted streams,
and gadget classes are not Commons vulnerabilities.
Never deserialize untrusted data.
- CWE-22
(path traversal, “zip-slip”):
validating extraction targets is permanently the host's job;
Compress offers
ArchiveEntry.resolveIn but does not enforce it.
- CWE-917
(expression language injection):
no sandbox for untrusted templates
(the JEXL permission mechanism, 3.7.0+, excepted);
default lookups can embed environment variables and files in output.
- CWE-611 (XXE):
XML parser hardening is the host's configuration,
unless a component documents otherwise.
- CWE-1333 (ReDoS):
disclaimed at the baseline;
counts as excessive CPU under “secure parsing”.
- CWE-918 (SSRF):
Net, Email, IO, and VFS contact whatever targets they are given;
allow-listing is the host's job.
- False friends:
Codec digests and CRCs are not MACs;
Lang's random utilities are not CSPRNGs;
StringSubstitutor is not a sandbox;
Crypto is a thin cipher wrapper that will not stop misuse.
- Writer and encoder output structure:
components aim to keep untrusted content
from breaking the structure of generated output
(CSV printing, Codec encoding, Text escaping),
but a failure there is an ordinary bug,
not a security vulnerability,
unless a component specifies otherwise.
- Active sinks:
structurally valid output can still be reinterpreted downstream
(CSV formulas in spreadsheets, ANSI escapes in terminals);
defending those is the host's job.
Reporting
A report is valid if it violates a guarantee above,
is reachable from input the model treats as attacker-controllable,
and describes behavior that would not be legitimate for the JDK.
Report undisclosed vulnerabilities privately,
as described on the
Apache Commons Security page;
questions about published vulnerabilities
go to the public user mailing list.
Everything else,
including the component family table, triage dispositions,
misuse patterns, and known non-findings,
is in the full threat model.
|
