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

Owner: Nobody
Requestors: eyal.itkin [at] gmail.com
Cc:
AdminCc:

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



From: Eyal Itkin <eyal.itkin [...] gmail.com>
To: perl5-security-report [...] perl.org
Date: Sat, 6 May 2017 01:01:21 +0300
Subject: Vulnerability report - perl sprintf implementation
Download (untitled) / with headers
text/plain 3.7k
Hello,

In a security audit to the sprintf implementation in perl (version 5.24.1) I found a major security vulnerability, here are the full details:

Technical Details:
file: sv.c
function: Perl_sv_vcatpvfn_flags

  • precis - represents a format's precision, and can be any size_t value
  • width - represents the format's width, and can be any non-negative size_t value
  • Using large values can cause multiple Integer-Overflows when calculating 'need' = the needed allocated space for a fraction
    • line 12300:        need += has_precis ? precis : 6; /* known default */
    • later on more values are added to need (need += 20, ...)
  • Later on the use of 'width' for padding with spaces assumes that there is enough space in the buffer, causing a Buffer Overflow

PoC Script:

print sprintf("%2000.2000f this is a spacer %4000.4294967245a", 1, 0x0.00008234p+9);

Crash trace - tested on a 32 bit linux machine:

Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x080ebbe0 in Perl_runops_standard ()
(gdb) bt
#0  0x080ebbe0 in Perl_runops_standard ()
#1  0x08069356 in S_fold_constants ()
#2  0x080a8336 in Perl_yyparse ()
#3  0x08083219 in perl_parse ()
#4  0x0806218c in main ()
(gdb) info reg
eax            0x20202020    538976288
ecx            0x9f72900    167192832
edx            0x0    0
ebx            0x0    0
esp            0xbfe0e8c0    0xbfe0e8c0
ebp            0x9f6c4d0    0x9f6c4d0
esi            0x9f6f58c    167179660
edi            0x0    0
eip            0x80ebbe0    0x80ebbe0 <Perl_runops_standard+16>
eflags         0x10202    [ IF RF ]
cs             0x73    115
ss             0x7b    123
ds             0x7b    123
es             0x7b    123
fs             0x0    0
gs             0x33    51
(gdb) x /10i $eip
=> 0x80ebbe0 <Perl_runops_standard+16>:    call   *0x8(%eax)
   0x80ebbe3 <Perl_runops_standard+19>:    test   %eax,%eax
   0x80ebbe5 <Perl_runops_standard+21>:    mov    %eax,0x8207a88
   0x80ebbea <Perl_runops_standard+26>:   
    jne    0x80ebbe0 <Perl_runops_standard+16>
   0x80ebbec <Perl_runops_standard+28>:    mov    0x8207290,%eax
   0x80ebbf1 <Perl_runops_standard+33>:    test   %eax,%eax
   0x80ebbf3 <Perl_runops_standard+35>:   
    jne    0x80ebc02 <Perl_runops_standard+50>
   0x80ebbf5 <Perl_runops_standard+37>:    movb   $0x0,0x82072b0
   0x80ebbfc <Perl_runops_standard+44>:    xor    %eax,%eax
   0x80ebbfe <Perl_runops_standard+46>:    add    $0xc,%esp

As you can see, the first %f print enlarged the buffer, and the controllable width in the second overflowed the buffer, causing eax to be corrupt (0x20 == ' ').

Threat Analysis:

This report demonstrates a potential code execution vulnerability, in case a sprintf format will be hostile. As format string attacks are relatively more popular on C/C++ languages, they are caused by the same programming bad practices:

  • "Generic" logging \ monitoring module that receives format + args, and build the message string
Such kind of vulnerabilities are still common in modern code projects, and during my career I found such vulnerabilities even in many high-profile companies. Since Perl (such as Python, and Ruby) is a memory-managed language, the programmer relies on the interpreter to "catch" problems for him, meaning that most programmers assume that these programs won't be vulnerable to format string attacks.

Conclusion:
The sprintf implementation has a severe vulnerability when handling a hostile format string. This vulnerability was demonstrated and can be easily leveraged into a remote code execution on the Perl interpreter (as I demonstrated last month in a similar vulnerability in the MRuby project).

