Re: apache as a system shell ( Debian Wheezy Compromised - www-data user is sending 1000 emails an hour)
On Thu, Jan 2, 2014 at 1:52 AM, Jerry Stuckle <jstuckle@attglobal.net> wrote:
> On 1/1/2014 7:20 AM, Joel Rees wrote:
>>
>> 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.
>
> No more than a text editor, word processor or spreadsheet does. The web
> server takes a request from a user and returns the appropriate resource.
> According to your definition, a spreadsheet is also a shell. So is an
> editor.
Well, yeah. And?
I'm sure you'll take exception to referencing wikipedia, but I will anyway.
http://en.wikipedia.org/wiki/Shell_%28computing%29
Now, there's a lot in there that would support your reference to the
prevailing use of the word, but there's a lot in there that would not
support your insistence on restricting the term to a shell that
provides a command line interface. We don't need to actually bat
quotes around, do we?
>>> 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?
>>
>
> It never has been.
Well, it's too bad I don't have my copies of the ACM IEEE journals
from sometime in the '80s when I subscribed, because there were sure
diagrams in several of those that showed that basically any wrapper
for OS functionality or resources should be viewed as a shell, and
accompanying articles that mentioned command shells and graphical
shells as two instances of the general class, and specifically
included applications as "higher level" wrappers around the OS.
Various kinds of general purpose servers were specifically included as
shells, as well.
Jests about reaching across the Pacific aside, they are on the other
side of the ocean. And I am not interested in spending money on PDFs
of the articles just to satisfy your demands.
>> 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.
>>
>
> Yes, and you have a perception problem.
Touche.
But completely irrelevant.
>>> 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?
>>
>
> Because you seem to be basing your theory on the fact Apache can do things
> other than return resources.
And? Considering that resources can be access to functioning instances
of programs, how does restricting web servers to returning resources
restrict one from viewing a server as a shell?
You aren't, I assume, going to claim that command line shells never
return resources?
>> 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.)
>>
>
> I never said any such thing.
I never said you did.
I did compare your attempts to assert that we must never attempt to
view or understand the web server as if it were a shell to attempts to
restrict the word to command line shells. It's a limit on your vision.
>>> But the
>>> addition of scripting languages does NOT make it a shell.
>>
>>
>> So what does make a shell?
>>
>
> You tell me. You're the one trying to fit a square peg in a round hole.
I am telling you and you are calling me names instead of considering
the definition, much less checking the alternative perspective for
usefulness.
I don't care whether you find the concept useless or not, BTW.
Your quibbles can be used to describe parts of the view, even if you
aren't interested.
>>>> 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. :-/)
>>
>
> And where in the Apache documentation does it say it is a shell?
Apache documentation is not written in the abstract, and I assume you
will argue that I'm making too much of the reference, but
http://httpd.apache.org/docs/2.2/howto/cgi.html.en
notes that apache works like *nix shells in recognizing the
interpreter declaration on the first line of a script.
>>>>>> 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.)
>>
>
> You're the one who started with the "whatever wall..." bullshit. I just
> took your question as a real one. Now I see it was only another excuse for
> you to to argue something about which you know nothing.
Does that really help the conversation?
> I've been using web servers ever since IBM came out with one in the mid 90's
> (thankfully it's gone). I also used Lotus Domino server. I've been
> running my own Apache and IIS web servers since the late 1990's or so.
> NEVER have I heard anyone with any knowledge of webservers claim they are
> shells.
I've been using web servers for a bit longer than you. Picked up
Apache just a little after they named it for being a patchy mess. So
what?
Except for this, I remember that back then, the purpose was
specifically to provide a shell to the network that would provide an
alternative view to the file system, as an applied instance of
providing alternate paths to a restricted set of the system resources.
I remember when Apache still responded to things like
"http://../bin/sh";, and the short discussion of whether that wasn't
something you might want to allow.
>>>> 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?
Wait a minute. I let you trap me into that? How careless of me.
That was a significant part of the reason why I wanted to talk about
the similarities between the command line shell and web servers,
including apache.
If you aren't careful with how you set up the OS ownership and
permissions, a web server can provide a random user from the network
with effective ownership of files they shouldn't have access to.
You have to use both the access controls that apache provides _and_
the access controls that the system provides, to keep the resources on
the system secure.
Maybe I'm reading too much into people's laziness, but the tenor of
the conversation leads me to suspect that many people do not
understand that web servers have certain things in common with shells,
and if you misuse them they give access.
And you're trying to turn the conversation into a quibble about the
definition of "shell".
> To you, "reasonable" is "I agree with it".
Again, that doesn't help anyone understand anything.
>>>>>> 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.
>>
>
> So does PostGresSQL.
The PostGreSQL client definitely presents a user shell. Not to the
whole system, but to the part of it managed by the PostGreSQL server.
> So does MySQL.
Ditto.
I'm sure you remember those diagrams which presented the kernel as a
ball surrounding the hardware, with various ABIs (APIs, back then)
wrapping --providing a "shell" around the kernel, with the
command-line shell providing another (partial) "shell" layer and the
GUI providing a separate shell, and various servers as yet further
layers.
Most layers do not completely cover the underlying layers, some reach
below the layers immediately below, etc. The "shell" metaphor has
issues, but so does the "wrapper" metaphor. Even in the usually
accepted case of the command-line shell and the graphical UI shell,
the metaphor is not a perfect match. But it's still a useful metaphor,
and it's still used.
> So does the Java interpreter.
Java is famous (or infamous) for presenting an alternate shell to the
programmer. With a little effort, it was possible to provide a full
command-line shell written in pure Java. The beanshell is probably the
most famous of those. It sports syntax derived from Java, and it's
pretty complete as a command-line shell.
> In
> fact, so does any non-trivial application which has security features.
Yeah, and you don't even need to mention security features, even
though security "features" exist implicitly.
> But
> it doesn't mean the application has any back door past the OS's security.
Sort of.
The stopping problem has been way-over-used as an excuse to be lazy
about security. But you can't have perfect security in any real
system, and every application must be expected to open holes. And
since talking about shells is talking about applications from a
specific point of view, you have to expect shells to open holes.
Likewise servers.
>> 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.)
>>
>
> There have been a lot of security problems in applications in the past. In
> fact, there have been problems in the Linux kernel in the past which allowed
> non-privileged users to gain root privileges.
>
> But that does not mean it is insecure today. And it does not mean it is a
> shell.
This does not mean, that does not mean.
But every real system is insecure somewhere. Some are more so than
others, but none is perfect. It's a fundamental problem with all
systems.
And every system is a shell/wrapper around the resources it is
designed to manage. I'm not inventing new usage to the jargon here,
even though the popular usage has moved underneath.
>> Initial implementations of WebDAV had serious configuration issues, as
>> well, which we regularly have to revisit with Drupal and other such
>> packages.
>>
>
> So? The security issues still don't bypass the OS (or Apache) security.
> Just because it has its own security issues has nothing to do with the OS or
> Apache.
Why defend either excessively? I'm not suggesting we belly-up to
Microsoft or Apple here, nor advocating a mass exodus to openBSD, etc.
The best defense is understanding the weaknesses of your tools and
using them the best you can, and preparing for the unfortunate
possibilities.
>> 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.
>>
>
> Please show where those vulnerabilities have existed and circumvent the
> linux security model.
When a user/programmer/system engineer/etc. fails to allocate
purpose-specific users for each kind of network access you expect, the
resulting configuration circumvents the privilege separation features
of the OS. Sure that's a configuration issue more than an OS issue,
but it's a limitation of all OSses. The people who build the OS don't
necessarily know much about what we at this end plan to do with it.
It's each user's responsibility to understand the security features at
each layer and use them the best he can.
But if you have to have proof that I've read a few of those, we can
talk about integer overflows and sign overflows, we can talk about
buffer overflows, we can talk about using both of those and other
tricks to overwrite a return address through an unprotected pointer,
or to write into a jump table, ...
Why are you still insisting on attacking the messenger?
Do you think there's a war going on here? If so, which side do you think I'm on?
>>>>>> 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?)
>>
>
> You said you didn't want to hear the comment. If you don't want the
> response, don't ask the question.
And you say I dodge your questions.
Which question did you intend to answer by telling me to learn
security? Is it just because I happen to be trying to convince some
people to use good security techniques using a different approach than
you?
>>> 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.
>>
>
> Maybe YOU do. But knowledgeable people don't. And just because you screw
> up your implementation does not mean the web server can bypass Linux
> security.
Would you consider that I'm trying to describe bad habits that many of
us are subject to, rather than assuming that I'm advising everyone to
give in to those habits?
> But I see this is just another excuse for you to argue rather than learn.
> Forget the questions I asked above. Don't bother replying. I'm not going
> to waste any more of my time.
Well, I'm sorry if it was a waste of your time.
I suppose I should have thought out all the ways I could be
misunderstood and presented a doctoral thesis in the original post,
instead of just posting something that I hoped would prompt
discussion.
> Jerry
--
Joel Rees
Be careful where you see conspiracy.
Look first in your own heart.
Reply to: