Home page logo
/

bugtraq logo Bugtraq mailing list archives

Re: [Full-disclosure] Apache suEXEC privilege elevation / information disclosure
From: coderaptor <coderaptor () gmail com>
Date: Mon, 12 Aug 2013 15:51:08 -0700

On Mon, Aug 12, 2013 at 2:45 PM, Reindl Harald <h.reindl () thelounge net> wrote:

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();

Why not?

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

Go ahead and disable all 1330 functions if the need be, and let the
Administrator figure out which ones he should carefully enable. It may
take a month to roll out the web app, but it will be secure and
totally under control. By your definition, an Administrator should
RTFM, be excellent at everything, so there should be no problem for
him/her to enable whatever he/she wants. And its a one time effort,
and worth it since it makes the security much better to begin with.

No, the actual fear most designers face is nobody using their designed
piece of art, which is why functionality trumps everything.

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

Just 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 decision
to start with, so no matter you have enable_functions, or
disable_functions, you are doomed.

As I said earlier, I am depressed.

-coderaptor



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



  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]
AlienVault