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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <5207F9E0.5060504@thelounge.net>
Date: Sun, 11 Aug 2013 22:53:52 +0200
From: Reindl Harald <h.reindl@...lounge.net>
To: Stefan Kanthak <stefan.kanthak@...go.de>
CC: Tobias Kreidl <tobias.kreidl@....edu>, bugtraq@...urityfocus.com
Subject: Re: [Full-disclosure] Apache suEXEC privilege elevation / information
 disclosure



Am 11.08.2013 22:15, schrieb Stefan Kanthak:
> "Reindl Harald" <h.reindl@...lounge.net> wrote:
>> Am 10.08.2013 16:52, schrieb Tobias Kreidl:
>>> It is for this specific reason that utilities like suPHP can be used as a powerful tool to at least keep the
>>> account user from shooting anyone but him/herself in the foot because of any configuration or broken security
>>> issues. Allowing suexec to anyone but a seasoned, responsible admin is IMO a recipe for disaster.
>>
>> and what makes you believe that a developer can not be a "seasoned, responsible admin"?
> 
> Because developers write functions like "system", "symlink" and "suexec"
> which can create havoc (and are WELL-KNOWN for creating havoc since
> years) and allow everybody to call them in the default configuration of
> their software.

a so because some stupid developers all are faulty?

>> bullshit, many of the "seasoned, responsible admins" which are only
>> admins are unable to really understand the implications of whatever
>> config they rollout
> 
> It was the developer who created and published this vulnerable software
> or the vulnerable default configuration in the first place.

it was the admin who did not RTFM and rolled out default
settings in environents with untrustable code

> If a user/administrator who installs software has to turn insecure
> features OFF its the developer who is to blame, and of course the
> testers, the QA and the management too

not entirely untrue, but anybody who thinks he can install
whatever server-software with defaults, not RTFM and call
hiself a serious admin is a fool

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


Download attachment "signature.asc" of type "application/pgp-signature" (264 bytes)