httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chuck Murcko <ch...@n2k.com>
Subject Re: small security hole in accept_mutex_init
Date Fri, 27 Dec 1996 23:47:38 GMT
I'm +1 for adding O_EXCL to the popenf() flags, unless someone knows of
an OS not supporting this. This should be in 1.2.

Gary, what about OS/2? Is this copacetic there?

Marc Slemko liltingly intones:
> 
> In http_main.c there is:
> 
> 	accept_mutex_init(pool *p)
> 	{
> 	    char lock_fname[30];
> 
> 	    strcpy(lock_fname, "/usr/tmp/htlock.XXXXXX");
> 	    
> 	    if (mktemp(lock_fname) == NULL || lock_fname[0] == '\0')
> 	    {
> 		fprintf (stderr, "Cannot assign name to lock file!\n");
> 		exit (1);
> 	    }
> 
> 	    lock_fd = popenf(p, lock_fname, O_CREAT | O_WRONLY, 0644);
> 	    if (lock_fd == -1)
> 	    {
> 		perror ("open");
> 		fprintf (stderr, "Cannot open lock file\n");
> 		exit (1);
> 	    }
> 	    unlink(lock_fname);
> 	}
> 
> It appears twice, once if USE_FLOCK_SERIALIZED_ACCEPT is defined and
> once if USE_FCNTL_SERIALIZED_ACCEPT is defined.  There is a race
> condition here that allows anyone to create any file as the user this
> bit of code is running as; for most standalone servers, that is root.
> There doesn't appear to be any way to overwrite files or to create any
> data in the file, but it is still a potential risk.
> 
> All the attacker has to do is:
> 	- guess what mktemp will return
> 	- "ln -s /usr/tmp/htlock.XXXXXX /file/to/overwrite", where XXXXXX
> 	  is what you guess mktemp will return.
> 	- wait for accept_mutex_init to run
> 
> The normal way to fix this would be to use mkstemp, but since there
> is a wraper around open() that probably wouldn't work too well.
> Adding O_EXCL to the flags should fix it.
> 
> 

chuck
Chuck Murcko	N2K Inc.	Wayne PA	chuck@telebase.com
And now, on a lighter note:
Life is a yo-yo, and mankind ties knots in the string.

Mime
View raw message