bugtraq - Re: [Full-disclosure] 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 23:11:32 +0400
From: George Machitidze <giomac@...il.com>
To: undisclosed-recipients: ;
Cc: "bugtraq@...urityfocus.com" <bugtraq@...urityfocus.com>
Subject: Re: [Full-disclosure] Apache suEXEC privilege elevation / information disclosure

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@...il.com> wrote:
>
> disable_functions

Best regards,
George Machitidze