OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
 
From: Steven Grimm (korethmidwinter.com)
Date: Wed Jul 18 2001 - 14:14:27 CDT

  • Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

    Un-CGI's author here, with a response to this report.

    > 1. uncgi does no relative directory checking; this means anyone can
    > execute any program on the remote system as the http user (to some
    > extent, permission wise of course) using the simple dot-dot-slash trick.

    I've released a fix for the ../ hole; thanks for pointing that one out.
    http://www.midwinter.com/~koreth/uncgi.html has a link to the new version.

    Adding relative directory checking beyond that would have little security
    benefit. The following two-line shell script demonstrates why:

    #!/bin/sh
    /run/a/malicious/program/somewhere/else

    Put that script in Un-CGI's script directory and you're off and running.
    If you can put a symbolic link into the script directory, you can put
    a script like this there instead, so blocking symbolic links doesn't make
    your system particularly more secure.

    > 2. uncgi does not check if the script it will execute has any executable
    > bits turned on. As most CGI scripts are just that-- scripts, uncgi
    > will try to execute the program located behind #! on the first line
    > of the CGI script and feed the CGI script filename itself as an
    > argument. This means the CGI script doesn't have to be executable
    > for uncgi to be able to execute it.

    See above. Nothing prevents a malicious user with write access to the
    script directory from writing an executable script that runs a non-
    executable one. Running scripts that don't have execute permission set
    is a convenience feature and frankly in the 7+ years Un-CGI has been
    released this is the first I can remember anyone taking issue with it.

    However, I've added a compile-time switch to disable the feature for
    those who feel it's not worth the potential for abuse.

    With the exception of the ../ hole, Un-CGI's security is exactly the same
    as the security of your script directory. Which, really, when you think
    about it, is also true of a typical CGI-capable Web server; as soon as
    you let random users stick programs in the cgi-bin directory you're
    opening yourself up to potential security problems.

    > As these vulnerabilities are
    > so easy to exploit, I almost know for sure these vulnerabilities are
    > already being exploited.

    Almost? I have a hard time imagining any that would have been prevented
    (as opposed to delayed for a few seconds) by adding realpath() calls and
    checking for executable bits. If you know of any specific instances of
    exploits, please drop me a line so I can talk to the sysadmins in question
    and get more details.

    Even the ../ hole is only theoretical on many Web servers; on my system,
    for example, the server silently translates /cgi-bin/uncgi/foo/../bar to
    /cgi-bin/uncgi/bar before running Un-CGI. But in any case it should no
    longer be a problem even on servers that don't do internal .. detection.

    -Steve