Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:57520 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 618 invoked from network); 26 Jan 2012 04:32:34 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 26 Jan 2012 04:32:34 -0000 Authentication-Results: pb1.pair.com header.from=me@ktamura.com; sender-id=unknown Authentication-Results: pb1.pair.com smtp.mail=me@ktamura.com; spf=permerror; sender-id=unknown Received-SPF: error (pb1.pair.com: domain ktamura.com from 209.85.210.170 cause and error) X-PHP-List-Original-Sender: me@ktamura.com X-Host-Fingerprint: 209.85.210.170 mail-iy0-f170.google.com Received: from [209.85.210.170] ([209.85.210.170:50887] helo=mail-iy0-f170.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id EA/D0-29384-167D02F4 for ; Wed, 25 Jan 2012 23:32:33 -0500 Received: by iaoo28 with SMTP id o28so288344iao.29 for ; Wed, 25 Jan 2012 20:32:30 -0800 (PST) Received: by 10.42.157.133 with SMTP id d5mr350318icx.46.1327552348758; Wed, 25 Jan 2012 20:32:28 -0800 (PST) Received: from 10-0-128-173.trialpay.com (107-0-11-193-ip-static.hfc.comcastbusiness.net. [107.0.11.193]) by mx.google.com with ESMTPS id kh9sm950802igc.1.2012.01.25.20.32.27 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 25 Jan 2012 20:32:28 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii In-Reply-To: Date: Wed, 25 Jan 2012 20:32:25 -0800 Cc: internals@lists.php.net Content-Transfer-Encoding: quoted-printable Message-ID: References: <38EE3732-F134-4C02-8F93-2E9C61FD1E81@ktamura.com> To: Chris Stockton X-Mailer: Apple Mail (2.1084) Subject: Re: [PHP-DEV] A potential patch for Bug#60668 From: me@ktamura.com (Kiyoto Tamura) Also, I am not sure if php_trim is what we want here. It looks like = vrana's initial proposal was to discard everything after CR-LF. This is = different from trimming CR/LF/whitespace at the end of the string. I suppose that's a less important issue. I am mainly curious about your = opinion as to why we might want to allow CR-LF in the user agent value. On Jan 25, 2012, at 7:33 PM, Chris Stockton wrote: > Hello, >=20 > On Wed, Jan 25, 2012 at 5:43 PM, Kiyoto Tamura wrote: >> vrana has raise a good point in a potentially dangerous behavior with = ini_set() in https://bugs.php.net/bug.php?id=3D60668. >>=20 >> Here is my proposed patch. Feedback is appreciated. Thanks! >>=20 >> Kiyoto Tamura >>=20 >> diff --git a/Zend/zend_ini.c b/Zend/zend_ini.c >> index a7ec5d7..89b1287 100644 >> --- a/Zend/zend_ini.c >> +++ b/Zend/zend_ini.c >> @@ -83,6 +83,23 @@ static int = zend_restore_ini_entry_wrapper(zend_ini_entry **ini_entry TSRMLS_DC) >> } >> /* }}} */ >>=20 >> +static uint zend_trim_after_carriage_return(char *value, uint = value_length) /* {{{ */ >> +{ >> + uint ii; >> + char prev_c =3D '\0', curr_c; >> + for (ii =3D 0; ii < value_length; ++ii) { >> + curr_c =3D *value; >> + if (prev_c =3D=3D '\r' && curr_c =3D=3D '\n') { >> + return ii - 1; >> + } >> + prev_c =3D curr_c; >> + ++value; >> + } >> + >> + return value_length; >> +} >> +/* }}} */ >> + >=20 > To comment specifically on the patch itself; I am not sure you need a > new zend func here, I think it would be more convenient (and safer) to > use php_trim in standard/string.c. Although I must say looking at the > bug, I am not sure this is exactly something that should be "fixed". > It could be a BC break and in my opinion is just a demonstration of > failure to properly sanitize user input as opposed to a security flaw > in php design itself. >=20 > -Chris