httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From (Robert S. Thau)
Subject Re: PUT handler spec?
Date Fri, 05 Jul 1996 20:02:06 GMT
  How about something like:

  - Browser sends a PUT request with a URI
  - Server sees the PUT request and automatically asks for authentication
  - Browser sends authentication username and password
  - Server authenticates through the normal mechanism

So far, the existing authentication modules give you all of that for
free (via <Limit PUT>).  In any case, there are circumstances in which
someone might want to create something like my "sandbox" directory,
which allows completely unauthenticated PUTs.  For a directory like
that, none of the above is even necessary.

However, this...

    if authenticated, server looks at owner of URI, or if not present,
    the owner of the directory.  If authenticated user does not match
    this owner, FAIL, otherwise, go ahead and replace/create the URI

would, if implemented precisely as you say, allow the following:

    # Mallet arranges for /etc to be mapped into his webspace... ln -s /etc ~mallet/public_html/etc

    # ...with a .htpasswd that gives a password he's chosen for "root". htpasswd -c ~mallet/htpass root
    Adding password for root.
    New password:
    Re-type new password: cat > ~mallet/public_html/.htaccess
    AuthType Basic
    AuthUserFile /homes/mallet/htpass
    <Limit PUT>
    require valid-user

    # He can now author files in "/etc/" at will... telnet 80
    PUT /~mallet/etc/passwd HTTP/1.0
    Authorization: ... whatever ...
    Content-length: ...


For PUT-handling mechanisms with failsafes that prevent attacking of
root-owned files directly, substitute indirect attacks via, say,
planting trojan horses in the .cshrc of a privileged user (or for that
matter, some particular user that our attacker has a grudge against,
if that's the sole objective of the prank).  The point here is that
you *must* think about ways in which whatever machinery you propose
could be exploited by an attacker (say, someone who has captured the
password of a legitimate user and is trying to consolidate their hold
on the machine), before deciding to trust it.

Most of the security checks in my PUT-handler (which consists of
almost nothing but security checks) are in fact there to cover that
sort of scenario --- that is, attacks by one authorized user against
another, or against the integrity of the system as a whole.  For
instance, the above attack would fail with my put-handler, even if
there were no backstop preventing PUTs on behalf of root, because the
attacker (one hopes!) has no way to create /etc/RCS/WEB.PUT.CTL or
even /etc/RCS.  (If they did, they probably wouldn't need to go
through the web server to create other files there).

In fact, all of those checks are there to guard against specific,
known attacks of one kind or another, and to limit the potential
damage generally in the case of server compromise.

In any case, PUT-handling of any sort requires the server to have
write permission on the target directory, in order to create or
replace the file.  You get that either by making that directory
writable by "other", so that the server's uid has write permission (or
make it group-writable and owned by a "web-authors" group to which the
server's uid and everyone else on the system belongs, which amounts to
the same thing), or by making the PUT-handling machinery suid-root.

The problem with with making all the files writable by "other" is that
if you have mutually suspicious users (university undergrads,
competing clients of a common ISP, whatever), they aren't protected
from each other.  

That leaves the suid-root approach, which in turn means either:

  1) Running the web server as root.  No thanks.
  2) Having it invoke a suid-root back end script to do the actual deed.

My PUT-handler uses the second approach, primarily because with less
code running as root, it's easier to think about how it might be
exploited and what might go wrong.  It is, as you have observed,
somewhat cautious in doing so.  I hope I've explained why.


View raw message