Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:72807 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 62182 invoked from network); 25 Feb 2014 11:40:04 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 25 Feb 2014 11:40:04 -0000 Authentication-Results: pb1.pair.com header.from=johannes@schlueters.de; sender-id=unknown Authentication-Results: pb1.pair.com smtp.mail=johannes@schlueters.de; spf=permerror; sender-id=unknown Received-SPF: error (pb1.pair.com: domain schlueters.de from 217.114.215.10 cause and error) X-PHP-List-Original-Sender: johannes@schlueters.de X-Host-Fingerprint: 217.114.215.10 mail.experimentalworks.net Received: from [217.114.215.10] ([217.114.215.10:35492] helo=mail.experimentalworks.net) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 6F/93-34115-3118C035 for ; Tue, 25 Feb 2014 06:40:04 -0500 Received: from [192.168.2.31] (ppp-188-174-53-131.dynamic.mnet-online.de [188.174.53.131]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: johannes@schlueters.de) by mail.experimentalworks.net (Postfix) with ESMTPSA id BBB9A3FE91; Tue, 25 Feb 2014 12:40:42 +0100 (CET) To: Stas Malyshev Cc: Yasuo Ohgaki , "internals@lists.php.net" In-Reply-To: <530C77F8.2060809@sugarcrm.com> References: <530C3C7B.8080907@sugarcrm.com> <530C77F8.2060809@sugarcrm.com> Content-Type: text/plain; charset="UTF-8" Date: Tue, 25 Feb 2014 12:39:40 +0100 Message-ID: <1393328380.5233.45.camel@guybrush> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] Resolution for ver_export()/addslashes() encoding based script execution attack? From: johannes@schlueters.de (Johannes =?ISO-8859-1?Q?Schl=FCter?=) On Tue, 2014-02-25 at 13:01 +0200, Stas Malyshev wrote: > Hi! > > > Engine supports SJIS/other encoding script execution. Therefore, > > I'm not sure what you mean by "other encoding script execution". Engine > execution is the same regardless of the data you use, nowhere in the > opcodes there's any encoding that is important. I think Yasuo refers to php -d zend.script_encoding=SJIS > > addslashes()/var_export() behavior is security vulnerability just like > > encoding based SQL/JavaScript injections. > > I don't see how it is "therefore". If there's SQL injection or JS > injection that is not the result of wrong code, then let's outline them > and consider them. Specifically for var_export, which behavior is > broken? I see no mention of the specific examples in the RFC. i think Yasuo assumes that results from those operations with a script_encoding setting would be handled "correctly". I don't think we can do that, though. zend.script_encoding is a hardly documented feature which should be used with care. The documentation of addslashes() refers to "characters". I don't think the behavior should depend on PHP settings but like all "basic" functions assume on ASCII compatible single byte strings. Adding magic there makes it more confusing and harder to use. As said in a previous discussion on this topic rather than using addslashes users should use context-aware escaping functions. Using addslashes is almost always a bad idea. The situation around var_export() is a bit more complicated. var_export() is used to create application configuration, cache data etc. so one might expect the PHP which created that to be able to read that, again. Doing this isn't easy, though, as it makes the generated file non-portable. Adding "magic" into probably security relevant features is problematic and unless the engine is truly encoding-aware I'd abstain from such changes. johannes