Re: SendGate: Sendmail Multiple Vulnerabilities (Race Condition DoS, Memory Jumps, Integer Overflow)
There are two exploit code samples I saw. There are two remote exploits for one of them so far that are public that I know of.
Please provide reference URLs or the code, if not then stop spreading FUD. Bugs happen, deal with them and move on. The endless whine is more annoying (as are 20 vendor notifications for the same bug each with their own spin/marketing, especially when they're all Linux with a different badge) brandon
Brandon Butterworth wrote:
There are two exploit code samples I saw. There are two remote exploits for one of them so far that are public that I know of.
Please provide reference URLs or the code, if not then stop spreading FUD.
No. Talk to you after the first worm.
On Sat, 25 Mar 2006, Gadi Evron wrote:
Brandon Butterworth wrote:
There are two exploit code samples I saw. There are two remote exploits for one of them so far that are public that I know of.
Please provide reference URLs or the code, if not then stop spreading FUD.
No.
Talk to you after the first worm.
I think this is the FUD brandon is speaking of... it's not helpful, please stop.
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
On Sun, 26 Mar 2006, Gadi Evron wrote:
Okay, if you insist we talk of exploits here, I take back the "talk after the first worm".
So you really are admitting that you were simply spreading more self-aggrandizing FUD? You may not stick to your promises, but at least you are honest about when you are lying. matto --matt@snark.net------------------------------------------<darwin>< Moral indignation is a technique to endow the idiot with dignity. - Marshall McLuhan
Brandon Butterworth wrote:
Please provide reference URLs or the code, if not then stop spreading FUD.
On Sat, 25 Mar 2006, Gadi Evron wrote:
No.
Talk to you after the first worm.
OK. We're holding you to your word there, Gadi. --matt@snark.net------------------------------------------<darwin>< Moral indignation is a technique to endow the idiot with dignity. - Marshall McLuhan
On Sat, 25 Mar 2006, Gadi Evron wrote:
Brandon Butterworth wrote:
There are two exploit code samples I saw. There are two remote exploits for one of them so far that are public that I know of.
Please provide reference URLs or the code, if not then stop spreading FUD.
No. Talk to you after the first worm.
That's just about as good of a statement as a demand for a phallus size check. If you can't back up claims, it is FUD by definition. So, just like BB wrote above:
[...] stop spreading FUD.
-- -- Todd Vierling <tv@duh.org> <tv@pobox.com> <todd@vierling.name>
On Sat, 25 Mar 2006, Gadi Evron wrote:
Brandon Butterworth wrote:
There are two exploit code samples I saw. There are two remote exploits for one of them so far that are public that I know of.
Please provide reference URLs or the code, if not then stop spreading FUD.
No. Talk to you after the first worm.
Hopefully we're not talking about blackworm.
That's just about as good of a statement as a demand for a phallus size check. If you can't back up claims, it is FUD by definition. So, just like BB wrote above:
[...] stop spreading FUD.
Gents, killfiles. This is not the only forum where this particular topic has been questioned as nothing more than common. -M<
-- -- Todd Vierling <tv@duh.org> <tv@pobox.com> <todd@vierling.name>
-- Martin Hannigan (c) 617-388-2663 Renesys Corporation (w) 617-395-8574 Member of Technical Staff Network Operations hannigan@renesys.com
participants (6)
-
Brandon Butterworth -
Christopher L. Morrow -
Gadi Evron -
Martin Hannigan -
Matt Ghali -
Todd Vierling