In case there are any questions regarding the vulnerability or the report, I will be more than happy to help.
Thanks for your attention,
Eyal Itkin.
Date: Mon, 8 May 2017 18:17:27 +0100
To: perl5-security-report [...] perl.org
From: Dave Mitchell <davem [...] iabyn.com>
Subject: Re: [perl #131260] Vulnerability report - perl sprintf implementation
Download (untitled) / with headers
text/plain 3.7k
On Fri, May 05, 2017 at 03:01:51PM -0700, Eyal Itkin wrote: Show quoted text
> In a security audit to the sprintf implementation in perl (version 5.24.1) > I found a major security vulnerability, here are the full details:
The same vulnerability persists in blead. Here is my provisional analysis. This function, Perl_sv_vcatpvfn_flags, is perl's lowest-level sprintf-ish function: all the others call this. It is a huge sprawling mess of code, with about 1700 lines and 36 goto's to 11 labels. There appear to be three places within that function where memory is allocated and could thus potentially under-allocate if the 'needed' calculations wrapped at some point. Of these, The main SvGROW() allocates extra space in the output string to append the next element, including any sign, padding, zeros etc. This appears to be safe from wrapping. A second SvGROW() is used when appending a bad format element as-is, e.g. ""%7. 6s". Triggering a wrap here would require the output-so-far plus the length of the malformed format segment to wrap, which is improbable and almost certainly impossible. Finally, a Newx(PL_efloatbuf, PL_efloatsize, char) is done for floating-point-related format elements. That is the one for which a buffer overrun is demonstrated in this ticket. Given the complexity of this function, it's possible that the description above is incomplete. But for the rest of this email I'll only discuss the third case above. When dealing with floating-point formats like e/f/g/a, perl allocates a buffer big enough to hold the actual stringified numerical value. Later, this buffer is appended to the output SV along with any padding, sign etc. As the OP points out, there are a number of calculations done to determine the needed size of PL_efloatbuf, which rely on the (possibly hostile) width and precision values in the "%NNN.PPPf" format, and many of these calculations can overflow, leading to an under-allocated PL_efloatbuf. This means that part of the f/p string will be written beyond the end of PL_efloatbuf. It's not possible write arbitrary data, but any sequence of bytes mainly from the set /[0-9 ep+\-]/, with long runs of 0x20's or 0x30's easily selectable by varying the width and precision. As the OP demonstrated, it's possible to overrun a PL_op->op_ppaddr field or similar, corrupting the address of a function to call. In the case of the OP, this resulting in trying to call the function at the address 0x202020..., and the inevitable crash. So this is bad, but the question is how bad. Obviously, any badly-written logging code which accepts a hostile sprintf format string and possibly hostile sprintf args, is already broken even if perl's sprintf implementation was bug-free, with hostile widths and precison allowing the attacker to force the perl executable to consume as much memory as the attacker desired, or to cause the perl process to die with an "out of memory" error or similar. Or to fill up a log file. But with a buggy perl implementation, this could cause an existing DoS situation to escalate to something worse. My gut feeling is that given the limited "palette" of byte values that could be used to overwrite the end of the buffer, it would be hard to achieve an arbitrary code execution. But I'm sure it could do a lot of damage. I will have a patch ready shortly for the specific PL_efloatbuf issues. In the longer term Perl_sv_vcatpvfn_flags() really needs an overhaul to make it simpler to analyse and avoid re-introducing bugs. So in the short term, is this issue serious enough that my patch or similar should be added to branches leading to the 5.26.0, 5.24.2 and 5.22.4 releases, or should it wait? This issue or similar appears to have been present since at least 5.10.0 and probably earlier. -- "You may not work around any technical limitations in the software" -- Windows Vista license
Date: Tue, 9 May 2017 08:24:51 +0100
To: perl5-security-report [...] perl.org
From: Dave Mitchell <davem [...] iabyn.com>
Subject: Re: [perl #131260] Vulnerability report - perl sprintf implementation
Download (untitled) / with headers
text/plain 712b
On Mon, May 08, 2017 at 06:17:27PM +0100, Dave Mitchell wrote: Show quoted text
> So in the short term, is this issue serious enough that my patch or > similar should be added to branches leading to the 5.26.0, 5.24.2 and > 5.22.4 releases, or should it wait? This issue or similar appears to have > been present since at least 5.10.0 and probably earlier.
With the pumpking's consent I've just committed v5.25.12-29-gbd1a29f to blead, which has a basic fix for this issue. This is just before the RC1 release is due. That patch is also suitable for maint-5.22 and maint-5.24. -- Technology is dominated by two types of people: those who understand what they do not manage, and those who manage what they do not understand.
Subject: Re: [perl #131260] Vulnerability report - perl sprintf implementation
Date: Tue, 9 May 2017 11:02:04 +0300
From: Eyal Itkin <eyal.itkin [...] gmail.com>
To: perl5-security-report [...] perl.org
Download (untitled) / with headers
text/plain 1.1k
Thanks for the feedback. I saw the commit in the git and it seems to solve the reported vulnerability.

Please notify me when the commit will be merged to all relevant branches, so I would be able to proceed with the publication to the bug bounty program of perl in hackerOne.

Thanks again for the fast reply.
Eyal 

On May 9, 2017 10:25 AM, "Dave Mitchell via RT" <perl5-security-report@perl.org> wrote:
Show quoted text
On Mon, May 08, 2017 at 06:17:27PM +0100, Dave Mitchell wrote:
> So in the short term, is this issue serious enough that my patch or
> similar should be added to branches leading to the 5.26.0, 5.24.2 and
> 5.22.4 releases, or should it wait? This issue or similar appears to have
> been present since at least 5.10.0 and probably earlier.

With the pumpking's consent I've just committed v5.25.12-29-gbd1a29f to
blead, which has a basic fix for this issue. This is just before the RC1
release is due.

That patch is also suitable for maint-5.22 and maint-5.24.

--
Technology is dominated by two types of people: those who understand what
they do not manage, and those who manage what they do not understand.

Date: Mon, 15 May 2017 11:15:22 +0100
From: Dave Mitchell <davem [...] iabyn.com>
To: perl5-security-report [...] perl.org
CC: steve.m.hay [...] googlemail.com
Subject: Re: [perl #131260] Vulnerability report - perl sprintf implementation
On Tue, May 09, 2017 at 08:24:51AM +0100, Dave Mitchell wrote: Show quoted text
> On Mon, May 08, 2017 at 06:17:27PM +0100, Dave Mitchell wrote:
> > So in the short term, is this issue serious enough that my patch or > > similar should be added to branches leading to the 5.26.0, 5.24.2 and > > 5.22.4 releases, or should it wait? This issue or similar appears to have > > been present since at least 5.10.0 and probably earlier.
> > With the pumpking's consent I've just committed v5.25.12-29-gbd1a29f to > blead, which has a basic fix for this issue. This is just before the RC1 > release is due. > > That patch is also suitable for maint-5.22 and maint-5.24.
Steve, would it be ok for me to cherry-pick these into maint-5.22 and maint-5.24 now? IIUC, 5.24.2 and 5.22.4 are supposed to be security-only releases, but this is a security fix. To everyone else - I'm currently auditing/hardening the code in Perl_sv_vcatpvfn_flags(), with a (not-yet-pushed) branch that I intend to merge into blead post 5.16.09 release (unless I find anything else exceptionally nasty in the meantime. -- A problem shared is a problem doubled.
CC: steve.m.hay [...] googlemail.com
Subject: Re: [perl #131260] Vulnerability report - perl sprintf implementation
From: Karl Williamson <public [...] khwilliamson.com>
To: Dave Mitchell <davem [...] iabyn.com>, perl5-security-report [...] perl.org
Date: Mon, 15 May 2017 09:39:03 -0600
Download (untitled) / with headers
text/plain 1.1k
On 05/15/2017 04:15 AM, Dave Mitchell wrote: Show quoted text
> On Tue, May 09, 2017 at 08:24:51AM +0100, Dave Mitchell wrote:
>> On Mon, May 08, 2017 at 06:17:27PM +0100, Dave Mitchell wrote:
>>> So in the short term, is this issue serious enough that my patch or >>> similar should be added to branches leading to the 5.26.0, 5.24.2 and >>> 5.22.4 releases, or should it wait? This issue or similar appears to have >>> been present since at least 5.10.0 and probably earlier.
>> >> With the pumpking's consent I've just committed v5.25.12-29-gbd1a29f to >> blead, which has a basic fix for this issue. This is just before the RC1 >> release is due. >> >> That patch is also suitable for maint-5.22 and maint-5.24.
> > Steve, would it be ok for me to cherry-pick these into maint-5.22 and > maint-5.24 now? IIUC, 5.24.2 and 5.22.4 are supposed to be security-only > releases, but this is a security fix. > > To everyone else - I'm currently auditing/hardening the code in > Perl_sv_vcatpvfn_flags(), with a (not-yet-pushed) branch that I intend to > merge into blead post 5.16.09 release (unless I find anything else > exceptionally nasty in the meantime. >
I'm trying to grok what '5.16.09' means here, without success.
Subject: Re: [perl #131260] Vulnerability report - perl sprintf implementation
CC: perl5-security-report [...] perl.org, steve.m.hay [...] googlemail.com
Date: Mon, 15 May 2017 16:48:34 +0100
From: Dave Mitchell <davem [...] iabyn.com>
To: Karl Williamson <public [...] khwilliamson.com>
Download (untitled) / with headers
text/plain 1.3k
On Mon, May 15, 2017 at 09:39:03AM -0600, Karl Williamson wrote: Show quoted text
> On 05/15/2017 04:15 AM, Dave Mitchell wrote:
> > On Tue, May 09, 2017 at 08:24:51AM +0100, Dave Mitchell wrote:
> > > On Mon, May 08, 2017 at 06:17:27PM +0100, Dave Mitchell wrote:
> > > > So in the short term, is this issue serious enough that my patch or > > > > similar should be added to branches leading to the 5.26.0, 5.24.2 and > > > > 5.22.4 releases, or should it wait? This issue or similar appears to have > > > > been present since at least 5.10.0 and probably earlier.
> > > > > > With the pumpking's consent I've just committed v5.25.12-29-gbd1a29f to > > > blead, which has a basic fix for this issue. This is just before the RC1 > > > release is due. > > > > > > That patch is also suitable for maint-5.22 and maint-5.24.
> > > > Steve, would it be ok for me to cherry-pick these into maint-5.22 and > > maint-5.24 now? IIUC, 5.24.2 and 5.22.4 are supposed to be security-only > > releases, but this is a security fix. > > > > To everyone else - I'm currently auditing/hardening the code in > > Perl_sv_vcatpvfn_flags(), with a (not-yet-pushed) branch that I intend to > > merge into blead post 5.16.09 release (unless I find anything else > > exceptionally nasty in the meantime. > >
> > I'm trying to grok what '5.16.09' means here, without success.
That's an astoundingly badly typed 5.26.0 -- Monto Blanco... scorchio!
From: Sawyer X <xsawyerx [...] gmail.com>
To: Eyal Itkin <eyal.itkin [...] gmail.com>
Date: Mon, 15 May 2017 23:12:03 +0200
CC: Perl 5 Security Report <perl5-security-report [...] perl.org>
Subject: Re: [perl #131260] Vulnerability report - perl sprintf implementation
Download (untitled) / with headers
text/plain 1.3k
Hi Eyal,

Do you have a CVE number to go along with the disclosure?
(Not all security issues must have a CVE, I'm just wondering if you have one for this.)


On Tue, May 9, 2017 at 10:02 AM, Eyal Itkin <eyal.itkin@gmail.com> wrote:
Show quoted text
Thanks for the feedback. I saw the commit in the git and it seems to solve the reported vulnerability.

Please notify me when the commit will be merged to all relevant branches, so I would be able to proceed with the publication to the bug bounty program of perl in hackerOne.

Thanks again for the fast reply.
Eyal 

On May 9, 2017 10:25 AM, "Dave Mitchell via RT" <perl5-security-report@perl.org> wrote:
On Mon, May 08, 2017 at 06:17:27PM +0100, Dave Mitchell wrote:
> So in the short term, is this issue serious enough that my patch or
> similar should be added to branches leading to the 5.26.0, 5.24.2 and
> 5.22.4 releases, or should it wait? This issue or similar appears to have
> been present since at least 5.10.0 and probably earlier.

With the pumpking's consent I've just committed v5.25.12-29-gbd1a29f to
blead, which has a basic fix for this issue. This is just before the RC1
release is due.

That patch is also suitable for maint-5.22 and maint-5.24.

--
Technology is dominated by two types of people: those who understand what
they do not manage, and those who manage what they do not understand.


From: Eyal Itkin <eyal.itkin [...] gmail.com>
To: perl5-security-report [...] perl.org
Date: Tue, 16 May 2017 09:08:47 +0300
Subject: Re: [perl #131260] Vulnerability report - perl sprintf implementation
Download (untitled) / with headers
text/plain 1.9k
No, I didn't​ issue a CVE id for this vulnerability.

Issuing CVE ids to open source interpreter languages is always tricky, as one cannot know when it will be "good enough". PHP issues CVEs even to simple DoS vulnerabilities, while (C)Ruby will argue all the way that "this is just a simple bug" and won't agree to tag it as a "security" issue.

If you prefer that a CVE id will be assigned to this vulnerability, I can contact MITRE to issue one.

On May 16, 2017 00:12, "Sawyer X via RT" <perl5-security-report@perl.org> wrote:
Show quoted text
Hi Eyal,

Do you have a CVE number to go along with the disclosure?
(Not all security issues must have a CVE, I'm just wondering if you have
one for this.)


On Tue, May 9, 2017 at 10:02 AM, Eyal Itkin <eyal.itkin@gmail.com> wrote:

> Thanks for the feedback. I saw the commit in the git and it seems to solve
> the reported vulnerability.
>
> Please notify me when the commit will be merged to all relevant branches,
> so I would be able to proceed with the publication to the bug bounty
> program of perl in hackerOne.
>
> Thanks again for the fast reply.
> Eyal
>
> On May 9, 2017 10:25 AM, "Dave Mitchell via RT" <
> perl5-security-report@perl.org> wrote:
>
>> On Mon, May 08, 2017 at 06:17:27PM +0100, Dave Mitchell wrote:
>> > So in the short term, is this issue serious enough that my patch or
>> > similar should be added to branches leading to the 5.26.0, 5.24.2 and
>> > 5.22.4 releases, or should it wait? This issue or similar appears to
>> have
>> > been present since at least 5.10.0 and probably earlier.
>>
>> With the pumpking's consent I've just committed v5.25.12-29-gbd1a29f to
>> blead, which has a basic fix for this issue. This is just before the RC1
>> release is due.
>>
>> That patch is also suitable for maint-5.22 and maint-5.24.
>>
>> --
>> Technology is dominated by two types of people: those who understand what
>> they do not manage, and those who manage what they do not understand.
>>
>>

Subject: Re: [perl #131260] Vulnerability report - perl sprintf implementation
CC: Perl 5 Security Report <perl5-security-report [...] perl.org>
Date: Tue, 16 May 2017 11:23:51 +0200
From: Sawyer X <xsawyerx [...] gmail.com>
To: Eyal Itkin <eyal.itkin [...] gmail.com>
Download (untitled) / with headers
text/plain 2.3k
If someone hasn't expressed an opinion that this requires a CVE by now, we are not likely to assign one ourselves. If it did have one, we would have included it in the change log.

Thanks. :)

On Tue, May 16, 2017 at 8:08 AM, Eyal Itkin <eyal.itkin@gmail.com> wrote:
Show quoted text
No, I didn't​ issue a CVE id for this vulnerability.

Issuing CVE ids to open source interpreter languages is always tricky, as one cannot know when it will be "good enough". PHP issues CVEs even to simple DoS vulnerabilities, while (C)Ruby will argue all the way that "this is just a simple bug" and won't agree to tag it as a "security" issue.

If you prefer that a CVE id will be assigned to this vulnerability, I can contact MITRE to issue one.

On May 16, 2017 00:12, "Sawyer X via RT" <perl5-security-report@perl.org> wrote:
Hi Eyal,

Do you have a CVE number to go along with the disclosure?
(Not all security issues must have a CVE, I'm just wondering if you have
one for this.)


On Tue, May 9, 2017 at 10:02 AM, Eyal Itkin <eyal.itkin@gmail.com> wrote:

> Thanks for the feedback. I saw the commit in the git and it seems to solve
> the reported vulnerability.
>
> Please notify me when the commit will be merged to all relevant branches,
> so I would be able to proceed with the publication to the bug bounty
> program of perl in hackerOne.
>
> Thanks again for the fast reply.
> Eyal
>
> On May 9, 2017 10:25 AM, "Dave Mitchell via RT" <
> perl5-security-report@perl.org> wrote:
>
>> On Mon, May 08, 2017 at 06:17:27PM +0100, Dave Mitchell wrote:
>> > So in the short term, is this issue serious enough that my patch or
>> > similar should be added to branches leading to the 5.26.0, 5.24.2 and
>> > 5.22.4 releases, or should it wait? This issue or similar appears to
>> have
>> > been present since at least 5.10.0 and probably earlier.
>>
>> With the pumpking's consent I've just committed v5.25.12-29-gbd1a29f to
>> blead, which has a basic fix for this issue. This is just before the RC1
>> release is due.
>>
>> That patch is also suitable for maint-5.22 and maint-5.24.
>>
>> --
>> Technology is dominated by two types of people: those who understand what
>> they do not manage, and those who manage what they do not understand.
>>
>>


CC: Eyal Itkin <eyal.itkin [...] gmail.com>, perl5-security-report [...] perl.org
Subject: Re: [perl #131260] Vulnerability report - perl sprintf implementation
Date: Wed, 17 May 2017 08:53:29 +0200
From: demerphq <demerphq [...] gmail.com>
To: Sawyer X <xsawyerx [...] gmail.com>
Download (untitled) / with headers
text/plain 2.7k
Personally I would say that the use of untrusted format strings is rare in the perl community and even less likely in hostile environments. Thus it probably doesn't merit a CVE but the core bug class does and if this use case were more common we would want one. 

So I guess we are somewhere in the middle of the Ruby and PHP guys on this subject. 

Yves


On 16 May 2017 11:24, "Sawyer X" <xsawyerx@gmail.com> wrote:
Show quoted text
If someone hasn't expressed an opinion that this requires a CVE by now, we are not likely to assign one ourselves. If it did have one, we would have included it in the change log.

Thanks. :)
On Tue, May 16, 2017 at 8:08 AM, Eyal Itkin <eyal.itkin@gmail.com> wrote:
No, I didn't​ issue a CVE id for this vulnerability.

Issuing CVE ids to open source interpreter languages is always tricky, as one cannot know when it will be "good enough". PHP issues CVEs even to simple DoS vulnerabilities, while (C)Ruby will argue all the way that "this is just a simple bug" and won't agree to tag it as a "security" issue.

If you prefer that a CVE id will be assigned to this vulnerability, I can contact MITRE to issue one.

On May 16, 2017 00:12, "Sawyer X via RT" <perl5-security-report@perl.org> wrote:
Hi Eyal,

Do you have a CVE number to go along with the disclosure?
(Not all security issues must have a CVE, I'm just wondering if you have
one for this.)


On Tue, May 9, 2017 at 10:02 AM, Eyal Itkin <eyal.itkin@gmail.com> wrote:

> Thanks for the feedback. I saw the commit in the git and it seems to solve
> the reported vulnerability.
>
> Please notify me when the commit will be merged to all relevant branches,
> so I would be able to proceed with the publication to the bug bounty
> program of perl in hackerOne.
>
> Thanks again for the fast reply.
> Eyal
>
> On May 9, 2017 10:25 AM, "Dave Mitchell via RT" <
> perl5-security-report@perl.org> wrote:
>
>> On Mon, May 08, 2017 at 06:17:27PM +0100, Dave Mitchell wrote:
>> > So in the short term, is this issue serious enough that my patch or
>> > similar should be added to branches leading to the 5.26.0, 5.24.2 and
>> > 5.22.4 releases, or should it wait? This issue or similar appears to
>> have
>> > been present since at least 5.10.0 and probably earlier.
>>
>> With the pumpking's consent I've just committed v5.25.12-29-gbd1a29f to
>> blead, which has a basic fix for this issue. This is just before the RC1
>> release is due.
>>
>> That patch is also suitable for maint-5.22 and maint-5.24.
>>
>> --
>> Technology is dominated by two types of people: those who understand what
>> they do not manage, and those who manage what they do not understand.
>>
>>



From: Eyal Itkin <eyal.itkin [...] gmail.com>
To: perl5-security-report [...] perl.org
Date: Sun, 28 May 2017 18:27:50 +0300
Subject: Re: [perl #131260] Vulnerability report - perl sprintf implementation
Download (untitled) / with headers
text/plain 3.1k
OK, sounds legit.

Is there a green light to proceed with a disclosure to the Perl hackerOne project? Are all branched were patched with the fix?

Take in notice that the average time for handling a ticket in hackerOne (in IBB projects) is 2 months, and the ticket won't get publicly disclosed without your confirmation.

Thanks again,
Eyal 

On May 17, 2017 09:53, "yves orton via RT" <perl5-security-report@perl.org> wrote:
Show quoted text
Personally I would say that the use of untrusted format strings is rare in
the perl community and even less likely in hostile environments. Thus it
probably doesn't merit a CVE but the core bug class does and if this use
case were more common we would want one.

So I guess we are somewhere in the middle of the Ruby and PHP guys on this
subject.

Yves


On 16 May 2017 11:24, "Sawyer X" <xsawyerx@gmail.com> wrote:

If someone hasn't expressed an opinion that this requires a CVE by now, we
are not likely to assign one ourselves. If it did have one, we would have
included it in the change log.

Thanks. :)
On Tue, May 16, 2017 at 8:08 AM, Eyal Itkin <eyal.itkin@gmail.com> wrote:

> No, I didn't​ issue a CVE id for this vulnerability.
>
> Issuing CVE ids to open source interpreter languages is always tricky, as
> one cannot know when it will be "good enough". PHP issues CVEs even to
> simple DoS vulnerabilities, while (C)Ruby will argue all the way that "this
> is just a simple bug" and won't agree to tag it as a "security" issue.
>
> If you prefer that a CVE id will be assigned to this vulnerability, I can
> contact MITRE to issue one.
>
> On May 16, 2017 00:12, "Sawyer X via RT" <perl5-security-report@perl.org>
> wrote:
>
>> Hi Eyal,
>>
>> Do you have a CVE number to go along with the disclosure?
>> (Not all security issues must have a CVE, I'm just wondering if you have
>> one for this.)
>>
>>
>> On Tue, May 9, 2017 at 10:02 AM, Eyal Itkin <eyal.itkin@gmail.com> wrote:
>>
>> > Thanks for the feedback. I saw the commit in the git and it seems to
>> solve
>> > the reported vulnerability.
>> >
>> > Please notify me when the commit will be merged to all relevant
>> branches,
>> > so I would be able to proceed with the publication to the bug bounty
>> > program of perl in hackerOne.
>> >
>> > Thanks again for the fast reply.
>> > Eyal
>> >
>> > On May 9, 2017 10:25 AM, "Dave Mitchell via RT" <
>> > perl5-security-report@perl.org> wrote:
>> >
>> >> On Mon, May 08, 2017 at 06:17:27PM +0100, Dave Mitchell wrote:
>> >> > So in the short term, is this issue serious enough that my patch or
>> >> > similar should be added to branches leading to the 5.26.0, 5.24.2 and
>> >> > 5.22.4 releases, or should it wait? This issue or similar appears to
>> >> have
>> >> > been present since at least 5.10.0 and probably earlier.
>> >>
>> >> With the pumpking's consent I've just committed v5.25.12-29-gbd1a29f to
>> >> blead, which has a basic fix for this issue. This is just before the
>> RC1
>> >> release is due.
>> >>
>> >> That patch is also suitable for maint-5.22 and maint-5.24.
>> >>
>> >> --
>> >> Technology is dominated by two types of people: those who understand
>> what
>> >> they do not manage, and those who manage what they do not understand.
>> >>
>> >>
>>
>>


CC: "perl5-security-report [...] perl.org" <perl5-security-report [...] perl.org>
Date: Sat, 3 Jun 2017 14:57:56 +0200
From: Leon Timmermans <fawaka [...] gmail.com>
To: Eyal Itkin <eyal.itkin [...] gmail.com>
Subject: Re: [perl #131260] Vulnerability report - perl sprintf implementation
Download (untitled) / with headers
text/plain 506b
Download (untitled) / with headers
text/html 1011b
On Sun, May 28, 2017 at 5:27 PM, Eyal Itkin <eyal.itkin@gmail.com> wrote:
Show quoted text
OK, sounds legit.

Is there a green light to proceed with a disclosure to the Perl hackerOne project? Are all branched were patched with the fix?

Take in notice that the average time for handling a ticket in hackerOne (in IBB projects) is 2 months, and the ticket won't get publicly disclosed without your confirmation.

Thanks again,
Eyal

It doesn't seem to have been backported to 5.24 and 5.22 yet.

Leon
Date: Sat, 3 Jun 2017 16:22:06 +0300
From: Eyal Itkin <eyal.itkin [...] gmail.com>
Subject: Re: [perl #131260] Vulnerability report - perl sprintf implementation
To: perl5-security-report [...] perl.org
Download (untitled) / with headers
text/plain 736b
Thanks for the update.

Please notify me when the patch will be backported to all relevant versions.

On Jun 3, 2017 15:58, "Leon Timmermans via RT" <perl5-security-report@perl.org> wrote:
Show quoted text
On Sun, May 28, 2017 at 5:27 PM, Eyal Itkin <eyal.itkin@gmail.com> wrote:

> OK, sounds legit.
>
> Is there a green light to proceed with a disclosure to the Perl hackerOne
> project? Are all branched were patched with the fix?
>
> Take in notice that the average time for handling a ticket in hackerOne
> (in IBB projects) is 2 months, and the ticket won't get publicly disclosed
> without your confirmation.
>
> Thanks again,
> Eyal
>

It doesn't seem to have been backported to 5.24 and 5.22 yet.

Leon

Date: Wed, 7 Jun 2017 11:23:18 +0100
From: Dave Mitchell <davem [...] iabyn.com>
CC: Eyal Itkin <eyal.itkin [...] gmail.com>, steve.m.hay [...] googlemail.com, "perl5-security-report [...] perl.org" <perl5-security-report [...] perl.org>
Subject: Re: [perl #131260] Vulnerability report - perl sprintf implementation
To: Leon Timmermans <fawaka [...] gmail.com>
Download (untitled) / with headers
text/plain 397b
On Sat, Jun 03, 2017 at 02:57:56PM +0200, Leon Timmermans wrote: Show quoted text
> It doesn't seem to have been backported to 5.24 and 5.22 yet.
Steve never replied to my query as to whether it was ok to backport it. In the meantime, I've just merged my general reworking of Perl_sv_vcatpvfn_flags into blead. -- Diplomacy is telling someone to go to hell in such a way that they'll look forward to the trip
From: Sawyer X <xsawyerx [...] gmail.com>
Date: Wed, 7 Jun 2017 13:02:39 +0200
CC: Leon Timmermans <fawaka [...] gmail.com>, Eyal Itkin <eyal.itkin [...] gmail.com>, Steve Hay <steve.m.hay [...] googlemail.com>, "perl5-security-report [...] perl.org" <perl5-security-report [...] perl.org>
To: Dave Mitchell <davem [...] iabyn.com>
Subject: Re: [perl #131260] Vulnerability report - perl sprintf implementation
Download (untitled) / with headers
text/plain 626b
I think we should backport it. However, Steve is working on 5.24.2 and 5.22.4 which should be focused on the remaining base.pm fix, I believe.

On 7 June 2017 at 12:23, Dave Mitchell <davem@iabyn.com> wrote:
Show quoted text
On Sat, Jun 03, 2017 at 02:57:56PM +0200, Leon Timmermans wrote:
> It doesn't seem to have been backported to 5.24 and 5.22 yet.

Steve never replied to my query as to whether it was ok to backport it.

In the meantime, I've just merged my general reworking of
Perl_sv_vcatpvfn_flags  into blead.

--
Diplomacy is telling someone to go to hell in such a way that they'll
look forward to the trip

RT-Send-CC: rt-deliver-to-perl5-security-report [...] rt.perl.org
Download (untitled) / with headers
text/plain 1.1k
On Wed, 07 Jun 2017 03:23:36 -0700, davem wrote: Show quoted text
> On Sat, Jun 03, 2017 at 02:57:56PM +0200, Leon Timmermans wrote:
> > It doesn't seem to have been backported to 5.24 and 5.22 yet.
> > Steve never replied to my query as to whether it was ok to backport it. > > In the meantime, I've just merged my general reworking of > Perl_sv_vcatpvfn_flags into blead. >
I apologize - I completely missed your question to me. It's probably because an email filter saw it was sent to 'perl5-security-report' and moved the message out of my Inbox to the relevant list folder... I'm afraid I don't read through every message on that (or any other) list. Please feel free to send email to me offlist to draw my attention to anything you fear I maye have missed -- as Karl has just done :-) I don't know exactly where things are with this now, but if you still want to merge anything back to maint-5.2[46] then yes, go ahead as long as at least two other committers have approved. (I doubt another maint-5.22 will get made now.) If it's in blead and ripe for cherry-picking anyway then it can equally go in the voting file instead and I'll pick it up myself in due course.
Subject: Re: [perl #131260] Vulnerability report - perl sprintf implementation
From: Eyal Itkin <eyal.itkin [...] gmail.com>
Date: Fri, 4 Aug 2017 14:41:22 +0300
To: perl5-security-report [...] perl.org, davem [...] iabyn.com
Download (untitled) / with headers
text/plain 1.9k
Thanks for the update.

As steve issued a "green light" for back porting the fixes to 5.2[46], it seems that the code fixes for the format string vulnerability can be closed now in all relevant versions. 

In addition, since the original report of the vulnerability was sent roughly 3 months ago, it would be very appreciated if the fixes will be integrated, and I'll get your approval to disclose the vulnerability to the perl-ibb bounty program through hackerOne. The disclosure won't be a public disclosure, however the Internet Bug Bounty mandates that the ticket will be opened only after the project's security team will approve it.

Thanks again for your cooperation,
Eyal Itkin.

On Fri, Jul 28, 2017 at 8:37 PM, Steve Hay via RT <perl5-security-report@perl.org> wrote:
Show quoted text
On Wed, 07 Jun 2017 03:23:36 -0700, davem wrote:
> On Sat, Jun 03, 2017 at 02:57:56PM +0200, Leon Timmermans wrote:
> > It doesn't seem to have been backported to 5.24 and 5.22 yet.
>
> Steve never replied to my query as to whether it was ok to backport it.
>
> In the meantime, I've just merged my general reworking of
> Perl_sv_vcatpvfn_flags  into blead.
>

I apologize - I completely missed your question to me. It's probably because an email filter saw it was sent to 'perl5-security-report' and moved the message out of my Inbox to the relevant list folder... I'm afraid I don't read through every message on that (or any other) list. Please feel free to send email to me offlist to draw my attention to anything you fear I maye have missed -- as Karl has just done :-)

I don't know exactly where things are with this now, but if you still want to merge anything back to maint-5.2[46] then yes, go ahead as long as at least two other committers have approved. (I doubt another maint-5.22 will get made now.) If it's in blead and ripe for cherry-picking anyway then it can equally go in the voting file instead and I'll pick it up myself in due course.

RT-Send-CC: rt-deliver-to-perl5-security-report [...] rt.perl.org
Download (untitled) / with headers
text/plain 1.4k
On Fri, 28 Jul 2017 10:37:34 -0700, shay wrote: Show quoted text
> On Wed, 07 Jun 2017 03:23:36 -0700, davem wrote:
> > On Sat, Jun 03, 2017 at 02:57:56PM +0200, Leon Timmermans wrote:
> > > It doesn't seem to have been backported to 5.24 and 5.22 yet.
> > > > Steve never replied to my query as to whether it was ok to backport > > it. > > > > In the meantime, I've just merged my general reworking of > > Perl_sv_vcatpvfn_flags into blead. > >
> > I apologize - I completely missed your question to me. It's probably > because an email filter saw it was sent to 'perl5-security-report' and > moved the message out of my Inbox to the relevant list folder... I'm > afraid I don't read through every message on that (or any other) list. > Please feel free to send email to me offlist to draw my attention to > anything you fear I maye have missed -- as Karl has just done :-) > > I don't know exactly where things are with this now, but if you still > want to merge anything back to maint-5.2[46] then yes, go ahead as > long as at least two other committers have approved. (I doubt another > maint-5.22 will get made now.) If it's in blead and ripe for cherry- > picking anyway then it can equally go in the voting file instead and > I'll pick it up myself in due course.
I see this was backported to maint-5.26 as ddb03b72f46eae3c278f28e8758e87b9c98c66a1, but I don't see it in maint-5.24 nor maint-5.22 and I don't see the commits in the votes files. Should it be? Tony
From: Eyal Itkin <eyal.itkin [...] gmail.com>
Subject: Re: [perl #131260] Vulnerability report - perl sprintf implementation
Date: Wed, 23 Aug 2017 11:34:41 +0300
To: perl5-security-report [...] perl.org
I I didn't write the fix, nor did I committed it to 5.26. If you look at the email conversation you could see all of the details regarding the fix.

The bottom line is that it was fixed in 5.26, and the fixes were NOT yet merged to prior versions. Since the backporting was approved, it only takes someone that will issue this backporting and will get it merged and approved.

I do not have the matching permissions for it, and I really hope that someone will merge it already as this issue is open for almost 4 months now...

On Aug 23, 2017 09:15, "Tony Cook via RT" <perl5-security-report@perl.org> wrote:
Show quoted text
On Fri, 28 Jul 2017 10:37:34 -0700, shay wrote:
> On Wed, 07 Jun 2017 03:23:36 -0700, davem wrote:
> > On Sat, Jun 03, 2017 at 02:57:56PM +0200, Leon Timmermans wrote:
> > > It doesn't seem to have been backported to 5.24 and 5.22 yet.
> >
> > Steve never replied to my query as to whether it was ok to backport
> > it.
> >
> > In the meantime, I've just merged my general reworking of
> > Perl_sv_vcatpvfn_flags  into blead.
> >
>
> I apologize - I completely missed your question to me. It's probably
> because an email filter saw it was sent to 'perl5-security-report' and
> moved the message out of my Inbox to the relevant list folder... I'm
> afraid I don't read through every message on that (or any other) list.
> Please feel free to send email to me offlist to draw my attention to
> anything you fear I maye have missed -- as Karl has just done :-)
>
> I don't know exactly where things are with this now, but if you still
> want to merge anything back to maint-5.2[46] then yes, go ahead as
> long as at least two other committers have approved. (I doubt another
> maint-5.22 will get made now.) If it's in blead and ripe for cherry-
> picking anyway then it can equally go in the voting file instead and
> I'll pick it up myself in due course.

I see this was backported to maint-5.26 as ddb03b72f46eae3c278f28e8758e87b9c98c66a1, but I don't see it in maint-5.24 nor maint-5.22 and I don't see the commits in the votes files.

Should it be?

Tony

To: Eyal Itkin <eyal.itkin [...] gmail.com>
From: Steve Hay via perl5-security-report <perl5-security-report [...] perl.org>
Subject: Re: [perl #131260] Vulnerability report - perl sprintf implementation
Date: Wed, 23 Aug 2017 14:09:58 +0100
CC: Perl 5 Security Report <perl5-security-report [...] perl.org>
Download (untitled) / with headers
text/plain 2.5k
Commit ddb03b72f46eae3c278f28e8758e87b9c98c66a1 wasn't a backport to maint-5.26; it was committed before 5.26.0 was released, i.e. before maint-5.26 was even created. I didn't realize this had happened, but I will add it to the maint-5.24 voting file now since there is now a commit to be voting for. (In general, I'm unsure how voting should work on security tickets that aren't public yet...) On 23 August 2017 at 09:34, Eyal Itkin <eyal.itkin@gmail.com> wrote: Show quoted text
> I I didn't write the fix, nor did I committed it to 5.26. If you look at the > email conversation you could see all of the details regarding the fix. > > The bottom line is that it was fixed in 5.26, and the fixes were NOT yet > merged to prior versions. Since the backporting was approved, it only takes > someone that will issue this backporting and will get it merged and > approved. > > I do not have the matching permissions for it, and I really hope that > someone will merge it already as this issue is open for almost 4 months > now... > > On Aug 23, 2017 09:15, "Tony Cook via RT" <perl5-security-report@perl.org> > wrote:
>> >> On Fri, 28 Jul 2017 10:37:34 -0700, shay wrote:
>> > On Wed, 07 Jun 2017 03:23:36 -0700, davem wrote:
>> > > On Sat, Jun 03, 2017 at 02:57:56PM +0200, Leon Timmermans wrote:
>> > > > It doesn't seem to have been backported to 5.24 and 5.22 yet.
>> > > >> > > Steve never replied to my query as to whether it was ok to backport >> > > it. >> > > >> > > In the meantime, I've just merged my general reworking of >> > > Perl_sv_vcatpvfn_flags into blead. >> > >
>> > >> > I apologize - I completely missed your question to me. It's probably >> > because an email filter saw it was sent to 'perl5-security-report' and >> > moved the message out of my Inbox to the relevant list folder... I'm >> > afraid I don't read through every message on that (or any other) list. >> > Please feel free to send email to me offlist to draw my attention to >> > anything you fear I maye have missed -- as Karl has just done :-) >> > >> > I don't know exactly where things are with this now, but if you still >> > want to merge anything back to maint-5.2[46] then yes, go ahead as >> > long as at least two other committers have approved. (I doubt another >> > maint-5.22 will get made now.) If it's in blead and ripe for cherry- >> > picking anyway then it can equally go in the voting file instead and >> > I'll pick it up myself in due course.
>> >> I see this was backported to maint-5.26 as >> ddb03b72f46eae3c278f28e8758e87b9c98c66a1, but I don't see it in maint-5.24 >> nor maint-5.22 and I don't see the commits in the votes files. >> >> Should it be? >> >> Tony >>
>
From: Sawyer X <xsawyerx [...] gmail.com>
Subject: Re: [perl #131260] Vulnerability report - perl sprintf implementation
To: Steve Hay <steve.m.hay [...] googlemail.com>
Date: Wed, 23 Aug 2017 15:12:21 +0200
CC: Eyal Itkin <eyal.itkin [...] gmail.com>, Perl 5 Security Report <perl5-security-report [...] perl.org>
Download (untitled) / with headers
text/plain 2.8k


On 23 August 2017 at 15:09, Steve Hay via perl5-security-report <perl5-security-report@perl.org> wrote:
Show quoted text
Commit ddb03b72f46eae3c278f28e8758e87b9c98c66a1 wasn't a backport to
maint-5.26; it was committed before 5.26.0 was released, i.e. before
maint-5.26 was even created. I didn't realize this had happened, but I
will add it to the maint-5.24 voting file now since there is now a
commit to be voting for. (In general, I'm unsure how voting should
work on security tickets that aren't public yet...)

I presume the security list needs to vote.


 
Show quoted text

On 23 August 2017 at 09:34, Eyal Itkin <eyal.itkin@gmail.com> wrote:
> I I didn't write the fix, nor did I committed it to 5.26. If you look at the
> email conversation you could see all of the details regarding the fix.
>
> The bottom line is that it was fixed in 5.26, and the fixes were NOT yet
> merged to prior versions. Since the backporting was approved, it only takes
> someone that will issue this backporting and will get it merged and
> approved.
>
> I do not have the matching permissions for it, and I really hope that
> someone will merge it already as this issue is open for almost 4 months
> now...
>
> On Aug 23, 2017 09:15, "Tony Cook via RT" <perl5-security-report@perl.org>
> wrote:
>>
>> On Fri, 28 Jul 2017 10:37:34 -0700, shay wrote:
>> > On Wed, 07 Jun 2017 03:23:36 -0700, davem wrote:
>> > > On Sat, Jun 03, 2017 at 02:57:56PM +0200, Leon Timmermans wrote:
>> > > > It doesn't seem to have been backported to 5.24 and 5.22 yet.
>> > >
>> > > Steve never replied to my query as to whether it was ok to backport
>> > > it.
>> > >
>> > > In the meantime, I've just merged my general reworking of
>> > > Perl_sv_vcatpvfn_flags  into blead.
>> > >
>> >
>> > I apologize - I completely missed your question to me. It's probably
>> > because an email filter saw it was sent to 'perl5-security-report' and
>> > moved the message out of my Inbox to the relevant list folder... I'm
>> > afraid I don't read through every message on that (or any other) list.
>> > Please feel free to send email to me offlist to draw my attention to
>> > anything you fear I maye have missed -- as Karl has just done :-)
>> >
>> > I don't know exactly where things are with this now, but if you still
>> > want to merge anything back to maint-5.2[46] then yes, go ahead as
>> > long as at least two other committers have approved. (I doubt another
>> > maint-5.22 will get made now.) If it's in blead and ripe for cherry-
>> > picking anyway then it can equally go in the voting file instead and
>> > I'll pick it up myself in due course.
>>
>> I see this was backported to maint-5.26 as
>> ddb03b72f46eae3c278f28e8758e87b9c98c66a1, but I don't see it in maint-5.24
>> nor maint-5.22 and I don't see the commits in the votes files.
>>
>> Should it be?
>>
>> Tony
>>
>

Subject: Re: [perl #131260] Vulnerability report - perl sprintf implementation
From: Tony Cook <tony [...] develop-help.com>
CC: Steve Hay <steve.m.hay [...] googlemail.com>, Eyal Itkin <eyal.itkin [...] gmail.com>, Perl 5 Security Report <perl5-security-report [...] perl.org>
Date: Wed, 23 Aug 2017 23:52:26 +1000
To: Sawyer X <xsawyerx [...] gmail.com>
Download (untitled) / with headers
text/plain 886b
On Wed, Aug 23, 2017 at 03:12:21PM +0200, Sawyer X wrote: Show quoted text
> On 23 August 2017 at 15:09, Steve Hay via perl5-security-report < > perl5-security-report@perl.org> wrote: >
> > Commit ddb03b72f46eae3c278f28e8758e87b9c98c66a1 wasn't a backport to > > maint-5.26; it was committed before 5.26.0 was released, i.e. before > > maint-5.26 was even created. I didn't realize this had happened, but I > > will add it to the maint-5.24 voting file now since there is now a > > commit to be voting for. (In general, I'm unsure how voting should > > work on security tickets that aren't public yet...) > >
> > I presume the security list needs to vote.
The commit is public, so we can vote on it. Since the commit is public, we could probably make this ticket public, but it might be nice to hold off on that until it's in a 5.24.x release. We can then both make it public and resolve it. Tony
Subject: Re: [perl #131260] Vulnerability report - perl sprintf implementation
From: Steve Hay via perl5-security-report <perl5-security-report [...] perl.org>
CC: Sawyer X <xsawyerx [...] gmail.com>, Eyal Itkin <eyal.itkin [...] gmail.com>, Perl 5 Security Report <perl5-security-report [...] perl.org>
Date: Wed, 23 Aug 2017 22:05:53 +0100
To: Tony Cook <tony [...] develop-help.com>
Download (untitled) / with headers
text/plain 1.1k
On 23 August 2017 at 14:52, Tony Cook <tony@develop-help.com> wrote: Show quoted text
> On Wed, Aug 23, 2017 at 03:12:21PM +0200, Sawyer X wrote:
>> On 23 August 2017 at 15:09, Steve Hay via perl5-security-report < >> perl5-security-report@perl.org> wrote: >>
>> > Commit ddb03b72f46eae3c278f28e8758e87b9c98c66a1 wasn't a backport to >> > maint-5.26; it was committed before 5.26.0 was released, i.e. before >> > maint-5.26 was even created. I didn't realize this had happened, but I >> > will add it to the maint-5.24 voting file now since there is now a >> > commit to be voting for. (In general, I'm unsure how voting should >> > work on security tickets that aren't public yet...) >> >
>> >> I presume the security list needs to vote.
> > The commit is public, so we can vote on it. > > Since the commit is public, we could probably make this ticket public, > but it might be nice to hold off on that until it's in a 5.24.x > release. > > We can then both make it public and resolve it. >
I've now added the commit to the 5.24 voting file. Note that wIth 5.26.1 due imminently (though other security fixes are possibly needed for it too), it's likely that 5.24.3 won't be released until late September / early October.
RT-Send-CC: rt-deliver-to-perl5-security-report [...] rt.perl.org
Download (untitled) / with headers
text/plain 1.4k
On Wed, 23 Aug 2017 14:06:02 -0700, shay wrote: Show quoted text
> On 23 August 2017 at 14:52, Tony Cook <tony@develop-help.com> wrote:
> > On Wed, Aug 23, 2017 at 03:12:21PM +0200, Sawyer X wrote:
> >> On 23 August 2017 at 15:09, Steve Hay via perl5-security-report < > >> perl5-security-report@perl.org> wrote: > >>
> >> > Commit ddb03b72f46eae3c278f28e8758e87b9c98c66a1 wasn't a backport to > >> > maint-5.26; it was committed before 5.26.0 was released, i.e. before > >> > maint-5.26 was even created. I didn't realize this had happened, but I > >> > will add it to the maint-5.24 voting file now since there is now a > >> > commit to be voting for. (In general, I'm unsure how voting should > >> > work on security tickets that aren't public yet...) > >> >
> >> > >> I presume the security list needs to vote.
> > > > The commit is public, so we can vote on it. > > > > Since the commit is public, we could probably make this ticket public, > > but it might be nice to hold off on that until it's in a 5.24.x > > release. > > > > We can then both make it public and resolve it. > >
> > I've now added the commit to the 5.24 voting file. > > Note that wIth 5.26.1 due imminently (though other security fixes are > possibly needed for it too), it's likely that 5.24.3 won't be released > until late September / early October.
Update: This commit is now in the maint-5.24 branch, so we're just waiting for a 5.24.3 release now - hopefully around a month or so from now.
Date: Wed, 29 Nov 2017 09:16:01 +0000
To: Eyal Itkin <eyal.itkin [...] gmail.com>
CC: perl5-security-report [...] perl.org
Subject: Re: [perl #131260] Vulnerability report - perl sprintf implementation
From: Dave Mitchell <davem [...] iabyn.com>
On Fri, Aug 04, 2017 at 02:41:22PM +0300, Eyal Itkin wrote: Show quoted text
> Thanks for the update. > > As steve issued a "green light" for back porting the fixes to 5.2[46], it > seems that the code fixes for the format string vulnerability can be closed > now in all relevant versions.
As far as I'm aware, the fix has now been backported and released in all maintenence versions of perl. Show quoted text
> In addition, since the original report of the vulnerability was sent > roughly 3 months ago, it would be very appreciated if the fixes will be > integrated, and I'll get your approval to disclose the vulnerability to the > perl-ibb bounty program through hackerOne. The disclosure won't be a public > disclosure, however the Internet Bug Bounty mandates that the ticket will > be opened only after the project's security team will approve it.
I am happy for the bug to be disclosed to perl-ibb. I'll also shortly mark this ticket as resolved and move it to the public queue. -- "I do not resent criticism, even when, for the sake of emphasis, it parts for the time with reality". -- Winston Churchill, House of Commons, 22nd Jan 1941.


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