------=_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> &nb
sp; 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--
|