[12260] in bugtraq
Re: execve bug linux-2.2.12
daemon@ATHENA.MIT.EDU (Alan Cox)
Mon Oct 18 13:08:23 1999
Content-Type: text
Message-Id: <E11cTmd-0005ta-00@the-village.bc.nu>
Date: Sat, 16 Oct 1999 14:22:02 +0100
Reply-To: Alan Cox <alan@LXORGUK.UKUU.ORG.UK>
From: Alan Cox <alan@LXORGUK.UKUU.ORG.UK>
X-To: ben@VALINUX.COM
To: BUGTRAQ@SECURITYFOCUS.COM
In-Reply-To: <199910160007.RAA04857@trill.valinux.com> from "ben@VALINUX.COM"
at Oct 15, 99 05:07:10 pm
> Basically the problem is that the execve system call checks that argv
> is a valid pointer but it doesn't check that all of the pointers in
> argv array are valid pointers. If you pass bad pointers into the
This is incorrect. To start with - it builds the argv pointer array
itself. The passed array is simply used to get a list of strings
and to build them on the stack of the target process.
The argv and envp is then built by the ELF loader walking these tables
in order to generate the argv and envp arrays that the SYS5 ABI expects
to be passed (saner ABI's the user space start up builds argc/argv).
> execve system call you can corrupt the processes stack before it
> returns to user space. Then when the kernel hands off the process to
I don't think you can. The built ELF stack looks roughly like
[Environment] - null terminated string data
[Arguments] - null terminated string data
[Elf gloop]
[envp]
[argv]
[argc]
-> You are here
on entry, so the stack is fine.
> The thing that tipped me off to the problem was that a program that I
> exec'd was getting killed with SIGSEGV in __libc_start_main before my
> main function began running.
I would certainly be interested in an example that caused this. That there
could be a bug in the kernel or glibc exec building I can believe. Your
diagnosis of the cause however is dubious.
Alan
