The Apache Logging Services PMC has received the security report
referenced below. After analysis, we classified it as a BUG: a real
defect, fixed through the public issue tracker, but without security
impact. In the interest of transparency and so that the community and
other researchers can benefit from the analysis, we are disclosing a
summary of it.
Report reference (Logging Services PMC / security archive):
https://lists.apache.org/thread/cz8jlkqqdny752mnbpkckg5xhvd5b66j
Reporter: Yu Bao from PayPal Cybersecurity Team
Disposition: BUG -- not a vulnerability; no CVE; fixed through a
public issue
TLP:CLEAR (this message may be redistributed without restriction)
The reporter was informed of this classification and of our intent to
publish this summary.
== Summary of the report ==
`DatagramOutputStream`, which backs the Socket and Syslog appenders when
`protocol="UDP"`, accumulates the bytes of a log event before sending
them as one datagram. Its private `copy()` method allocates a new array
sized to the exact accumulated length and copies the previous contents
on every `write()` call. Since the encoder writes a formatted event in
chunks of 8 KiB, accumulating an event of n bytes costs time
proportional to n squared. The reporter measured the effect on an 8 KiB
chunked write loop: the time quadruples each time the payload doubles,
reaching 99 seconds of CPU time for a single 256 MB value, and argued
that an attacker able to get an oversized value logged could pin a CPU
core for the duration (CWE-407). The report states explicitly that this
requires the non-default `UDP` protocol, and proposes a growable buffer
and a maximum datagram size.
== PMC assessment ==
This is NOT a vulnerability, but the code is indeed wrong and will be
fixed. The quadratic regime cannot be reached with events that can
actually be sent. With `protocol="UDP"`, the appenders force
`immediateFlush`, so `DatagramOutputStream#flush` sends one datagram per
event and resets the accumulator. A UDP datagram carries at most 65,507
bytes and `DatagramSocket#send` fails above that, so the largest
deliverable event is accumulated in at most eight copies of at most 64
KiB, far below the sizes where the reporter's benchmark leaves linear
behavior. For a larger event, the copying cost is dominated by the cost
the application already paid to build, format and encode a
multi-megabyte message that the transport then drops.
Under our threat model, the cost of processing excessively long log
content is bounded by the limits the calling application enforces, and
keeping the appenders able to sustain the application's log volume is a
deployer responsibility:
https://logging.apache.org/security.html#threat-common-adversary
https://logging.apache.org/security.html#threat-common-threat
== Fix ==
The accumulator will be backed by a growable buffer, and payloads above
the maximum datagram size will be rejected with a status logger warning
instead of being sent:
https://github.com/apache/logging-log4j2/issues/4333
== References ==
Threat model:
https://logging.apache.org/security.html
Socket appender documentation:
https://logging.apache.org/log4j/2.x/manual/appenders/network.html#SocketAppender
Questions and follow-up are welcome on this list or GitHub Discussions.
On behalf of the Apache Logging Services PMC,
Piotr P. Karwasz
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
