[CVE-2017-12837]Heap overflow in Perl__to_fold_latin1 when compiling case-insensitive regexp #16021
Comments
From @jwilkThe following program makes Perl (v5.26.0 on i686-linux) crash: $pat = "\x800000000\xd4\xd4\xd4\xd4\xd4\xd4\xd4\xd1\xf2\xf2\xf2\xf2\xf2\xf2\xf2\xf2\xf2\xf2\xf2\xf2\xf2\xf2\xf2\xf2\xf2\xf2\xf2\xf2\xf2\xf2\xf2\xf2\xf2\x970\xdf0\xe90\\N{U+4000}0000000\xd4\xd4\xd4\xd4\xd4\xd4\xd4\xd4\xd4\xd4\xd4\xd4\xd4\xd4\xd4\xd4A000000"; ASAN says it's a heap overflow: ================================================================= 0xb3801180 is located 0 bytes to the right of 80-byte region [0xb3801130,0xb3801180) SUMMARY: AddressSanitizer: heap-buffer-overflow /home/jwilk/perl/utf8.c:2399 Perl__to_fold_latin1 -- |
From @khwilliamsonOn 06/15/2017 06:37 PM, Jakub Wilk (via RT) wrote:
I have a one line fix for this. The problem is a pointer was getting I don't know how exploitable this is. It requires matching an exact I don't know for sure what the other preconditions are. If I change the So, an attacker can craft a pattern, that if compiled will crash the So what to do? I can patch blead, and since this crashes perl, it |
|
The RT System itself - Status changed from 'new' to 'open' |
From @xsawyerxOn 16 June 2017 at 15:06, Karl Williamson <public@khwilliamson.com> wrote:
Let's patch blead. We can add it to the votes file and I believe we could |
From @khwilliamsonOn 06/20/2017 12:18 PM, Sawyer X wrote:
And what do we do about this ticket, and about the commit message? |
From @iabynOn Fri, Jun 16, 2017 at 01:06:40PM -0600, Karl Williamson wrote:
Can you show that change, please. I might help me better understand the
-- |
From @khwilliamsonOn 06/21/2017 08:15 AM, Dave Mitchell wrote:
Attached. I'm unsure if the setting of RExC_parse not changed by this |
From @khwilliamson0100-perl-131582.patchFrom d78e88add522aff0d218d7991bddb672971cbf21 Mon Sep 17 00:00:00 2001
From: Karl Williamson <khw@cpan.org>
Date: Wed, 21 Jun 2017 11:33:37 -0600
Subject: [PATCH 100/100] [perl #131582]
---
regcomp.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/regcomp.c b/regcomp.c
index d10dea0fbf..5c2e43a2d2 100644
--- a/regcomp.c
+++ b/regcomp.c
@@ -13285,6 +13285,7 @@ S_regatom(pTHX_ RExC_state_t *pRExC_state, I32 *flagp, U32 depth)
goto loopdone;
}
p = RExC_parse;
+ RExC_parse = parse_start;
if (ender > 0xff) {
REQUIRE_UTF8(flagp);
}
--
2.11.0
|
From @iabynOn Wed, Jun 21, 2017 at 11:38:29AM -0600, Karl Williamson wrote:
I don;'t understand that sentence :-( Also, even after looking at the code for a bit, I still don't understand the So from valgrind, I see its writing bytes at locations 0,1,21,22,23 beyond So that seems rather serious. Maybe combine this and the other regex compilation bug (#131598) into -- |
From @khwilliamsonOn 06/22/2017 04:07 AM, Dave Mitchell wrote:
I looked, and it is harmless. In thinking about this, I got new insight The parser has the equivalent of the topic variable $_, but it is a The lines that get patched are RExC_parse = p = oldp; The "}; is the end of an 'if' What I meant in the sentence you didn't understand is that the lines RExC_parse = p = oldp; is setting RExC_parse, but this isn't the proper value to restore it to. The other branch updates p, which is the parse pointer local to this
Maybe, I guess Sawyer decides. |
From @demerphqOn 22 June 2017 at 22:58, Karl Williamson <public@khwilliamson.com> wrote:
IIRC this is happens in some places where we aren't sure what we are Yves |
From @xsawyerxOn Thu, 22 Jun 2017 13:58:37 -0700, public@khwilliamson.com wrote:
I think a single CVE for those, as long as they share a common fix or a common category (something more narrow than "regex compilation bug"). Do they fit together or are they categorically different in behavior, bug, or fix? |
From @tonycozOn Wed, 12 Jul 2017 13:42:50 -0700, xsawyerx@cpan.org wrote:
As requested on IRC I've applied for a CVE ID for this issue. Tony |
From @tonycozOn Fri, 11 Aug 2017 03:16:45 -0700, tonyc wrote:
This is CVE-2017-12837. Tony |
From @khwilliamsonOn Fri, 11 Aug 2017 17:53:41 -0700, tonyc wrote:
This should go into 5.26.1; I will attach a patch. |
From @khwilliamsonOn Thu, 24 Aug 2017 13:10:14 -0700, khw wrote:
-- |
From @khwilliamson0001-regcomp-perl-131582.patchFrom 4b116c2495aacf6f869c1ea4416858680f76ca17 Mon Sep 17 00:00:00 2001
From: Karl Williamson <khw@cpan.org>
Date: Wed, 21 Jun 2017 11:33:37 -0600
Subject: [PATCH] regcomp [perl #131582]
---
regcomp.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/regcomp.c b/regcomp.c
index 5a9e56b080..6a07bf2c70 100644
--- a/regcomp.c
+++ b/regcomp.c
@@ -13321,6 +13321,7 @@ S_regatom(pTHX_ RExC_state_t *pRExC_state, I32 *flagp, U32 depth)
goto loopdone;
}
p = RExC_parse;
+ RExC_parse = parse_start;
if (ender > 0xff) {
REQUIRE_UTF8(flagp);
}
--
2.11.0
|
From @steve-m-hayNow in blead as commit 96c83ed. Will shortly also be in 5.24.3-RC1 and 5.26.1-RC1... |
1 similar comment
From @steve-m-hayNow in blead as commit 96c83ed. Will shortly also be in 5.24.3-RC1 and 5.26.1-RC1... |
From @tonycozOn Fri, 11 Aug 2017 17:53:41 -0700, tonyc wrote:
The details I entered when requesting the CVE ID:
Proposed update for the CVE entry once the issue is public (the field names are from the CVE allocation form): Affected components: Regular expression compiler, S_regatom() in regcomp.c. Attack vector: An attacker can provide a crafted regular expression with a Discoverer: Jakub Wilk <jwilk@jwilk.net> (no change) Affected Product Code Base: perl - 5.26.0, fixed in 5.26.1 References: https://rt.perl.org/Public/Bug/Display.html?id=131582 Impact: [+] CVE_Request.Impact_Denial_of_Service Additional information: (none) Tony |
From @tonycozOn Mon, 11 Sep 2017 16:35:32 -0700, tonyc wrote:
perl - 5.26.0, fixed in 5.26.1 Tony |
|
@xsawyerx - Status changed from 'open' to 'resolved' |
From @xsawyerxNow open. |
From @tonycozOn Mon, 25 Sep 2017 03:11:22 -0700, xsawyerx@cpan.org wrote:
Update to CVE requested. Tony |
Migrated from rt.perl.org#131582 (status was 'resolved')
Searchable as RT131582$
The text was updated successfully, but these errors were encountered: