Use-After-Free in regcomp.c:5617 #17117
Comments
From [email protected]Hi All, Thanks, ====================================== - Crafted PoC: ASAN says: 0x7fd452ab983d is located 249917 bytes inside of 262672-byte region previously allocated by thread T0 here:
|
From [email protected]Hi All, Thanks, ====================================== - Crafted PoC: ASAN says: Valgrind says:
|
From [email protected]Hi All, Thanks, ====================================== - Crafted PoC: ASAN says: Valgrind says:
|
From [email protected]Hi All, Thanks, ====================================== - Crafted PoC: ASAN says: 0x7fdbc9be4c3c is located 177212 bytes inside of 262260-byte region previously allocated by thread T0 here: Valgrind says:
|
From [email protected]On Thu, 01 Aug 2019 02:25:16 -0700, nguyenmanhdung1710@gmail.com wrote:
As requested by James E Keenan, I add the binaries of Perl (commit 45f8e7b on the branch blead): |
From [email protected]On Thu, 01 Aug 2019 06:35:00 -0700, nguyenmanhdung1710@gmail.com wrote:
As requested by James E Keenan, I add the binaries of Perl (commit 45f8e7b on the branch blead): |
From [email protected]On Thu, 01 Aug 2019 06:35:21 -0700, nguyenmanhdung1710@gmail.com wrote:
As requested by James E Keenan, I add the binaries of Perl (commit 45f8e7b on the branch blead): |
From [email protected]On Thu, 01 Aug 2019 06:35:55 -0700, nguyenmanhdung1710@gmail.com wrote:
As requested by James E Keenan, I add the binaries of Perl (commit 45f8e7b on the branch blead): |
From @tonycozOn Thu, 01 Aug 2019 06:35:55 -0700, nguyenmanhdung1710@gmail.com wrote:
This bisects down to bf848a1 is the first bad commit Add more checking for regnode offset overflowing for me. Bisected with: perl ../bisect.pl --start=v5.28.0 --end=v5.30.0 -DDEBUGGING -- ./perl ../134329.pl Tony |
|
The RT System itself - Status changed from 'new' to 'open' |
From @tonycozOn Sun, 11 Aug 2019 18:58:39 -0700, tonyc wrote:
This commit changed allocation of the regexp program from: - Newxc(RExC_rxi, sizeof(regexp_internal) + (unsigned)RExC_size * sizeof(regnode), to: + Newxc(RExC_rxi, sizeof(regexp_internal) + RExC_size, char, regexp_internal); assuming I understand the code. I expect this is the cause for #134325 too. Tony |
From @tonycozAttached the PoC to save people time. |
From @khwilliamsonOn 8/12/19 12:08 AM, Tony Cook via RT wrote:
This is fixed by this commit, currently smoking as khw-134329 PATCH: [perl #134329] Use after free in regcomp.c A compiled regex is composed of nodes, forming a linked list, with When compiling a pattern, the 16 bit mechanism is used, until it When I rewrote the compiler last year to make it generally one pass, I But seeing this example, it's clear that the return value should be |
From @tonycozOn Thu, 01 Aug 2019 06:35:21 -0700, nguyenmanhdung1710@gmail.com wrote:
Attached the POC. This looks like it's the same problem as with 134329. On a debug build the tail of the run is: 65565: END (0) The offset there is wrong, so it's trying to interpret from the middle of a regexp op. If I test with khw-134329 I get: 162257: EXACT <n> (0) Tony |
|
The RT System itself - Status changed from 'new' to 'open' |
From @tonycozOn Thu, 01 Aug 2019 06:35:00 -0700, nguyenmanhdung1710@gmail.com wrote:
Attached the PoC. Also appears to be fixed by khw-134329 blead: 65665: EXACT <n> (0) Note the 65535 offset and the bad close paren. khw-134329: 162495: CURLY{0,1} (162499) Tony |
|
The RT System itself - Status changed from 'new' to 'open' |
From @tonycozOn Thu, 01 Aug 2019 02:25:16 -0700, nguyenmanhdung1710@gmail.com wrote:
Attached the PoC. Also fixed by khw-134329. blead: ~ tying lastbr BRANCH (65473) to ender CLOSE7 (65480) offset 7 khw-134329: ~ tying lastbr BRANCHJ (162406) to ender CLOSE1 (162410) offset 4 (some of the funny characters were probably mangled here) Tony |
|
The RT System itself - Status changed from 'new' to 'open' |
From @khwilliamsonThanks for finding and reporting this 3b2e562 |
|
@khwilliamson - Status changed from 'open' to 'pending release' |
From [email protected]On Fri, 30 Aug 2019 07:23:52 -0700, khw wrote:
Can I request a CVE for this bug? Thanks. |
From @xsawyerxOn Sat, 31 Aug 2019 07:40:43 -0700, nguyenmanhdung1710@gmail.com wrote:
Hi, [I've included this response in RT#134325 as well. I'm quoting Tony Cook here: All cases for both tickets are bad reads, either of freed memory, or None of the reads result in returning data to a potential attacker According to our usual criteria such reads aren't a security issue. Can an attacker craft a regexp with data at the offset 65535 point to I'm not sure. While we are looking into this, we would appreciate any help in proving this. If we can answer Tony's questions, we can discern better if this suits as a security issue. |
|
Hi all! Was the fix to this issue incorporated into the 5.30.2 release? I am currently trying to update the perl package for mageia linux v8 (currently cauldron), and Patch58 (for this bug) does not get applied cleanly using git: Update: randir_ on irc.perl.org informed me that it was applied as part of v5.30.2 in commit 9067ea0 . HTH. |
Migrated from rt.perl.org#134329 (status was 'pending release')
Searchable as RT134329$
The text was updated successfully, but these errors were encountered: