--r5Pyd7+fXNt84Ff3 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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. > > >=20 > > > 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. > > >=20 > > > >How-To-Repeat: > > > #include <stdio.h> > > > #include <unistd.h> > > >=20 > > > int main(int argc, char **argv) { > > > execve("/bin/ls", NULL, NULL); > > >=20 > > > return (1); > > > } > >=20 > > The execve(2) manpage says: > >=20 > > : The argument argv is a pointer to a null-terminated array of character > > : pointers to null-terminated character strings. These strings constru= ct > > : 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 com= po- > > : nent of path). > >=20 > >=20 >=20 > Indeed you are correct, but I would have wished that execve(2) could > set argc =3D 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). >=20 > Thanks for the quick response. >=20 The problem is not with execve(2) (which correctly sets argc to 0), but with the standard getopt(3) usage: : while ((ch =3D getopt(argc, argv, "bf:")) !=3D -1) : switch (ch) { : ... : default: : usage(); : } : argc -=3D optind; : argv +=3D 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, --=20 Ruslan Ermilov FreeBSD committer [email protected] --r5Pyd7+fXNt84Ff3 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFAUZnRUkv4P6juNwoRAn8UAJ9umI1JJFx5VE4iPJT/9INroNdntwCfYPjP WCACD7ftH7/D0zYItIK7HrA= =0y99 -----END PGP SIGNATURE----- --r5Pyd7+fXNt84Ff3--