full-disclosure - Re: 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>] [day] [month] [year] [list]

Date: Mon, 12 Aug 2013 15:03:09 -0400
From: Jeffrey Walton <noloader@...il.com>
To: Coderaptor <coderaptor@...il.com>
Cc: Full Disclosure List <full-disclosure@...ts.grok.org.uk>,
 BugTraq <bugtraq@...urityfocus.com>
Subject: Re: Apache suEXEC privilege elevation /
	information disclosure

On Mon, Aug 12, 2013 at 1:28 PM, Coderaptor <coderaptor@...il.com> wrote:
> I have been a silent spectator to this drama, and could not resist adding a few thoughts of my own:
>
> 1. All software, especially webservers, should ship with secure defaults. Period. It is a fundamental mistake to assume all admins who roll out web apps and maintain servers RTFM before rolling out. The key idea here is "time to market", and there is huge amount of data to prove this.
>
+1. All software should be shipped "secure out of the box". Its
amazing so many folks keep making the same mistakes from the 1980s and
1990s.

> ...
> Huge amount of software today is turd polishing, open source no exception (though it is supposed to have better track record). The blame lies squarely on everyone.
>
The "more eyes the better" theory is hogwash. I cringe when I hear
anyone discussing the security of crowd sourcing. There's two problems
with their arguments: first is Cognitive Biases, and second is the
Bystander Effect. The biases are being demonstrated by NB and RH, and
its results are typical (no offense NB and RH). The Bystander Effect
ensures that the more people see a bug, the less likely they are going
to do anything about it because they believe someone else has already
done something.

They are well known problems in Security Engineering. See Peter
Gutmann's Engineering Security
(www.cs.auckland.ac.nz/~pgut001/pubs/book.pdf‎) or Ross Anderson's
Security Engineering (http://www.cl.cam.ac.uk/~rja14/book.html).

Jeff

> On Aug 11, 2013, at 3:30 PM, Reindl Harald <h.reindl@...lounge.net> wrote:
>
>> Am 11.08.2013 23:56, schrieb Stefan Kanthak:
>>> "Reindl Harald" <h.reindl@...lounge.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
>>
>>

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/