DISQUS

blog · 3 years ago

It wouldn't be a race if you won everytime, would it
Dr. Strangelove | 03.27.06 - 10:46 am | #

Keep checking the rapture link for updates. When we get a more reliable method of exploitation, I'll post it to the Dyad page in the advisory section.

Robert
Robert E. Lee | Homepage | 03.28.06 - 5:36 am | #

fingerout · 3 years ago

Anything new about this issue? I'm doing research on this and it seems that the only possible way of making this race occur is sleeping on sm_io_getc in switch(mstate) case MS_HEADER since after sm_io_getc at the beginnig of inner loop (for(;;)) will cause setting CollectProgress to true which results in resetting the timer, so no race (no longjmp call) will occur.
Any thoughts?

fingerout · 3 years ago

After some more code analysis I think that it is impossible for the signal to be delivered while being in sm_syslog because of headers length -> can't get there with CollectProgress == false (which is the condition of longjmp occurance), since if we manage to bypass setting CollectProgres to true by going into switch(istate) case IS_DOTCR thus having pbp incremented, we will land in sm_io_getc after which CollectProgres is set to true, because of:
if (c == '\r' && !bitset(EF_CRLF_NOT_EOL, e->e_flags)) {
istate = IS_CR;
continue;
}
since c is set to '\r' in IS_DOTCR and with default settings this bitset() will return false so condition will be met.
The char will be processed and we'll be back waiting for another one (then CollectProgres = true).
Please correct me if I'm wrong...

fingerout · 3 years ago

So the only possible exploitation vector I see is to be in chompheader() when the signal is delivered.


MODERATOR, PLEASE MAKE THESE 3 COMMENTS ONE ;], THX

fingerout · 3 years ago

Or in any other function before this code:
if (CollectTimeout != NULL)
sm_clrevent(CollectTimeout);

Thomas Ptacek · 3 years ago

I really want to follow up on this stuff (for what it's worth, from memory, this is basically a weaponized version of the classic C++ exception handling bug --- aborting in the middle of a function, unbeknownst to the code in that function, leaves dangling references. In this case, a dangling referencing into the stack, stored in a function static.)

I'm a bit buried, but I'll try to get at it later on tonight.

fingerout · 3 years ago

After a bit cheating (putting sleep in sm_syslog() :P) i managed to exploit the race condiotion and got: Jun 29 02:48:14 fingerout sendmail[10085]: k5T0m3Lv010085: Séˇout waiting for inpTö˙˙˙om fingerout.lambda.furrynet.org during message collect
in syslog. Now comes another part: how to exploit this static pointer overwrite;]. Any ideas?

Thomas Ptacek · 3 years ago

I haven't gotten back to this yet, but, the static pointer can be left in a state where it's pointing into the stack.

fingerout · 3 years ago

Correct, but how to exploit it ;)?

Thomas Ptacek · 3 years ago

Like any other stack overflow?

fingerout · 3 years ago

Or heap one, since it's possible to force sm_syslog making this static pointer = mallocated buffer.

Thomas Ptacek · 3 years ago

My sense of it was, addresses written over stack frames (part of the trick is getting the function to abort leaving a dangling pointer into the stack).

fingerout · 3 years ago

DONE :]

Thomas Ptacek · 3 years ago

Congratulations. How'd you do it?

piscis · 1 year ago

hello~~~dear All~~~~
I am just starting to learn this bug~~~~
I find this issue too. And I get the program sendtest_c from http://www.securityfocus.com/bid/17192/exploit. But I don't know how to make this become a really expolitation. I think this for months. I feel that I can't go forward any more~~~~please give me some hint or help~~~~
thanks~~~