Re: apache as a system shell ( Debian Wheezy Compromised - www-data user is sending 1000 emails an hour)
On Wed, Jan 1, 2014 at 7:30 PM, Jerry Stuckle <drunkensot9999@gmail.com> wrote:
> On 1/1/2014 2:52 AM, Joel Rees wrote:
>>
>> [...]
>> On Wed, Jan 1, 2014 at 11:51 AM, Jerry Stuckle <jstuckle@attglobal.net>
>> wrote:
>>>
>>> On 12/31/2013 8:43 PM, Joel Rees wrote:
>>>>
>>>>
>>>> On Wed, Jan 1, 2014 at 12:58 AM, Raffaele Morelli
>>>> <raffaele.morelli@gmail.com> wrote:
>>>>>
>>>>>
>>>>> [...]
>>>>> I just want to add a (relevant) bit.
>>>>> Apache has tons of directives to secure a website and if you really
>>>>> need
>>>>> to
>>>>> upload in a dir you can tell apache to not execute php scripts in there
>>>>> or
>>>>> force file type to text or prevent POST request from untrusted ip, etc
>>>>> etc.... and you'are done.
>>>>
>>>>
>>>>
>>>> It has occurred to me on several occasions that apache is essentially
>>>> another shell over the underlying OS calls -- like bash is a shell for
>>>> character/command-line-oriented terminal (sessions).
>>>>
>>>
>>> No, Apache is a web server. It can load certain modules to provide
>>> additional services, e.g. PHP or Python. But it is not a shell.
>>
>>
>> "Shell" has multiple meanings. Character-oriented command-line shell
>> is just one of them. (And I'm sure you know that.)
>>
>
> Yes, and "Web Server" is not one of those meanings.
Why not?
A web server exposes various aspects of the system to users, including
parts of the file system and parts of the ABI. That's basically what a
shell does.
> Apache is a web server.
> Nothing more, nothing less. It is not, and never has been, a shell.
And when has a web server not been a shell?
Sure, the division between user instances and the daemons that manage
the instances and keep the data moving between them and the external
world is a bit different. We usually forget that there is a daemon
keeping our shell instances running, where, with the web server, we
don't consider the shell and the daemon to be distinct.
But that's a problem of perception, not function.
> Without additional modules, Apache can't even execute scripts.
What are you saying here? Why should a shell have to be able to
execute scripts if it can pass them off to appropriate interpreters?
And how does it fit with what you say below?
I suppose you might find some jargon dictionaries that insist that a
shell be a Turing complete programming language, but such dictionaries
are likely to claim that a graphical shell is fundamentally a
different thing from a shell. (Begging questions about scriptable
graphical shells.)
> But the
> addition of scripting languages does NOT make it a shell.
So what does make a shell?
>> If you aren't willing to use the term in the more complete meaning,
>> please stay out of the conversation. (And don't bother digging up
>> "definitions" that would eliminate purpose-specific-shells over the
>> ABIs or APIs, or I'll reach across the Pacific, grab my 30 year old
>> copy of the XINU text and throw it at you. ;-)
>>
>
> If you aren't willing to learn what Apache is and is not, please don't ask
> the question.
Okay, so I just virtually threw my extra copy of the Apache manual at
you. Did you virtually duck?
(Now, if I were to send the apache documentation bundled as a pdf to
your e-mail address, that would be a pointless exercise in literal
throwing, not virtual, so I won't do that. :-/)
>>>> It has also occurred to me on several occasions that it implements its
>>>> own security model, and provides an alternate path into the system
>>>> resources (file system, etc.) that sometimes circumvents the native
>>>> security model.
>>>>
>>>
>>> Yes, it has some security features built in. But it cannot circumvent
>>> the
>>> native security model. If an application could do that, the security
>>> model
>>> in Debian would be worthless.
>>
>>
>> Yes and no, and if you would bother yourself to think beyond whatever
>> wall stands between you and me, I think you would not have said that.
>>
>
> You seem to have a problem with "whatever wall stands between you and me",
> not me. I'm just trying to answer your question. But you are unwilling to
> learn.
As in learn not to give you an excuse to flame the list?
If you want to flame me, you can do it in private, but of course that
would be less interesting to people watching me figure out why you're
wrong here. (And then again maybe no one is interested.)
>> I mean, in the parent thread to this, you laid out quite well the
>> problems of application support files being owned by root -- the
>> problem of who gets/has to edit them. You can see the larger issues if
>> you will.
>>
>
> Yes, and who can own the files has nothing to do with whether Apache is a
> shell or not.
True, I was just commenting on the fact that you can sometimes say
quite reasonable and meaningful things. I suppose there's something
wrong with that?
>>>> And I note that I prefer the native Unix basic security model not to
>>>> be circumvented.
>>>>
>>>
>>> It cannot be.
>>
>>
>> If that were true, why would Apache (or any other web server) ever
>> have security advisories?
>>
>
> Because Apache has added additional security features to limit what people
> can do from the web. These features are in addition to those of Linux (and
> Windows), not a replacement for them.
Sure, it sometimes has issues with its implementation of separate
security models.
It also has had problems because of the practice it allowed (and used
to effectively encourage) of running as root or other privileged user.
That's a configuration issue, and the openBSD team did a good job of
demonstrating how to drop privileges after getting port 80, but it
provided a path to circumvent the system security model until it
became part of the standard server startup and configuration. (Still
some theoretical issues there.)
Initial implementations of WebDAV had serious configuration issues, as
well, which we regularly have to revisit with Drupal and other such
packages.
And there have been vulnerabilities in the past where the way it
exposed the file system ABI provided hard paths for privilege
escalation, literal circumvention of the *nix security model. There
will be again.
>>>> I have other thoughts on the subject, but my wife says we have to go
>>>> do the family new-year's stuff. Be interested in comments.
>>>>
>>>
>>> Learn how security works.
>>>
>>> Jerry
>>
>>
>> That's not a comment I'm interested in.
>>
>
> Then don't ask the question.
Why? (And which question did you take offense at?)
> Jerry
Part of the problem with the disagreements about best practices for
configuring web servers, particularly those that expose a writable
path to the file system, is that we ignore the fact that the server
is, in effect, a shell.
We want to give it some special, superhero status that it is supposed
to do things that are fundamentally impossible, by virtue of it being
a web server instead of a shell. But that just leads us to take
shortcuts we shouldn't take -- like handling uploads as the same
system user as the daemon process that manages the entire server.
--
Joel Rees
Be careful where you see conspiracy.
Look first in your own heart.
Reply to: