httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Slemko <>
Subject small security hole in accept_mutex_init
Date Fri, 27 Dec 1996 21:18:01 GMT
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);

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.

View raw message