full-disclosure - Re: No Subject

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

From: lcamtuf at ghettot.org (Michal Zalewski)
Subject: Re: No Subject

On Tue, 21 Oct 2003, Frank Knobbe wrote:

> 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.

Once again, I don't want to take sides, I had barely seen the code, never
really bothered to analyze the problem, and it's been a while since I had
my peek; if the new length of the buffer at the time realloc fails can be
something else than a multiple of 4, you should be able to do this;
otherwise, it makes the exploitability even less likely.

> 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?

Many systems use malloc implementations derived from Doug Lea's malloc
design, which is designed to have very low size overhead and offers
excellent performance, but has no security features whatsoever, and allows
multiple free()s, control structure overwrite, etc, etc.

Some folks, such as OpenBSD developers, decided the extra overhead is well
worth all the benefits, and have a guarded implementation that keeps track
of allocated and released chunks, and prevents harmful operations.

I have no idea why GNU libc sticks with pretty much vanilla dlmalloc -
glibc is not quite aimed at efficiency and small size, with all the awful
bloat which, many argue, should be optional at the very least...

Rant: mainstream Linux is generally not all that enthusiastic about
implementing security features (even non-executable stack or using some
feeble but standard kernel security capabilities is quite unpopular in
major distributions). Adding transcluent buttons to KDE/GNOME seems to be
the top priority.

> 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).

Well, they all got burned in the past with "not exploitable" statements
;-) And it is not quite easy to come up with a conclusive statement for
all the platforms affected in this case.

To summarize, once again, I am not saying the problem is not exploitable.
I doubt it is, but I have not and am not likely to look at it in more
detail. I sincerely doubt there is an exploit making rounds, but damnit,
do patch your systems - you do not even have to reboot.

-- 
------------------------- bash$ :(){ :|:&};: --
 Michal Zalewski * [http://lcamtuf.coredump.cx]
    Did you know that clones never use mirrors?
--------------------------- 2003-10-22 00:58 --

   http://lcamtuf.coredump.cx/photo/current/