[
https://issues.apache.org/jira/browse/DIRAPI-438?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Emmanuel Lécharny resolved DIRAPI-438.
--------------------------------------
Resolution: Fixed
Fixed with commit 41d3714fbd06f89d096acfd5b3aa5240d0bff285
The _ads-maxFilterDepth_ configuration parameter has been added for *ApacheDS*,
and is set to 128 by default.
The LDAP API has an added _setMaxFilterDepth()_ allowing a user to set the
limit to another value:
{code:java}
LdapConnectionConfig config = new LdapConnectionConfig();
// Set the max filter depth to 10
config.setMaxFilterDepth( 10 );
LdapNetworkConnection connection = new LdapNetworkConnection( config );
// And now use the connection to do searches with a limit on the nexted filters
...
{code}
> Unbounded filter-nesting recursion causes StackOverflowError at decode time
> ---------------------------------------------------------------------------
>
> Key: DIRAPI-438
> URL: https://issues.apache.org/jira/browse/DIRAPI-438
> Project: Directory Client API
> Issue Type: Bug
> Affects Versions: 2.1.8
> Reporter: Emmanuel Lécharny
> Priority: Major
> Fix For: 2.1.9
>
>
> Attacker opens a *TCP* connection to an *ApacheDS*-based server (no bind) and
> sends an _LDAPMessage_ whose _SearchRequest_ filter is 15,000 nested NOT
> filters followed by the attributes SEQUENCE; _transform()_ recurses 15,000
> deep and _StackOverflowError_ escapes to the *MINA* processor thread shared
> by other connections. The same *PDU* sent by a hostile server crashes an
> ldap-api client's reader thread.
> The *LDAP* grammar places no limit on search-filter nesting depth (neither
> _Asn1Decoder_ nor _LdapMessageContainer_ imposes a depth cap).
> *BER* decoding builds the _Filter_ tree iteratively, but when the attributes
> *SEQUENCE* tag arrives, _InitSearchRequestAttributeDescList.action()_ calls
> the private recursive _transform()_ — one stack frame per nesting level.
> ~7-15k levels (2-4 wire bytes each, i.e. a ~40-60 KB *PDU*) overflow a
> default thread stack.
> _StackOverflowError_ is an _Error_, so it bypasses the codec's
> _DecoderException_/_PROTOCOL_ERROR_ handling and propagates into the *MINA*
> I/O processor thread.
> Reachability is double-sided: the _SearchRequest_ is decoded pre-bind on the
> server side, and the client's _LdapMessageContainer<Message>_ uses the full
> grammar which accepts request-typed messages from the server.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
