Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.
Sign upheap-buffer-overflow S_scan_const (toke.c:2975) #15624
Comments
This comment has been minimized.
This comment has been minimized.
From @geeknikTriggered in Perl v5.25.5-8-g3c42ae1 with AFL+ASAN. ./perl -e 'y%\o-0%%' ================================================================= 0x60200000e1af is located 1 bytes to the left of 10-byte region SUMMARY: AddressSanitizer: heap-buffer-overflow /root/perl/toke.c:2975 A non-ASAN build of 5.20.2 errors out: |
This comment has been minimized.
This comment has been minimized.
From @hvdsThe tr/// range constructor in scan_const knows that the characters representing start and end of the range have been written to sv; however on parse errors we don't do that but still continue. The effect is to read a (possibly utf8) character before the start of sv's PV, but then still give the parse error. I don't think this is a security concern; if someone gives a +1 I'll push the patch and open up the ticket. The attached patch fixes it, so valgrind shows no error on 'y//\o-x/' nor on 'y//x-\o/', but I can't think how to write a test. Hugo |
This comment has been minimized.
This comment has been minimized.
From @hvds |
This comment has been minimized.
This comment has been minimized.
|
The RT System itself - Status changed from 'new' to 'open' |
This comment has been minimized.
This comment has been minimized.
From @tonycozOn Wed, 05 Oct 2016 07:08:23 -0700, hv wrote:
Your fix looks fine to me. Patch with a test attached. Tony |
This comment has been minimized.
This comment has been minimized.
From @tonycoz0001-perl-129342-test-for-buffer-overflow.patchFrom d8435d6bd3614c149b02ee591dba8d7f769843fc Mon Sep 17 00:00:00 2001
From: Tony Cook <tony@develop-help.com>
Date: Tue, 17 Jan 2017 11:52:53 +1100
Subject: (perl #129342) test for buffer overflow
---
t/lib/croak/toke | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/t/lib/croak/toke b/t/lib/croak/toke
index d35eab6..f1817b3 100644
--- a/t/lib/croak/toke
+++ b/t/lib/croak/toke
@@ -350,3 +350,10 @@ EXPECT
syntax error at - line 4, near "ϡ time"
(Might be a runaway multi-line ϡϡ string starting on line 3)
Execution of - aborted due to compilation errors.
+########
+# NAME tr/// handling of mis-formatted \o characters
+# may only fail with ASAN
+tr/\o-0//;
+EXPECT
+Missing braces on \o{} at - line 2, within string
+Execution of - aborted due to compilation errors.
--
2.1.4
|
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
|
@hvds - Status changed from 'open' to 'pending release' |
This comment has been minimized.
This comment has been minimized.
From @khwilliamsonI now think this is the wrong solution. There are other occurrences of where there is an error in the parse and we continue on, so that the tr code will have invalid inputs. Rather than fix them all (and we might miss some), why not have the tr code check if there has been an error, and if so, quit now. instead of forging ahead and getting into trouble? Trying to continue parsing in the face of errors is problematic. There are times when we can't obviously continue, and there are times when we can continue, so as to find the most number of problems in a single run. (I remember how frustrating it was to work with SNOBOL that quit on the first error. This was compounded by the fact that it was punch cards, and the turnaround was 8 hours per job, except in the middle of the night.) And there are times when we think we can continue, but it creates problems. This is one of them. And we could continue except in the case of tr. So I think the tr code should be the part that changes. -- |
This comment has been minimized.
This comment has been minimized.
From @hvdsOn Fri, 20 Jan 2017 10:49:40 -0800, khw wrote:
I'm happy to consider replacing my fix with such an approach - do you have an implementation to show? "Wrong" feels like an overstatement though, and I don't think further improvements belong on this ticket. More generally, scan_const as a whole has become unwieldy enough to merit some refactoring. And in considering the current complexity, I'm also looking askance at your recently added cases for range_min == range_max and range_min + 1 == range_max: a small compile-time benefit for code that nobody would normally write does not seem worth any added complexity to the implementation. Hugo |
This comment has been minimized.
This comment has been minimized.
From @khwilliamsonOn 01/21/2017 03:29 AM, Hugo van der Sanden via RT wrote:
Perhaps you take the word "wrong" more seriously than I meant it. The I hadn't come up with an implementation, but it would essentially be
It's been unwieldy longer than I've been involved in this project; and You're right, but the reason I did this is that there is now code below
|
This comment has been minimized.
This comment has been minimized.
From @khwilliamsonOn 01/21/2017 03:43 PM, Karl Williamson wrote:
In the end, I came to the conclusion that Hugo's original approach is commit 6b58f9b * toke.c: Make sure things are initialized Commit 3dd4eae fixed a bug That commit fixed the ticket by making sure the things mentioned there At the time, I thought it would be easier to instead change the tr/// But then I thought, maybe tr/// isn't the only operator that could be The previous few commits have refactored things so as to minimize the Another way to handle this would have been to, instead of doing an |
This comment has been minimized.
This comment has been minimized.
From @khwilliamsonThank you for filing this report. You have helped make Perl better. With the release today of Perl 5.26.0, this and 210 other issues have been Perl 5.26.0 may be downloaded via: If you find that the problem persists, feel free to reopen this ticket. |
This comment has been minimized.
This comment has been minimized.
|
@khwilliamson - Status changed from 'pending release' to 'resolved' |
Migrated from rt.perl.org#129342 (status was 'resolved')
Searchable as RT129342$