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: <B3BDA5BBBDFC4EAB959989D3C4E0B342@celsius>
Date: Sun, 11 Aug 2013 23:56:31 +0200
From: "Stefan Kanthak" <stefan.kanthak@...go.de>
To: "Reindl Harald" <h.reindl@...lounge.net>
Cc: "Tobias Kreidl" <tobias.kreidl@....edu>, <bugtraq@...urityfocus.com>
Subject: Re: [Full-disclosure] Apache suEXEC privilege elevation / information disclosure

"Reindl Harald" <h.reindl@...lounge.net> wrote:

> 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?

If you say so: OK.
Read again what I wrote, carefully!

>>> 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

JFTR: untrustable <> vulnerable!

Read again what I wrote, carefully.

If you'd have a clue you may have heard of concepts like "fail safe"
or "safe default configuration".
ANY software with an insecure default configuration is DEFECTIVE!

JFTR: why should gazillions of users/administrators fix the fault(s)
of a single/few developer(s)?

>> 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

Why not: I expect every developer to exercise all due diligence,
test the code, and ship it with a SECURE default configuration.
Software with an insecure default configuration is DEFECTIVE!

> 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!

It's not the user/administrator who develops or ships insecure
code!

Stefan