Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:29610 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 22749 invoked by uid 1010); 21 May 2007 08:11:00 -0000 Delivered-To: ezmlm-scan-internals@lists.php.net Delivered-To: ezmlm-internals@lists.php.net Received: (qmail 22733 invoked from network); 21 May 2007 08:11:00 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 21 May 2007 08:11:00 -0000 Authentication-Results: pb1.pair.com smtp.mail=sesser@hardened-php.net; spf=permerror; sender-id=unknown Authentication-Results: pb1.pair.com header.from=sesser@hardened-php.net; sender-id=unknown Received-SPF: error (pb1.pair.com: domain hardened-php.net from 81.169.159.221 cause and error) X-PHP-List-Original-Sender: sesser@hardened-php.net X-Host-Fingerprint: 81.169.159.221 hardened-php.net Linux 2.4/2.6 Received: from [81.169.159.221] ([81.169.159.221:36176] helo=mail.hardened-php.net) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 34/34-30777-21451564 for ; Mon, 21 May 2007 04:10:59 -0400 Received: from [192.168.1.77] (p5B0072A8.dip.t-dialin.net [91.0.114.168]) by mail.hardened-php.net (Postfix) with ESMTP id B55361202B3; Mon, 21 May 2007 08:46:59 +0200 (CEST) Message-ID: <46515417.3030904@hardened-php.net> Date: Mon, 21 May 2007 10:11:03 +0200 User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Alexey Zakhlestin , PHP internals References: <465022BE.1020905@hardened-php.net> <7d5a202f0705201415s71982fd2jb61b8bffbb7ba6de@mail.gmail.com> <46513546.5000303@zend.com> <7d5a202f0705202303s2ff4d0cdg1157c1e245c3c2e4@mail.gmail.com> <46513745.7030701@zend.com> <000001c79b71$543e0970$fcba1c50$@com> <46513E93.5000902@hardened-php.net> <465140BE.8050502@zend.com> <4651454B.4080000@hardened-php.net> <465149FE.4070100@zend.com> In-Reply-To: X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] Dismantling the lies... From: sesser@hardened-php.net (Stefan Esser) Alexey Zakhlestin schrieb: > the problem is, that, in this case, code is not broken. it is not an > error to use large stack. > it is an error to let someone use the low-level side-effects of a > problem in a high-level language. Uhmm you only look at the MOPB #2 issue. The main point of this whole thread is however the performance impact through the #1 issue that does not depend on stack usage, but allows PHP userspace code to execute arbitrary machine code. The problem here is that some voices inside the PHP team and community claim that you can takeover the system through the execution of high level PHP code anyway and therefore using a local PHP vulnerability to execute arbitrary machine code would not be an issue. If you see it this way there is actually no reason to do this performance impact. However it should be obvious that I see this all a little bit different, because I think about defense in depth and realise that to attack tightly secured systems you NEED direct memory manipulation and/or execute arbitrary machine code. For example to get around non-executable HEAP situation you first need to poke the right offsets in memory to "reenable" the dl() function (NOT possible with plain PHP code), find some writeable diskspace, dump a shared library there and load it. From there you can execute whatever kernel exploit you want, to get for example out of the chroot, to disable SELINUX... And here is the problem with the OS hardening argument of the PHP developers. OS hardening is useless if I can use exploits in PHP to simply disable/get around this hardening. Stefan Esser