Home page logo

bugtraq logo Bugtraq mailing list archives

Re: [Full-disclosure] Apache suEXEC privilege elevation / information disclosure
From: "Brandon M. Graves" <bgraves () slicer-net com>
Date: Mon, 12 Aug 2013 15:42:02 -0700

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

 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

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
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
disable_functions is a example

disable_functions has *nothing* to do with Apache because it is a php
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
(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
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
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>
Am 11.08.2013 23:56, schrieb Stefan Kanthak:
"Reindl Harald" <h.reindl () thelounge net> wrote:
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

  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]