[CVE-2015-8853] Regexp-matching "hangs" indefinitely on illegal input using binmode :utf8 using 100%CPU #14406
Comments
From torge.husfeldt@1und1.deCreated by torge.husfeldt@1und1.deThis only gets triggered for specific regexes. I stumbled upon this To reproduce: Result: 100% CPU + no progress Expected Result: some kind of error message Perl Info |
From @jkeenanOn Wed Jan 07 07:15:24 2015, torge.husfeldt@1und1.de wrote:
Confirmed with blead (3147e83) on Ubuntu Linux 14.04 LTS.
-- |
|
The RT System itself - Status changed from 'new' to 'open' |
From @jkeenanOn Wed Jan 07 16:54:45 2015, jkeenan wrote:
And found as far back as 5.8.9. (I tried 5.6.2, but that version did not have the ':utf8' discipline. -- |
From torge.husfeldt@1und1.deHi, the following does exactly what I expected and may be what I should have echo -e "a\x80" | perl -e 'binmode STDIN, ":encoding(utf8)"; while -- Senior Anti-Abuse Engineer 1&1 Internet Service GmbH | Brauerstraße 50 | 76135 Karlsruhe | Germany Hauptsitz Montabaur, Amtsgericht Montabaur, HRB 20141 Geschäftsführer: Frank Einhellinger, Uwe Lamnek, Jan Oetjen Member of United Internet Diese E-Mail kann vertrauliche und/oder gesetzlich geschützte This e-mail may contain confidential and/or privileged information. If |
From @khwilliamsonThe reason you didn't see warnings is because you didn't enable warnings. Several are raised. But the underlying issue remains: It should not loop when confronted with malformed input. That is now fixed by commit 22b433e Thanks for reporting this -- |
|
@khwilliamson - Status changed from 'open' to 'pending release' |
From @jmdhThis issue is being treated as a security issue by Debian; see http://www.openwall.com/lists/oss-security/2016/04/20/5 If p5p agrees that this is a correct assessment (it seems so to me) then it should be queued for 5.20.4, I presume? The Debian bug reporter has rebased the patch for 5.20, but I haven't reviewed that: |
From @jmdhOn Wed Apr 20 05:04:56 2016, dom wrote:
This issue has been assigned CVE-2015-8853. |
From @demerphqOn 22 April 2016 at 12:19, Dominic Hargreaves via RT
FYI: I pushed backport patches for Karls fix for 5.18.2 and 5.18.4 I can do other backports if needed. Yves -- |
From @jmdhOn Fri, Apr 22, 2016 at 11:25:36PM -0700, yves orton via RT wrote:
Hi yves, Do you mean 5.20.x for one of these? I couldn't see any pushes to either Thanks for your work! Dominic. |
From @khwilliamsonOn 04/23/2016 03:50 AM, Dominic Hargreaves wrote:
Dominic, He prudently is smoking them first http://perl5.git.perl.org/perl.git/shortlog/refs/heads/smoke-me/rt_123562_5184 http://perl5.git.perl.org/perl.git/shortlog/refs/heads/smoke-me/rt_123562_5182 |
From @jmdhOn Sat Apr 23 11:40:13 2016, public@khwilliamson.com wrote:
Ah, great. Thanks for pointing that out! I had a closer look, and I noticed that in blead, 22b433e was followed by d820a0f which amends the change to use Perl_croak_nocontext(). That change did not make it into maint-5.22, nor is it in either of the above smoke branches. Is this important? Anyway, I've pushed the same change to smoke-me/rt_123562_520 too. Thanks, |
From @khwilliamsonOn 04/23/2016 03:51 PM, Dominic Hargreaves via RT wrote:
It would be slightly better to use change as amended, but I don't think
|
From @demerphqOn 24 April 2016 at 00:28, Karl Williamson <public@khwilliamson.com> wrote:
If its just a performance thing then I agree. Yves -- |
From @khwilliamsonThank you for submitting this report. You have helped make Perl better. Perl 5.24.0 may be downloaded via https://metacpan.org/release/RJBS/perl-5.24.0 |
|
@khwilliamson - Status changed from 'pending release' to 'resolved' |
Migrated from rt.perl.org#123562 (status was 'resolved')
Searchable as RT123562$
The text was updated successfully, but these errors were encountered: