full-disclosure - THREATCON HITTING DANGEROUS LEVELS!

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] [day] [month] [year] [list]

Message-ID: <20020930010003.A6655@hamsec.aurora.sfo.interquest.net>
From: silvio at big.net.au (silvio@....net.au)
Subject: THREATCON HITTING DANGEROUS LEVELS!

On Mon, Sep 30, 2002 at 07:40:00AM +0100, Dave Wilson wrote:
> On Sun, Sep 29, 2002 at 10:03:36PM -0700, silvio@....net.au wrote:
> 
> > #include <stdio.h>
> > int main(int argc, char *argv[]) { char *v[] = { NULL };
> > execve(argv[1], v, NULL); }
> 
> This is the linux glibc bootstrap code behaviour. main() is never
> reached. It's not new either.

erm.
thanks for the descriptive information! -->

(for linux ia32)
can you provide more details on this?  I'm not seeing this behaviour on
glibc 2.1.3 and 2.2.4, and at least the code for 2.1.3 verifies this
quite well (ignoring the __libc_start_main never going to happen argc + 1,
integer overflow if you ever get argc to be fully controllable - not on linux
at least.. might want to check other systems).  glibc 2.2.x has changed
the __libc_start_main code a bit (start.S for i386 looks the same), so
i manually tried some code on a rh 7.2 box - which doesnt
have startup code crashes you talk about.  From my tests, it passes control
into main from __libc_start_main ok.
there is some debugging output which uses argv[0] in __libc_start_main,
but this can be ignored.

is this linux your talking about, or some other system?  i have not
been able to reproduce the behaviour you describe, but i do not know the
code that well, and only am using linux ia32.

> > This is of course, not really a security threat by any means.. It is an
> > annoying bug that effects alot of things and is really not handled
> > correctly in the majority of implementations.
> 
> How about not misusing exec()?  'course not, let's patch our kernels to
> stop idiots from using exec()!!

i think maybe a kernel patch is the best place for this.. its not fantastic
I agree, but is probably the best solution.  Do the single unix specs or
something have anything to say of what is standard behaviour here? - ie,
kernel or user space problem.

BUT..

if you really know what your talking about.. can you actually say what
versions its effecting.. because i cannot see which version of
glibc code your talking about here!  and "glibc bootstrap code".. seriously,
what does that mean?  i'm really only thinking of _start or __libc_start_main
at this point, unless your refering to some sort of whack rtld issue, or
kernel -> rtld issue, which i dont see is going happen.  lets not even
get into code that doesnt link against libc

*sigh*

--
Silvio