Message-ID: <1066772687.417.53.camel@localhost>
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