regcomp: heap-buffer-overflow read numeric= (perl-5.30.0) #17017
Comments
From @EtsukataPoC ``` [eiichi@x1 ~]$ valgrind perl5/perlbrew/perls/perl-5.30.0/bin/perl -e ``` |
From @khwilliamsonOn 5/24/19 9:27 AM, Karl Williamson wrote:
And I carelessly pushed that patch to blead in So we have a patch publicly available for an undisclosed potential I'm not sure what to do. |
|
The RT System itself - Status changed from 'new' to 'open' |
From @hvdsOn Mon, 03 Jun 2019 14:11:52 -0700, public@khwilliamson.com wrote:
First thing is probably to work out whether it's more than a _potential_ flaw. It isn't obvious to me from a brief look: what is the buffer that's being overrun? It looks like it should be the SV with the string being qr{}d, but I'd expect that to be nul-terminated. Hugo |
From @hvdsOn Mon, 03 Jun 2019 18:01:33 -0700, hv wrote:
I've found the Newx at the top of parse_uniprop_string() string now. Digging a bit further, I don't see an avenue for a security problem here: worst case seems to be that the following bytes will successfully parse as a number without causing SEGV, in which case that number will be stored in 'value', fail the immediate test on the returned char*, and be discarded. Unless I'm missing some further payload, this should not be a problem: I don't see a way that the following bytes can be overwritten, nor any way for information about what was read to leak out unless my_atof3 itself has debug paths or failure cases that can emit diagnostics (and I don't see any). I do think the earlier code in parse_uniprop_string could be tightened further: there look to be cases where we look at name[i] when we may already have reached namelen. It's possible that we can always rely on a '}' protecting us there, but it seems unwise to rely on that in the longer term. Hugo |
From @iabynOn Tue, Jun 04, 2019 at 03:05:35AM -0700, Hugo van der Sanden via RT wrote:
I agree. -- |
From @khwilliamsonOn 6/4/19 4:34 AM, Dave Mitchell wrote:
So, should this be moved to the public queue before closing? |
From @khwilliamsonOn 6/4/19 4:05 AM, Hugo van der Sanden via RT wrote:
I found one such case, fixed by the attached patch. If you know of others, please tell me. |
From @khwilliamson0005-regcomp.c-Don-t-read-off-the-end-of-buffer.patchFrom 81a6635310602f5a7564d6e7a2f6aeed04e05929 Mon Sep 17 00:00:00 2001
From: Karl Williamson <khw@cpan.org>
Date: Thu, 27 Jun 2019 15:39:11 -0600
Subject: [PATCH 5/5] regcomp.c: Don't read off the end of buffer
Until this commit, it was possible that \p{nv=3/} would cause the right
brace to be considered part of the property name.
---
regcomp.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/regcomp.c b/regcomp.c
index aa291a20d0..ab0aac0d96 100644
--- a/regcomp.c
+++ b/regcomp.c
@@ -23090,7 +23090,9 @@ Perl_parse_uniprop_string(pTHX_
}
/* Store the first real character in the denominator */
- lookup_name[j++] = name[i];
+ if (i < name_len) {
+ lookup_name[j++] = name[i];
+ }
}
}
--
2.17.1
|
From @iabynOn Thu, Jun 27, 2019 at 03:44:08PM -0600, Karl Williamson wrote:
Which doesn't appear to have been applied yet.
-- |
From @khwilliamsonOn 8/6/19 8:02 AM, Dave Mitchell wrote:
It was applied after your email as
|
From @khwilliamsonThis was fixed by |
|
@khwilliamson - Status changed from 'open' to 'pending release' |
From @khwilliamsonOn 8/6/19 8:02 AM, Dave Mitchell wrote:
Now done
|
Migrated from rt.perl.org#134134 (status was 'pending release')
Searchable as RT134134$
The text was updated successfully, but these errors were encountered: