Filters like "(x=\))" will loop forever at source3/lib/tldap.c:1240 /* find terminator */ while (*s) { s = strchr(s, ')'); if (s && (*(s - 1) == '\\')) { continue; } break; } because *s never advances past the first ')'. I am marking as private for now, in case there is some way in which attackers can control a tldap filter string (it looks like not, so far). According to RFCs and Technet, the correct escaping for ')' is "\29", not "\)". I have not tested what Windows accepts.
Created attachment 16370 [details] simple fix
Created attachment 16371 [details] the fuzz target that finds this This was found using Honggfuzz and the attached fuzz target. Honggfuzz took half a second to find this, but it has found no more after a day and a half.
(In reply to Douglas Bagnall from comment #0) > I am marking as private for now, in case there is some way in which attackers can control a tldap filter string (it looks like not, so far). So my reasoning for thinking this is not a security issue is the ultimate callers of tldap_search* are: tldap_gensec_bind_send() with fixed filter. tldap_fetch_rootdse_send() with fixed filter. torture/torture.c idmap searches constructed filters from known parts pdb_samba_dsdb_set_aliasinfo within '#if 0', completely broken Some of the idmap filters contain string representations of sids, but even if these are not trusted, they are escaped in the \hh form (using ldb_binary_encode). Metze and slow: have I missed anything?
Removing embargo on Douglas's analysis.
Created attachment 17283 [details] tldap push fuzzer with a parsing fix Metze: did you have a different patch in mind? Otherwise I'd like to open an MR for the fuzzer and simple fix.
This bug was referenced in samba master: f0e0ff262ab720e2e0cd48aa82549ad9c5ed69ec