RE: [PHP-DEV] PCRE jit security hole WAS PCRE JIT stack size limit

> -----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 > > 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]. > > > 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: > > preg_match('~(a)*~', str_repeat('a', 5431), $match); var_dump($match); > > gives the output: > > array(0) { > } > > i.e. there is no notification that the preg_match failed to match. > > 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. > > I don't think we should ship PHP 7 with this issue unresolved. A suggested fix for > PHP 7.1 has been mentioned: > 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