Split out of the review of #811.
What happens
Since #811 every batchRequest of a SOAP body gets its own LDAPConnection and therefore its own bind — before that fix the connection was reused, so the second and later batch requests of a body were silently skipped (which is the bug #811 fixes, not a property worth keeping).
That makes a single HTTP POST an amplifier: N batchRequest elements cost N binds against the directory server, and password verification is deliberately expensive (PBKDF2, bcrypt and the other salted schemes are tuned to be slow). The body is small — an empty <batchRequest requestID="n"/> is a few dozen bytes — so the ratio between what the client sends and what the server computes is high.
Valid credentials are not needed either: a failed bind costs the same password verification, doPost() reports it as an errorResponse and moves on to the next batchRequest of the same body rather than stopping.
Where
opendj-dsml-servlet/src/main/java/org/opends/dsml/protocol/DSMLServlet.java, the loop over soapBody.getChildElements().
Suggested fix
A configurable cap on the number of batchRequest elements accepted per SOAP body, as a web.xml init-param next to the existing ldap.* parameters, with a conservative default; the excess is rejected with an errorResponse instead of being executed. A cap on the size of the request body is worth considering in the same change.
The gateway is not deployed by default, so this is hardening rather than an exposure in a stock installation.
Split out of the review of #811.
What happens
Since #811 every
batchRequestof a SOAP body gets its ownLDAPConnectionand therefore its own bind — before that fix the connection was reused, so the second and later batch requests of a body were silently skipped (which is the bug #811 fixes, not a property worth keeping).That makes a single HTTP POST an amplifier:
NbatchRequestelements costNbinds against the directory server, and password verification is deliberately expensive (PBKDF2, bcrypt and the other salted schemes are tuned to be slow). The body is small — an empty<batchRequest requestID="n"/>is a few dozen bytes — so the ratio between what the client sends and what the server computes is high.Valid credentials are not needed either: a failed bind costs the same password verification,
doPost()reports it as anerrorResponseand moves on to the nextbatchRequestof the same body rather than stopping.Where
opendj-dsml-servlet/src/main/java/org/opends/dsml/protocol/DSMLServlet.java, the loop oversoapBody.getChildElements().Suggested fix
A configurable cap on the number of
batchRequestelements accepted per SOAP body, as aweb.xmlinit-param next to the existingldap.*parameters, with a conservative default; the excess is rejected with anerrorResponseinstead of being executed. A cap on the size of the request body is worth considering in the same change.The gateway is not deployed by default, so this is hardening rather than an exposure in a stock installation.