lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
From: frank at knobbe.us (Frank Knobbe) Subject: Re: No Subject 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: This is a digitally signed message part Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20031021/16e9dbdd/attachment.bin
Powered by blists - more mailing lists