New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
regcomp: heap-buffer-overflow read utf8::= (perl-5.30.0) #17016
Comments
From @EtsukataPoC ``` [eiichi@x1 ~]$ valgrind perl5/perlbrew/perls/perl-5.30.0/bin/perl -e ``` |
From @khwilliamsonResending the below as it did not get attached to the ticket. On 5/23/19 11:52 PM, Eiichi Tsukata (via RT) wrote:
This is fixed by the attached file |
From @khwilliamson0001-PATCH-perl-134133-read-beyond-end-of-buffer.patch>From ee6f83153ea3eca198f39b966057339418840a7f Mon Sep 17 00:00:00 2001
From: Karl Williamson <khw@cpan.org>
Date: Fri, 24 May 2019 09:01:46 -0600
Subject: [PATCH 1/2] PATCH: [perl #134133] read beyond end of buffer
The code was using the wrong limit variable.
---
regcomp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/regcomp.c b/regcomp.c
index 9bd6dd3739..51e286bc20 100644
--- a/regcomp.c
+++ b/regcomp.c
@@ -22857,7 +22857,7 @@ Perl_parse_uniprop_string(pTHX_
/* Certain properties whose values are numeric need special handling.
* They may optionally be prefixed by 'is'. Ignore that prefix for the
* purposes of checking if this is one of those properties */
- if (memBEGINPs(lookup_name, name_len, "is")) {
+ if (memBEGINPs(lookup_name, j, "is")) {
lookup_offset = 2;
}
--
2.17.1
|
The RT System itself - Status changed from 'new' to 'open' |
From @khwilliamsonOn 6/27/19 12:26 PM, Karl Williamson wrote:
I'm trying to figure out if this is a real potential attack vector. I don't understand how this actually is generating this valgrind error. On #irc, people said this kind of error only comes from reading an |
From @hvdsOn Thu, 27 Jun 2019 12:31:30 -0700, public@khwilliamson.com wrote:
I think lookup_name has been moved since it was malloced, probably by: .. which would explain valgrind's diagnosis: In any case, reading (but not leaking information about) some bytes of malloc bookkeeping doesn't sound to me like much of an attack vector. I think worst case is that we get unlucky with the bookkeeping bytes causing the memBEGINPs to return TRUE; I'd expect that to be only a bug though, not a security issue. Briefly looking at other uses of name_len, this one might also be dodgy: /* If the original input began with 'In' or 'Is', it could be a subroutine Shouldn't that be "if (name_len - non_pkg_begin > 2"? Hugo |
From @khwilliamsonOn 7/5/19 7:23 AM, Hugo van der Sanden via RT wrote:
Yes it should, thank you. Fixed in 8d3e023 Since no one has disagreed with Hugo's assessment that this isn't a and moved this to the public queue, marking it pending release. Is a test needed, since this only surfaces under valgrind? |
@khwilliamson - Status changed from 'open' to 'pending release' |
Migrated from rt.perl.org#134133 (status was 'pending release')
Searchable as RT134133$
The text was updated successfully, but these errors were encountered: