[CVE-2018-18313] regcomp: heap-buffer-overflow read in S_grok_bslash_N (perl-5.26.2) #16554
Comments
From @Etsukata# Summary - a crafted regular expression can cause heap-buffer-overflow read during ## (At least) Affected Versions - 5.26.2 # PoC - attack PoC : source code dumped to stderr
|
From @khwilliamsonOn 05/11/2018 02:51 AM, Eiichi Tsukata (via RT) wrote:
This was fixed in blead by regcomp.c: Convert some strchr to memchr This allows things to work properly in the face of embedded NULs. So this ticket does not apply to our pending 5.28. The date on that commit is misleading. It was not placed into blead commit c33d640 * Merge branch 'convert strchr to memchr' into blead Using C string functions on Perl strings doesn't work properly if they I have done an audit on core for cases where C string functions Also, memchr and memrchr tend to be faster than their str equivalents, I may have converted some str functions to mem ones unnecessarily, We could fix this particular instance in maintenance releases, but I
|
|
The RT System itself - Status changed from 'new' to 'open' |
From @khwilliamsonOn 05/11/2018 10:23 AM, Karl Williamson wrote:
This issue was added to blead by this commit: Fix qr'\N{U+41}' on EBCDIC platforms Prior to this commit, the regex compiler was relying on the lexer to do This was spotted by Father Chrysostomos.
|
From @EtsukataThanks for your excellent and detailed explanation!
I understand. I'll check similar attacks at current blead in case. 2018-05-12 5:03 GMT+09:00 karl williamson via RT <
|
From @tonycozOn Fri, 11 May 2018 09:23:48 -0700, public@khwilliamson.com wrote:
The attached is a backport back to maint-5.26. Tony |
From @tonycozmaint-5.26-133192.patchFrom cc56be313c7d4e7c266c01dabc762a153d5b2c28 Mon Sep 17 00:00:00 2001
From: Karl Williamson <khw@cpan.org>
Date: Sat, 25 Mar 2017 15:00:22 -0600
Subject: [PATCH] regcomp.c: Convert some strchr to memchr
This allows things to work properly in the face of embedded NULs.
See the branch merge message for more information.
(cherry picked from commit 43b2f4ef399e2fd7240b4eeb0658686ad95f8e62)
---
regcomp.c | 11 +++++++----
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/regcomp.c b/regcomp.c
index d0d08352c0..2bee9d4460 100644
--- a/regcomp.c
+++ b/regcomp.c
@@ -12018,7 +12018,8 @@ S_grok_bslash_N(pTHX_ RExC_state_t *pRExC_state,
RExC_parse++; /* Skip past the '{' */
- if (! (endbrace = strchr(RExC_parse, '}'))) { /* no trailing brace */
+ endbrace = (char *) memchr(RExC_parse, '}', RExC_end - RExC_parse);
+ if (! endbrace) { /* no trailing brace */
vFAIL2("Missing right brace on \\%c{}", 'N');
}
else if(!(endbrace == RExC_parse /* nothing between the {} */
@@ -12687,9 +12688,11 @@ S_regatom(pTHX_ RExC_state_t *pRExC_state, I32 *flagp, U32 depth)
else {
STRLEN length;
char name = *RExC_parse;
- char * endbrace;
+ char * endbrace = NULL;
RExC_parse += 2;
- endbrace = strchr(RExC_parse, '}');
+ if (RExC_parse < RExC_end) {
+ endbrace = (char *) memchr(RExC_parse, '}', RExC_end - RExC_parse);
+ }
if (! endbrace) {
vFAIL2("Missing right brace on \\%c{}", name);
@@ -16210,7 +16213,7 @@ S_regclass(pTHX_ RExC_state_t *pRExC_state, I32 *flagp, U32 depth,
vFAIL2("Empty \\%c", (U8)value);
if (*RExC_parse == '{') {
const U8 c = (U8)value;
- e = strchr(RExC_parse, '}');
+ e = (char *) memchr(RExC_parse, '}', RExC_end - RExC_parse);
if (!e) {
RExC_parse++;
vFAIL2("Missing right brace on \\%c{}", c);
--
2.11.0
|
From @tonycozI plan to request a CVE ID for this issue in the next couple of days. If anyone has already requested an ID, please let me know. Thanks, |
From @tonycozOn Sun, 23 Sep 2018 23:41:48 -0700, tonyc wrote:
This is CVE-2018-18313. Tony |
From @steve-m-hayMoved to public queue with the release of 5.26.3. |
From [Unknown Contact. See original ticket]Moved to public queue with the release of 5.26.3. |
From @steve-m-hayThis was fixed in blead by commit 43b2f4e, and back-ported to 5.26.3 by commit c1c28ce. |
|
@steve-m-hay - Status changed from 'open' to 'resolved' |
Migrated from rt.perl.org#133192 (status was 'resolved')
Searchable as RT133192$
The text was updated successfully, but these errors were encountered: