[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [cobalt-users] Cobalt wishlist
- Subject: Re: [cobalt-users] Cobalt wishlist
- From: Chris Adams <cmadams@xxxxxxxxxx>
- Date: Mon Apr 17 06:53:28 2000
Once upon a time, Robert G. Fisher <rfisher@xxxxxxxxxxxxxxx> said:
> On Wed, Apr 05, 2000 at 04:32:56PM -0500, Chris Adams wrote:
> > That is not where the bug is. It doesn't matter what version of the FP
> > extensions are installed. If your site is uploaded through the FP
> > interface, anybody with an account on that RaQ can edit your site
> > (add/modify/delete pages). If you don't believe me, give me a site on
> > your RaQ. :-)
>
> Okay, now you really have my curiosity up. Where's the condition
> that lets you write to files? The biggest thing I can see is
> a possible CGI exploit in that since all users CGIs run as httpd,
> and all FP enabled webs are owned by httpd -- that a malicious
> user could put together a small cgi using the POST method to let
> any upload a file that posts to a directory tree outside your
> own directory.
You have the problem - you can short circuit CGIs to _not_ run under
cgiwrap. On the RaQ3, you can even make them run under mod_perl (since
that is included). If you do that, your code will run as user httpd.
You don't have to have a CGI that uses POST to upload files. All you
have to do is write a script that copies a file from one place to
another, or removes files, etc. Then you put it in your web directory
and run it by calling it like a CGI. Who cares if you get an "Internal
Server Error" because your script didn't put out proper HTTP headers?
You just overwrote (or erased) someone else's FP site.
> Is this what you're talking about? Unfortunately, that's something
> I suspect you'd encounter with all ports of FrontPage until you are
> able to run the FP extensions to setuid to an admin for a particular
> site in each site that has FP enabled.
What I remember from the times I've looked at FP extensions for Apache
is that they run the extensions as the user that owns the site. I guess
that since the Cobalt way doesn't have any user associated with the top
level site, they didn't do it that way.
What I'd like to see Cobalt do is create an extra user that is the
"site" user (so for site 24, in addition to a new group "site24" you
would have a new user "site24"). The user would be a site
administrator, but it would not have a password (so no direct access)
and it would not show up on the site user list (so nobody could delete
it). This user could be used for FP extensions for that site. In
addition, this would allow CGI and FP to co-exist with no extra effort,
because the CGIs would be owned by a site admin of the site, so cgiwrap
would run them. This would also fix any security bugs related to all FP
sites having common ownership.
--
Chris Adams <cmadams@xxxxxxxxxx>
Systems and Network Administrator - HiWAAY Information Services
I don't speak for anybody but myself - that's enough trouble.