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
| ||
|
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
Powered by blists - more mailing lists