Emmanuel Lécharny created DIRAPI-437:
----------------------------------------
Summary: Attacker-declared TLV length drives up-front unbounded
byte[] allocation; no default PDU cap
Key: DIRAPI-437
URL: https://issues.apache.org/jira/browse/DIRAPI-437
Project: Directory Client API
Issue Type: Bug
Affects Versions: 2.1.8
Reporter: Emmanuel Lécharny
Fix For: 2.1.9
A malicious or compromised *LDAP* server (or *MITM* before *StartTLS*) sends
~12-20 bytes, e.g. _30 84 7F FF FF F0 (SEQUENCE) 02 84 7F FF FF EA (INTEGER
declaring ~2GB)_: _treatValueStartState_ executes _new byte[0x7FFFFFEA] _before
any body bytes arrive.
The client *JVM OOMs* (_OutOfMemoryError_ bypasses the _DecoderException_
handlers) or pins ~2 GB per connection while the attacker stalls; a handful of
connections exhausts any heap. The same bytes from an unauthenticated pre-bind
client hit any embedding server that did not set _MAX_PDU_SIZE_ATTR_
_Asn1Decoder.treatValueStartState_ calls _currentTlv.getValue().init(length);_
_BerValue.init_ executes _data = new byte[size]_ using the length taken
directly from the wire, before a single value byte has arrived.
The only guard, _length > container.getMaxPDUSize()_ in _treatLengthEndState_
(:360-363), is vacuous: _AbstractContainer.maxPDUSize_ defaults to
_Integer.MAX_VALUE_ and _setMaxPDUSize_ is invoked only from
_LdapProtocolDecoder.decode_ when the embedder has stored the
_LdapDecoder.MAX_PDU_SIZE_ATTR_ *MINA* session attribute — which nothing in
this library ever does.
_LdapNetworkConnection.setBinaryDetector_ and _sessionCreated_ create the
_LdapMessageContainer_ without touching _maxPDUSize_, and
_LdapConnectionConfig_ has no PDU-size knob at all, so every client connection
decodes with an effectively unlimited PDU size; the server role has the same
default unless the embedder (e.g. *ApacheDS*) opts in.
The 4-byte length-field cap and negative-length check bound the declared length
only to <= 0x7FFFFFFF.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
