Full Disclosure mailing list archives
Re: Re: No Subject
From: Michal Zalewski <lcamtuf () ghettot org>
Date: Wed, 22 Oct 2003 01:20:53 +0200 (CEST)
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/ _______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Current thread:
- No subject Pocjfr (Oct 13)
- Re: No subject Gregory A. Gilliss (Oct 13)
- <Possible follow-ups>
- No Subject mitch_hurrison (Oct 20)
- Re: No Subject Frank Knobbe (Oct 20)
- Re: Re: No Subject Michal Zalewski (Oct 21)
- Re: Re: No Subject Frank Knobbe (Oct 21)
- Re: Re: No Subject Michal Zalewski (Oct 21)
- Re: Re: No Subject Bradford Shedwick (Oct 21)
- Re: Re: No Subject Frank Knobbe (Oct 21)
- Re: Re: No Subject Michal Zalewski (Oct 21)
- Re: Re: No Subject Paul Schmehl (Oct 21)
- Re: Re: No Subject Byron Copeland (Oct 21)
- Re: Re: No Subject Peter Busser (Oct 22)
- Re: No Subject Frank Knobbe (Oct 20)
- Linux (in)security (Was: Re: Re: No Subject) Peter Busser (Oct 22)
- Re: Linux (in)security (Was: Re: Re: No Subject) Bruce Ediger (Oct 22)
- Re: Linux (in)security (Was: Re: Re: No Subject) Darren Reed (Oct 22)
- Re: Linux (in)security (Was: Re: Re: No Subject) Gary Flynn (Oct 22)
- Re: Linux (in)security (Was: Re: Re: No Subject) Ron DuFresne (Oct 23)
- Re: Linux (in)security (Was: Re: Re: No Subject) Paul Schmehl (Oct 22)
- Re: Linux (in)security (Was: Re: Re: No Subject) Ron DuFresne (Oct 23)