https://bugs.openldap.org/show_bug.cgi?id=10641
Issue ID: 10641 Summary: Missing bound check on X.509 SAN string before wildcard matching Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: backends Assignee: bugs@openldap.org Reporter: xfding@google.com Target Milestone: ---
In tls_o.c:1082, https://git.openldap.org/openldap/openldap/-/blob/master/libraries/libldap/t...
(sn[0] == '*') && (sn[1] == '.')
was tested before checking ( sl > 1 )
Similarly, on 1191, https://git.openldap.org/openldap/openldap/-/blob/master/libraries/libldap/t...
( cnstr[0] == '*' ) && ( cnstr[1] == '.' )
also has a missing bound check ( cnlen > 1 )
Note that OpenSSL would stop null-terminating strings by default in the major releases.
https://bugs.openldap.org/show_bug.cgi?id=10641
--- Comment #1 from Howard Chu hyc@openldap.org --- (In reply to Xiangfei Ding from comment #0)
In tls_o.c:1082, https://git.openldap.org/openldap/openldap/-/blob/master/libraries/libldap/ tls_o.c?ref_type=heads&plain=1&blame=1#L1082
(sn[0] == '*') && (sn[1] == '.')was tested before checking ( sl > 1 )
The actual statement is if (domain && (sn[0] == '*') && (sn[1] == '.') && (len2 == sl-1) && !strncasecmp(domain, &sn[1], len2))
so the length is still being checked.
Similarly, on 1191, https://git.openldap.org/openldap/openldap/-/blob/master/libraries/libldap/ tls_o.c?ref_type=heads&plain=1&blame=1#L1191
( cnstr[0] == '*' ) && ( cnstr[1] == '.' )also has a missing bound check ( cnlen > 1 )
Likewise /* Is this a wildcard match? */ if ((dlen == cnlen-1) &&
The length checks are not missing, and a short string cannot match erroneously.
Note that OpenSSL would stop null-terminating strings by default in the major releases.
Makes no difference here.
https://bugs.openldap.org/show_bug.cgi?id=10641
--- Comment #2 from Xiangfei Ding xfding@google.com ---
so the length is still being checked.
I think the order matters. Without bound check coming first, under MSAN that is one assertion for you.
if ((dlen == cnlen-1) &&
Likewise, this is one check coming too late.
https://bugs.openldap.org/show_bug.cgi?id=10641
--- Comment #3 from Howard Chu hyc@openldap.org --- (In reply to Xiangfei Ding from comment #2)
so the length is still being checked.
I think the order matters. Without bound check coming first, under MSAN that is one assertion for you.
if ((dlen == cnlen-1) &&
Likewise, this is one check coming too late.
MSAN/ASAN are pointlessly pedantic here. No production server will ever fail due to a 1 byte overread past a 1 byte memory allocation because all normal (non-debugging) malloc libraries return 4- or 8-byte aligned memory (on 32 or 64 bit architectures).
The only reason we would fix something like this is to prevent meaningless bug reports like this from being filed in the future. Not because it in any way impacts the runtime behavior of any code.
https://bugs.openldap.org/show_bug.cgi?id=10641
Howard Chu hyc@openldap.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |IN_PROGRESS Ever confirmed|0 |1
--- Comment #4 from Howard Chu hyc@openldap.org --- https://git.openldap.org/openldap/openldap/-/merge_requests/943
https://bugs.openldap.org/show_bug.cgi?id=10641
Howard Chu hyc@openldap.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Severity|normal |trivial Target Milestone|--- |2.6.16 Assignee|bugs@openldap.org |hyc@openldap.org Keywords|needs_review | Priority|--- |Lowest
https://bugs.openldap.org/show_bug.cgi?id=10641
Quanah Gibson-Mount quanah@openldap.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|2.6.16 |2.6.17