bin/64150: [PATCH] ls(1) coredumps when started via execve(2) with no argv.

[Ruslan Ermilov]

On Fri, Mar 12, 2004 at 11:57:30AM +0100, Morten Rodal wrote:
> On Fri, Mar 12, 2004 at 12:49:14PM +0200, Ruslan Ermilov wrote:
> > On Fri, Mar 12, 2004 at 10:22:00AM +0100, Morten Rodal wrote:
> > > >Description:
> > > ls(1) calls the fts(3) functions for traversing a file hierarchy.
> > > If ls(1) is executed via execve(2) system call with a NULL argv
> > > and envp it will make the fts(3) functions core dump with a
> > > SIGBUS.
> > > 
> > > If execve(2) is executed with a NULL (I am not sure this is
> > > legal?) argv, the executed program will have an argc value of -1.
> > > 
> > > >How-To-Repeat:
> > > #include <stdio.h>
> > > #include <unistd.h>
> > > 
> > > int main(int argc, char **argv) {
> > > 	execve("/bin/ls", NULL, NULL);
> > > 
> > > 	return (1);
> > > }
> > 
> > The execve(2) manpage says:
> > 
> > : The argument argv is a pointer to a null-terminated array of character
> > : pointers to null-terminated character strings.  These strings construct
> > : the argument list to be made available to the new process.  At least one
> > : argument must be present in the array; by custom, the first element
> > : should be the name of the executed program (for example, the last compo-
> > : nent of path).
> > 
> > 
> 
> Indeed you are correct, but I would have wished that execve(2) could
> set argc = 0 and not -1 for the newly created process.  However I
> think this is a standards issue and I'll just correct this program to
> include argv and envp vectors when calling execve(2).
> 
> Thanks for the quick response.
> 
The problem is not with execve(2) (which correctly sets argc to 0),
but with the standard getopt(3) usage:

: while ((ch = getopt(argc, argv, "bf:")) != -1)
: 	switch (ch) {
: 		...
: 	default:
: 		usage();
: 	}
: argc -= optind;
: argv += optind;

And the fact that optind is initially set to 1.  I wonder what
could be the implications for setuid programs.  There could be
quite unpredictable results, as the "argv" pointer is incorrectly
advanced in this case, and at least several setuid programs that
I've glanced at are vulnerable to this attack.


Cheers,
-- 
Ruslan Ermilov
FreeBSD committer
ru at FreeBSD.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-security/attachments/20040312/d470e4ad/attachment.bin