Date: Fri, 12 Mar 2004 13:06:57 +0200 From: Ruslan Ermilov <ru@FreeBSD.org> To: Morten Rodal <morten@rodal.no> Cc: security@FreeBSD.org Subject: Re: bin/64150: [PATCH] ls(1) coredumps when started via execve(2) with no argv. Message-ID: <20040312110657.GB52099@ip.net.ua> In-Reply-To: <20040312105730.GA99925@stud326.idi.ntnu.no> References: <200403120922.i2C9M0jC002510@stud326.idi.ntnu.no> <20040312104914.GA52099@ip.net.ua> <20040312105730.GA99925@stud326.idi.ntnu.no>
next in thread | previous in thread | raw e-mail | index | archive | help
--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
ru@FreeBSD.org
--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--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040312110657.GB52099>