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

["Brandon M. Graves" <bgraves () slicer-net com>]

I hate to come late to the party, but following all of this, it is kind of
ridiculous.

 I have to agree with those before in saying software should ship secure.
in my environment whenever we are given a new bit to add to our
infrastructure, be it a new server, new version of an OS, or new version
of a software, either A) it comes to us from those at our distribution
point pre templated to be unusable due to security, or B) we first make
it unusable by configuring every possible security setting to be as tight
as possible... After which we slowly switch off or pull back settings
until it meets the functionality required.

 It has been repeated throughout the course of this...Discussion? if whats
been going on qualifies as a discussion, that the default settings are
fine, and that it is only lazy admins who don't take the time to rtfm
that are the problems. Why is that acceptable?

Should it not be the job of the software to be as secure as possible, with
the admins/local developers having to take the time to read through the
configs to make it work in the way they need it to?

when you buy a house you don't buy it with no doors or windows, and then
have them say "well, if you want you can add doors, that will make it a
little safer, we recommend getting doors with locks, for the best possible
security.

No, You expect your house to come to you with doors and locks, and these
day's, most of the time, security systems, pre installed.

 This idea that it is OK to ship software insecure not only weakens the
security posture of the internet/intranet in general, but actually breeds
the "lazy admins" that others seem to keep pinning the problem on. If
every bit of software was shipped as a brick, instead of "just working"
with security flaws, then admins and developers alike would have to own
up to their own weaknesses and make things work while understanding what
they are doing.

Forget the professional high level development or admin level. Lets talk
about the basic user that is just trying to stumble their way through
getting something setup. There are a lot of them, and if they run
./install or ./setup on a program, and it works afterwards, that is the
end of it. Having more of those sites floating around due to ignorant
masses does not in anyway help the security posture of the world at large,
and it is a narrow mind-set that thinks that it is OK for software
developers such as apache to pass the buck onto their users.


---
Brandon Graves


> 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
>
> > 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
>
> > 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
>
> > do you expect an admin to be a unix expert or know what each parameter
> > in there means?
>
> *yes* *yes* and *yes* again
>
> > 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
>
> > 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


-- 
Brandon M. Graves
Slicer-Net