Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:87748
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain belski.net from 85.214.73.107 cause and error)
To: "'Dan Ackroyd'" <danack@basereality.com>,
	"'Christoph Becker'" <cmbecker69@gmx.de>
Cc: <internals@lists.php.net>
References: <CA+kxMuSQkk9XUU_fLOmKjH5-a_QHUfzBBiMecZ83U2m8Ommx-w@mail.gmail.com>
In-Reply-To: <CA+kxMuSQkk9XUU_fLOmKjH5-a_QHUfzBBiMecZ83U2m8Ommx-w@mail.gmail.com>
Date: Fri, 14 Aug 2015 01:09:56 +0200
Message-ID: <066601d0d61d$2dbb4e30$8931ea90$@belski.net>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Thread-Index: AQGpQ2TeSytRGVHqXWOQEYcRS7At755Zrn4w
Content-Language: en-us
Subject: RE: [PHP-DEV] PCRE jit security hole WAS PCRE JIT stack size limit
From: anatol.php@belski.net ("Anatol Belski")



> -----Original Message-----
> From: Dan Ackroyd [mailto:danack@basereality.com]
> Sent: Thursday, August 13, 2015 5:00 PM
> To: Christoph Becker <cmbecker69@gmx.de>
> Cc: internals@lists.php.net
> Subject: [PHP-DEV] PCRE jit security hole WAS PCRE JIT stack size =
limit
>=20
> On 23 July 2015 at 11:07, Christoph Becker <cmbecker69@gmx.de> wrote:
> > PHP7 supports PCRE's JIT compilation of patterns by default, which
> > mostly works fine.  However, there are issues when the matching
> > exceeds the JIT stack limit, see bug #70110[1].
>=20
>=20
> So to summarise and bring more people's attention to this =
conversation; the
> change to using pcre.jit does not seem to be a fantastic one. It =
allows
> preg_match to fail silently e.g. this code:
>=20
> preg_match('~(a)*~', str_repeat('a', 5431), $match); var_dump($match);
>=20
> gives the output:
>=20
> array(0) {
> }
>=20
> i.e. there is no notification that the preg_match failed to match.
>=20
> People use preg_match for black/white listing input for security =
purposes. As the
> input is under attacker control this seems like a very bad situation, =
as attackers
> will be able to figure out what input can be used to make those =
security checks
> give incorrect results silently.
>=20
> I don't think we should ship PHP 7 with this issue unresolved. A =
suggested fix for
> PHP 7.1 has been mentioned:
>=20
Could you please point to a real example where security is hurt, maybe =
in a real app? A security one were like password match. But even if an =
attacker sends str_repeat('a', 5431)  and application doesn't check =
input password length - it's a flaw in the app itself with or without =
jit. If at the same time the stored password were "(a)*" and not escaped =
prior to matching - same, it's already a security flaw before.

Thanks

Anatol