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]
Message-ID: <CAH8yC8mcgkvtO1is6fDPcqPnut_wnxtZj8YbAqUeuoxwty0qCQ@mail.gmail.com>
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