This is the mail archive of the
libc-alpha@sources.redhat.com
mailing list for the glibc project.
Re: Traceroute exploit + story (fwd)
- To: Geoff Keating <geoffk at cygnus dot com>
- Subject: Re: Traceroute exploit + story (fwd)
- From: Daniel Jacobowitz <dmj+ at andrew dot cmu dot edu>
- Date: Thu, 5 Oct 2000 19:03:45 -0400
- Cc: chris at scary dot beasts dot org, security-audit at ferret dot lmh dot ox dot ac dot uk,libc-alpha at sourceware dot cygnus dot com
- References: <Pine.LNX.4.21.0010051953300.10542-100000@ferret.lmh.ox.ac.uk> <20001005163626.A9438@drow.them.org> <200010052058.NAA02042@geoffk.org>
On Thu, Oct 05, 2000 at 01:58:54PM -0700, Geoff Keating wrote:
> > Date: Thu, 5 Oct 2000 16:36:26 -0400
> > From: Daniel Jacobowitz <dmj+@andrew.cmu.edu>
>
> > I don't think this is exploitable, esp. since we do not seem to malloc
> > until afterwards... but perhaps this should be fixed.
>
> You didn't say what you think the problem might be. The code you
> quoted looks correct to me. You might be lost in the twisty maze of
> libc startup code; I believe this code happens before any user code
> gets executed, or even before it gets relocated.
I can't see any possible way, no. But I like the fact that in the
other declaration of __libc_enable_secure it defaults to 1 in case the
test somehow gets skipped; it's more failsafe. Any reason not to
change this similarly?
I'm not saying that anything is broken. But why encourage breakage if
we don't have to?
Dan
/--------------------------------\ /--------------------------------\
| Daniel Jacobowitz |__| SCS Class of 2002 |
| Debian GNU/Linux Developer __ Carnegie Mellon University |
| dan@debian.org | | dmj+@andrew.cmu.edu |
\--------------------------------/ \--------------------------------/