------=_Part_3380_11468608.1164742144339 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline
So after playing with this a bit more, I think there may be 'something else' going on, although what that something else is I'm not entirely sure. This may be another facet of the bug, a new bug entirely, or nothing to do with OpenLDAP code.
Specifically, I played around with what the NASL script was sending to the server. I tried sending different space counts, followed by padding of some other character ('A'), to see what it would do. I'm afraid the results aren't as conclusive as I'd hoped.
1) If I send a SINGLE SPACE to start the data portion, like so:
mkbyte(4) + mkbyte(8) + "CRAM-MD5" + mkbyte(4) + mkbyte(0x82) + mkword(0x0400) + crap(data:" ", length:1) + crap(data:"A", length:1023);
the server NEVER crashes, no matter how many times I try it.
2) If I send more than a single space, even just 2 (followed by 1022 A's, for example), the server will USUALLY, but NOT ALWAYS crash. (Approx 80% of the time it chokes)
3) If I send more than 64 spaces, the server ALWAYS crashes. I do not know if 64 is a magic number; I originally started out trying to send only 254 spaces + padding, which reliably caused crashes, and kept ratching down the number until I suddenly stopped getting crashes reliably at 64 spaces. I started to send a eureka email of sorts, but a couple more tests yielded crashes at 64, and now it's crashing relatively reliably (90% of the time, I'd say) from spaces=2 on up.
Finally, and I'm not sure how significant this is, every time it crashes the [len=XXX] portion of the slapd_sasl_getdn debug line is ONE CHARACTER LESS than the number of spaces I send. So, for example, if I send 2 spaces followed by 1022 A's, then I see:
slap_sasl_getdn: conn 10 id= [len=1]
If I send 64 spaces followed by 960 A's, then len=63, and so on. If the server does not crash, getdn is never called, with SASL complaining "Failure: need authentication name".
I'm not sure if this helps or just muddies the issue further.
------=_Part_3380_11468608.1164742144339 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
So after playing with this a bit more, I think there may be 'something else' going on, although what that something else is I'm not entirely sure. This may be another facet of the bug, a new bug entirely, or nothing to do with OpenLDAP code. <br><br>Specifically, I played around with what the NASL script was sending to the server. I tried sending different space counts, followed by padding of some other character ('A'), to see what it would do. I'm afraid the results aren't as conclusive as I'd hoped. <br><br>1) If I send a SINGLE SPACE to start the data portion, like so:<br><br> mkbyte(4) + mkbyte(8) + "CRAM-MD5" +<br> mkbyte(4) + mkbyte(0x82) + mkword(0x0400) +<br> crap(data:" ", length:1) + <br> crap(data:"A", length:1023);<br><br>the server NEVER crashes, no matter how many times I try it.<br><br>2) If I send more than a single space, even just 2 (followed by 1022 A's, for example), the server will USUALLY, but NOT ALWAYS crash. (Approx 80% of the time it chokes) <br><br>3) If I send more than 64 spaces, the server ALWAYS crashes. I do not know if 64 is a magic number; I originally started out trying to send only 254 spaces + padding, which reliably caused crashes, and kept ratching down the number until I suddenly stopped getting crashes reliably at 64 spaces. I started to send a eureka email of sorts, but a couple more tests yielded crashes at 64, and now it's crashing relatively reliably (90% of the time, I'd say) from spaces=2 on up. <br><br>Finally, and I'm not sure how significant this is, every time it crashes the [len=XXX] portion of the slapd_sasl_getdn debug line is ONE CHARACTER LESS than the number of spaces I send. So, for example, if I send 2 spaces followed by 1022 A's, then I see: <br><br>slap_sasl_getdn: conn 10 id= [len=1]<br><br> If I send 64 spaces followed by 960 A's, then len=63, and so on. If the server does not crash, getdn is never called, with SASL complaining "Failure: need authentication name". <br><br>I'm not sure if this helps or just muddies the issue further.<br>
------=_Part_3380_11468608.1164742144339--
-
bthomas＠google.com