Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 24 Oct 1997 01:08:02 -0400 (EDT)
From:      Bernie Doehner <bad@uhf.wireless.net>
To:        Marc Slemko <marcs@znep.com>
Cc:        "Scot W. Hetzel" <hetzels@aol.com>, FreeBSD Ports <ports@FreeBSD.ORG>
Subject:   Re: Apache w/FrontPage Module Port
Message-ID:  <Pine.BSF.3.96.971024003523.579H-100000@uhf.wireless.net>
In-Reply-To: <Pine.BSF.3.95.971023215007.11617H-100000@alive.znep.com>

next in thread | previous in thread | raw e-mail | index | archive | help
> I don't really want to do that right now, because you raise misleading
> points that need clarification.  If you wish to in the future, feel free.

Ok..  There just comes a point when a conversation is more of a personal
discussion than a public discussion, but I agree for the moment.

> > > Those directories should NEVER EVER EVER (unless you are an uber-guru and
> > > know what you are doing and what the risks are and how to avoid them) be
> > 
> > Tend to differ. On one of our secondary apache servers we have it set up
> > this way because the web server runs on the professor's UID, and most of
> > the apache directories to mode 700 so that noone else can log into the
> > machine and look around them directly (they are used for  courses and we
> > wanted to control how information in these directories is presented -
> > only in a controled way through apache, and never directly under Unix). He
> > also needed the flexibility of being able to kill and restart the web
> > server (without root password). There is no other way to accomplish this
> > if you run the web server under the default uid of nobody, and root.wheel
> > file permissions. 
> 
> That is different; it is not running on port 80 presumably and presumable
> it is very tightly controlled so only the one user can place make content
> available on it.  In the vast majority of cases, Apache is started as root
> because it does need to bind to port 80.

RIGHT.. Port 8080 (sorry forgot to mention that very important fact).

> I still do not recommend doing things as in the above situation because it
> allows any holes to compromise the (presumably) important professor's
> account.  Make things group readable and setup a seperate group to avoid

I like the word "presumably" :)

> > I am in favor of Scott's proposed way of doing this because it allows for
> > special circumstances such as the one above.

> It is not acceptable for the vast majority of sites.  Unless I
> misunderstand what is being suggested, I would strongly oppose such a port
> ever being included in the FreeBSD ports collection and suspect I would be
> well supported in this view.  Nothing prevents people from setting up
> their own server for special circumstances.  Defaults must not be made
> insecure because of it.

In that case (if we are throwing configurability out the window and going 
for a basic / securely installed server server), how about also keeping
CGI and frontpage extensions out of the "default"? 

After all, front page extensions/CGI is not a critical part
of the web server and not needed for a very basic/secure ports based
collection. Like you said, people can set up their own servers for special
circumstances. Our organization  does not consider front page extensions
or CGI (with the exception of a numbers CGI) a necessity for a functioning
server.

> Install script: "hey, I am going to do this but it is a stupid idea.
> should I proceed?"
> 
> User: "ermmm... I don't have much choice, do I?  I don't understand.
> Better let it do what it wants, after all the people who made this must
> know what they are doing."

Ok.. I see your point, now that you put it so eloquently.. :)
 
> That isn't really an option.  There is no need.  It is not, in the general
> case, secure.  Prohibiting all CGI is impossible if you are trying to use
> MS's FrontPage modifications because the very basis of them is that you
> allow the execution of CGIs.  CGIs that you don't have the source for. 
> CGIs that very likely have security holes in.  In any case, not only is
> prohibiting user CGIs not an option for many, many don't know how to do it
> correctly even if they wanted to.  Even if they do, it does not solve the
> problems.  Setup properly, a hole in Apache does not compromise root. 
> That is the way it should be.  You are foolish if you trust the Apache
> code (or any other webserver that I have examined) with root; it is far
> too large and has far too much legacy code in. 

Right..  I like the default UID nobody, directories root.wheel (and
correct per installation instructions modes) scheme on all our "standard"
servers.
 
> > 
> > I tend to differ however about the ownership of the binary (as long as you
> > don't set the setuid/setgid bits). The only thing that ownership and mode
> > will affect is who can run the binary.
> 
> No.  Try it some day.  If you own it, you can modify it unless you take
> special care like setting it immutable.  In the typical setup running on
> port 80, that means you can modify a binary run by root.

AHHH.. I see what you mean (in the "default/standard" configuration).

> My thing with guru points is that some people have been through all these
> details before and know the risks and why not to do certain things. 
> Warnings scattered through the Apache documentation and that I have posted
> are not senseless nonsense.  They have a very firm basis in reality; I am
> not trying demean you or be an arrogant bastard but the fact is that I
> have been through these issues, I am very familiar with the Apache source,
> and I know many of the consequences of the things you are suggesting. 
> They are not good and pose unacceptable risks, even if you don't
> understand them. 

[this is why I was suggesting private mail..oh well]. 
I like to think of this as an open/contructive forum for discussion and
take it as such. Nonetheless, I don't understand what you mean by guru
points.. This isn't a grand competition we are in.

> > point about root compromise in the case that web server is run by the same
> > uid as the owner of the logs directory.. Assuming someone can maliciously
> > mangle the logs through apache, at most it would be a user compromise. A
> > bit far fletched, but perhaps possible through the frontpage module
> > (only module I haven't picked apart yet).
> 
> No.  It gives you very easy root access.  The Apache docs explicitly warn
> about this for good reason.  Hint: what user opens the Apache log files? 

In this scenario, with the web server running under the uid of the owner
of the logs directory and on a port > 1024, the uid of the owner of the
logs directory. In this scenario I don't see how the web server can obtain
root privileges because root never executed the web server program in the
first place. 

> What are symbolic links on Unix?  Put those two together and you get the
> answer.  If you really want details, I'm sure you can find reference (try

You still need something to be executed by root in order for this to
happen. If the web server was never run by root, I just don't see it.

> Dejanews) to a post I made on comp.infosystems.www.servers.unix a number
> of months ago that explained all the details.

Ok, yes, I am interested, if this exploit is a way to compromise
root through apache, fitting the above scenario (not executed by root to
start it up), and somehow uses symbolic links to accomplish this.
 
> There is a large difference between allowing users to write stupid CGI
> scripts and setting your server up so anyone can get almost instant root. 
> The former is a local policy decision based on what risks are acceptable
> to you.  The latter is an unacceptable thing to do, especially for a
> distributed port. 

Again, it's all a question of how secure you want the default ports
collection to be.. Can you honestly say that including frontpage in the
"default" leads to a secure installation?. I am not sure if I'll ever
fully understand frontpage and the extensions (besides I try to avoid it
like the pest)..






Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.96.971024003523.579H-100000>