Vulnerability Development mailing list archives

Re: Bug in Apache 1.3.20 Server - Hackemate Research


From: Steve Grubb <linux_4ever () yahoo com>
Date: 30 Sep 2001 13:40:17 -0000

Hello,

Several months ago, I posted something along 
these lines to apache-bugdb. I think this is the 
same problem, but from a different angle. I 
personally believe that apache should close all 
file descriptors except stdin, stdout, & stderr...just 
like inetd. I seriously wonder what these holes 
can be made into in the hands of a master. Many 
places have untrusted user accounts and 
chroot'ed or not, these are open descriptors. ;)

---Snip----

I have a program that can run as a cgi-bin script 
that audits the environment inherited by a child 
process. It can be found at:
www.web-insights.net/env_audit.c

When this is run against Apache 1.3.14 as 
distributed by RedHat 6.2, I find that all cgi-bin 
programs inherit these open descriptors from 
apache (besides 0,1, &2):

Open file descriptor: 7
User ID of File Owner: 0
Group ID of File Owner: 0
WARNING - Descriptor is leaked from parent.
File type: fifo
File decriptor is read only

---
Open file descriptor: 8
User ID of File Owner: 0
Group ID of File Owner: 0
WARNING - Descriptor is leaked from parent.
File type: fifo
File decriptor is write only

---
Open file descriptor: 21
User ID of File Owner: 0
Group ID of File Owner: 0
WARNING - Descriptor is leaked from parent.
File type: character device
File decriptor is write only

On apache 1.3.19 as distributed by RedHat 7.1, 
(beside 0,1, &2) I see these descriptors leaked to 
all cgi-bin programs:

Open file descriptor: 3
User ID of File Owner: 48
Group ID of File Owner: 0
WARNING - Descriptor is leaked from parent.
File type: regular file, inode: 558149
The leaked descriptor 
is: /var/run/httpd.mm.765.sem
File decriptor is read and write

---
Open file descriptor: 4
User ID of File Owner: 48
Group ID of File Owner: 0
WARNING - Descriptor is leaked from parent.
File type: regular file, inode: 739054
The leaked descriptor 
is: /var/cache/ssl_gcache_data.sem
File decriptor is read and write

Is this security issue? And do these leaked 
descriptors have a purpose for
cgi-bin programs to use (or abuse)?

Cheers,
Steve Grubb


Current thread: