Bugtraq mailing list archives
Re: [Full-disclosure] Apache suEXEC privilege elevation / information disclosure
From: Reindl Harald <h.reindl () thelounge net>
Date: Mon, 12 Aug 2013 23:45:38 +0200
Am 12.08.2013 23:32, schrieb coderaptor:
Why can't enable_functions be pre-populated with known good functions, and everything else disabled? Again, sacrificing security convenience is the norm.
if you would only have the slightest clue what you are speaking about you would not ask that naive [harry@srv-rhsoft:~]$ php -r "print_r(get_defined_functions());" | wc -l 1330 oh, and they depend on the loaded extensions (inlcuding 3rd party extensions) oh, and they *all* would have to be classified if, how and in which context they all may or may not have a secuirity impact
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(); 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 white 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 - period
On Mon, Aug 12, 2013 at 12:10 PM, George Machitidze <giomac () gmail com <mailto:giomac () gmail com>> wrote: Heh disable_functions and open_basedir is bad example. It's not an apache part - it's PHP, so forget about it - <it's a feature of PHP>. enable_functions is a very bad idea - the list of allowed ones would be too large for any business, development or user needs. That's why administrators (I do) read changelogs before upgrading software, and why they check all the functions documented and all the details regarding what these functions do, this is PHP feature, not httpd feature or httpd bug. The question is why PHP processes, forks etc running under apache/cgi/etc are allowed to do anything what apache can do. This is the issue right? If PHP has security a bug, which allows to bypass these php.ini-related security/sandboxing settings, it means we should sacrifice security needs and trust PHP only? I need them both, where possible. We can't even control and isolate subprocesses with selinux, because for cgroups/selinux they share same group and contexts. BTW, one reminded me in here - itk mpm has workarounds for this problem. http://mitka.us/articles/mpm-itk/ It's definitely not a bug, it's an architecture, which must be redesigned sooner or later. On Mon, Aug 12, 2013 at 9:28 PM, Coderaptor <coderaptor () gmail com <mailto:coderaptor () gmail com>> wrote: disable_functions
Attachment:
signature.asc
Description: OpenPGP digital signature
Current thread:
- Re: [Full-disclosure] Apache suEXEC privilege elevation / information disclosure, (continued)
- Re: [Full-disclosure] Apache suEXEC privilege elevation / information disclosure Stefan Kanthak (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 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)