You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directory.apache.org by "Emmanuel Lécharny (Jira)" <ji...@apache.org> on 2026/09/28 10:14:00 UTC

[jira] [Commented] (DIRAPI-437) Attacker-declared TLV length drives up-front unbounded byte[] allocation; no default PDU cap

    [ https://issues.apache.org/jira/browse/DIRAPI-437?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18120093#comment-18120093 ] 

Emmanuel Lécharny commented on DIRAPI-437:
------------------------------------------

The API now has a MAX_PDU_SIZE set to 8Mo.

This default value can be changed with a call the the _LdapConnectionConfig.setMaxPDUSize()_ method:


{code:java}
LdapConnectionConfig config = new LdapConnectionConfig();

// Set the max PDU size to 1MB
config.setMaxPduSize( 1*1024*1024 );        

LdapNetworkConnection connection = new LdapNetworkConnection( config );

// And now use the connection to do operation with a limited PDU size
...
{code}

Note: ApacheDS has a configuration parameter that is used to set this limit: _ads-maxPDUSize_.

> 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
>            Priority: Major
>             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: dev-unsubscribe@directory.apache.org
For additional commands, e-mail: dev-help@directory.apache.org