Re: [Full-disclosure] Apache suEXEC privilege elevation / information disclosure

[coderaptor <coderaptor () gmail com>]

On Mon, Aug 12, 2013 at 11:11 AM, Reindl Harald <h.reindl () thelounge 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 () thelounge net> wrote:
> > > Am 11.08.2013 23:56, schrieb Stefan Kanthak:
> > > > "Reindl Harald" <h.reindl () thelounge 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