On Tue, 2003-10-21 at 11:42, Michal Zalewski wrote: > On low endian, you can > change a pointer such as: > 0x08049648 > ...to be one of the following: > 0x08049600 > 0x08040000 > 0x08000000 Ah, duh... that just didn't enter my brain since I was focused on the exploit at hand, which I believe doesn't not allow such a precise sniping. > Zero overwrites are a tricky business. heh... hence the question if it really is exploitable. > It's not as much about looking at the code, but looking at the library > malloc() implementation, and then figuring out what can be put on heap and > where. I am way too lazy / too busy to give it much thought - I don't see > any benefit from writing an exploit or proving (?) it is not exploitable. That brings up a good point. If this issue is not exploitable on *BSD but on Linux due to a different implementation of memory handling, doesn't that mean that Linux is generally less secure than *BSD just for that reason? And if so, why haven't the Linux memory handling routines been fixed/strengthened? > At first sight, it does not seem to be exploitable on some platforms, on > others, is uncertain at best. Quite frankly, I would expect the exploit to > leak already, or be developed independently, so I am sort of skeptical. I agree. So the lack of any such activity within a months is a good indicator for the non-exploitability (exploitivness? exploitivity?) of this thing. > If it is exploitable and there is an exploit, the public will sooner or > later find out, don't force it if there is no good reason... I agree that I rather not see an exploit being written. But I'm extremely curious if it can be done. My reason, again, is that the advisories came out with "*may* be exploitable" as Mark noted. I think security advisories should be more precise and accurate (I know it can't be done always, but hey, please try). When the advisories hit, especially from some organizations I don't want to name here, it sounded like FUD feeding. Everyone and their mother seems to get off on FUD and hype these days. I think we (as the security community) should do a better job in stating the facts and should strive to avoid FUD. I especially remember one notice that said that this issue is already widely exploited... errr... with a bug which doesn't seem to be exploitable, excuse me? That's the whole reason I got pissed off weeks ago, and is the reason I really would like to see an answer to the exploitability. Because if it isn't exploitable, and no exploit had been in use in the underground, then that would be a clear indication that certain folks flat out lie and spread FUD to their benefit. A dangerous precedent if we want the area of security to remain a serious business. Cheers, Frank
Attachment:
signature.asc
Description: This is a digitally signed message part