[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

"Reindl Harald" <h.reindl@xxxxxxxxxxxxx> wrote:

> Am 11.08.2013 22:15, schrieb Stefan Kanthak:
>> "Reindl Harald" <h.reindl@xxxxxxxxxxxxx> 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