Date: Mon, 12 Aug 2013 14:39:53 -0700
From: coderaptor <coderaptor@...il.com>
To: Reindl Harald <h.reindl@...lounge.net>
Cc: "bugtraq@...urityfocus.com" <bugtraq@...urityfocus.com>
Subject: Re: [Full-disclosure] Apache suEXEC privilege elevation / information disclosure

On Mon, Aug 12, 2013 at 11:11 AM, Reindl Harald <h.reindl@...lounge.net> wrote:
>
> Am 12.08.2013 19:28, schrieb Coderaptor:
> > I have been a silent spectator to this drama, and could not resist adding a few thoughts of my own:
> > All software, especially webservers, should ship with secure defaults
>
> yes, but define secure defaults without a context
> hint: you can't

Oh, a practical context can very well be established. We aren't
talking about formal methods are we?

> > It is a fundamental mistake to assume all admins who roll out web apps and
> > maintain servers RTFM before rolling out
>
> it is a fundamental mistake not doing so and be admin

Agree. However, the vast amount of data shows otherwise. Its easy to
have reasonable secure defaults than expect knowledgeable admins, IMO.

> > 2. Apache clearly does not ship with secure defaults in favor of convenience?
> > disable_functions is a example
>
> disable_functions has *nothing* to do with Apache because it is a php option
> apache itself *does not* create symlinks at all

My bad. PHP it is. Well, PHP design is broken then.

> > do you expect an admin to be a unix expert or know what each parameter in there means?
>
> *yes* *yes* and *yes* again

*cough* *cough*. Ideally, yes. Practically, no.

> > Why not enable_functions instead, with everything disabled to begin with?
> > (Oh, that wouldn't help you achieve world dominance and fast!)
>
> another example that people with no clue make proposals
>
> there you go: http://www.php.net/manual/en/funcref.php
> come on, list all functions except the one i listed
>
> *Again*: Apache does not create any symlink
> Apache does only *follow*
>
> so what should suExec do for you if you are refuse to understand what
> the different software-layers are supposed to do and why different
> layers exist at all and finally how to manage all of them?
>
> so disable follow symlinks in Apache or disable potential dangerous functions
> in scripting languages - and since Apache can not control any low level
> function a scripting language is using and symlinks are not the only
> dangerous thing you should do *both* or not play admin
>
> this thread is a good example that lazy admins are dreaming about rollout a
> powerful *and* secure service with default configurations and this naive
> attitude is only possible by beeing completly clueless, if one would
> understand the underlying tech he would no longer dream of flying horses

That's a sad fact. And it is compounded by poorly written framework,
and software. I am depressed, we are doomed. Now, where is my coffee?

-coderaptor

>
> > On Aug 11, 2013, at 3:30 PM, Reindl Harald <h.reindl@...lounge.net> wrote:
> >> Am 11.08.2013 23:56, schrieb Stefan Kanthak:
> >>> "Reindl Harald" <h.reindl@...lounge.net> wrote:
> >>>> again:
> >>>> symlinks are to not poision always and everywhere
> >>>> they become where untrusted customer code is running
> >>>> blame the admin which doe snot know his job and not
> >>>> the language offering a lot of functions where some
> >>>> can be misused
> >>>
> >>> Again: symlinks are well-known as attack vector for years!
> >>
> >> and that's why any admin which is not clueless
> >> disables the symlink function - but there exists
> >> code which *is* secure, runs in a crontrolled
> >> environment and make use of it for good reasons
> >>
> >>> It's not the user/administrator who develops or ships insecure code!
> >>
> >> but it's the administrator which has the wrong job if
> >> create symlinks is possible from any random script
> >> running on his servers
> >>
> >> anyways, i am done with this thread
> >>
> >> the topic is *not* "Apache suEXEC privilege elevation" it
> >> is "admins not secure their servers" - period
>

Powered by blists - more mailing lists