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

[Seth Arnold <seth.arnold () canonical com>]

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.

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: Digital signature