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
heap-use-after-free in pp.c:Perl_pp_list() #16124
Comments
From imdb95@gmail.comHello, **********Build Date & Hardware********** This is perl 5, version 27, subversion 4 (v5.27.4 Copyright 1987-2017, Larry Wall Perl may be copied only under the terms of either the Artistic License or the Complete documentation for Perl, including FAQ lists, should be found on OS: Ubuntu 16.04 Desktop Compilation: **********Reproduce**********
|
From @tonycozOn Wed, 23 Aug 2017 21:07:53 -0700, imdb95@gmail.com wrote:
Thanks for the analysis, it made this very easy to fix, per the attached patch. As an attack, it overwrites a single pointer worth of memory with an address the attacker has little control over. On a 64-bit system they could predict the high-bytes of the address are zeros, but not much beyond that. Tony |
From @tonycoz0001-perl-131954-don-t-initialize-mark-before-a-possible-.patchFrom 6197d39797b6d1113c7129ac838eba5e3479b381 Mon Sep 17 00:00:00 2001
From: Tony Cook <tony@develop-help.com>
Date: Thu, 24 Aug 2017 15:52:33 +1000
Subject: (perl #131954) don't initialize mark before a possible move of the
stack
---
pp.c | 4 +++-
t/op/list.t | 42 +++++++++++++++++++++++++++++++++++++++++-
2 files changed, 44 insertions(+), 2 deletions(-)
diff --git a/pp.c b/pp.c
index 46366c3..2898d15 100644
--- a/pp.c
+++ b/pp.c
@@ -5120,9 +5120,11 @@ PP(pp_list)
{
I32 markidx = POPMARK;
if (GIMME_V != G_ARRAY) {
- SV **mark = PL_stack_base + markidx;
+ /* don't initialize mark here, EXTEND() may move the stack */
+ SV **mark;
dSP;
EXTEND(SP, 1); /* in case no arguments, as in @empty */
+ mark = PL_stack_base + markidx;
if (++MARK <= SP)
*MARK = *SP; /* unwanted list, return last item */
else
diff --git a/t/op/list.t b/t/op/list.t
index 3f9487b..2acb03a 100644
--- a/t/op/list.t
+++ b/t/op/list.t
@@ -6,7 +6,7 @@ BEGIN {
set_up_inc(qw(. ../lib));
}
-plan( tests => 71 );
+plan( tests => 72 );
@foo = (1, 2, 3, 4);
cmp_ok($foo[0], '==', 1, 'first elem');
@@ -228,3 +228,43 @@ ok(($0[()[()]],1), "[perl #126193] list slice with zero indexes");
@x;
pass('no panic'); # panics only under DEBUGGING
}
+
+fresh_perl_is(<<'EOS', "", {}, "[perl #131954] heap use after free in pp_list");
+#!./perl
+BEGIN {
+my $bar = "bar";
+
+sub test_no_error {
+ eval $_[0];
+}
+
+test_no_error($_) for split /\n/,
+q[ x
+ definfoo, $bar;
+ x
+ x
+ x
+ grep((not $bar, $bar, $bar), $bar);
+ x
+ x
+ x
+ x
+ x
+ x
+ x
+ x
+ x
+ x
+ x
+ x
+ x
+ x
+ x
+ x
+ x
+ x
+ x
+ x
+ ];
+}
+EOS
--
2.1.4
|
The RT System itself - Status changed from 'new' to 'open' |
From imdb95@gmail.comThank you for quick reply.This is the first time i submit a perl bug. Would this bug qualify for a bounty? Gửi từ điện thoại thông minh Samsung Galaxy của tôi.-------- Tin nhắn gốc --------Từ: Tony Cook via RT <perl5-security-report@perl.org> Ngày: 24/08/2017 13:03 (GMT+07:00) Đến: imdb95@gmail.com Chủ đề: [perl #131954] heap-use-after-free in pp.c:Perl_pp_list()
Thanks for the analysis, it made this very easy to fix, per the attached patch. As an attack, it overwrites a single pointer worth of memory with an address the attacker has little control over. On a 64-bit system they could predict the high-bytes of the address are zeros, but not much beyond that. Tony |
From @jhiThe Perl project does not offer bug bounties, sorry. Perl is an open source to 24. elokuuta 2017 klo 12.54 imdb95 <imdb95@gmail.com> kirjoitti:
-- |
From imdb95@gmail.comOh, I read about HackerOne: |
From @nwc10On Thu, Aug 24, 2017 at 12:24:34PM +0000, Jarkko Hietaniemi wrote:
However HackerOne (completely independently) does offer a bug bounty program This might be eligible for their bounty. Given that their steps are: Submission Process * Disclose a previously unknown security vulnerability directly to the if you wanted to follow this up with them, I think you'd 1) need to figure out how to comply with their requirement to HackerOne's rider about "cannot invest significant effort" applies here. I'm personally not aware of any existing framework for remote exploits of I have no idea how HackerOne assess eligibility (beyond what I read on their As an attack, it overwrites a single pointer worth of memory with an I'm *guessing* that it's going to be hard to demonstrate that it has Less than that and it's not a remote exploit. To me that looks like a lot of work for a low chance of payout *for this Whilst *we* can't offer you monetary bounties, we can offer you thanks and Thanks for reporting this bug, and for the very clear analysis, and good Nicholas Clark * they clarify remote exploitation as "typically Arbitrary Code Execution or |
From imdb95@gmail.comHello, On Thu, Aug 24, 2017 at 1:03 PM, Tony Cook via RT <
|
From @tonycozOn Thu, 24 Aug 2017 08:21:16 -0700, nicholas wrote:
AFAIK Hackerone lets each project decide whether an issue is a security vulnerability or not. As an aside - the eval is not required for this code to write to a freed block, removig the sub definition and changing the loop to: grep((not $bar, $bar, $bar), $bar) for split /\n/, also writes to a freed block. So vaguely sane code can misbehave with the right input here which might be supplied by an attacker. Depending on the implementation of malloc, that might result in perl segfaulting, which could be a denial of service. I don't think it can reasonably result in code execution - the memory overwritten in within a memory block which has only just been freed (by EXTEND()) so it's unlikely to overwrite any heap housekeeping data which might be at that location for new allocations within the freed block. This was introduced in v5.27.1-248-gb54564c which might make us feel safe since we don't do security support for blead-ish releases, but unfortunately this was backported to maint-5.26 as v5.26.0-16-g6a20648 (which fixed 131732, not 131627.) I'd tend to treat this issue as a security issue, but it's difficult to tell - and if this is a security issue, 131732 was one too. Tony |
From @iabynOn Thu, Aug 24, 2017 at 1:03 PM, Tony Cook via RT <
Tony, any particular reason why this patch hasn't been applied yet?
-- |
From @tonycozOn Wed, 29 Nov 2017 01:23:16 -0800, davem wrote:
Mostly indecisiveness on whether to treat this as a security issue. I've applied this as 57bd660 and made the ticket public. I've also added this to the 5.26 maint-votes file since the patch that introduced the bug was backported to maint-5.26. Vote early, vote often. Tony |
@tonycoz - Status changed from 'open' to 'pending release' |
From @xsawyerxOn 01/17/2018 01:53 AM, Tony Cook via RT wrote:
Added my vote +1 to this. |
From @khwilliamsonThank you for filing this report. You have helped make Perl better. With the release yesterday of Perl 5.28.0, this and 185 other issues have been Perl 5.28.0 may be downloaded via: If you find that the problem persists, feel free to reopen this ticket. |
@khwilliamson - Status changed from 'pending release' to 'resolved' |
Migrated from rt.perl.org#131954 (status was 'resolved')
Searchable as RT131954$
The text was updated successfully, but these errors were encountered: