Re: Another Frontpage Bug, with promiscuous ScriptAliases

[marcs () ZNEP COM (Marc Slemko)]

On Thu, 23 Apr 1998 pedward () WEBCOM COM wrote:

> The Apache hack that M$ distributes allows one to create ANY directory
> on a Frontpage enabled web server, and execute content in it.
> This also goes for the stock Netscape Server config that M$ recommends.
>
> Hmm, I wonder if M$ deliberately places security holes in Unix apps so
> that they can claim "but Frontpage under IIS doesn't have that hole!".
>
> Mainly because IIS loads Frontpage as a DLL (I suppose).  Frontpage
> wouldn't be anywhere near the PIG it is if it ran as an Apache module
> or NSAPI module...but then who has an extra 5 megs per server process
> to burn???

Trust me, you don't want the frontpage extensions running in your server's
address space if you are concerned about security.  There are many ways to
improve on them without making them a module.

In any case, if you make them a module then you are right back to the
problems that older versions had where all the content was owned by the
same user.

> EG:
>
> You want a rogue program to run, and the victim has anonymous uploadable
> FTP (or you sign up for a service and you want to run binaries on the
> server, but can't):
>
> mkdir _vti_bin
> cd _vti_bin
> put [whatever bin]
>
> Web browser:
>
> http://www.victim.com/somedirectorystructure/_vti_bin/trojanfile
>
> Boom you've got stuff runnin on that server.

Not very interesting.

What you are saying is that if you have access to the server, then you
have access to the server.  If someone has anonymous ftp uploads setup so
the upload are readable and are inside a tree that is available from the
web, _that_ is the problem.

Well, guess what?  The default Apache configuration does the same thing
and I do not think it is a bug.  Let me restate that: the default Apache
config should be more explicit about what is enabled by default and
should, for consistency's sake, completely disable htaccess files and all
options except Indexes and FollowSymLinks everywhere, but the failure to
do so is not a serious security bug as you claim.

I should really finish rewriting the default config files to make more
sense.

If someone is running in a special environment where people have limited
access to the machine, they have to configure their software to respect
that.  I am more than willing to point out flaws in Microsoft software,
but you are barking up the wrong tree.  There are other issues with the fp
extensions.  I'm not aware of anything like what there was in the past,
and have not had the time nor interest to fully review the implications,
however some of the implied trust relationships associated with running
the scripts as the owner of the webspace concern me.  This problem is not,
however, easy to solve in general on Unix or most operating systems; you
want a set of programs that are accessed by others to be able to read and
write to part of your filesystem, you want it all to still be controlled
by a normal user, you want to do this for a large number of users, and you
don't want to create extra users on the system.

Web servers could add a whole lot of very cool and useful features if this
was easier to do securely, but I don't trust Apache running with a real or
saved uid of root.