Re: CVE request: FD leakage for cgi program on Monkey HTTPD

[John Lightsey <john () nixnuts net>]

On Fri, 2013-06-14 at 12:02 -0700, Seth Arnold wrote: 
> On Fri, Jun 14, 2013 at 06:20:59PM +0000, Christey, Steven M. wrote:
> > Felipe,
> >
> > Sorry if this is a dumb question.
> >
> > If you are using "file descriptor leak" in the sense of "malicious
> > parties can directly access the file descriptor" - then that doesn't
> > seem to be the case here, because permissions are limited only to you.
>
> I seem to recall this issue came up for Apache around a decade back; it
> also forgot to close the listening sockets before executing CGI scripts.
>
> These sorts of events brought about a general consensus that scripts
> or other programmable code executed directly by the webserver was by
> definition completely trusted. If you don't trust the CGIs or plugin
> modules as much as the webserver, you'd run them via FastCGI as another
> user or otherwise use the webserver as a proxy in front of the services.
>
> Yes, a CGI could accept() connections on those sockets and generally
> muck things up -- but they already run with the full privileges of the
> webserver.

CGI scripts don't run with the full privileges of the webserver. They
typically run with the privileges appropriate to a container inside the
webserver (a combination of virtualhost configuration directives, URL
address space, document root and  uid/gid.)

A user on the server that can edit CGI scripts in one context shouldn't
be able to take over other contexts on the same system. How would shared
hosting and userdir be possible if CGI scripts were allowed to do this?

You could certainly argue that some webservers are not written to
support shared hosting or userdir style functionality, but Monkey
clearly is written to support it.

I don't see how this issue is very different from CVE-2012-4442 and
CVE-2012-4443. Do you believe those CVEs were not appropriate?

> The Monkey folks probably should use close-on-exec on their file
> descriptors for simple reliability reasons. And this should probably
> not get a CVE -- unless the Monkey server documentation claims there is
> a trust boundary between the server and CGIs. I'd be surprised.

Attachment: signature.asc
Description: This is a digitally signed message part