Bugtraq mailing list archives
Re: [Full-disclosure] Apache suEXEC privilege elevation / information disclosure
From: coderaptor <coderaptor () gmail com>
Date: Mon, 12 Aug 2013 16:45:10 -0700
On Mon, Aug 12, 2013 at 4:06 PM, Reindl Harald <h.reindl () thelounge net> wrote:
Am 13.08.2013 00:51, schrieb coderaptor:On Mon, Aug 12, 2013 at 2:45 PM, Reindl Harald <h.reindl () thelounge net> wrote:ALL software MUST come with SECURE DEFAULTS. PERIOD. Anyone who thinks otherwise should fly in an aircraft running his own designed software. Knowledgeable Admins are not an alternative to secure defaults, rather I'd prefer both.*define what is secure* and make sure you define it by context unlink('file_my_script_wrote'); is fine unlink($_GET['what_ever_input']): is a security hole so do we now disable unlink();Why not?because it is plain stupid
You think so. Not everyone shares your opinion.
you even statet that you did not realize that others are talking about PHP and you not knew the context of 'disable_functions' and so stop trying to be a smartass in topics you are clueless
Please no personal insults.
hey in this case you need also to disable fopen(), file_put_contents() and whatever function can open and overwrite a file - now you could come and argue "but the permissions should not allow" - well, your config should also not allow any random script to create symlinks on a internal application which is not accesable from the web symlink() is harmless and may be used for good reasons so you should realize that security is not black and whiteGo ahead and disable all 1330 functions if the need be, and let the Administrator figure out which ones he should carefully enableplease stop making yourself *that* laughable
I don't care.
if you nned 100% secure defaults do not allow CGI and script interpreters and go back to static sites because you have to realize that *any* scripting lanuguage is a security risk per definition - periodJust for the sake of argument? Which sane framework provides 1330 functions? Security is surely not black and white, but this argument should not justify poor design choices. Anyways, no matter what one does, using a framework with 1330 functions is poor security decisionplease be quite and come back after you understood the difference between a programming language and a framework hint: * PHP: programming language * Ruby: programming language * Zend Framework, Symfony: Framework * Ruboy On Rails: Framework
Does it matter if I call at a framework, programming language, or dancing donkey? It doesn't change the reality. Just because you have an opinion does not make it more right than others. PHP sucks with 1300 functions (what programming language requires 1300 functions? The one that is designed poorly), that's a fact. And you aren't helping it suck less. I may be clueless about how the apache + php glue and php work, but I am now very sure that I won't use PHP. And will probably stick with my OpenBSD implementation of chrooted apache - apache is fit to be in a jail. I rest my case. -coderaptor
Current thread:
- RE: [Full-disclosure] Apache suEXEC privilege elevation / information disclosure, (continued)
- RE: [Full-disclosure] Apache suEXEC privilege elevation / information disclosure Peter Gregory (Aug 12)
- Re: [Full-disclosure] Apache suEXEC privilege elevation / information disclosure Reindl Harald (Aug 12)
- Re: [Full-disclosure] Apache suEXEC privilege elevation / information disclosure coderaptor (Aug 12)
- Re: [Full-disclosure] Apache suEXEC privilege elevation / information disclosure Brandon M. Graves (Aug 12)
- Re: Re: [Full-disclosure] Apache suEXEC privilege elevation / information disclosure Marco Floris (Aug 13)
- Message not available
- Re: [Full-disclosure] Apache suEXEC privilege elevation / information disclosure George Machitidze (Aug 12)
- Re: [Full-disclosure] Apache suEXEC privilege elevation / information disclosure Jeffrey Walton (Aug 12)
- Message not available
- Message not available
- Re: [Full-disclosure] Apache suEXEC privilege elevation / information disclosure Reindl Harald (Aug 13)
- Re: [Full-disclosure] Apache suEXEC privilege elevation / information disclosure coderaptor (Aug 13)
- Re: [Full-disclosure] Apache suEXEC privilege elevation / information disclosure Reindl Harald (Aug 13)
- Re: [Full-disclosure] Apache suEXEC privilege elevation / information disclosure coderaptor (Aug 13)
- Re: [Full-disclosure] Apache suEXEC privilege elevation / information disclosure Reindl Harald (Aug 13)
- Re: [Full-disclosure] Apache suEXEC privilege elevation / information disclosure terry white (Aug 13)
- Message not available
- Re: [Full-disclosure] Apache suEXEC privilege elevation / information disclosure Chris Meisinger (Aug 13)
- Re: [Full-disclosure] Apache suEXEC privilege elevation / information disclosure Jorge Dorantes (Aug 13)
- Re: [Full-disclosure] Apache suEXEC privilege elevation / information disclosure James Birk (Aug 13)
- Re: [Full-disclosure] Apache suEXEC privilege elevation / information disclosure Mike Ely (Aug 13)
- Re: [Full-disclosure] Apache suEXEC privilege elevation / information disclosure Matthew Caron (Aug 13)
- Re: [Full-disclosure] Apache suEXEC privilege elevation / information disclosure Stefan Kanthak (Aug 13)
- Re: [Full-disclosure] Apache suEXEC privilege elevation / information disclosure Reindl Harald (Aug 13)