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

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@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

On Fri, Mar 12, 2004 at 01:06:57PM +0200, Ruslan Ermilov
wrote:
> 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.
See also: http://www.freebsd.org/cgi/query-pr.cgi?pr=33738

Marc