[CVE-2017-12883]Buffer over-read in S_grok_bslash_N #16025
Comments
From @jwilkConsider the following program: m'\N{U+.}'; When you run it under valgrind, you get: Invalid read of size 2 The above was tested on v5.26.0 built for i686-linux. The exact symptoms seem to vary with Perl version. For example, when I run it Invalid hexadecimal number in \N{U+...} in regex; marked by <-- HERE in m/ <-- HERE <binary garbage> where binary garbage looks like a large chunk of the program memory, including -- |
From @hvdsOn Sun, 18 Jun 2017 08:53:27 -0700, jwilk@jwilk.net wrote:
I tried a few builds of perl - both blead and 5.26.0 - to reproduce this, without success. Please could you supply the output of 'perl -V' for the build with which you found this? For future reports, it would be helpful if you could use 'perlbug', which would include that sort of information automatically. Cheers, Hugo |
|
The RT System itself - Status changed from 'new' to 'open' |
From @khwilliamsonOn 06/18/2017 09:53 AM, Jakub Wilk (via RT) wrote:
I single stepped through this in blead. On a DEBUGGING build, instead ==15879== Process terminating with default action of signal 6 (SIGABRT) Without DEBUGGING, and with -O2 optimization, I get Using Valgrind-3.12.0 and LibVEX; rerun with -h for copyright info It looks to me that S_grok_bslash_N is passing correct stuff to the |
From @iabynOn Mon, Jun 19, 2017 at 07:23:10PM -0600, Karl Williamson wrote:
Or maybe it isn't :-) vFAIL() is using the "%"UTF8f mechanism to pass a (possibly utf8) string It uses this: #define REPORT_LOCATION_ARGS(xC) \ Looking at the second UTF8fARG, eC expands to: pRExC_state->precomp_end xI(xC) expands to: pRExC_state->precomp At this point I see the following values: (gdb) p pRExC_state->precomp It appears that pRExC_state->adjusted_start is "wild", causing potentially Can you handle it from here? (regcomp.c is, to me, a riddle wrapped in -- |
From @khwilliamsonOn 06/20/2017 01:58 AM, Dave Mitchell wrote:
Yes, and thank you for the diagnosis. I have a trivial fix. This is a I will do an audit looking for similar cases in regcomp.c. The question now is how do we handle this. Since the fix is so trivial, (regcomp.c is, to me, a riddle wrapped in
That's how I feel about a bunch of the other core code. (And about the |
From @khwilliamsonOn 06/20/2017 10:46 AM, Karl Williamson wrote:
My audit indicates this is the only problematic case in regcomp.c
|
From @iabynOn Tue, Jun 20, 2017 at 10:46:34AM -0600, Karl Williamson wrote:
It seems that for certain types of syntax error in a pattern, So if an attacker can control the pattern, they make be able to DoS, fill I think the last one is least likely - for example if a web page accepted Personally I think we we just fix it in blead, backport in the normal (*) you probably have a better idea than me about how much memory could be -- |
From @jwilk* Dave Mitchell, 2017-06-21, 05:03:
It's a bad user experience if the search engine tells you that your query is So for the implementer, it makes sense to wrap regex compilation in eval{} and -- |
From @khwilliamsonOn 06/21/2017 06:02 AM, Dave Mitchell wrote:
The particular error happens only if someone has a single quotish \N{U+.} In raising a fatal error, there is a wild pointer. I believe that
I don't understand. I thought one wanted to synchronize things so the
|
From @iabynOn Wed, Jun 21, 2017 at 10:15:19PM -0600, Karl Williamson wrote:
So it sounds like it has the potential to dump an random large
I meant to say "and no CVE etc", although the OP's comment about web -- |
From @khwilliamsonOn 06/22/2017 03:31 AM, Dave Mitchell wrote:
FWIW, at dmq's suggestion at the core hackathon, I have code in the I pinged sawyer about your idea of combining this and 131582. I could |
From @tonycozOn Wed, 21 Jun 2017 21:15:51 -0700, public@khwilliamson.com wrote:
If this only happens for single-quotish patterns, then this isn't a security issue, since single quotish patterns don't do interpolation. I wasn't able to reproduce it (but I only tested on x64). Can it happen in other cases, like: $x = "\\N{U+.}"; ? Tony |
From @jwilk* Tony Cook via RT <perl5-security-report@perl.org>, 2017-08-11, 02:30:
Yes; I get the same symptoms for this code as for the original one. -- |
From @tonycozOn Fri, 11 Aug 2017 05:45:54 -0700, jwilk@jwilk.net wrote:
Thanks, so it's a security issue. I think it should be treated as a separate CVE from #131582, since they're different bugs and different consequences. Tony |
From @khwilliamsonOn Fri, 11 Aug 2017 18:00:15 -0700, tonyc wrote:
So my claim that it only happens with a single-quoted pattern was wrong |
From @tonycozOn Fri, 11 Aug 2017 18:00:15 -0700, tonyc wrote:
This is CVE-2017-12883. Tony |
From @tonycozOn Mon, 10 Jul 2017 20:37:20 -0700, public@khwilliamson.com wrote:
Could you post that fix here as a patch please? Thanks, |
From @khwilliamsonOn Wed, 16 Aug 2017 16:55:52 -0700, tonyc wrote:
Will do, somehow this request didn't get emailed to me. It should go in 26.1, but that discloses it |
From @tonycozOn Thu, 24 Aug 2017 13:08:10 -0700, khw wrote:
Yeah, it's possible not all RT responses are going through to the list.
I'm not asking that it go into blead, ideally the patch would get disclosed publicly and committed to blead, maint all at the same time. Tony |
From @khwilliamsonOn Thu, 24 Aug 2017 21:45:31 -0700, tonyc wrote:
Is there any way to fix this?
Attached. What I neglected to say is that I think this should go into 5.24.3, so that would mean that release and 5.26.1 and blead all have to be updated in sync. |
From @khwilliamson0002-PATCH-perl-131598.patchFrom d4857ae370c5a111b5f0ae61c3ae05e0b99e2237 Mon Sep 17 00:00:00 2001
From: Karl Williamson <khw@cpan.org>
Date: Fri, 25 Aug 2017 11:33:58 -0600
Subject: [PATCH 2/2] PATCH: [perl #131598]
The cause of this is that the vFAIL macro uses RExC_parse, and that
variable has just been changed in preparation for code after the vFAIL.
The solution is to not change RExC_parse until after the vFAIL.
This is a case where the macro hides stuff that can bite you.
---
regcomp.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/regcomp.c b/regcomp.c
index 6a07bf2c70..4eff83e50e 100644
--- a/regcomp.c
+++ b/regcomp.c
@@ -12199,14 +12199,16 @@ S_grok_bslash_N(pTHX_ RExC_state_t *pRExC_state,
}
sv_catpv(substitute_parse, ")");
- RExC_parse = RExC_start = RExC_adjusted_start = SvPV(substitute_parse,
- len);
+ len = SvCUR(substitute_parse);
/* Don't allow empty number */
if (len < (STRLEN) 8) {
RExC_parse = endbrace;
vFAIL("Invalid hexadecimal number in \\N{U+...}");
}
+
+ RExC_parse = RExC_start = RExC_adjusted_start
+ = SvPV_nolen(substitute_parse);
RExC_end = RExC_parse + len;
/* The values are Unicode, and therefore not subject to recoding, but
--
2.11.0
|
From @steve-m-hayNow in blead as commit 2be4ede. 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 2be4ede. Will shortly also be in 5.24.3-RC1 and 5.26.1-RC1... |
From @tonycozOn Wed, 16 Aug 2017 16:53:18 -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_grok_bslash_N() in regcomp.c Attack vector: An attacker can provide a crafted regular expression with an Discoverer: Jakub Wilk <jwilk@jwilk.net> Affected Product Code Base: perl - 5.26.0, fixed in 5.26.1 References: https://rt.perl.org/Public/Bug/Display.html?id=131598 Additional information: (none) Tony |
From @tonycozOn Mon, 11 Sep 2017 15:48:41 -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:10:11 -0700, xsawyerx@cpan.org wrote:
Update to CVE requested. Tony |
Migrated from rt.perl.org#131598 (status was 'resolved')
Searchable as RT131598$
The text was updated successfully, but these errors were encountered: