Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:57769 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 1845 invoked from network); 6 Feb 2012 15:32:59 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 6 Feb 2012 15:32:59 -0000 Authentication-Results: pb1.pair.com header.from=h.reindl@thelounge.net; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=h.reindl@thelounge.net; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain thelounge.net designates 91.118.73.15 as permitted sender) X-PHP-List-Original-Sender: h.reindl@thelounge.net X-Host-Fingerprint: 91.118.73.15 mail.thelounge.net Received: from [91.118.73.15] ([91.118.73.15:39884] helo=mail.thelounge.net) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id A9/91-28299-9A2FF2F4 for ; Mon, 06 Feb 2012 10:32:58 -0500 Received: from rh.thelounge.net (rh.thelounge.net [10.0.0.99]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mail.thelounge.net (Postfix) with ESMTPSA id D08A098 for ; Mon, 6 Feb 2012 16:32:54 +0100 (CET) Message-ID: <4F2FF2A5.7000906@thelounge.net> Date: Mon, 06 Feb 2012 16:32:53 +0100 Organization: the lounge interactive design User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0) Gecko/20120131 Thunderbird/10.0 MIME-Version: 1.0 To: internals@lists.php.net References: <72878E6C-4C17-4D94-9F73-1446769247E1@nopiracy.de> <4F2CEA7E.9010906@sugarcrm.com> <9684A843-5A7F-43BB-BFC2-86F34E27EC3B@nopiracy.de> <90A22109-8267-4C6F-B35C-0A3612213915@nopiracy.de> <4F2FEE7A.9030309@thelounge.net> In-Reply-To: X-Enigmail-Version: 1.3.5 OpenPGP: id=7F780279; url=http://arrakis.thelounge.net/gpg/h.reindl_thelounge.net.pub.txt Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig5A734E19E314A5CEAB815CA9" Subject: Re: [PHP-DEV] Suhosin patch disabled by default in Debian php5 builds From: h.reindl@thelounge.net (Reindl Harald) --------------enig5A734E19E314A5CEAB815CA9 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable first: do not top-post if you get a reply below second: in the context of suhosin "when mistakes get made by such a person, they are hidden away rather than honestly reported" is bullshit at it's best * look at the disclosure below * look at the author * look at the way it was made if only 10% of developers would work like Stefan most software out there would be much better as it is and was all the last years and if someone has this attitude and knowledge is see no single problem and understand fully that he is frustrated _______________ Author: Stefan Esser [stefan.esser[at]sektioneins.de] Disclosure Timeline: 12. January 2012 - Vulnerability was found during an internal audit 14. January 2012 - Vulnerability was fixed in the source code 19. January 2012 - Public Disclosure Am 06.02.2012 16:23, schrieb Michael Morris: > I don't think so. My experience with the attitude he has shown is, when= > mistakes get made by such a person, they are hidden away rather than > honestly reported. To paraphrase a line from Harry Potter - brilliant > people don't make many mistakes, but the ones they make tend to be larg= e > and very damaging. >=20 > Security is trust. Given what I have seen I do not trust Stefan to rep= ort > any vulnerabilities created in PHP by Sushonin in a timely manner. I do= not > believe he has the humility necessary to own up to a mistake. Since he= is > that project's only caretaker, I cannot trust the code. If I do not tru= st > it, I don't run it. >=20 > On Mon, Feb 6, 2012 at 10:15 AM, Reindl Harald = wrote: >=20 >> if your make technical decisions especially security ones by >> "The character displayed by Stefan" you are maybe doing the >> wrong job! -------- Original-Nachricht -------- Betreff: Advisory 01/2012: Suhosin PHP Extension Transparent Cookie Encry= ption Stack Buffer Overflow Datum: Thu, 19 Jan 2012 17:18:23 +0100 Von: Stefan Esser An: Full-Disclosure , Bugtraq SektionEins GmbH www.sektioneins.de -=3D Security Advisory =3D- Advisory: Suhosin PHP Extension Transparent Cookie Encryption Stack Buffer Overflow Release Date: 2012/01/19 Last Modified: 2012/01/19 Author: Stefan Esser [stefan.esser[at]sektioneins.de] Application: Suhosin Extension <=3D 0.9.32.1 Severity: A possible stack buffer overflow in Suhosin extension's transparent cookie encryption that can only be triggered in an uncommon and weakened Suhosin configuration can lead= to arbitrary remote code execution, if the FORTIFY_SOURCE compile option was not used when Suhosin was compiled. Risk: Medium Vendor Status: Suhosin Extension 0.9.33 was released which fixes this vulnerability Reference: http://www.suhosin.org/ https://github.com/stefanesser/suhosin Overview: Quote from http://www.suhosin.org "Suhosin is an advanced protection system for PHP installations. It was designed to protect servers and users from known and unknown flaws in PHP applications and the PHP core. Suhosin comes in two independent parts, that can be used separately or in combination. The first part is a small patch against the PHP core, that implements a few low-level protections against buffer overflows or format string vulnerabilities and the second part is a powerful PHP extension that implements all the other protections.." During an internal audit of the Suhosin PHP extension, which is often confused with the Suhosin PHP Patch, although they are not the same, a possible stack based buffer overflow inside the transparent cookie encryption feature was discovered. If successfully exploited this vulnerability can lead to arbitrary remote code execution. However further investigation into the vulnerability revealed that it can only be triggered if the admin has not only activated transparent cookie encryption, but also explicitly disabled several other security features of Suhosin. In addition to that remote exploitation requires a PHP application that puts unfiltered user input into a call to the header() function that sends a Set-Cookie header. Furthermore most modern unix systems compile the Suhosin extension with the FORTIFY_SOURCE flag, which will detect the possible buffer overflow and abort execution before something bad can happen. Details: The transparent cookie encryption of Suhosin is disabled by default because it stops applications using JavaScript to access cookies, which would break these applications. In order to activate it an admin has to enable this feature in the configuration file: suhosin.cookie.encrypt =3D On Once activated all incoming cookies will be decrypted and all outgoing Set-Cookie HTTP headers will be rewritten to only contain encrypted data. When this happens the following code of Suhosin extension will be triggered. char *suhosin_encrypt_single_cookie(char *name, int name_len, char *value, int value_len, char *key TSRMLS_DC) { char buffer[4096]; char buffer2[4096]; char *buf =3D buffer, *buf2 =3D buffer2, *d, *d_url; int l; if (name_len > sizeof(buffer)-2) { buf =3D estrndup(name, name_len); } else { memcpy(buf, name, name_len); buf[name_len] =3D 0; } ... if (strlen(value) <=3D sizeof(buffer2)-2) { memcpy(buf2, value, value_len); buf2[value_len] =3D 0; } else { buf2 =3D estrndup(value, value_len); } The problem with this code is that the second call to mempcy() uses strlen() to check if there is enough buffer space but uses the variable value_len to determine the amount of bytes to copy. The problem is that there could be a NUL byte inside the value of the cookie, which will result in a stack based buffer overflow. While the same code can also be found inside the suhosin_decrypt_single_cookie() function the problem cannot be exploited, because in that case there cannot be a NUL byte. To understand the limited impact of this vulnerability it is important to know that NUL bytes are not allowed inside HTTP headers in a default Suhosin installation. In order to be vulnerable it is therefore required that the admin explicitly weakened security by disabling the HTTP response splitting protection of Suhosin by using the following configuration: suhosin.multiheader=3DOn The next thing to know is that PHP applications normally use the functions setcookie() and setrawcookie() to set cookies. Both functions are however not affected by the problem because both functions will eliminate a possible NUL byte when constructing the Set-Cookie header. Therefore the only way to trigger this vulnerability is to call the header() function directly with a "Set-Cookie" header and put unfiltered user input into the cookie value. This is very uncommon in normal PHP applications. In addition to that the default configuration of Suhosin will not allow NUL bytes in user input. Therefore in order to trigger the vulnerability remotely the user input must have been double decoded or the admin must have weakened the installation once again by disabling the protection against NUL bytes. This can be done by changing the configuration to. suhosin.request.disallow_nul=3DOff suhosin.get.disallow_nul=3DOff suhosin.post.disallow_nul=3DOff suhosin.cookie.disallow_nul=3DOff Finally even if the vulnerability is triggerable from remote it depends on the compilation of the Suhosin extension if the bug can be abused. Most modern unix systems will compile the Suhosin extension with the FORTIFY_SOURCE compile option, which will detect the buffer overflow before it actually happens and abort execution. If either suhosin.multiheader or suhosin.cookie.encrypt are set to "off" in your configuration than you are safe from remote attacks. In addition to that the default configuration of suhosin.perdir disallows to set these variables from .htaccess which also provides some protection against local attackers. Proof of Concept: Locally the problem can be reproduced by the following PHP code: