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>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Tue, 13 Aug 2013 21:36:32 +0200
From: "Stefan Kanthak" <stefan.kanthak@...go.de>
To: "Reindl Harald" <h.reindl@...lounge.net>,
  "coderaptor" <coderaptor@...il.com>
Cc: <bugtraq@...urityfocus.com>
Subject: Re: [Full-disclosure] Apache suEXEC privilege elevation / information disclosure

"Reindl Harald" <h.reindl@...lounge.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@...-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

That's one of the duties/tasks of their developer(s): WTFM!

>> 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

No, its UNSAFE!
The standard use case of PHP is "preprocessor for HTTP demon".
There is ABSOLUTELY no need to allow the preprocessor to unlink a file.

> unlink($_GET['what_ever_input']): is a security hole

No, not necessarily. The user who can run

$ php -r "unlink($_GET['what_ever_input']);"

can also run

$ rm "$SOMEFILE"

OTOH: the user who can instruct his web browser to fetch
<http://example.org/index.html> is not able to unlink $SOMEFILE by
calling "rm".

> so do we now disable unlink();

Not WE, but the developer.
All functions which are not used in the typical operating
environment of the resp. program (see above) have to be turned
off by default. "file handling" is NONE of PHPs typical operations!

Stefan Kanthak