Parsing ACI with userdn containing encoded characters like %B2 are failing in case less then 2 symbols are provided after %

[myandrews]

Describe the bug
We use OpenDJ 5.1.0 and one of our fuzzing test is failed for decoding ACI containing malformed userdn.
Problem ACI is (version 3.0; acl ":"; allow (search) userdn="ldap://cn=name%B"; )

Error:
java.lang.ArrayIndexOutOfBoundsException: Index 49 out of bounds for length 49
at org.opends.server.types.LDAPURL.urlDecode(LDAPURL.java:693)
at org.opends.server.types.LDAPURL.decode(LDAPURL.java:335)
at org.opends.server.authorization.dseecompat.UserDN.decode(UserDN.java:89)
at org.opends.server.authorization.dseecompat.BindRule.decode(BindRule.java:407)
at org.opends.server.authorization.dseecompat.BindRule.parseAndCreateBindrule(BindRule.java:267)
at org.opends.server.authorization.dseecompat.BindRule.decode(BindRule.java:220)
at org.opends.server.authorization.dseecompat.PermBindRulePair.(PermBindRulePair.java:37)
at org.opends.server.authorization.dseecompat.PermBindRulePair.decode(PermBindRulePair.java:50)
at org.opends.server.authorization.dseecompat.AciBody.decode(AciBody.java:161)
at org.opends.server.authorization.dseecompat.Aci.decode(Aci.java:276)

Root cause is in slightly incorrect check LDAPURL class, urlDecode method.
Condition if (i+2 > length) should be if (i+2 >= length).

Test to reproduce the probem:
String aciString = "(version 3.0; acl ":"; allow (search) userdn="ldap://cn=name%B"; )";
ByteSequence aciByteString = ByteString.valueOfUtf8(aciString);
Aci.decode(aciByteString, DN.rootDN());

[vharseko]

Thanks for the excellent analysis — the root cause and the proposed fix were both spot on.

Fixed in #676:

• LDAPURL.urlDecode: the bounds check now uses i+2 >= length, so a truncated percent-encoded sequence ("...%B", "...%") is rejected with INVALID_ATTRIBUTE_SYNTAX, which UserDN.decode converts into a clean AciException instead of the ArrayIndexOutOfBoundsException.
• The same defect also existed in the SDK (org.forgerock.opendj.ldap.LDAPUrl.percentDecoder had no bounds check at all and threw StringIndexOutOfBoundsException) — fixed as well.

Your reproducer is now part of the test suite (UserDNTestCase), together with truncated-percent cases for both URL decoders.

Could you please verify the fix against your fuzzing tests (branch issues/673-ldapurl-percent-decode, PR #676)?

[myandrews]

@vharseko fuzzing tests are ok. Thanks