Skip Menu |
Report information
Id: 131665
Status: resolved
Priority: 0/
Queue: perl5

Owner: Nobody
Requestors: john [at] autosectools.com
Cc: andyg [at] activestate.com
daver [at] activestate.com
AdminCc:

Operating System: (no value)
PatchStatus: (no value)
Severity: (no value)
Type: (no value)
Perl Version: (no value)
Fixed In: (no value)



From: John Leitch <john [...] autosectools.com>
Date: Tue, 27 Jun 2017 03:21:42 -0700
Subject: Perl $ENV Key Stack Buffer Overflow
To: perl5-security-report [...] perl.org
Download (untitled) / with headers
text/html 21.5k

Message body is not shown because it is too large.

RT-Send-CC: rt-deliver-to-perl5-security-report [...] rt.perl.org
Download (untitled) / with headers
text/plain 2.2k
As text, since RT didn't want to display it inline, and the text/html link displayed source: The CPerlHost::Add method in win32\perlhost.h is vulnerable to a stack buffer overflow. void CPerlHost::Add(LPCSTR lpStr) { char szBuffer[1024]; LPSTR *lpPtr; int index, length = strlen(lpStr)+1; for(index = 0; lpStr[index] != '\0' && lpStr[index] != '='; ++index) szBuffer[index] = lpStr[index]; szBuffer[index] = '\0'; [...] } The issue exists because the size of lpStr, the key passed in when indexing into $ENV, is not checked before it is copied into szBuffer, a fixed size stack buffer. The issue can be reproduced on a win32 build with the following script. print "Starting\r\n"; $ENV{"A" x (0x1000)} = 0; print "Done\r\n"; In cases where the $ENV key is exposed as attack surface, it may be possible for an attacker to achieve arbitrary code execution. The issue was exploited in Strawberry Perl, which appears to be compiled without stack canaries and ASLR. print "Starting\r\n"; $chars = "\x41\x41\x41\x41" . "\x78\x6e\x3b\x6e" . # perl526!exit (6E3B6E78) "\x43\x43\x43\x43" . "\x4e\x1d\x1e\x03" . # exit code (52305230) "\x45\x45\x45\x45" . "\x46\x46\x46\x46" . "\x47\x47\x47\x47" . "\x30\x2c\x3a\x6e"; # perl526!win32_getpid (6e3a2c30) $ENV{$chars x ((0x400+0x4*0x10) / length $chars)} = 0; print "Done\r\n"; A proposed patch that validates the length of lpStr follows. diff --git "a/d:\\source2\\perl-raw\\win32\\perlhost.h" "b/D:\\source2\\perl\\win32\\perlhost.h" index 84b08c9..665504e 100644 --- "a/d:\\source2\\perl-raw\\win32\\perlhost.h" +++ "b/D:\\source2\\perl\\win32\\perlhost.h" @@ -2177,12 +2177,15 @@ compare(const void *arg1, const void *arg2) void CPerlHost::Add(LPCSTR lpStr) { - char szBuffer[1024]; + char szBuffer[2048]; LPSTR *lpPtr; int index, length = strlen(lpStr)+1; for(index = 0; lpStr[index] != '\0' && lpStr[index] != '='; ++index) - szBuffer[index] = lpStr[index]; + if (index != sizeof(szBuffer) - 1) + szBuffer[index] = lpStr[index]; + else + Perl_croak_nocontext("$ENV key too large"); szBuffer[index] = '\0'; Note that the buffer size had to be increased to accommodate larger values that were previously causing silent overwrites. Credit: John Leitch (john@autosectools.com), Bryce Darling (darlingbryce@gmail.com)
RT-Send-CC: rt-deliver-to-perl5-security-report [...] rt.perl.org
Download (untitled) / with headers
text/plain 529b
On Tue, 27 Jun 2017 03:22:45 -0700, john@autosectools.com wrote: Show quoted text
> CPerlHost::Add(LPCSTR lpStr) > > { > > - char szBuffer[1024]; > > + char szBuffer[2048]; > > LPSTR *lpPtr; >
Why the 2048 byte limit? Neither 1024 not 2048 is the limit on the length of an environment variable entry or name, and they're each about as silly as the other as the practical length of an environment variable name. I'd be inclined to either go for a dynamically allocated buffer, or a fixed buffer with a fallback to dynamic allocation. Tony
Date: Thu, 6 Jul 2017 23:13:33 -0700
From: John Leitch <john [...] autosectools.com>
Subject: Re: [perl #131665] Perl $ENV Key Stack Buffer Overflow
To: perl5-security-report [...] perl.org
Download (untitled) / with headers
text/plain 813b
I kept it as a stack buffer in case of perf concerns, and upped the size because one of the tests was overrunning. That said, I do think dynamic allocation is a better solution, and will update the patch accordingly. On 7/5/2017 06:18 PM, Tony Cook via RT wrote: Show quoted text
> On Tue, 27 Jun 2017 03:22:45 -0700, john@autosectools.com wrote:
>> CPerlHost::Add(LPCSTR lpStr) >> >> { >> >> - char szBuffer[1024]; >> >> + char szBuffer[2048]; >> >> LPSTR *lpPtr; >>
> Why the 2048 byte limit? Neither 1024 not 2048 is the limit on the length of an environment variable entry or name, and they're each about as silly as the other as the practical length of an environment variable name. > > I'd be inclined to either go for a dynamically allocated buffer, or a fixed buffer with a fallback to dynamic allocation. > > Tony > >
Subject: Re: [perl #131665] Perl $ENV Key Stack Buffer Overflow
To: John Leitch <john [...] autosectools.com>
CC: perl5-security-report [...] perl.org
From: Tony Cook <tony [...] develop-help.com>
Date: Fri, 7 Jul 2017 16:18:38 +1000
Download (untitled) / with headers
text/plain 354b
On Thu, Jul 06, 2017 at 11:13:33PM -0700, John Leitch wrote: Show quoted text
> I kept it as a stack buffer in case of perf concerns, and upped the size > because one of the tests was overrunning. That said, I do think dynamic > allocation is a better solution, and will update the patch accordingly.
Please attach the patch rather than pasting in inline. Thanks, Tony
From: John Leitch <john [...] autosectools.com>
Date: Wed, 12 Jul 2017 01:08:34 -0700
Subject: Re: [perl #131665] Perl $ENV Key Stack Buffer Overflow
To: perl5-security-report [...] perl.org
Download (untitled) / with headers
text/plain 502b
Attached is an updated patch that uses a dynamically allocated heap buffer. John On 7/6/2017 11:18 PM, Tony Cook via RT wrote: Show quoted text
> On Thu, Jul 06, 2017 at 11:13:33PM -0700, John Leitch wrote:
>> I kept it as a stack buffer in case of perf concerns, and upped the size >> because one of the tests was overrunning. That said, I do think dynamic >> allocation is a better solution, and will update the patch accordingly.
> Please attach the patch rather than pasting in inline. > > Thanks, > Tony > > >

Message body is not shown because sender requested not to inline it.

RT-Send-CC: rt-deliver-to-perl5-security-report [...] rt.perl.org
Download (untitled) / with headers
text/plain 443b
On Wed, 12 Jul 2017 01:09:44 -0700, john@autosectools.com wrote: Show quoted text
> Attached is an updated patch that uses a dynamically allocated heap buffer.
That's what I was looking for, but... I had a look over the Lookup() (and lookup()) code, and if I'm reading it correctly it treats the string passed in as terminated by either '=' or NUL, so the copy process that requires the buffer is unnecessary. The attached patch eliminates the buffer. Tony
Subject: 0001-perl-131665-avoid-a-buffer-overflow-in-a-buffer-we-d.patch
From ea29f1f997817437106be659a9c357d01aba08b8 Mon Sep 17 00:00:00 2001 From: Tony Cook <tony@develop-help.com> Date: Mon, 17 Jul 2017 15:21:08 +1000 Subject: (perl #131665) avoid a buffer overflow in a buffer we didn't need since Lookup() treats its argument as NUL or '=' terminated. --- win32/perlhost.h | 10 ++-------- 1 file changed, 2 insertions(+), 8 deletions(-) diff --git a/win32/perlhost.h b/win32/perlhost.h index 84b08c9..0ce0175 100644 --- a/win32/perlhost.h +++ b/win32/perlhost.h @@ -2177,17 +2177,11 @@ compare(const void *arg1, const void *arg2) void CPerlHost::Add(LPCSTR lpStr) { - char szBuffer[1024]; LPSTR *lpPtr; - int index, length = strlen(lpStr)+1; - - for(index = 0; lpStr[index] != '\0' && lpStr[index] != '='; ++index) - szBuffer[index] = lpStr[index]; - - szBuffer[index] = '\0'; + int length = strlen(lpStr)+1; // replacing ? - lpPtr = Lookup(szBuffer); + lpPtr = Lookup(lpStr); if (lpPtr != NULL) { // must allocate things via host memory allocation functions // rather than perl's Renew() et al, as the perl interpreter -- 2.7.0.windows.1
To: perl5-security-report [...] perl.org
Subject: Re: [perl #131665] Perl $ENV Key Stack Buffer Overflow
Date: Mon, 17 Jul 2017 00:29:46 -0700
From: John Leitch <john [...] autosectools.com>
Download (untitled) / with headers
text/plain 580b
In that case, eliminating the superfluous buffer seems ideal. John On 7/16/2017 10:22 PM, Tony Cook via RT wrote: Show quoted text
> On Wed, 12 Jul 2017 01:09:44 -0700, john@autosectools.com wrote:
>> Attached is an updated patch that uses a dynamically allocated heap buffer.
> That's what I was looking for, but... > > I had a look over the Lookup() (and lookup()) code, and if I'm > reading it correctly it treats the string passed in as > terminated by either '=' or NUL, so the copy process that requires > the buffer is unnecessary. > > The attached patch eliminates the buffer. > > Tony
RT-Send-CC: rt-deliver-to-perl5-security-report [...] rt.perl.org
Download (untitled) / with headers
text/plain 401b
On Sun, 16 Jul 2017 22:22:12 -0700, tonyc wrote: Show quoted text
> I had a look over the Lookup() (and lookup()) code, and if I'm > reading it correctly it treats the string passed in as > terminated by either '=' or NUL, so the copy process that requires > the buffer is unnecessary. > > The attached patch eliminates the buffer.
Added tests. Do we need a CVE for this, and how are we allocating those now? Tony
Subject: 0001-perl-131665-avoid-a-buffer-overflow-in-a-buffer-we-d.patch
From 35ce250032264068ed8f95410e9fbf81873d75b9 Mon Sep 17 00:00:00 2001 From: Tony Cook <tony@develop-help.com> Date: Thu, 27 Jul 2017 10:12:02 +1000 Subject: (perl #131665) avoid a buffer overflow in a buffer we didn't need since Lookup() treats its argument as NUL or '=' terminated. Previously environment variable names longer than the size of the buffer would result in a buffer overflow. --- t/win32/runenv.t | 21 ++++++++++++++++----- win32/perlhost.h | 10 ++-------- 2 files changed, 18 insertions(+), 13 deletions(-) diff --git a/t/win32/runenv.t b/t/win32/runenv.t index 514eda0..4746afa 100644 --- a/t/win32/runenv.t +++ b/t/win32/runenv.t @@ -14,10 +14,10 @@ BEGIN { require Win32; ($::os_id, $::os_major) = ( Win32::GetOSVersion() )[ 4, 1 ]; if ($::os_id == 2 and $::os_major == 6) { # Vista, Server 2008 (incl R2), 7 - $::tests = 43; + $::tests = 45; } else { - $::tests = 40; + $::tests = 42; } require './test.pl'; @@ -70,11 +70,12 @@ sub runperl_and_capture { } sub try { - my ($env, $args, $stdout, $stderr) = @_; + my ($env, $args, $stdout, $stderr, $name) = @_; my ($actual_stdout, $actual_stderr) = runperl_and_capture($env, $args); + $name ||= ""; local $::Level = $::Level + 1; - is $actual_stdout, $stdout; - is $actual_stderr, $stderr; + is $actual_stdout, $stdout, "$name - stdout"; + is $actual_stderr, $stderr, "$name - stderr"; } # PERL5OPT Command-line options (switches). Switches in @@ -196,6 +197,16 @@ try({PERL5LIB => "foo", '', ''); +{ + # 131665 + # crashes without the fix + my $longname = "X" x 2048; + try({ $longname => 1 }, + [ '-e', '"print q/ok/"' ], + 'ok', '', + 'very long env var names' ); +} + # Tests for S_incpush_use_sep(): my @dump_inc = ('-e', '"print \"$_\n\" foreach @INC"'); diff --git a/win32/perlhost.h b/win32/perlhost.h index 84b08c9..3260f62 100644 --- a/win32/perlhost.h +++ b/win32/perlhost.h @@ -2177,17 +2177,11 @@ compare(const void *arg1, const void *arg2) void CPerlHost::Add(LPCSTR lpStr) { - char szBuffer[1024]; LPSTR *lpPtr; - int index, length = strlen(lpStr)+1; - - for(index = 0; lpStr[index] != '\0' && lpStr[index] != '='; ++index) - szBuffer[index] = lpStr[index]; - - szBuffer[index] = '\0'; + STRLEN length = strlen(lpStr)+1; // replacing ? - lpPtr = Lookup(szBuffer); + lpPtr = Lookup(lpStr); if (lpPtr != NULL) { // must allocate things via host memory allocation functions // rather than perl's Renew() et al, as the perl interpreter -- 2.7.0.windows.1
Date: Mon, 7 Aug 2017 11:12:28 -0700
To: perl5-security-report [...] perl.org
From: John Leitch <john [...] autosectools.com>
Subject: Re: [perl #131665] Perl $ENV Key Stack Buffer Overflow
Download (untitled) / with headers
text/plain 1.1k
I would say this warrants a CVE as it is highly exploitable, especially given the lack of mitigations in the two major windows builds, as demonstrated by the exploit provided. Shellshock proved that there are numerous vectors for controlling environment arguments, so it stands to reason that the same is true for keys. Especially so, considering complete control of the key is not necessary--even if the tainted key data is prefixed and suffixed with trusted data, this vuln can still exploited. Also, to further expand upon the impact of this issue, please find attached a list of all modules in ActiveState and Strawberry Perl that had ASLR and/or DEP disabled. John On 7/26/2017 05:12 PM, Tony Cook via RT wrote: Show quoted text
> On Sun, 16 Jul 2017 22:22:12 -0700, tonyc wrote:
>> I had a look over the Lookup() (and lookup()) code, and if I'm >> reading it correctly it treats the string passed in as >> terminated by either '=' or NUL, so the copy process that requires >> the buffer is unnecessary. >> >> The attached patch eliminates the buffer.
> Added tests. > > Do we need a CVE for this, and how are we allocating those now? > > Tony >

Message body is not shown because sender requested not to inline it.

RT-Send-CC: rt-deliver-to-perl5-security-report [...] rt.perl.org
Download (untitled) / with headers
text/plain 1.2k
On Mon, 07 Aug 2017 11:13:34 -0700, john@autosectools.com wrote: Show quoted text
> I would say this warrants a CVE as it is highly exploitable, especially > given the lack of mitigations in the two major windows builds, as > demonstrated by the exploit provided. Shellshock proved that there are > numerous vectors for controlling environment arguments, so it stands to > reason that the same is true for keys. Especially so, considering > complete control of the key is not necessary--even if the tainted key > data is prefixed and suffixed with trusted data, this vuln can still > exploited. > > Also, to further expand upon the impact of this issue, please find > attached a list of all modules in ActiveState and Strawberry Perl that > had ASLR and/or DEP disabled.
That's probably our issue - the fixed base for the perl dll was introduced in 9d2428989d95cd0d9d5fc1f1fcf60ab67cde0b7f. As to allocating a CVE ID, I'm not sure how. Going by http://cve.mitre.org/cve/request_id.html - Redhat isn't suitable, this issue has no effect on Linux - the DWF form is for public issues only - the other CNAs appear to allocate ids for their own products only The Mitre form doesn't indicate whether the issue will immediately become public, I've mailed cve@mitre.org about it. Tony
From: Tony Cook <tony [...] develop-help.com>
Subject: [perl #131665] ActiveState security contact
Date: Thu, 10 Aug 2017 11:13:01 +1000
To: Andy Grundman <andyg [...] activestate.com>
CC: perl5-security-report [...] perl.org
Download (untitled) / with headers
text/plain 513b
Hi, We have a confirmed Win32 specific perl security issue, and I'd like to arrange for a co-ordinated release of a fixed ActivePerl and public disclosure of the problem. Are you the correct person to deal with this? Your name/email came up in another issue [perl #129251] which ended up not being a perl/ActiveState issue, but you stated: Show quoted text
> Actually, I'll check if we have a general security@ address > or create one if not. I'll get back to you on that.
but I didn't see a follow-up on that. Thanks, Tony
Subject: Re: [perl #131665] ActiveState security contact
From: Andy Grundman <andyg [...] activestate.com>
CC: perl5-security-report [...] perl.org, Dave Rolsky <daver [...] activestate.com>
To: Tony Cook <tony [...] develop-help.com>
Date: Thu, 10 Aug 2017 20:40:33 +0000
Download (untitled) / with headers
text/plain 879b
Hi Tony,

Thanks, please include both Dave Rolsky and myself in discussions about this issue. We are in the process of preparing new 5.22/5.24/5.26 ActivePerl releases for later this month, so we should definitely be able to get this addressed quickly.

-Andy

On Wed, Aug 9, 2017 at 9:13 PM Tony Cook <tony@develop-help.com> wrote:
Show quoted text
Hi,

We have a confirmed Win32 specific perl security issue, and I'd like
to arrange for a co-ordinated release of a fixed ActivePerl and public
disclosure of the problem.

Are you the correct person to deal with this?

Your name/email came up in another issue [perl #129251] which ended up
not being a perl/ActiveState issue, but you stated:

> Actually, I'll check if we have a general security@ address
> or create one if not. I'll get back to you on that.

but I didn't see a follow-up on that.

Thanks,
Tony
RT-Send-CC: rt-deliver-to-perl5-security-report [...] rt.perl.org
On Tue, 08 Aug 2017 22:48:27 -0700, tonyc wrote: Show quoted text
> On Mon, 07 Aug 2017 11:13:34 -0700, john@autosectools.com wrote:
> > I would say this warrants a CVE as it is highly exploitable, > > especially > > given the lack of mitigations in the two major windows builds, as > > demonstrated by the exploit provided. Shellshock proved that there > > are > > numerous vectors for controlling environment arguments, so it stands > > to > > reason that the same is true for keys. Especially so, considering > > complete control of the key is not necessary--even if the tainted key > > data is prefixed and suffixed with trusted data, this vuln can still > > exploited. > > > > Also, to further expand upon the impact of this issue, please find > > attached a list of all modules in ActiveState and Strawberry Perl > > that > > had ASLR and/or DEP disabled.
> > That's probably our issue - the fixed base for the perl dll was > introduced in 9d2428989d95cd0d9d5fc1f1fcf60ab67cde0b7f. > > As to allocating a CVE ID, I'm not sure how.
I've requested a CVE ID for this issue. Tony
RT-Send-CC: rt-deliver-to-perl5-security-report [...] rt.perl.org
Download (untitled) / with headers
text/plain 122b
On Fri, 11 Aug 2017 03:17:17 -0700, tonyc wrote: Show quoted text
> I've requested a CVE ID for this issue.
This is CVE-2017-12814. Tony
Download (untitled) / with headers
text/plain 1.3k
On Tue, 08 Aug 2017 22:48:27 -0700, tonyc wrote: Show quoted text
> On Mon, 07 Aug 2017 11:13:34 -0700, john@autosectools.com wrote:
Show quoted text
> > Also, to further expand upon the impact of this issue, please find > > attached a list of all modules in ActiveState and Strawberry Perl > > that > > had ASLR and/or DEP disabled.
> > That's probably our issue - the fixed base for the perl dll was > introduced in 9d2428989d95cd0d9d5fc1f1fcf60ab67cde0b7f.
The relocation stuff is a pretty messy issue, but I believe we build things this way because you can get address space collisions in rare cases when using many large XS modules (Wx comes to mind). bulk88 and Jan Dubois probably know the most about this issue. One bug to see is https://rt.cpan.org/Ticket/Display.html?id=78395 As for this patch, it's nice and simple and is working fine in our builds. It applies cleanly back through 5.18, and I will back-port it down to 5.8 for our enterprise customers. ActivePerl for those versions is built with Visual Studio, but I don't know if this is a more or less severe issue there. So what are the next steps here? Since this bug only affects Windows, is it enough to warrant a new point release? We had been on track to release 5.22.4, 5.24.2, and 5.26.0 before the end of August, and the patch could go in those if you don't think we need an upstream release.
RT-Send-CC: rt-deliver-to-perl5-security-report [...] rt.perl.org
Download (untitled) / with headers
text/plain 587b
To build on what Andy said, we'd really like to be able to schedule our releases for this quarter. We do private releases to customers of our Enterprise builds. This would disclose the vulnerability to a small group of people. We also do Community releases which are freely available on our website. This would disclose the vulnerability to essentially everybody. Can we come up with a schedule for disclosing this bug? I assume the goal is to synchronize the bug disclosure with our Community releases and with a new Strawberry Perl release. What do we need to do to make that happen?
RT-Send-CC: rt-deliver-to-perl5-security-report [...] rt.perl.org
Download (untitled) / with headers
text/plain 2.1k
On Tue, 22 Aug 2017 12:25:05 -0700, andyg@activestate.com wrote: Show quoted text
> On Tue, 08 Aug 2017 22:48:27 -0700, tonyc wrote:
> > On Mon, 07 Aug 2017 11:13:34 -0700, john@autosectools.com wrote:
>
> > > Also, to further expand upon the impact of this issue, please find > > > attached a list of all modules in ActiveState and Strawberry Perl > > > that > > > had ASLR and/or DEP disabled.
> > > > That's probably our issue - the fixed base for the perl dll was > > introduced in 9d2428989d95cd0d9d5fc1f1fcf60ab67cde0b7f.
> > The relocation stuff is a pretty messy issue, but I believe we build > things this way because you can get address space collisions in rare > cases when using many large XS modules (Wx comes to mind). bulk88 and > Jan Dubois probably know the most about this issue. One bug to see is > https://rt.cpan.org/Ticket/Display.html?id=78395
From the discussions this is a tools bug, not a bug in Perl, and this bug can cause problems even if all of the executables/DLLs involved have non-overlapping base addresses (since some third-party DLL can cause a conflict.) Show quoted text
> As for this patch, it's nice and simple and is working fine in our > builds. It applies cleanly back through 5.18, and I will back-port it > down to 5.8 for our enterprise customers. ActivePerl for those > versions is built with Visual Studio, but I don't know if this is a > more or less severe issue there. > > So what are the next steps here? Since this bug only affects Windows, > is it enough to warrant a new point release? We had been on track to > release 5.22.4, 5.24.2, and 5.26.0 before the end of August, and the > patch could go in those if you don't think we need an upstream > release.
I haven't heard back from kmx yet, at this point I'm inclined to go ahead on this issue, but... We hsve two other non-Win32-specific issues https://rt.perl.org/rt3/Ticket/Display.html?id=131598 https://rt.perl.org/rt3/Ticket/Display.html?id=131582 (which I believe you now have access to) that we have CVE IDs for and we were planning to disclose at the same time. Last time I discussed this with Sawyer he was going to notify the disclosure mailing list once they all have CVE IDs, but it might have fallen off his radar. Tony
RT-Send-CC: perl5-security-report [...] perl.org
Download (untitled) / with headers
text/plain 117b
Now in blead as commit 8586647e338e8eb42c00fe6f687105c9b8a36d44. Will shortly also be in 5.24.3-RC1 and 5.26.1-RC1...
CC: Perl 5 Security Report <perl5-security-report [...] perl.org>
To: rt-comment [...] perl.org
Subject: Re: [perl #131665] [CVE-2017-12814]Perl $ENV Key Stack Buffer Overflow
From: Sawyer X <xsawyerx [...] gmail.com>
Date: Mon, 11 Sep 2017 12:12:32 +0300
Download (untitled) / with headers
text/plain 278b
This was set to be disclosed on September 22nd. Disclosure list was informed. On 10 September 2017 at 16:17, Steve Hay via RT <rt-comment@perl.org> wrote: Show quoted text
> > Now in blead as commit 8586647e338e8eb42c00fe6f687105c9b8a36d44. Will shortly also be in 5.24.3-RC1 and 5.26.1-RC1...
RT-Send-CC: perl5-security-report [...] perl.org
Download (untitled) / with headers
text/plain 1.8k
On Fri, 11 Aug 2017 17:52:21 -0700, tonyc wrote: Show quoted text
> On Fri, 11 Aug 2017 03:17:17 -0700, tonyc wrote:
> > I've requested a CVE ID for this issue.
> > This is CVE-2017-12814.
The details I entered when requesting the CVE ID: Show quoted text
> [Suggested description] > Will be made public once co-ordinated release is done. > ------------------------------------------ > [Vulnerability Type] > Buffer Overflow > > ------------------------------------------ > [Vendor of Product] > Perl5 Porters > ------------------------------------------ > [Affected Product Code Base] > perl - 5.005_03 through 5.26 > ------------------------------------------ > [Affected Component] > > ------------------------------------------ > [Attack Type] > Local > > ------------------------------------------ > [Impact ] > > [+] CVE_Request.Impact_Code_execution > [-] CVE_Request.Impact_Denial_of_Service > [-] CVE_Request.Impact_Escalation_of_Privileges > [-] CVE_Request.Impact_Information_Disclosure > ------------------------------------------ > [Attack Vectors] > > ------------------------------------------ > [Reference ] > > ------------------------------------------ > [Discoverer ] > John Leitch (john@autosectools.com), Bryce Darling (darlingbryce@gmail.com)
Proposed update for the CVE entry once the issue is public (the field names are from the CVE allocation form): Suggested description: Stack buffer overflow with crafted environment variable, leading to code execution Affected components: CPerlHost::Add() in win32/perlhost.h Attack vector: An attacker can provide a long environment variable name overflowing a stack allocated buffer. This issue only occurs for Win32 builds of perl. Discoverer: John Leitch (john@autosectools.com), Bryce Darling (darlingbryce@gmail.com) (no change) Affected Product Code Base: perl - 5.005_03 through 5.26 (no change) References: https://rt.perl.org/Public/Bug/Display.html?id=131665 Tony
From: john [...] autosectools.com
Subject: RE: [perl #131665] [CVE-2017-12814]Perl $ENV Key Stack Buffer Overflow
Date: Fri, 22 Sep 2017 18:23:13 -0700
CC: andyg [...] activestate.com, daver [...] activestate.com
To: perl5-security-report-followup [...] perl.org
Download (untitled) / with headers
text/plain 3.4k
Hi all,
 
One quick but important nitpick. This vulnerability is described as a possible stack overflow here: https://metacpan.org/changes/release/SHAY/perl-5.26.1-RC1#%5BCVE-2017-12814%5D-$ENV%7B$key%7D-stack-buffer-overflow-on-Windows
 
While it's true that I said this is possibly exploitable depending on context, there is no question that it is a stack overflow, as the exploit PoC demonstrates. Further, I prefixed my exploitability claim with "possibly" solely to avoid speaking in absolutes. I would say this is highly exploitable in most scenarios that expose env keys as attack surface.
 
Our main concern here is that people may underestimate the severity, and our advisory will contain multiple exploits demonstrating scenarios wherein this can be remote. Internally (we don't name bugs as that's rather tacky) we affectionately refer to this one as "PerlShock," and it is by far the most critical issue we have discovered in a language to date.
 
To provide an example, it's not uncommon for CGI web apps to save query strings name value pairs as env vars. In this case, the vulnerability would be exploitable through said query string. Though we have no concrete statistics, we have seen this pattern in the wild and thus expect this issue to have real-world ramifications.
 
John
 
Show quoted text
--------- Original Message ---------
Subject: [perl #131665] [CVE-2017-12814]Perl $ENV Key Stack Buffer Overflow
From: "Tony Cook via RT" <perl5-security-report-followup@perl.org>
Date: 9/11/17 4:50 pm
To: john@autosectools.com
Cc: andyg@activestate.com, daver@activestate.com

On Fri, 11 Aug 2017 17:52:21 -0700, tonyc wrote:
> On Fri, 11 Aug 2017 03:17:17 -0700, tonyc wrote:
> > I've requested a CVE ID for this issue.
>
> This is CVE-2017-12814.

The details I entered when requesting the CVE ID:

> [Suggested description]
> Will be made public once co-ordinated release is done.
> ------------------------------------------
> [Vulnerability Type]
> Buffer Overflow
>
> ------------------------------------------
> [Vendor of Product]
> Perl5 Porters
> ------------------------------------------
> [Affected Product Code Base]
> perl - 5.005_03 through 5.26
> ------------------------------------------
> [Affected Component]
>
> ------------------------------------------
> [Attack Type]
> Local
>
> ------------------------------------------
> [Impact ]
>
> [+] CVE_Request.Impact_Code_execution
> [-] CVE_Request.Impact_Denial_of_Service
> [-] CVE_Request.Impact_Escalation_of_Privileges
> [-] CVE_Request.Impact_Information_Disclosure
> ------------------------------------------
> [Attack Vectors]
>
> ------------------------------------------
> [Reference ]
>
> ------------------------------------------
> [Discoverer ]
> John Leitch (john@autosectools.com), Bryce Darling (darlingbryce@gmail.com)

Proposed update for the CVE entry once the issue is public (the field names are from the CVE allocation form):

Suggested description:

Stack buffer overflow with crafted environment variable, leading to code execution

Affected components:

CPerlHost::Add() in win32/perlhost.h

Attack vector:

An attacker can provide a long environment variable name
overflowing a stack allocated buffer.

This issue only occurs for Win32 builds of perl.

Discoverer:

John Leitch (john@autosectools.com), Bryce Darling (darlingbryce@gmail.com) (no change)

Affected Product Code Base:

perl - 5.005_03 through 5.26 (no change)

References:

https://rt.perl.org/Public/Bug/Display.html?id=131665

Tony
Date: Fri, 22 Sep 2017 18:28:11 -0700
From: john [...] autosectools.com
Subject: RE: [perl #131665] [CVE-2017-12814]Perl $ENV Key Stack Buffer Overflow
To: perl5-security-report-followup [...] perl.org
CC: andyg [...] activestate.com, daver [...] activestate.com
Addendum: a quick search for an example revealed that custom headers may be stored in env:
 
 
I will investigate further this weekend, but there's a good chance this is a viable exploitation vector.
 
Show quoted text
--------- Original Message ---------
Subject: RE: [perl #131665] [CVE-2017-12814]Perl $ENV Key Stack Buffer Overflow
From: john@autosectools.com
Date: 9/22/17 6:23 pm
To: perl5-security-report-followup@perl.org
Cc: andyg@activestate.com, daver@activestate.com

Hi all,
 
One quick but important nitpick. This vulnerability is described as a possible stack overflow here: https://metacpan.org/changes/release/SHAY/perl-5.26.1-RC1#%5BCVE-2017-12814%5D-$ENV%7B$key%7D-stack-buffer-overflow-on-Windows
 
While it's true that I said this is possibly exploitable depending on context, there is no question that it is a stack overflow, as the exploit PoC demonstrates. Further, I prefixed my exploitability claim with "possibly" solely to avoid speaking in absolutes. I would say this is highly exploitable in most scenarios that expose env keys as attack surface.
 
Our main concern here is that people may underestimate the severity, and our advisory will contain multiple exploits demonstrating scenarios wherein this can be remote. Internally (we don't name bugs as that's rather tacky) we affectionately refer to this one as "PerlShock," and it is by far the most critical issue we have discovered in a language to date.
 
To provide an example, it's not uncommon for CGI web apps to save query strings name value pairs as env vars. In this case, the vulnerability would be exploitable through said query string. Though we have no concrete statistics, we have seen this pattern in the wild and thus expect this issue to have real-world ramifications.
 
John
 
--------- Original Message ---------
Subject: [perl #131665] [CVE-2017-12814]Perl $ENV Key Stack Buffer Overflow
From: "Tony Cook via RT" <perl5-security-report-followup@perl.org>
Date: 9/11/17 4:50 pm
To: john@autosectools.com
Cc: andyg@activestate.com, daver@activestate.com

On Fri, 11 Aug 2017 17:52:21 -0700, tonyc wrote:
> On Fri, 11 Aug 2017 03:17:17 -0700, tonyc wrote:
> > I've requested a CVE ID for this issue.
>
> This is CVE-2017-12814.

The details I entered when requesting the CVE ID:

> [Suggested description]
> Will be made public once co-ordinated release is done.
> ------------------------------------------
> [Vulnerability Type]
> Buffer Overflow
>
> ------------------------------------------
> [Vendor of Product]
> Perl5 Porters
> ------------------------------------------
> [Affected Product Code Base]
> perl - 5.005_03 through 5.26
> ------------------------------------------
> [Affected Component]
>
> ------------------------------------------
> [Attack Type]
> Local
>
> ------------------------------------------
> [Impact ]
>
> [+] CVE_Request.Impact_Code_execution
> [-] CVE_Request.Impact_Denial_of_Service
> [-] CVE_Request.Impact_Escalation_of_Privileges
> [-] CVE_Request.Impact_Information_Disclosure
> ------------------------------------------
> [Attack Vectors]
>
> ------------------------------------------
> [Reference ]
>
> ------------------------------------------
> [Discoverer ]
> John Leitch (john@autosectools.com), Bryce Darling (darlingbryce@gmail.com)

Proposed update for the CVE entry once the issue is public (the field names are from the CVE allocation form):

Suggested description:

Stack buffer overflow with crafted environment variable, leading to code execution

Affected components:

CPerlHost::Add() in win32/perlhost.h

Attack vector:

An attacker can provide a long environment variable name
overflowing a stack allocated buffer.

This issue only occurs for Win32 builds of perl.

Discoverer:

John Leitch (john@autosectools.com), Bryce Darling (darlingbryce@gmail.com) (no change)

Affected Product Code Base:

perl - 5.005_03 through 5.26 (no change)

References:

https://rt.perl.org/Public/Bug/Display.html?id=131665

Tony
Subject: Re: [perl #131665] [CVE-2017-12814]Perl $ENV Key Stack Buffer Overflow
From: Tony Cook <tony [...] develop-help.com>
Date: Sat, 23 Sep 2017 11:49:32 +1000
CC: perl5-security-report-followup [...] perl.org, andyg [...] activestate.com, daver [...] activestate.com
To: john [...] autosectools.com
Download (untitled) / with headers
text/plain 4.4k
Yes, custom CGI headers are passed through with the header name upper-cased, - replaced with _ and HTTP_ prefixed. https://tools.ietf.org/html/rfc3875#section-4.1.18 Tony On Fri, Sep 22, 2017 at 06:28:11PM -0700, john@autosectools.com wrote: Show quoted text
> Addendum: a quick search for an example revealed that custom headers may be stored in env: > > https://stackoverflow.com/questions/4007007/how-do-i-access-the-http-header-of-request-in-a-cgi-script > > I will investigate further this weekend, but there's a good chance this is a viable exploitation vector. > > --------- Original Message --------- Subject: RE: [perl #131665] [CVE-2017-12814]Perl $ENV Key Stack Buffer Overflow > From: john@autosectools.com > Date: 9/22/17 6:23 pm > To: perl5-security-report-followup@perl.org > Cc: andyg@activestate.com, daver@activestate.com > > Hi all, > > One quick but important nitpick. This vulnerability is described as a possible stack overflow here: https://metacpan.org/changes/release/SHAY/perl-5.26.1-RC1#%5BCVE-2017-12814%5D-$ENV%7B$key%7D-stack-buffer-overflow-on-Windows > > While it's true that I said this is possibly exploitable depending on context, there is no question that it is a stack overflow, as the exploit PoC demonstrates. Further, I prefixed my exploitability claim with "possibly" solely to avoid speaking in absolutes. I would say this is highly exploitable in most scenarios that expose env keys as attack surface. > > Our main concern here is that people may underestimate the severity, and our advisory will contain multiple exploits demonstrating scenarios wherein this can be remote. Internally (we don't name bugs as that's rather tacky) we affectionately refer to this one as "PerlShock," and it is by far the most critical issue we have discovered in a language to date. > > To provide an example, it's not uncommon for CGI web apps to save query strings name value pairs as env vars. In this case, the vulnerability would be exploitable through said query string. Though we have no concrete statistics, we have seen this pattern in the wild and thus expect this issue to have real-world ramifications. > > John > > --------- Original Message --------- Subject: [perl #131665] [CVE-2017-12814]Perl $ENV Key Stack Buffer Overflow > From: "Tony Cook via RT" <perl5-security-report-followup@perl.org> > Date: 9/11/17 4:50 pm > To: john@autosectools.com > Cc: andyg@activestate.com, daver@activestate.com > > On Fri, 11 Aug 2017 17:52:21 -0700, tonyc wrote:
> > On Fri, 11 Aug 2017 03:17:17 -0700, tonyc wrote:
> > > I've requested a CVE ID for this issue.
> > > > This is CVE-2017-12814.
> > The details I entered when requesting the CVE ID: >
> > [Suggested description] > > Will be made public once co-ordinated release is done. > > ------------------------------------------ > > [Vulnerability Type] > > Buffer Overflow > > > > ------------------------------------------ > > [Vendor of Product] > > Perl5 Porters > > ------------------------------------------ > > [Affected Product Code Base] > > perl - 5.005_03 through 5.26 > > ------------------------------------------ > > [Affected Component] > > > > ------------------------------------------ > > [Attack Type] > > Local > > > > ------------------------------------------ > > [Impact ] > > > > [+] CVE_Request.Impact_Code_execution > > [-] CVE_Request.Impact_Denial_of_Service > > [-] CVE_Request.Impact_Escalation_of_Privileges > > [-] CVE_Request.Impact_Information_Disclosure > > ------------------------------------------ > > [Attack Vectors] > > > > ------------------------------------------ > > [Reference ] > > > > ------------------------------------------ > > [Discoverer ] > > John Leitch (john@autosectools.com), Bryce Darling (darlingbryce@gmail.com)
> > Proposed update for the CVE entry once the issue is public (the field names are from the CVE allocation form): > > Suggested description: > > Stack buffer overflow with crafted environment variable, leading to code execution > > Affected components: > > CPerlHost::Add() in win32/perlhost.h > > Attack vector: > > An attacker can provide a long environment variable name > overflowing a stack allocated buffer. > > This issue only occurs for Win32 builds of perl. > > Discoverer: > > John Leitch (john@autosectools.com), Bryce Darling (darlingbryce@gmail.com) (no change) > > Affected Product Code Base: > > perl - 5.005_03 through 5.26 (no change) > > References: > > https://rt.perl.org/Public/Bug/Display.html?id=131665 > > Tony
CC: john [...] autosectools.com, perl5-security-report-followup [...] perl.org, Andy Grundman <andyg [...] activestate.com>, Dave Rolsky <daver [...] activestate.com>
To: Tony Cook <tony [...] develop-help.com>
Date: Sat, 23 Sep 2017 13:33:29 +0200
From: Sawyer X <xsawyerx [...] gmail.com>
Subject: Re: [perl #131665] [CVE-2017-12814]Perl $ENV Key Stack Buffer Overflow
Download (untitled) / with headers
text/plain 4.6k
Based on this, should we postpone the disclosure of the RT ticket? On 23 September 2017 at 03:49, Tony Cook <tony@develop-help.com> wrote: Show quoted text
> Yes, custom CGI headers are passed through with the header name > upper-cased, - replaced with _ and HTTP_ prefixed. > > https://tools.ietf.org/html/rfc3875#section-4.1.18 > > Tony > > On Fri, Sep 22, 2017 at 06:28:11PM -0700, john@autosectools.com wrote:
>> Addendum: a quick search for an example revealed that custom headers may be stored in env: >> >> https://stackoverflow.com/questions/4007007/how-do-i-access-the-http-header-of-request-in-a-cgi-script >> >> I will investigate further this weekend, but there's a good chance this is a viable exploitation vector. >> >> --------- Original Message --------- Subject: RE: [perl #131665] [CVE-2017-12814]Perl $ENV Key Stack Buffer Overflow >> From: john@autosectools.com >> Date: 9/22/17 6:23 pm >> To: perl5-security-report-followup@perl.org >> Cc: andyg@activestate.com, daver@activestate.com >> >> Hi all, >> >> One quick but important nitpick. This vulnerability is described as a possible stack overflow here: https://metacpan.org/changes/release/SHAY/perl-5.26.1-RC1#%5BCVE-2017-12814%5D-$ENV%7B$key%7D-stack-buffer-overflow-on-Windows >> >> While it's true that I said this is possibly exploitable depending on context, there is no question that it is a stack overflow, as the exploit PoC demonstrates. Further, I prefixed my exploitability claim with "possibly" solely to avoid speaking in absolutes. I would say this is highly exploitable in most scenarios that expose env keys as attack surface. >> >> Our main concern here is that people may underestimate the severity, and our advisory will contain multiple exploits demonstrating scenarios wherein this can be remote. Internally (we don't name bugs as that's rather tacky) we affectionately refer to this one as "PerlShock," and it is by far the most critical issue we have discovered in a language to date. >> >> To provide an example, it's not uncommon for CGI web apps to save query strings name value pairs as env vars. In this case, the vulnerability would be exploitable through said query string. Though we have no concrete statistics, we have seen this pattern in the wild and thus expect this issue to have real-world ramifications. >> >> John >> >> --------- Original Message --------- Subject: [perl #131665] [CVE-2017-12814]Perl $ENV Key Stack Buffer Overflow >> From: "Tony Cook via RT" <perl5-security-report-followup@perl.org> >> Date: 9/11/17 4:50 pm >> To: john@autosectools.com >> Cc: andyg@activestate.com, daver@activestate.com >> >> On Fri, 11 Aug 2017 17:52:21 -0700, tonyc wrote:
>> > On Fri, 11 Aug 2017 03:17:17 -0700, tonyc wrote:
>> > > I've requested a CVE ID for this issue.
>> > >> > This is CVE-2017-12814.
>> >> The details I entered when requesting the CVE ID: >>
>> > [Suggested description] >> > Will be made public once co-ordinated release is done. >> > ------------------------------------------ >> > [Vulnerability Type] >> > Buffer Overflow >> > >> > ------------------------------------------ >> > [Vendor of Product] >> > Perl5 Porters >> > ------------------------------------------ >> > [Affected Product Code Base] >> > perl - 5.005_03 through 5.26 >> > ------------------------------------------ >> > [Affected Component] >> > >> > ------------------------------------------ >> > [Attack Type] >> > Local >> > >> > ------------------------------------------ >> > [Impact ] >> > >> > [+] CVE_Request.Impact_Code_execution >> > [-] CVE_Request.Impact_Denial_of_Service >> > [-] CVE_Request.Impact_Escalation_of_Privileges >> > [-] CVE_Request.Impact_Information_Disclosure >> > ------------------------------------------ >> > [Attack Vectors] >> > >> > ------------------------------------------ >> > [Reference ] >> > >> > ------------------------------------------ >> > [Discoverer ] >> > John Leitch (john@autosectools.com), Bryce Darling (darlingbryce@gmail.com)
>> >> Proposed update for the CVE entry once the issue is public (the field names are from the CVE allocation form): >> >> Suggested description: >> >> Stack buffer overflow with crafted environment variable, leading to code execution >> >> Affected components: >> >> CPerlHost::Add() in win32/perlhost.h >> >> Attack vector: >> >> An attacker can provide a long environment variable name >> overflowing a stack allocated buffer. >> >> This issue only occurs for Win32 builds of perl. >> >> Discoverer: >> >> John Leitch (john@autosectools.com), Bryce Darling (darlingbryce@gmail.com) (no change) >> >> Affected Product Code Base: >> >> perl - 5.005_03 through 5.26 (no change) >> >> References: >> >> https://rt.perl.org/Public/Bug/Display.html?id=131665 >> >> Tony
To: Sawyer X <xsawyerx [...] gmail.com>
CC: john [...] autosectools.com, perl5-security-report-followup [...] perl.org, Andy Grundman <andyg [...] activestate.com>, Dave Rolsky <daver [...] activestate.com>
Date: Mon, 25 Sep 2017 10:13:42 +1000
Subject: Re: [perl #131665] [CVE-2017-12814]Perl $ENV Key Stack Buffer Overflow
From: Tony Cook <tony [...] develop-help.com>
Download (untitled) / with headers
text/plain 1.6k
On Sat, Sep 23, 2017 at 01:33:29PM +0200, Sawyer X wrote: Show quoted text
> Based on this, should we postpone the disclosure of the RT ticket? > > On 23 September 2017 at 03:49, Tony Cook <tony@develop-help.com> wrote:
> > Yes, custom CGI headers are passed through with the header name > > upper-cased, - replaced with _ and HTTP_ prefixed. > > > > https://tools.ietf.org/html/rfc3875#section-4.1.18
No, it's an obvious consequence of the now public patch. 5.26.1/5.24.3 (and 5.27.4) have been released so we can't change the description in those releases. We can go back and change the relevant perldeltas in maint-5.24. maint-5.26 and blead (in blead so the 5.28.0 perldelta gets the better description.) Here's a possible replacement pod section: Show quoted text
>>
=head2 [CVE-2017-12814] C<$ENV{$key}> stack buffer overflow on Windows A very long environment variable would produce a buffer overflow on a stack allocated buffer. This has been leveraged into local code execution. If the environment variable was remotely sourced, such as with CGI, this could indirectly lead to remote code execution. L<[perl #131665]|https://rt.perl.org/Public/Bug/Display.html?id=131665> << John, did my updated CVE details get through to you, and do you think they covered the issue adequately? Repeated below: Show quoted text
>>
Suggested description: Stack buffer overflow with crafted environment variable, leading to code execution. Affected components: CPerlHost::Add() in win32/perlhost.h Attack vector: An attacker can provide a long environment variable name overflowing a stack allocated buffer. This issue only occurs for Win32 builds of perl. << Tony (Something in the formatting has messed up RT's rendering of the ticket history.)
Subject: Re: [perl #131665] [CVE-2017-12814]Perl $ENV Key Stack Buffer Overflow
From: Tony Cook <tony [...] develop-help.com>
Date: Mon, 25 Sep 2017 10:26:58 +1000
CC: john [...] autosectools.com, perl5-security-report-followup [...] perl.org, Andy Grundman <andyg [...] activestate.com>, Dave Rolsky <daver [...] activestate.com>
To: Sawyer X <xsawyerx [...] gmail.com>
Download (untitled) / with headers
text/plain 338b
On Mon, Sep 25, 2017 at 10:13:42AM +1000, Tony Cook wrote: Show quoted text
> =head2 [CVE-2017-12814] C<$ENV{$key}> stack buffer overflow on Windows > > A very long environment variable would produce a buffer overflow on a > stack allocated buffer. This has been leveraged into local code > execution.
Urr, "On Win32, " at the beginning of that. Tony
Date: Sun, 24 Sep 2017 17:27:52 -0700
To: perl5-security-report-followup [...] perl.org
CC: andyg [...] activestate.com, daver [...] activestate.com
From: John Leitch <john [...] autosectools.com>
Subject: Re: [perl #131665] [CVE-2017-12814]Perl $ENV Key Stack Buffer Overflow
Looks good. Unfortunately, I got sucked into another project and didn't get a chance to do any testing this weekend, but alpha upper shellcode encoders are publicly available. Given that, there's a good chance this is exploitable through the CGI vector despite the constraints. John On 9/24/2017 05:14 PM, Tony Cook via RT wrote: Show quoted text
> On Sat, Sep 23, 2017 at 01:33:29PM +0200, Sawyer X wrote:
>> Based on this, should we postpone the disclosure of the RT ticket? >> >> On 23 September 2017 at 03:49, Tony Cook <tony@develop-help.com> wrote:
>>> Yes, custom CGI headers are passed through with the header name >>> upper-cased, - replaced with _ and HTTP_ prefixed. >>> >>> https://tools.ietf.org/html/rfc3875#section-4.1.18
> No, it's an obvious consequence of the now public patch. > > 5.26.1/5.24.3 (and 5.27.4) have been released so we can't change the > description in those releases. > > We can go back and change the relevant perldeltas in > maint-5.24. maint-5.26 and blead (in blead so the 5.28.0 perldelta > gets the better description.) > > Here's a possible replacement pod section: > > =head2 [CVE-2017-12814] C<$ENV{$key}> stack buffer overflow on Windows > > A very long environment variable would produce a buffer overflow on a > stack allocated buffer. This has been leveraged into local code > execution. > > If the environment variable was remotely sourced, such as with CGI, > this could indirectly lead to remote code execution. > > L<[perl #131665]|https://rt.perl.org/Public/Bug/Display.html?id=131665> > > << > > John, did my updated CVE details get through to you, and do you think > they covered the issue adequately? Repeated below: > > Suggested description: > > Stack buffer overflow with crafted environment variable, leading to code execution. > > Affected components: > > CPerlHost::Add() in win32/perlhost.h > > Attack vector: > > An attacker can provide a long environment variable name overflowing a > stack allocated buffer. > > This issue only occurs for Win32 builds of perl. > > << > > Tony > > (Something in the formatting has messed up RT's rendering of the > ticket history.) > > >
RT-Send-CC: perl5-porters [...] perl.org
Now public.
Subject: Re: [perl #131665] [CVE-2017-12814]Perl $ENV Key Stack Buffer Overflow
From: Tony Cook <tony [...] develop-help.com>
Date: Tue, 26 Sep 2017 09:34:41 +1000
CC: ;, perl5-porters [...] perl.org
To: Sawyer X via RT <perlbug-followup [...] perl.org>
Download (untitled) / with headers
text/plain 119b
On Mon, Sep 25, 2017 at 03:12:23AM -0700, Sawyer X via RT wrote: Show quoted text
> Now public.
Update to CVE details submitted. Tony


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

For issues related to this RT instance (aka "perlbug"), please contact perlbug-admin at perl.org