Skip Menu |
Report information
Id: 127834
Status: open
Priority: 0/
Queue: perl5

Owner: Nobody
Requestors: carnil [at] debian.org
fw [at] deneb.enyo.de
lightsey [at] debian.org
TODDR <toddr [at] cpan.org>
Cc: aristotle <pagaltzis [at] gmx.de>
dom <dom [at] earth.li>
ntyni [at] debian.org
AdminCc:

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

Attachments
0001-perl-127834-remove-.-from-the-end-of-INC-if-complex-.patch
0001-Set-INC-for-generated-classes.patch
0002-perl-127834-bump-versions-of-modules-in-dists-we-upd.patch
0003-perl5db.pl-ensure-PadWalker-is-loaded-from-standard-.patch
0004-perl5db.pl-bump-perldb-VERSION.patch
0005-dist-remove-.-from-INC-when-loading-optional-modules.patch
0006-dist-bump-VERSION-as-needed.patch
0007-cpan-remove-.-from-INC-when-loading-optional-modules.patch
0008-cpan-bump-VERSION-as-needed.patch
maint-5.22-dot-in-inc.patch
maint-5.24-dot-in-inc.patch
perl_inc.stap
signature.asc
smime.p7s



Subject: Flaws in Perl code due to unsafe module load path
Date: Mon, 04 Apr 2016 22:22:56 -0500
From: John Lightsey <lightsey [...] debian.org>
To: team [...] security.debian.org, perl5-security-report [...] perl.org, Todd Rinaldo <toddr [...] cpanel.net>
Download (untitled) / with headers
text/plain 3.9k
Hi there, I need some guidance from the Perl and Debian security teams on how to handle vulnerabilities related to Perl's inclusion of the current working directory in its default module load path. Todd raised this issue on the p5p list in 2012 when he was updating cPanel to Perl 5.14. The cPanel Security Team (my day job) took note of the problem late last year while we were auditing for local file read and write attacks. The problem was pervasive in cPanel's codebase and we resolved the issues with the assumption that this was a well established Perl behavior and cPanel's code was responsible for mitigating the risks. This work led to the discovery of several other interesting flaws in open source code and we've been working with the upstream authors to get those resolved. I started putting together a conference talk to summarize all of the work cPanel had put into this effort, the flaws we found and the tools we used. At that same time, Todd was putting together a patch submission to revisit the 2012 decision to leave the '.' in @INC in Perl. The more we've looked at this problem though, the more convinced we've become that this needs to be handled and resolved as a vulnerability in Perl itself. The major problem with this behavior is that it unexpectedly puts a user at risk whenever they execute any Perl scripts from a directory that is writable by other accounts on the system. For instance, if I'm logged in as root and I change directory into /tmp or an account's home directory, I can run any shell commands that are written in C, Python or Ruby without fear. The same isn't true for any shell commands that are written in Perl, since a significant proportion of Perl scripts will execute code in the current working directory whenever they are run. For example, if a user on a shared system creates the file /tmp/Pod/Perldoc/Toterm.pm, and then I log in as root, change directory to /tmp, and run "perldoc perlrun", it will execute the code they have placed in the file. The most severe example I've found on Debian is that apt-get will load and execute the /tmp/Log/Agent.pm file regardless of the directory it is started from since it automatically changes directory to /tmp. To reproduce this: mkdir -p /tmp/Log echo '`wall hello`;die;' >/tmp/Log/Agent.pm sudo apt-get update A very simplistic analysis of my personal Debian laptop shows that over 40% of the perl scripts have this behavior. You can run the same analysis with this ugly shell command: grep '^#!/usr/bin/perl' /usr/*bin/* | cut -d ':' -f 1 | xargs -n1 /bin/sh -c 'TEST="$0"; if [ "`strace -f perl -c \"$TEST\" 2>&1 | grep '\''stat(\"\..*\.pm\"'\''`" != "" ] ; then echo "Vulnerable: $TEST"; else echo "Not vulnerable: $TEST"; fi' Or to test an individual script you can do something like this: strace -f /usr/bin/perldoc perldoc 2>&1 | grep 'stat("\..*\.pm"' This kind of analysis definitely underestimates the number of affected scripts though. So...with all that explanation said... My question is, which codebase is supposed to fix this issue? I figure there are four possible answers to which piece of code was responsible for preventing these types of attacks: 1) The Perl interpreter for placing the '.' in @INC. 2) Any module that fails to remove the '.' from @INC before attempting to load other modules that are not specified as hard requirements. 3) Any script that loads any modules that end up exhibiting this behavior. 4) End users must avoid running Perl scripts in directories that other users can modify. The only vulnerable code is code that moves to an unsafe location on its own. At cPanel we started off with approach #3, then ended up leaning towards #1. I can probably provide a fairly good list of places that need to be fixed in Debian once I know exactly where to focus. I haven't contacted Debian's Perl team about this problem. Please CC whoever should be informed from that team if they are not already on the perl-security or debian-security lists.
Download signature.asc
application/pgp-signature 819b

Message body not shown because it is not plain text.

Date: Tue, 05 Apr 2016 08:59:46 +0200
From: Florian Weimer <fw [...] deneb.enyo.de>
To: John Lightsey <lightsey [...] debian.org>
CC: team [...] security.debian.org, perl5-security-report [...] perl.org, Todd Rinaldo <toddr [...] cpanel.net>
Subject: Re: Flaws in Perl code due to unsafe module load path
Download (untitled) / with headers
text/plain 663b
* John Lightsey: Show quoted text
> So...with all that explanation said... My question is, which codebase > is supposed to fix this issue? I figure there are four possible answers > to which piece of code was responsible for preventing these types of > attacks: > > 1) The Perl interpreter for placing the '.' in @INC.
'.' in @INC is certainly handy for development, so that you can access modules from the same directory as your script. Maybe it could make sense to extract the full path to the executable and use that? This would still put at risk applications which write temporary scripts to locations such as /tmp and /var/tmp, but it would cover more common scenarios.
CC: "bugs-bitbucket [...] rt.perl.org" <bugs-bitbucket [...] rt.perl.org>
Subject: Re: [perl #127834] Flaws in Perl code due to unsafe module load path
Date: Tue, 5 Apr 2016 09:21:21 +0200
From: demerphq <demerphq [...] gmail.com>
To: "perl5-security-report [...] perl.org" <perl5-security-report [...] perl.org>
Download (untitled) / with headers
text/plain 4.6k
Maybe we should handle this with a command line operation. So perl -Q script.pl would not add ".". People that want to write scripts that dont use the cwd could add the -Q to the shebang line. I hate to make security opt-in tho. Yves On 5 April 2016 at 05:23, John Lightsey <perl5-security-report@perl.org> wrote: Show quoted text
> # New Ticket Created by John Lightsey > # Please include the string: [perl #127834] > # in the subject line of all future correspondence about this issue. > # <URL: https://rt.perl.org/Ticket/Display.html?id=127834 > > > > Hi there, > > I need some guidance from the Perl and Debian security teams on how to > handle vulnerabilities related to Perl's inclusion of the current > working directory in its default module load path. > > Todd raised this issue on the p5p list in 2012 when he was updating > cPanel to Perl 5.14. The cPanel Security Team (my day job) took note of > the problem late last year while we were auditing for local file read > and write attacks. The problem was pervasive in cPanel's codebase and > we resolved the issues with the assumption that this was a well > established Perl behavior and cPanel's code was responsible for > mitigating the risks. This work led to the discovery of several other > interesting flaws in open source code and we've been working with the > upstream authors to get those resolved. > > I started putting together a conference talk to summarize all of the > work cPanel had put into this effort, the flaws we found and the tools > we used. At that same time, Todd was putting together a patch > submission to revisit the 2012 decision to leave the '.' in @INC in > Perl. The more we've looked at this problem though, the more convinced > we've become that this needs to be handled and resolved as a > vulnerability in Perl itself. > > The major problem with this behavior is that it unexpectedly puts a > user at risk whenever they execute any Perl scripts from a directory > that is writable by other accounts on the system. For instance, if I'm > logged in as root and I change directory into /tmp or an account's home > directory, I can run any shell commands that are written in C, Python > or Ruby without fear. The same isn't true for any shell commands that > are written in Perl, since a significant proportion of Perl scripts > will execute code in the current working directory whenever they are > run. > > For example, if a user on a shared system creates the file > /tmp/Pod/Perldoc/Toterm.pm, and then I log in as root, change directory > to /tmp, and run "perldoc perlrun", it will execute the code they have > placed in the file. > > The most severe example I've found on Debian is that apt-get will load > and execute the /tmp/Log/Agent.pm file regardless of the directory it > is started from since it automatically changes directory to /tmp. To > reproduce this: > > mkdir -p /tmp/Log > echo '`wall hello`;die;' >/tmp/Log/Agent.pm > sudo apt-get update > > > A very simplistic analysis of my personal Debian laptop shows that over > 40% of the perl scripts have this behavior. You can run the same > analysis with this ugly shell command: > > grep '^#!/usr/bin/perl' /usr/*bin/* | cut -d ':' -f 1 | xargs -n1 > /bin/sh -c 'TEST="$0"; if [ "`strace -f perl -c \"$TEST\" 2>&1 | grep > '\''stat(\"\..*\.pm\"'\''`" != "" ] ; then echo "Vulnerable: $TEST"; > else echo "Not vulnerable: $TEST"; fi' > > Or to test an individual script you can do something like this: > > strace -f /usr/bin/perldoc perldoc 2>&1 | grep 'stat("\..*\.pm"' > > > This kind of analysis definitely underestimates the number of affected > scripts though. > > > So...with all that explanation said... My question is, which codebase > is supposed to fix this issue? I figure there are four possible answers > to which piece of code was responsible for preventing these types of > attacks: > > 1) The Perl interpreter for placing the '.' in @INC. > > 2) Any module that fails to remove the '.' from @INC before attempting > to load other modules that are not specified as hard requirements. > > 3) Any script that loads any modules that end up exhibiting this > behavior. > > 4) End users must avoid running Perl scripts in directories that other > users can modify. The only vulnerable code is code that moves to an > unsafe location on its own. > > > At cPanel we started off with approach #3, then ended up leaning > towards #1. I can probably provide a fairly good list of places that > need to be fixed in Debian once I know exactly where to focus. > > > I haven't contacted Debian's Perl team about this problem. Please CC > whoever should be informed from that team if they are not already on > the perl-security or debian-security lists.
-- perl -Mre=debug -e "/just|another|perl|hacker/"
CC: John Lightsey <lightsey [...] debian.org>, team [...] security.debian.org, perl5-security-report [...] perl.org, Todd Rinaldo <toddr [...] cpanel.net>
Subject: Re: Flaws in Perl code due to unsafe module load path
Date: Tue, 5 Apr 2016 09:37:36 +0200
From: Salvatore Bonaccorso <carnil [...] debian.org>
To: Florian Weimer <fw [...] deneb.enyo.de>
Download (untitled) / with headers
text/plain 793b
Hi, On Tue, Apr 05, 2016 at 08:59:46AM +0200, Florian Weimer wrote: Show quoted text
> * John Lightsey: >
> > So...with all that explanation said... My question is, which codebase > > is supposed to fix this issue? I figure there are four possible answers > > to which piece of code was responsible for preventing these types of > > attacks: > > > > 1) The Perl interpreter for placing the '.' in @INC.
> > '.' in @INC is certainly handy for development, so that you can access > modules from the same directory as your script. > > Maybe it could make sense to extract the full path to the executable > and use that?
One addition/context: Just recently #588017 got activity: https://bugs.debian.org/588017#76, which refer/leads to https://rt.perl.org/Public/Bug/Display.html?id=127810 Regards, Salvatore
Download signature.asc
application/pgp-signature 819b

Message body not shown because it is not plain text.

To: perl5-security-report [...] perl.org
From: Dave Mitchell <davem [...] iabyn.com>
Date: Tue, 5 Apr 2016 09:07:24 +0100
Subject: Re: [perl #127834] Flaws in Perl code due to unsafe module load path
Download (untitled) / with headers
text/plain 1.8k
On Mon, Apr 04, 2016 at 08:23:27PM -0700, John Lightsey wrote: Show quoted text
> I need some guidance from the Perl and Debian security teams on how to > handle vulnerabilities related to Perl's inclusion of the current > working directory in its default module load path.
My personal feeling is that perl should *not* include '.' in @INC by default, but that a Configure option (i.e. effectively the inverse of todd's proposed -Dfortify inc) whould make a perl with the old behaviour restored. I think we are in the same situation where UNIXy OSes gradually stopped making '.' be included by default in $PATH. It probably annoyed some people and broke some things, but the workarounds were trivial and people soon got used to it. In the same way, if we change the default, the good thing is that it's usually pretty obvious that there's a fault - the module fails to load and the script dies. Fixing is trivial, e.g. '-I.' or 'unshift @INC, ".". The converse is not true - its not easy to spot that a script isn't secure. Any script that optionally loads a module, e.g. tries an XS version and falls back to a pure-perl version can be hijacked if the optional module isn't available on that systemm and if the script is run from a directory that the attacker has write access to (such as tmp). Very few people writing a boring everyday admin script are going to be aware of such a subtlety and make their scripts immune to it. What I would like to see is: 1) Todd's changes to cpan/ modules to make them dot-agnostic get pushed as tickets to the relevant distributions ASAP; 2) early in the 5.25.x development cycle, once those distributions have been updated, released and pulled into bleed, that we switch @INC to be no-dot by default 3) If it all turns into a disaster, we can always back out before 5.26 is released. -- "You're so sadly neglected, and often ignored. A poor second to Belgium, When going abroad." -- Monty Python, "Finland"
Subject: Re: [perl #127834] Flaws in Perl code due to unsafe module load path
CC: perl5-security-report [...] perl.org
Date: Tue, 5 Apr 2016 10:25:10 +0200
To: Dave Mitchell <davem [...] iabyn.com>
From: Rafael Garcia-Suarez <rgs [...] consttype.org>
Download (untitled) / with headers
text/plain 2.1k
On 5 April 2016 at 10:07, Dave Mitchell <davem@iabyn.com> wrote: Show quoted text
> On Mon, Apr 04, 2016 at 08:23:27PM -0700, John Lightsey wrote:
>> I need some guidance from the Perl and Debian security teams on how to >> handle vulnerabilities related to Perl's inclusion of the current >> working directory in its default module load path.
> > My personal feeling is that perl should *not* include '.' in @INC by > default, but that a Configure option (i.e. effectively the inverse of > todd's proposed -Dfortify inc) whould make a perl with the old behaviour > restored. > > I think we are in the same situation where UNIXy OSes gradually stopped > making '.' be included by default in $PATH. It probably annoyed some > people and broke some things, but the workarounds were trivial and people > soon got used to it. > > In the same way, if we change the default, the good thing is that it's > usually pretty obvious that there's a fault - the module fails to load and > the script dies. Fixing is trivial, e.g. '-I.' or 'unshift @INC, ".". > > The converse is not true - its not easy to spot that a script isn't > secure. Any script that optionally loads a module, e.g. tries an XS > version and falls back to a pure-perl version can be hijacked if the > optional module isn't available on that systemm and if the script is run > from a directory that the attacker has write access to (such as tmp). > > Very few people writing a boring everyday admin script are going to be > aware of such a subtlety and make their scripts immune to it. > > What I would like to see is: > > 1) Todd's changes to cpan/ modules to make them dot-agnostic get pushed as > tickets to the relevant distributions ASAP; > 2) early in the 5.25.x development cycle, once those distributions have > been updated, released and pulled into bleed, that we switch @INC > to be no-dot by default > 3) If it all turns into a disaster, we can always back out before 5.26 is > released.
I'd like to add that -T also removes . from @INC, so anything that would break without . would also break with -T. One more argument to simply ditch . from @INC. (I was under the impression that running perl as root was also removing . but it seems I'm wrong)
CC: perl5-security-report [...] perl.org
Subject: Re: [perl #127834] Flaws in Perl code due to unsafe module load path
Date: Tue, 5 Apr 2016 09:48:02 +0100
To: Dave Mitchell <davem [...] iabyn.com>
From: Tim Bunce <Tim.Bunce [...] pobox.com>
Download (untitled) / with headers
text/plain 490b
On Tue, Apr 05, 2016 at 09:07:24AM +0100, Dave Mitchell wrote: Show quoted text
> > What I would like to see is: > > 1) Todd's changes to cpan/ modules to make them dot-agnostic get pushed as > tickets to the relevant distributions ASAP; > 2) early in the 5.25.x development cycle, once those distributions have > been updated, released and pulled into bleed, that we switch @INC > to be no-dot by default > 3) If it all turns into a disaster, we can always back out before 5.26 is > released.
+1 Tim.
Date: Tue, 5 Apr 2016 06:39:02 -0400
From: Jarkko Hietaniemi <jhi [...] iki.fi>
To: perl5-security-report [...] perl.org
Subject: Re: [perl #127834] Flaws in Perl code due to unsafe module load path
Download (untitled) / with headers
text/plain 556b
On Tuesday-201604-05 4:48, Tim Bunce wrote: Show quoted text
> On Tue, Apr 05, 2016 at 09:07:24AM +0100, Dave Mitchell wrote:
>> >> What I would like to see is: >> >> 1) Todd's changes to cpan/ modules to make them dot-agnostic get pushed as >> tickets to the relevant distributions ASAP; >> 2) early in the 5.25.x development cycle, once those distributions have >> been updated, released and pulled into bleed, that we switch @INC >> to be no-dot by default >> 3) If it all turns into a disaster, we can always back out before 5.26 is >> released.
> > +1 > > Tim. >
+1
CC: perl5-security-report [...] perl.org, Todd Rinaldo <toddr [...] cpanel.net>
Subject: Re: [perl #127834] Flaws in Perl code due to unsafe module load path
Date: Wed, 06 Apr 2016 11:27:01 -0500
To: team [...] security.debian.org
From: John Lightsey <lightsey [...] debian.org>
Download (untitled) / with headers
text/plain 2.2k
On Tue, 2016-04-05 at 09:37 +0200, Salvatore Bonaccorso wrote: Show quoted text
> Hi,
Show quoted text
> > One addition/context: Just recently #588017 got activity: > https://bugs.debian.org/588017#76, which refer/leads to > https://rt.perl.org/Public/Bug/Display.html?id=127810 >
Right, that bug report basically shows the full public lifespan of the issue. Debian raised it on p5p in 2010, Todd raised it again on p5p in 2012, and Todd submitted a patch for the issue recently. There are also several bodies of code that more or less inherited this behavior from Perl and have already been publicly fixed. The ones I'm aware of are Ruby, Perl6, Module::Signature, EXIM, and cPanel. Some of the responses to my email weren't sent to all of the parties I originally CC'd. The summary of the missing bits is that the perl- security team would like to switch Todd's patch from defaulting off to defaulting on, and get it incorporated into Perl 5.26 if possible. I agree that its a great idea going forward, but it still leaves my original question unanswered. If fixing Perl 5.26+ is the only solution, it will result in a very long window where Perl scripts remain vulnerable to these problems. For some scripts this is a relatively obscure risk, but for others it's a meaningful risk that should be addressed with a more direct solution. For instance, the behavior in the apt-get tools is a local root exploit without any unusual preconditions. Taking the apt-get scripts in isolation from the rest of the Perl ecosystem, the vulnerability is trivial to fix at all levels (the Perl interpreter, the Storable and Encode modules, the various apt-get Perl helper scripts.) I would expect that leaving this vulnerability in place for several years while Debian slowly obsoletes all versions of Perl before 5.26 isn't going to be a reasonable approach. The likelihood of someone else noticing the same attacks during that timeframe seems too high to me. It's also difficult to keep fixing flaws like this in isolation without inadvertently shining a brighter spotlight on the underlying risk to all existing Perl scripts. It would be very helpful to know which of the various pieces of code are responsible for addressing the risk with Perl before 5.26? The interpreter, the modules, or the script?
Download signature.asc
application/pgp-signature 819b

Message body not shown because it is not plain text.

To: team [...] security.debian.org, perl5-security-report [...] perl.org, Todd Rinaldo <toddr [...] cpanel.net>
From: Zefram <zefram [...] fysh.org>
Date: Wed, 6 Apr 2016 18:33:06 +0100
Subject: Re: [perl #127834] Flaws in Perl code due to unsafe module load path
Download (untitled) / with headers
text/plain 1.4k
John Lightsey wrote: Show quoted text
>It would be very helpful to know which of the various pieces of code >are responsible for addressing the risk with Perl before 5.26? The >interpreter, the modules, or the script?
Patching older interpreters would change their behaviour in a breaking way, so isn't a great idea. It's also infeasible for a lot of people; we'd like to have a solution that people who don't build their own perl can apply. Modules are the wrong place to do this. It is not for a module to question the @INC that it sees; even if it were, there's no clear criterion for which modules ought to disrespect a "." entry. Generally, modules are not aware of the security requirements and other situational aspects of the running program. That leaves the script, i.e., the top-level program. This is the right place. The top level knows what the overall purpose of running the program is, knows what aspects of the environment can be trusted, and what kind of security requirements can apply. It also has the capability to control the @INC that will apply to almost all module loading that occurs as part of the program's compilation and execution. (It doesn't control PERL5OPT=-MFoo type stuff, but that's much less of a security worry.) We should recommend that (all?) perl programs begin with an invocation such as BEGIN { pop @INC if $INC[-1] eq "."; } This invocation is portable back to very old perls, and will be safe to retain on future perls that don't put "." into @INC. -zefram
Date: Wed, 06 Apr 2016 13:44:39 -0500
From: John Lightsey <lightsey [...] debian.org>
To: perl5-security-report [...] perl.org
Subject: Re: [perl #127834] Flaws in Perl code due to unsafe module load path
Download (untitled) / with headers
text/plain 2.2k
On Wed, 2016-04-06 at 10:33 -0700, Zefram via RT wrote: Show quoted text
> John Lightsey wrote:
> >It would be very helpful to know which of the various pieces of code > >are responsible for addressing the risk with Perl before 5.26? The > >interpreter, the modules, or the script?
> > Patching older interpreters would change their behaviour in a > breaking > way, so isn't a great idea.  It's also infeasible for a lot of > people; > we'd like to have a solution that people who don't build their own > perl > can apply. > > Modules are the wrong place to do this.  It is not for a module to > question the @INC that it sees; even if it were, there's no clear > criterion for which modules ought to disrespect a "." > entry.  Generally, > modules are not aware of the security requirements and other > situational > aspects of the running program. > > That leaves the script, i.e., the top-level program.  This is the > right place.  The top level knows what the overall purpose of running > the program is, knows what aspects of the environment can be trusted, > and what kind of security requirements can apply.  It also has the > capability to control the @INC that will apply to almost all module > loading that occurs as part of the program's compilation and > execution. > (It doesn't control PERL5OPT=-MFoo type stuff, but that's much less > of > a security worry.)
One compelling reason to avoid this approach is just the numbers. There are a small handful of common modules that trigger this behavior over and over in most scripts. For example, by default my Debian box has 136 perl scripts that do a module load from the current working directory under a simple perl -c test. If I fix the two most common modules that cause this (Storable loading Log::Agent and Encode loading Encode::ConfigLocal) by localizing and filtering @INC before they load these optional dependencies, the number of vulnerable scripts drops to 12. It's much simpler to change 2 modules than 124 scripts as a security fix. The behavior of Storable and Encode does change as a result, but not in a fashion anyone is likely dependent on, and technically the scripts aren't guaranteed to be "safe". It's a simple way to get a lot of coverage with a very small set of changes though.
Download signature.asc
application/pgp-signature 819b

Message body not shown because it is not plain text.

RT-Send-CC: rt-deliver-to-perl5-security-report [...] rt.perl.org
Download (untitled) / with headers
text/plain 147b
I've merged the extra tickets created into the main ticket. Please make sure [perl #127834] is in the subject when you reply to this ticket. Tony
RT-Send-CC: rt-deliver-to-perl5-security-report [...] rt.perl.org
Download (untitled) / with headers
text/plain 709b
On Tue Apr 05 01:07:50 2016, davem wrote: Show quoted text
> 1) Todd's changes to cpan/ modules to make them dot-agnostic get pushed as > tickets to the relevant distributions ASAP; > 2) early in the 5.25.x development cycle, once those distributions have > been updated, released and pulled into bleed, that we switch @INC > to be no-dot by default > 3) If it all turns into a disaster, we can always back out before 5.26 is > released.
This. I don't think Todd's PERL_USE_UNSAFE_INC environment variable should be included - if someone wants . in @INC they can set PERL5LIB, or add -I. to the #! line. The behaviour isn't exactly the same, but I expect it's close enough for most of the cases that expect . in @INC. Tony
From: Leon Timmermans <fawaka [...] gmail.com>
To: "perl5-security-report [...] perl.org" <perl5-security-report [...] perl.org>
Date: Thu, 7 Apr 2016 10:49:45 +0200
Subject: Re: [perl #127834] Flaws in Perl code due to unsafe module load path
CC: "bugs-bitbucket [...] rt.perl.org" <bugs-bitbucket [...] rt.perl.org>
Download (untitled) / with headers
text/plain 4.4k
On Tue, Apr 5, 2016 at 5:23 AM, John Lightsey <perl5-security-report@perl.org> wrote:
Show quoted text
Hi there,

I need some guidance from the Perl and Debian security teams on how to
handle vulnerabilities related to Perl's inclusion of the current
working directory in its default module load path.

Todd raised this issue on the p5p list in 2012 when he was updating
cPanel to Perl 5.14. The cPanel Security Team (my day job) took note of
the problem late last year while we were auditing for local file read
and write attacks. The problem was pervasive in cPanel's codebase and
we resolved the issues with the assumption that this was a well
established Perl behavior and cPanel's code was responsible for
mitigating the risks. This work led to the discovery of several other
interesting flaws in open source code and we've been working with the
upstream authors to get those resolved.

I started putting together a conference talk to summarize all of the
work cPanel had put into this effort, the flaws we found and the tools
we used. At that same time, Todd was putting together a patch
submission to revisit the 2012 decision to leave the '.' in @INC in
Perl. The more we've looked at this problem though, the more convinced
we've become that this needs to be handled and resolved as a
vulnerability in Perl itself.

The major problem with this behavior is that it unexpectedly puts a
user at risk whenever they execute any Perl scripts from a directory
that is writable by other accounts on the system. For instance, if I'm
logged in as root and I change directory into /tmp or an account's home
directory, I can run any shell commands that are written in C, Python
or Ruby without fear. The same isn't true for any shell commands that
are written in Perl, since a significant proportion of Perl scripts
will execute code in the current working directory whenever they are
run.

For example, if a user on a shared system creates the file
/tmp/Pod/Perldoc/Toterm.pm, and then I log in as root, change directory
to /tmp, and run "perldoc perlrun", it will execute the code they have
placed in the file.

The most severe example I've found on Debian is that apt-get will load
and execute the /tmp/Log/Agent.pm file regardless of the directory it
is started from since it automatically changes directory to /tmp. To
reproduce this:

mkdir -p /tmp/Log
echo '`wall hello`;die;' >/tmp/Log/Agent.pm
sudo apt-get update


A very simplistic analysis of my personal Debian laptop shows that over
40% of the perl scripts have this behavior. You can run the same
analysis with this ugly shell command:

grep '^#!/usr/bin/perl' /usr/*bin/* | cut -d ':' -f 1 | xargs -n1
/bin/sh -c 'TEST="$0"; if [ "`strace -f perl -c \"$TEST\" 2>&1 | grep
'\''stat(\"\..*\.pm\"'\''`" != "" ] ; then echo "Vulnerable: $TEST";
else echo "Not vulnerable: $TEST"; fi'

Or to test an individual script you can do something like this:

strace -f /usr/bin/perldoc perldoc 2>&1 | grep 'stat("\..*\.pm"'


This kind of analysis definitely underestimates the number of affected
scripts though.


So...with all that explanation said... My question is, which codebase
is supposed to fix this issue? I figure there are four possible answers
to which piece of code was responsible for preventing these types of
attacks:

1) The Perl interpreter for placing the '.' in @INC.

2) Any module that fails to remove the '.' from @INC before attempting
to load other modules that are not specified as hard requirements.

3) Any script that loads any modules that end up exhibiting this
behavior.

4) End users must avoid running Perl scripts in directories that other
users can modify. The only vulnerable code is code that moves to an
unsafe location on its own.


At cPanel we started off with approach #3, then ended up leaning
towards #1. I can probably provide a fairly good list of places that
need to be fixed in Debian once I know exactly where to focus.


I haven't contacted Debian's Perl team about this problem. Please CC
whoever should be informed from that team if they are not already on
the perl-security or debian-security lists.

I've never liked this behavior TBH. I've recommended using taint mode on system tools for exactly this reason (the other differences matter much less to me in most cases), even though it's a pain. Yet at the same time, I fear the backwards compatibility consequences of this; it will be significant.

It's a mess :-(

Leon

Date: Wed, 6 Apr 2016 13:56:47 -0500
From: Todd Rinaldo <toddr [...] cpanel.net>
To: John Lightsey <john [...] nixnuts.net>, team [...] security.debian.org, perl5-security-report [...] perl.org
Subject: Re: [Fwd: Re: [perl #127834] Flaws in Perl code due to unsafe module load path]
Download (untitled) / with headers
text/plain 2.8k
Show quoted text
> On Apr 6, 2016, at 1:49 PM, John Lightsey <john@nixnuts.net> wrote: > > On Wed, 2016-04-06 at 10:33 -0700, Zefram via RT wrote:
>> John Lightsey wrote:
>>> It would be very helpful to know which of the various pieces of code >>> are responsible for addressing the risk with Perl before 5.26? The >>> interpreter, the modules, or the script?
>> >> Patching older interpreters would change their behaviour in a >> breaking >> way, so isn't a great idea. It's also infeasible for a lot of >> people; >> we'd like to have a solution that people who don't build their own >> perl >> can apply. >> >> Modules are the wrong place to do this. It is not for a module to >> question the @INC that it sees; even if it were, there's no clear >> criterion for which modules ought to disrespect a "." >> entry. Generally, >> modules are not aware of the security requirements and other >> situational >> aspects of the running program. >> >> That leaves the script, i.e., the top-level program. This is the >> right place. The top level knows what the overall purpose of running >> the program is, knows what aspects of the environment can be trusted, >> and what kind of security requirements can apply. It also has the >> capability to control the @INC that will apply to almost all module >> loading that occurs as part of the program's compilation and >> execution. >> (It doesn't control PERL5OPT=-MFoo type stuff, but that's much less >> of >> a security worry.)
> > One compelling reason to avoid this approach is just the numbers. There > are a small handful of common modules that trigger this behavior over > and over in most scripts. > > For example, by default my Debian box has 136 perl scripts that do a > module load from the current working directory under a simple perl -c > test. > > If I fix the two most common modules that cause this (Storable loading > Log::Agent and Encode loading Encode::ConfigLocal) by localizing and > filtering @INC before they load these optional dependencies, the number > of vulnerable scripts drops to 12. > > It's much simpler to change 2 modules than 124 scripts as a security > fix. The behavior of Storable and Encode does change as a result, but > not in a fashion anyone is likely dependent on, and technically the > scripts aren't guaranteed to be "safe". It's a simple way to get a lot > of coverage with a very small set of changes though.
So this exchange gets to the heart of the problem Zefram argues the module shouldn't be manipulating @INC. But as JD points out if we apply this simple fix, all sorts of code is magically secure: Storable does: if (eval { local $SIG{__DIE__}; require Log::Agent; 1 }) { Log::Agent->import; } In this case you could change it to this and fix Storable's issue: if (eval { local @INC= grep {$_ ne "." } @INC; local $SIG{__DIE__}; require Log::Agent; 1 }) { Log::Agent->import; }
Download signature.asc
application/pgp-signature 842b

Message body not shown because it is not plain text.

Subject: Re: [Fwd: Re: [perl #127834] Flaws in Perl code due to unsafe module load path]
From: Zefram <zefram [...] fysh.org>
To: team [...] security.debian.org, perl5-security-report [...] perl.org, Todd Rinaldo <toddr [...] cpanel.net>
Date: Sat, 9 Apr 2016 17:12:32 +0100
Download (untitled) / with headers
text/plain 814b
Todd Rinaldo wrote: Show quoted text
>In this case you could change it to this and fix Storable's issue: > >if (eval { local @INC= grep {$_ ne "." } @INC; local $SIG{__DIE__}; require Log::Agent; 1 }) {
This kind of patch, like the formulation that I proposed for top-level programs, wouldn't work on OSes where the current directory is denoted by a pathname other than ".". In general that is a problem for modules, which tend to be expected to be widely portable. Storable actually already has some dependence on Unix-like pathname semantics built in, but only in a way that's difficult to invoke, so in practice it's mostly portable, and the portability would take a significant hit from adding this @INC hack. This is much less of an issue for top-level program code, which is much more likely to be OS-specific. -zefram
Subject: Re: [Fwd: Re: [perl #127834] Flaws in Perl code due to unsafe module load path]
CC: team [...] security.debian.org, perl5-security-report [...] perl.org, Todd Rinaldo <toddr [...] cpanel.net>
To: Zefram <zefram [...] fysh.org>
From: "Craig A. Berry" <craig.a.berry [...] gmail.com>
Date: Sat, 9 Apr 2016 11:53:45 -0500
Download (untitled) / with headers
text/plain 818b
On Sat, Apr 9, 2016 at 11:12 AM, Zefram <zefram@fysh.org> wrote: Show quoted text
> Todd Rinaldo wrote:
>>In this case you could change it to this and fix Storable's issue: >> >>if (eval { local @INC= grep {$_ ne "." } @INC; local $SIG{__DIE__}; require Log::Agent; 1 }) {
> > This kind of patch, like the formulation that I proposed for top-level > programs, wouldn't work on OSes where the current directory is denoted > by a pathname other than ".".
FWIW, the @INC entry for current working directory is '.' on both VMS and Windows. On Windows because that's the native format for current working directory. On VMS because (for the last five years or so) all paths are converted to Unix format before storing in @INC. Not sure if there are any non-Unix, non-Windows, non-VMS filename syntaxes that need worrying about. Amiga?
Subject: Re: [Fwd: Re: [perl #127834] Flaws in Perl code due to unsafe module load path]
Date: Sat, 9 Apr 2016 18:59:40 -0400
To: perl5-security-report [...] perl.org
From: Jarkko Hietaniemi <jhi [...] iki.fi>
Download (untitled) / with headers
text/plain 542b
On Saturday-201604-09 12:53, Craig A. Berry wrote: Show quoted text
> Not sure if there are any non-Unix, non-Windows, non-VMS filename > syntaxes that need worrying about. Amiga?
I asked Andy Broad and the UNIX emulation layer used in AmigaOS does translate "." in INC to current directory. (FWIW, the native form would be CURRDIR: or through the emulation layer, /CURRDIR.) Though to quote Andy: "Securitywise, on the amiga the horse bolted before then barn was even built, let alone the doors locked....", being essentially a single user system.
Subject: Re: [Fwd: Re: [perl #127834] Flaws in Perl code due to unsafe module load path]
To: perl5-security-report [...] perl.org
From: Zefram <zefram [...] fysh.org>
Date: Sun, 10 Apr 2016 01:38:41 +0100
Download (untitled) / with headers
text/plain 314b
Jarkko Hietaniemi wrote: Show quoted text
>Though to quote Andy: "Securitywise, on the amiga the horse bolted >before then barn was even built, let alone the doors locked....", >being essentially a single user system.
Consistency of behaviour between systems is to be preferred, even when it's not a matter of security. -zefram
Subject: Re: [Fwd: Re: [perl #127834] Flaws in Perl code due to unsafe module load path]
From: Jarkko Hietaniemi <jhi [...] iki.fi>
To: perl5-security-report [...] perl.org
Date: Sat, 9 Apr 2016 20:45:50 -0400
Download (untitled) / with headers
text/plain 415b
On Saturday-201604-09 20:38, Zefram wrote: Show quoted text
> Jarkko Hietaniemi wrote:
>> Though to quote Andy: "Securitywise, on the amiga the horse bolted >> before then barn was even built, let alone the doors locked....", >> being essentially a single user system.
> > Consistency of behaviour between systems is to be preferred, even when > it's not a matter of security.
Sure. Nobody was arguing the opposite. Show quoted text
> -zefram >
Date: Mon, 11 Apr 2016 17:40:33 -0500
To: perl5-security-report [...] perl.org
From: Todd Rinaldo <toddr [...] cpanel.net>
CC: carnil [...] debian.org, fw [...] deneb.enyo.de, lightsey [...] debian.org, toddr [...] cpan.org
Subject: Re: [Fwd: Re: [perl #127834] Flaws in Perl code due to unsafe module load path]
Show quoted text
> On Apr 9, 2016, at 11:12 AM, Zefram via RT <perl5-security-report@perl.org> wrote: > > Todd Rinaldo wrote:
>> In this case you could change it to this and fix Storable's issue: >> >> if (eval { local @INC= grep {$_ ne "." } @INC; local $SIG{__DIE__}; require Log::Agent; 1 }) {
> > This kind of patch, like the formulation that I proposed for top-level > programs, wouldn't work on OSes where the current directory is denoted > by a pathname other than ".". In general that is a problem for modules, > which tend to be expected to be widely portable. Storable actually > already has some dependence on Unix-like pathname semantics built in, > but only in a way that's difficult to invoke, so in practice it's mostly > portable, and the portability would take a significant hit from adding > this @INC hack. This is much less of an issue for top-level program code, > which is much more likely to be OS-specific. >
Based on the replies already, . in @INC is the same on all supported systems, right? So this is a possible fix? Todd
RT-Send-CC: rt-deliver-to-perl5-security-report [...] rt.perl.org
Download (untitled) / with headers
text/plain 425b
On Mon Apr 11 15:56:51 2016, toddr@cpanel.net wrote: Show quoted text
> Based on the replies already, . in @INC is the same on all supported > systems, right? So this is a possible fix?
Considering your last patch set, I think: a) we should hide the unsafe_inc options a little deeper (require -Accflags=-D...), or not have it at all. b) we shouldn't have the environment variable, adjusting PERL5LIB is suitable for most purposes. Tony
Subject: Re: [perl #127834] Flaws in Perl code due to unsafe module load path
CC: rt-deliver-to-perl5-security-report [...] rt.perl.org
From: Leon Timmermans <fawaka [...] gmail.com>
To: "perl5-security-report [...] perl.org" <perl5-security-report [...] perl.org>
Date: Tue, 12 Apr 2016 10:26:14 +0200
Download (untitled) / with headers
text/plain 813b
On Tue, Apr 12, 2016 at 3:02 AM, Tony Cook via RT <perl5-security-report@perl.org> wrote:
Show quoted text
Considering your last patch set, I think:

a) we should hide the unsafe_inc options a little deeper (require -Accflags=-D...), or not have it at all.

I'd go for hiding. Making it impossible seems unperlish, but we do want to disrecommend this strongly.
 
Show quoted text
b) we shouldn't have the environment variable, adjusting PERL5LIB is suitable for most purposes.

PERL5LIB added to the front of @INC, while . is currently added to the back; this is a fundamentally different thing to me. I do believe we need a way to explicitly say to add it back in. To me a command-line flag is more appropriate than an environmental flag, if only because you can use PERL5OPT to make it an environmental flag if necessary.

Leon

Subject: Re: [perl #127834] Flaws in Perl code due to unsafe module load path
Date: Tue, 12 Apr 2016 11:17:59 -0500
To: perl5-security-report [...] perl.org, carnil [...] debian.org, fw [...] deneb.enyo.de, toddr [...] cpan.org
From: John Lightsey <lightsey [...] debian.org>
Download (untitled) / with headers
text/plain 1.3k
On Tue, 2016-04-12 at 01:27 -0700, Leon Timmermans via RT wrote: Show quoted text
> On Tue, Apr 12, 2016 at 3:02 AM, Tony Cook via RT < > perl5-security-report@perl.org> wrote: >
> > Considering your last patch set, I think: > > > > a) we should hide the unsafe_inc options a little deeper (require > > -Accflags=-D...), or not have it at all. > >
> > I'd go for hiding. Making it impossible seems unperlish, but we do > want to > disrecommend this strongly. > >
> > b) we shouldn't have the environment variable, adjusting PERL5LIB
> is
> > suitable for most purposes. > >
> > PERL5LIB added to the front of @INC, while . is currently added to > the > back; this is a fundamentally different thing to me. I do believe we > need a > way to explicitly say to add it back in. To me a command-line flag is > more > appropriate than an environmental flag, if only because you can use > PERL5OPT to make it an environmental flag if necessary. >
The downside to this approach is that the code using it must be aware of the version of Perl that will inherit the PERL5OPT setting. Any version of Perl before the new flag is added will break if it inherits the PERL5OPT setting. Using a new environmental variable that returned the original @INC configuration kept the original proposed patch very small because the versions of Perl that already had '.' in @INC would ignore it.
Download signature.asc
application/pgp-signature 819b

Message body not shown because it is not plain text.

Subject: Re: [perl #127834] Flaws in Perl code due to unsafe module load path
CC: carnil [...] debian.org, fw [...] deneb.enyo.de, toddr [...] cpan.org
From: Todd Rinaldo <toddr [...] cpanel.net>
To: perl5-security-report [...] perl.org
Date: Tue, 12 Apr 2016 11:32:45 -0500
Download (untitled) / with headers
text/plain 1.7k

Show quoted text
On Apr 12, 2016, at 11:18 AM, John Lightsey via RT <perl5-security-report@perl.org> wrote:

On Tue, 2016-04-12 at 01:27 -0700, Leon Timmermans via RT wrote:
On Tue, Apr 12, 2016 at 3:02 AM, Tony Cook via RT <
perl5-security-report@perl.org> wrote:

Considering your last patch set, I think:

a) we should hide the unsafe_inc options a little deeper (require
-Accflags=-D...), or not have it at all.


I'd go for hiding. Making it impossible seems unperlish, but we do
want to
disrecommend this strongly.


b) we shouldn't have the environment variable, adjusting PERL5LIB
is
suitable for most purposes.


PERL5LIB added to the front of @INC, while . is currently added to
the
back; this is a fundamentally different thing to me. I do believe we
need a
way to explicitly say to add it back in. To me a command-line flag is
more
appropriate than an environmental flag, if only because you can use
PERL5OPT to make it an environmental flag if necessary.


The downside to this approach is that the code using it must be aware
of the version of Perl that will inherit the PERL5OPT setting. Any
version of Perl before the new flag is added will break if it inherits
the PERL5OPT setting.

Using a new environmental variable that returned the original @INC
configuration kept the original proposed patch very small because the
versions of Perl that already had '.' in @INC would ignore it.
<signature.asc>

IMO This whole conversation about what to do for 5.26 needs to move to RT 127810 so it will do better as a public discussion. This thread seems like a better place for us to discuss the proper way to fix 5.24 and below and how to coordinate the security disclosure that's going to have to come with it, right?

Todd
From: John Lightsey <lightsey [...] debian.org>
To: perl5-security-report [...] perl.org, carnil [...] debian.org, fw [...] deneb.enyo.de, toddr [...] cpan.org
Date: Fri, 15 Apr 2016 14:25:05 -0500
Subject: Re: [perl #127834] Flaws in Perl code due to unsafe module load path
Download (untitled) / with headers
text/plain 1.4k
On Tue, 2016-04-12 at 09:33 -0700, Todd Rinaldo via RT wrote: Show quoted text
>  > IMO This whole conversation about what to do for 5.26 needs to move > to RT 127810 so it will do better as a public discussion. This thread > seems like a better place for us to discuss the proper way to fix > 5.24 and below and how to coordinate the security disclosure that's > going to have to come with it, right? >
The discussion about what to do with 5.24 and earlier seems to have died off here. It's probably unrealistic to attempt coordinating simultaneous fixes for all of the individual Perl scripts that are unsafe to run in a directory that another user has write access to going backwards. I would think of this more like XXE attacks or the RLIM_NPROC setuid() attacks where an unsafe but documented behavior made large bodies of code vulnerable to a specific attack scenario that was not considered when the behavior was established. I'm guessing, that the Debian security team does want to fix all of the apt related Perl scripts before the problem is discussed publicly. Does the Perl security team want to fix the scripts it maintains that have the same problems? I'd really like to present this stuff publicly to make Perl developers and security testers aware of the risks, but I don't want to do so until both teams are satisfied that they have fixed everything they feel is important enough to fix. What's a reasonable timeframe before publicly discussing attacks against apt, perldoc, and the LWP tools?
Download signature.asc
application/pgp-signature 819b

Message body not shown because it is not plain text.

Date: Sat, 16 Apr 2016 15:57:07 +0200
From: demerphq <demerphq [...] gmail.com>
To: John Lightsey <lightsey [...] debian.org>
CC: "perl5-security-report [...] perl.org" <perl5-security-report [...] perl.org>, carnil [...] debian.org, fw [...] deneb.enyo.de, toddr [...] cpan.org
Subject: Re: [perl #127834] Flaws in Perl code due to unsafe module load path
Download (untitled) / with headers
text/plain 2.5k
On 15 April 2016 at 21:25, John Lightsey <lightsey@debian.org> wrote: Show quoted text
> On Tue, 2016-04-12 at 09:33 -0700, Todd Rinaldo via RT wrote:
>> >> IMO This whole conversation about what to do for 5.26 needs to move >> to RT 127810 so it will do better as a public discussion. This thread >> seems like a better place for us to discuss the proper way to fix >> 5.24 and below and how to coordinate the security disclosure that's >> going to have to come with it, right? >>
> > The discussion about what to do with 5.24 and earlier seems to have > died off here.
I think we are still figuring things out. Ric, our point man for these things has been busy with a new release, and has decided to step down from his role as a leader in our community, so we are a bit at loose ends right now. Show quoted text
> It's probably unrealistic to attempt coordinating simultaneous fixes > for all of the individual Perl scripts that are unsafe to run in a > directory that another user has write access to going backwards.
I have been thinking about this. I guess it means we are vulnerable in any script where use lib is required to run, as well as any script that depends on finding a file in ".", or any script which does an "eval require" or "eval use" right? Is that right? Show quoted text
> I would think of this more like XXE attacks or the RLIM_NPROC setuid() > attacks where an unsafe but documented behavior made large bodies of > code vulnerable to a specific attack scenario that was not considered > when the behavior was established. > > I'm guessing, that the Debian security team does want to fix all of the > apt related Perl scripts before the problem is discussed publicly.
I am just thinking that a lot of these bugs can be fixed by distribution of all dependencies. That would fix any code that does "eval use/eval require". Show quoted text
> Does the Perl security team want to fix the scripts it maintains that > have the same problems?
I think we do. Show quoted text
> I'd really like to present this stuff publicly to make Perl developers > and security testers aware of the risks, but I don't want to do so > until both teams are satisfied that they have fixed everything they > feel is important enough to fix.
I think this is already being half discussed in public, although I don't think that the public thread has made obvious references to the security dimension. I worry that discussing the fix for 5.26 in a public thread is a good idea actually. Show quoted text
> What's a reasonable timeframe before publicly discussing attacks > against apt, perldoc, and the LWP tools?
IMO we would definitely like more time before this happens. Cheers, yves -- perl -Mre=debug -e "/just|another|perl|hacker/"
From: John Lightsey <lightsey [...] debian.org>
To: demerphq <demerphq [...] gmail.com>
Date: Sat, 16 Apr 2016 10:57:42 -0500
Subject: Re: [perl #127834] Flaws in Perl code due to unsafe module load path
CC: "perl5-security-report [...] perl.org" <perl5-security-report [...] perl.org>, carnil [...] debian.org, fw [...] deneb.enyo.de, toddr [...] cpan.org
Download (untitled) / with headers
text/plain 4.8k
On Sat, 2016-04-16 at 15:57 +0200, demerphq wrote: Show quoted text
> On 15 April 2016 at 21:25, John Lightsey <lightsey@debian.org> wrote:
> > On Tue, 2016-04-12 at 09:33 -0700, Todd Rinaldo via RT wrote:
> >> > >> IMO This whole conversation about what to do for 5.26 needs to
> move
> >> to RT 127810 so it will do better as a public discussion. This
> thread
> >> seems like a better place for us to discuss the proper way to fix > >> 5.24 and below and how to coordinate the security disclosure
> that's
> >> going to have to come with it, right? > >>
> > > > The discussion about what to do with 5.24 and earlier seems to have > > died off here.
> > I think we are still figuring things out. Ric, our point man for > these > things has been busy with a new release, and has decided to step down > from his role as a leader in our community, so we are a bit at loose > ends right now. >
> > It's probably unrealistic to attempt coordinating simultaneous
> fixes
> > for all of the individual Perl scripts that are unsafe to run in a > > directory that another user has write access to going backwards.
> > I have been thinking about this. I guess it means we are vulnerable > in > any script where use lib is required to run, as well as any script > that depends on finding a file in ".", or any script which does an > "eval require" or "eval use" right? > > Is that right?
More or less, yes... I'd think of it this way: - All Perl scripts start off with the risk of loading a module from the current directory. - The Perl script can eliminate this risk entirely by turning on taint mode or filtering @INC in a BEGIN block before loading any modules. - If the Perl script doesn't eliminate the risk directly, then the risk becomes an actual flaw if the script or one of the modules it uses attempts to load a module that doesn't exist in any of the normal library paths. - Flawed scripts are widespread now because certain core modules try to load optional modules that typically are not installed (Storable, Encode, and Pod have this behavior.) In terms of ease of deployment and overall effect, you get much better bang for the buck by simply fixing the core modules so that they don't look for optional dependencies in '.'. Filtering @INC in Storable before it tries to load Log::Agent and in Encode before it tries to load Encode::ConfigLocal switches 90% of the "flawed" scripts on my system to just being "at risk". It's likely that changing a dozen or so common modules in this fashion would push that number up to 99% or higher. It doesn't guarantee that subsequent updates to other modules won't reintroduce a similar flawed behavior, but it has a very large immediate effect through very small set of changes. Show quoted text
>
> > I would think of this more like XXE attacks or the RLIM_NPROC
> setuid()
> > attacks where an unsafe but documented behavior made large bodies
> of
> > code vulnerable to a specific attack scenario that was not
> considered
> > when the behavior was established. > > > > I'm guessing, that the Debian security team does want to fix all of
> the
> > apt related Perl scripts before the problem is discussed publicly.
> > I am just thinking that a lot of these bugs can be fixed by > distribution of all dependencies. That would fix any code that does > "eval use/eval require". >
> > Does the Perl security team want to fix the scripts it maintains
> that
> > have the same problems?
> > I think we do. >
> > I'd really like to present this stuff publicly to make Perl
> developers
> > and security testers aware of the risks, but I don't want to do so > > until both teams are satisfied that they have fixed everything they > > feel is important enough to fix.
> > I think this is already being half discussed in public, although I > don't think that the public thread has made obvious references to the > security dimension. > > I worry that discussing the fix for 5.26 in a public thread is a good > idea actually.
Me too. I'd much prefer that the immediate issues with Perl scripts in 5.24 and earlier are addressed before getting too deep into discussions about what sort of things the Perl interpreter should be doing to prevent these kinds of issues in the future. It's difficult to explain why the @INC changes for 5.26 are important without also making it obvious how the current behavior can be misused. You'll have to forgive me and Todd for these two discussions running concurrently. We both worked on this problem in different areas for a long time before I clued into the fact that half of the Linux systems in existence could be rooted with it. The main goal in looking for ways to abuse the @INC behavior in 5.24 and earlier was to justify its removal in 5.26. The subject was raised on P5P before and the risk was discounted as theoretical in the past. Show quoted text
>
> > What's a reasonable timeframe before publicly discussing attacks > > against apt, perldoc, and the LWP tools?
> > IMO we would definitely like more time before this happens. > > Cheers, > yves >
Download signature.asc
application/pgp-signature 819b

Message body not shown because it is not plain text.

Subject: Re: [perl #127834] Flaws in Perl code due to unsafe module load path
CC: demerphq <demerphq [...] gmail.com>, "perl5-security-report\ [...] perl.org" <perl5-security-report [...] perl.org>, carnil [...] debian.org, toddr [...] cpan.org
From: Florian Weimer <fw [...] deneb.enyo.de>
To: John Lightsey <lightsey [...] debian.org>
Date: Sat, 16 Apr 2016 19:30:53 +0200
Download (untitled) / with headers
text/plain 826b
* John Lightsey: Show quoted text
> Filtering @INC in Storable before it tries to load Log::Agent and in > Encode before it tries to load Encode::ConfigLocal switches 90% of the > "flawed" scripts on my system to just being "at risk". It's likely that > changing a dozen or so common modules in this fashion would push that > number up to 99% or higher. It doesn't guarantee that subsequent > updates to other modules won't reintroduce a similar flawed behavior, > but it has a very large immediate effect through very small set of > changes.
It's also an option that has reduced risk of breaking legitimate user/developer setups which may rely on @INC containing . So from a distribution point-of-view, it is more work than a single patch to Perl itself, but I think it is still preferable for us over removal of . from the default @INC.
Date: Sun, 17 Apr 2016 08:03:11 +0200
From: demerphq <demerphq [...] gmail.com>
To: Florian Weimer <fw [...] deneb.enyo.de>
CC: John Lightsey <lightsey [...] debian.org>, "perl5-security-report [...] perl.org" <perl5-security-report [...] perl.org>, carnil [...] debian.org, Todd Rinaldo <toddr [...] cpan.org>
Subject: Re: [perl #127834] Flaws in Perl code due to unsafe module load path
Download (untitled) / with headers
text/plain 1.3k
On 16 April 2016 at 19:30, Florian Weimer <fw@deneb.enyo.de> wrote: Show quoted text
> * John Lightsey: >
>> Filtering @INC in Storable before it tries to load Log::Agent and in >> Encode before it tries to load Encode::ConfigLocal switches 90% of the >> "flawed" scripts on my system to just being "at risk". It's likely that >> changing a dozen or so common modules in this fashion would push that >> number up to 99% or higher. It doesn't guarantee that subsequent >> updates to other modules won't reintroduce a similar flawed behavior, >> but it has a very large immediate effect through very small set of >> changes.
> > It's also an option that has reduced risk of breaking legitimate > user/developer setups which may rely on @INC containing . > > So from a distribution point-of-view, it is more work than a single > patch to Perl itself, but I think it is still preferable for us over > removal of . from the default @INC.
Note that any distribution could achieve the same result without changing ANY code by simply always distributing Log::Agent with their Perl builds. This is a backwards compatible approach too. Any existing system can ameliorate their risk by simply installing the missing optional dependencies all the time. Yes it results in distribution bloat, but it is also safe and easy. Yves -- perl -Mre=debug -e "/just|another|perl|hacker/"
CC: Florian Weimer <fw [...] deneb.enyo.de>, John Lightsey <lightsey [...] debian.org>, "perl5-security-report [...] perl.org" <perl5-security-report [...] perl.org>, carnil [...] debian.org, Todd Rinaldo <toddr [...] cpan.org>
To: demerphq <demerphq [...] gmail.com>
From: Dave Mitchell <davem [...] iabyn.com>
Date: Mon, 18 Apr 2016 15:13:44 +0100
Subject: Re: [perl #127834] Flaws in Perl code due to unsafe module load path
Download (untitled) / with headers
text/plain 3.6k
On Sun, Apr 17, 2016 at 08:03:11AM +0200, demerphq wrote: Show quoted text
> Note that any distribution could achieve the same result without > changing ANY code by simply always distributing Log::Agent with their > Perl builds. This is a backwards compatible approach too. Any existing > system can ameliorate their risk by simply installing the missing > optional dependencies all the time. Yes it results in distribution > bloat, but it is also safe and easy.
I think that overall we're not taking this issue seriously enough. A quick scan through the .pm files in the core turns up 280 instances of this match: /(eval\s*\{[^}]*require\s*\S+)/msg i.e. where we're looking for something like 'eval { ....; require .... }'. While some of these will be false positives, many of them represent attempts to load optional modules not included in the core, e.g. dist/Test/lib/Test.pm: if eval { require Algorithm::Diff; Algorithm::Diff->VERSION(1.15); 1; }; Even the ones which optionally load core modules will be vulnerable in an OS distribution which includes perl but doesn't include some core modules by default (many Linux distros do this). A similar search on grep.cpan.me shows 'over 1000' affected distributions. Exploiting this is as easy as writing a bunch of files in a common writable directory, e.g. /tmp/Algorithm/Diff.pm, then sit back and wait a while, then you've got access to any account where that user has run a relevant perl script while chdir'ed to that writable directory. If they ran it while root, then the whole system is immediately compromised. Once could also envisage a CGI-type script that allows files to be uploaded to a temporary staging directory, and where the script chdir's to that directory, thus giving a remote exploit. The big problem we have is that 5.24.0-RC1 is due to be released in 2 day's time, and the question is what, if anything, we do before 5.24.0 is released. One possible compromise for 5.24.0 would be be exclude '.' in @INC only if the script is running as root (and possibly something analogous for non-UNIXY OSes). Conventional wisdom is that things like perl shouldn't be built while logged in as root; only the final 'make install' step should be run as root. Blead 'make install' can be made to work while running as root (and thus with no '.') with a simple fix to pod/buildtoc: - require 'Porting/pod_lib.pl'; + require './Porting/pod_lib.pl'; I don't know whether installing CPAN modules while running as root would break, however. So it might be that the minimum we do for 5.24.0 is hack perl.c so that '.' isn't pushed when running as root, plus the pod/buildtoc fix. Then we could extend the proposed Configure/-Accflags build option to be multivalued rather than binary, to handle 3 options: 1) never push '.' 2) push '.' only if not root 3) always push '.' Then we could discuss whether that new build option should be included with 5.24.0 or leave till 5.25.0. if the former, then we would make (2) the default in 5.24.0 and (1) the default in 5.26.0. Further, with a 'belt and braces' approach to security, I think it would still be worth fixing up modules that do an optional require, to make them localise @INC without the '.': especially dual-lived modules, which will then auto-fix older perls. Whether we should pull these fixes into core for 5.24.0 too, I don't know. Finally, I think it's unreasonable to expect writers of scripts to know that they should always sanitise @INC at the top of their scripts. -- More than any other time in history, mankind faces a crossroads. One path leads to despair and utter hopelessness. The other, to total extinction. Let us pray we have the wisdom to choose correctly. -- Woody Allen
CC: demerphq <demerphq [...] gmail.com>, Florian Weimer <fw [...] deneb.enyo.de>, John Lightsey <lightsey [...] debian.org>, "perl5-security-report [...] perl.org" <perl5-security-report [...] perl.org>, carnil [...] debian.org, Todd Rinaldo <toddr [...] cpan.org>
Subject: Re: [perl #127834] Flaws in Perl code due to unsafe module load path
Date: Mon, 18 Apr 2016 17:41:38 +0200
To: Dave Mitchell <davem [...] iabyn.com>
From: Leon Timmermans <fawaka [...] gmail.com>
Download (untitled) / with headers
text/plain 3.4k
On Mon, Apr 18, 2016 at 4:13 PM, Dave Mitchell <davem@iabyn.com> wrote:
Show quoted text
I think that overall we're not taking this issue seriously enough.

A quick scan through the .pm files in the core turns up 280 instances
of this match:

    /(eval\s*\{[^}]*require\s*\S+)/msg

i.e. where we're looking for something like 'eval { ....; require .... }'.
While some of these will be false positives, many of them represent
attempts to load optional modules not included in the core, e.g.

    dist/Test/lib/Test.pm:

     if eval { require Algorithm::Diff; Algorithm::Diff->VERSION(1.15); 1; };

Even the ones which optionally load core modules will be vulnerable in an
OS distribution which includes perl but doesn't include some core modules
by default (many Linux distros do this).

A similar search on grep.cpan.me shows 'over 1000' affected distributions.

Exploiting this is as easy as writing a bunch of files in a common
writable directory, e.g. /tmp/Algorithm/Diff.pm, then sit back
and wait a while, then you've got access to any account where that user
has run a relevant perl script while chdir'ed to that writable directory.
If they ran it while root, then the whole system is immediately
compromised.

Once could also envisage a CGI-type script that allows files to be
uploaded to a temporary staging directory, and where the script chdir's to
that directory, thus giving a remote exploit.

The big problem we have is that 5.24.0-RC1 is due to be released in 2
day's time, and the question is what, if anything, we do before 5.24.0 is
released.

 
Show quoted text
One possible compromise  for 5.24.0 would be be exclude '.' in @INC only
if the script is running as root (and possibly something analogous for
non-UNIXY OSes).

Conventional wisdom is that things like perl shouldn't be built while
logged in as root; only the final 'make install' step should be run as
root.

Blead 'make install' can be made to work while running as root (and thus
with no '.') with a simple fix to  pod/buildtoc:

    -  require 'Porting/pod_lib.pl';
    +  require './Porting/pod_lib.pl';

I don't know whether installing CPAN modules while running as root
would break, however.

So it might be that the minimum we do for 5.24.0 is hack perl.c so that
'.' isn't pushed when running as root, plus the pod/buildtoc fix.

Then we could extend the proposed Configure/-Accflags build option
to be multivalued rather than binary, to handle 3 options:

    1) never push '.'
    2) push '.' only if not root
    3) always push '.'

Then we could discuss whether that new build option should be included
with 5.24.0 or leave till 5.25.0. if the former, then we would make
(2) the default in 5.24.0 and (1) the default in 5.26.0.

Further, with a 'belt and braces' approach to security, I think it would
still be worth fixing up modules that do an optional require, to make them
localise @INC without the '.': especially dual-lived modules, which will
then auto-fix older perls. Whether we should pull these fixes into core
for 5.24.0 too, I don't know.

Finally, I think it's unreasonable to expect writers of scripts to know
that they should always sanitise @INC at the top of their scripts.

Another option may be to not add '.' if it isn't owned by you or root, or if it is world-writable. Both of these can easily be checked for (at least on Unix). This won't safe you if your program chdir()s, but I suspect that category of programs is significantly smaller.

Leon
 
Date: Mon, 18 Apr 2016 10:55:58 -0500
To: Leon Timmermans <fawaka [...] gmail.com>
From: Todd Rinaldo <toddr [...] cpanel.net>
CC: Dave Mitchell <davem [...] iabyn.com>, demerphq <demerphq [...] gmail.com>, Florian Weimer <fw [...] deneb.enyo.de>, John Lightsey <lightsey [...] debian.org>, "perl5-security-report [...] perl.org" <perl5-security-report [...] perl.org>, carnil [...] debian.org, Todd Rinaldo <toddr [...] cpan.org>
Subject: Re: [perl #127834] Flaws in Perl code due to unsafe module load path
Download (untitled) / with headers
text/plain 3.9k

Show quoted text
On Apr 18, 2016, at 10:41 AM, Leon Timmermans <fawaka@gmail.com> wrote:

On Mon, Apr 18, 2016 at 4:13 PM, Dave Mitchell <davem@iabyn.com> wrote:
I think that overall we're not taking this issue seriously enough.

A quick scan through the .pm files in the core turns up 280 instances
of this match:

    /(eval\s*\{[^}]*require\s*\S+)/msg

i.e. where we're looking for something like 'eval { ....; require .... }'.
While some of these will be false positives, many of them represent
attempts to load optional modules not included in the core, e.g.

    dist/Test/lib/Test.pm:

     if eval { require Algorithm::Diff; Algorithm::Diff->VERSION(1.15); 1; };

Even the ones which optionally load core modules will be vulnerable in an
OS distribution which includes perl but doesn't include some core modules
by default (many Linux distros do this).

A similar search on grep.cpan.me shows 'over 1000' affected distributions.

Exploiting this is as easy as writing a bunch of files in a common
writable directory, e.g. /tmp/Algorithm/Diff.pm, then sit back
and wait a while, then you've got access to any account where that user
has run a relevant perl script while chdir'ed to that writable directory.
If they ran it while root, then the whole system is immediately
compromised.

Once could also envisage a CGI-type script that allows files to be
uploaded to a temporary staging directory, and where the script chdir's to
that directory, thus giving a remote exploit.

The big problem we have is that 5.24.0-RC1 is due to be released in 2
day's time, and the question is what, if anything, we do before 5.24.0 is
released.

 
One possible compromise  for 5.24.0 would be be exclude '.' in @INC only
if the script is running as root (and possibly something analogous for
non-UNIXY OSes).

Conventional wisdom is that things like perl shouldn't be built while
logged in as root; only the final 'make install' step should be run as
root.

Blead 'make install' can be made to work while running as root (and thus
with no '.') with a simple fix to  pod/buildtoc:

    -  require 'Porting/pod_lib.pl';
    +  require './Porting/pod_lib.pl';

I don't know whether installing CPAN modules while running as root
would break, however.

So it might be that the minimum we do for 5.24.0 is hack perl.c so that
'.' isn't pushed when running as root, plus the pod/buildtoc fix.

Then we could extend the proposed Configure/-Accflags build option
to be multivalued rather than binary, to handle 3 options:

    1) never push '.'
    2) push '.' only if not root
    3) always push '.'

Then we could discuss whether that new build option should be included
with 5.24.0 or leave till 5.25.0. if the former, then we would make
(2) the default in 5.24.0 and (1) the default in 5.26.0.

Further, with a 'belt and braces' approach to security, I think it would
still be worth fixing up modules that do an optional require, to make them
localise @INC without the '.': especially dual-lived modules, which will
then auto-fix older perls. Whether we should pull these fixes into core
for 5.24.0 too, I don't know.

Finally, I think it's unreasonable to expect writers of scripts to know
that they should always sanitise @INC at the top of their scripts.

Another option may be to not add '.' if it isn't owned by you or root, or if it is world-writable. Both of these can easily be checked for (at least on Unix). This won't safe you if your program chdir()s, but I suspect that category of programs is significantly smaller.


This isn't technically a root only problem. It's of course much worse when it's a root process but lots of critical processes don't run as root. I'm also not clear if the original report JD provided would not be addressed by this fix. 

Todd

CC: Dave Mitchell <davem [...] iabyn.com>, demerphq <demerphq [...] gmail.com>, Florian Weimer <fw [...] deneb.enyo.de>, John Lightsey <lightsey [...] debian.org>, "perl5-security-report [...] perl.org" <perl5-security-report [...] perl.org>, carnil [...] debian.org, Todd Rinaldo <toddr [...] cpan.org>
Subject: Re: [perl #127834] Flaws in Perl code due to unsafe module load path
Date: Mon, 18 Apr 2016 11:05:39 -0500
From: "Craig A. Berry" <craig.a.berry [...] gmail.com>
To: Leon Timmermans <fawaka [...] gmail.com>
Download (untitled) / with headers
text/plain 1.1k
On Mon, Apr 18, 2016 at 10:41 AM, Leon Timmermans <fawaka@gmail.com> wrote: Show quoted text
> On Mon, Apr 18, 2016 at 4:13 PM, Dave Mitchell <davem@iabyn.com> wrote:
Show quoted text
>> One possible compromise for 5.24.0 would be be exclude '.' in @INC only >> if the script is running as root (and possibly something analogous for >> non-UNIXY OSes).
Show quoted text
> Another option may be to not add '.' if it isn't owned by you or root, or if > it is world-writable. Both of these can easily be checked for (at least on > Unix). This won't safe you if your program chdir()s, but I suspect that > category of programs is significantly smaller.
Is there a way to describe the privilege involved that doesn't require referring to the root user? Perhaps testing for whether the filesystem bits tell you that you do not have write access to the current working directory but a stat() tells you that you do? I believe geteuid always returns zero on Windows and never returns zero on VMS, and don't modern unixen often define privileged access (ACLs and what-not) that do not require being root? For the chdir problem, perhaps pp_require could become involved as well as the initial loading of @INC.
CC: Dave Mitchell <davem [...] iabyn.com>, demerphq <demerphq [...] gmail.com>, Florian Weimer <fw [...] deneb.enyo.de>, John Lightsey <lightsey [...] debian.org>, "perl5-security-report [...] perl.org" <perl5-security-report [...] perl.org>, carnil [...] debian.org, Todd Rinaldo <toddr [...] cpan.org>
Subject: Re: [perl #127834] Flaws in Perl code due to unsafe module load path
Date: Mon, 18 Apr 2016 18:27:15 +0200
From: Leon Timmermans <fawaka [...] gmail.com>
To: "Craig A. Berry" <craig.a.berry [...] gmail.com>
Download (untitled) / with headers
text/plain 966b
On Mon, Apr 18, 2016 at 6:05 PM, Craig A. Berry <craig.a.berry@gmail.com> wrote:
Show quoted text
Is there a way to describe the privilege involved that doesn't require
referring to the root user?  Perhaps testing for whether the
filesystem bits tell you that you do not have write access to the
current working directory but a stat() tells you that you do?

What I suggested has nothing to do with "do I have permissions", but with "do I trust the owner".
 
Show quoted text
I believe geteuid always returns zero on Windows and never returns zero
on VMS, and don't modern unixen often define privileged access (ACLs
and what-not) that do not require being root?

Security logic is rarely portable between OSes; I wasn't not expecting this to work verbatim on non-unix.
 
Show quoted text
For the chdir problem, perhaps pp_require could become involved as
well as the initial loading of @INC.

I suspect that will quickly become something too complicated for the current infrastructure.

Leon

Date: Mon, 18 Apr 2016 08:53:13 -0700
To: Leon Timmermans <fawaka [...] gmail.com>
From: Ask Bjørn Hansen <ask [...] nutmegjobs.com>
CC: Dave Mitchell <davem [...] iabyn.com>, demerphq <demerphq [...] gmail.com>, Florian Weimer <fw [...] deneb.enyo.de>, John Lightsey <lightsey [...] debian.org>, "perl5-security-report [...] perl.org" <perl5-security-report [...] perl.org>, carnil [...] debian.org, Todd Rinaldo <toddr [...] cpan.org>
Subject: Re: [perl #127834] Flaws in Perl code due to unsafe module load path
Download (untitled) / with headers
text/plain 558b
Show quoted text
> On Apr 18, 2016, at 08:41, Leon Timmermans <fawaka@gmail.com> wrote: > > Another option may be to not add '.' if it isn't owned by you or root, or if it is world-writable. Both of these can easily be checked for (at least on Unix). This won't safe you if your program chdir()s, but I suspect that category of programs is significantly smaller.
Isn't that just extra complexity for no real gain? It'd really need to check if ./Module/Path/File.pm or any of the parent directories have "bad" permissions (not necessarily limited to world writable). Ask
Date: Wed, 20 Apr 2016 11:57:38 -0500
To: Leon Timmermans <fawaka [...] gmail.com>
From: "Craig A. Berry" <craig.a.berry [...] gmail.com>
CC: Dave Mitchell <davem [...] iabyn.com>, demerphq <demerphq [...] gmail.com>, Florian Weimer <fw [...] deneb.enyo.de>, John Lightsey <lightsey [...] debian.org>, "perl5-security-report [...] perl.org" <perl5-security-report [...] perl.org>, carnil [...] debian.org, Todd Rinaldo <toddr [...] cpan.org>
Subject: Re: [perl #127834] Flaws in Perl code due to unsafe module load path
On Mon, Apr 18, 2016 at 11:27 AM, Leon Timmermans <fawaka@gmail.com> wrote: Show quoted text
> On Mon, Apr 18, 2016 at 6:05 PM, Craig A. Berry <craig.a.berry@gmail.com> > wrote:
>> >> Is there a way to describe the privilege involved that doesn't require >> referring to the root user? Perhaps testing for whether the >> filesystem bits tell you that you do not have write access to the >> current working directory but a stat() tells you that you do?
> > What I suggested has nothing to do with "do I have permissions", but with > "do I trust the owner".
Right, sorry. I conflated the desire to prevent the problem from happening with the desire to limit the damage when it does happen. We probably have to attempt both, but perhaps not all at once. Show quoted text
>> I believe geteuid always returns zero on Windows and never returns zero >> on VMS, and don't modern unixen often define privileged access (ACLs >> and what-not) that do not require being root?
> > Security logic is rarely portable between OSes; I wasn't not expecting this > to work verbatim on non-unix.
It should be possible to test ownership and world writability across platforms. At least more easily than testing for privilege. It might still be tricky on any platform to define who a trusted owner is. Show quoted text
>> For the chdir problem, perhaps pp_require could become involved as >> well as the initial loading of @INC.
> > I suspect that will quickly become something too complicated for the current > infrastructure.
I think we're doomed to attempting multiple partial mitigations in the absence of any simple solution that won't cause breakage. I wouldn't rule out looking at pp_require at some point, but I agree there are complications there and it's not a good place to start. Back to Dave's point. If we want any mitigation at all in 5.24.0, it should have been done and ready to go, like a week ago. The only thing that seems simple enough to do quickly is his suggestion of preventing '.' in @INC when root. However, won't the very common idiom: $ sudo cpan -i Acme::Foo fail if Acme::Foo is using Module::Install or if its tests depend on '.' in @INC to find things?
Date: Thu, 21 Apr 2016 00:30:08 -0500
From: John Lightsey <lightsey [...] debian.org>
To: Florian Weimer <fw [...] deneb.enyo.de>
CC: demerphq <demerphq [...] gmail.com>, "perl5-security-report [...] perl.org" <perl5-security-report [...] perl.org>, carnil [...] debian.org, toddr [...] cpan.org
Subject: Re: [perl #127834] Flaws in Perl code due to unsafe module load path
Download (untitled) / with headers
text/plain 2.5k
On Sat, 2016-04-16 at 19:30 +0200, Florian Weimer wrote: Show quoted text
> * John Lightsey: >
> > Filtering @INC in Storable before it tries to load Log::Agent and in > > Encode before it tries to load Encode::ConfigLocal switches 90% of the > > "flawed" scripts on my system to just being "at risk". It's likely that > > changing a dozen or so common modules in this fashion would push that > > number up to 99% or higher. It doesn't guarantee that subsequent > > updates to other modules won't reintroduce a similar flawed behavior, > > but it has a very large immediate effect through very small set of > > changes.
> > It's also an option that has reduced risk of breaking legitimate > user/developer setups which may rely on @INC containing . > > So from a distribution point-of-view, it is more work than a single > patch to Perl itself, but I think it is still preferable for us over > removal of . from the default @INC.
This may help a bit in evaluating any potential fixes... The attached systemtap script will display a message whenever something on the system tries to load a Perl module using the '.' in @INC. It shows the command line of the script, the directory it was running in, and the module it was trying to load. It's much simpler to test with globally than strace. Install systemtap with: apt-get install linux-headers-`uname -r` linux-image-`uname -r`-dbg systemtap Then start it running as root with: stap perl_inc.stap And in another terminal run commands that directly or indirectly execute perl: cd /tmp/ perldoc perlrun apt-get update && apt-get upgrade apt-get install --reinstall exim4-config exim4-daemon-heavy You should see output from systemtap like this: CMD: "/usr/bin/perl /usr/bin/perldoc perlrun" DIR: "/tmp" FILENAME: "./Encode/ConfigLocal.pm" CMD: "/usr/bin/perl /usr/bin/perldoc perlrun" DIR: "/tmp" FILENAME: "./Pod/Perldoc/Toterm.pm" CMD: "/usr/bin/perl -w /usr/bin/apt-show-versions -i" DIR: "/tmp" FILENAME: "./Log/Agent.pm" CMD: "/usr/bin/perl -w /usr/sbin/dpkg-preconfigure --apt" DIR: "/tmp" FILENAME: "./Encode/ConfigLocal.pm" ... The modules that pop out the most on my system with simple perl -c tests are: Encode::ConfigLocal (via Encode) Log::Agent (via Storable) Locale::Maketext::Lexicon (via Local::Maketext::Simple) Mo::builder and Mo::default (via YAML::Mo) Other ones that show up repeatedly when actually running different Perl scripts: Pod::Perldoc::ToXXXX (via Pod::Perldoc's find_good_formatter_class()) Net::LocalConfig (via Net::Config) Term::ReadLine::XXXX (via Term::ReadLine) IO::Uncompress::XXXX (via IO::Uncompress::AnyUncompress)
Download perl_inc.stap
text/plain 370b

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

Download signature.asc
application/pgp-signature 819b

Message body not shown because it is not plain text.

From: Steve Hay via perl5-security-report <perl5-security-report [...] perl.org>
To: John Lightsey <lightsey [...] debian.org>
Date: Sun, 24 Apr 2016 01:16:33 +0100
CC: demerphq <demerphq [...] gmail.com>, toddr [...] cpan.org, carnil [...] debian.org, "perl5-security-report [...] perl.org" <perl5-security-report [...] perl.org>, Florian Weimer <fw [...] deneb.enyo.de>
Subject: Re: [perl #127834] Flaws in Perl code due to unsafe module load path

There has been discussion in this ticket about which version(s) of perl to apply any fixes to, and I'm wondering whether it's worth delaying the release of 5.22.2, which is otherwise due to go ahead tomorrow (24th)?

Does anyone know if any fixes are sufficiently close for that to be sensible and whether there are any plans for 5.24.0 to be delayed?

On 21 Apr 2016 06:30, "John Lightsey" <lightsey@debian.org> wrote:
Show quoted text
On Sat, 2016-04-16 at 19:30 +0200, Florian Weimer wrote:
> * John Lightsey:
>
> > Filtering @INC in Storable before it tries to load Log::Agent and in
> > Encode before it tries to load Encode::ConfigLocal switches 90% of the
> > "flawed" scripts on my system to just being "at risk". It's likely that
> > changing a dozen or so common modules in this fashion would push that
> > number up to 99% or higher. It doesn't guarantee that subsequent
> > updates to other modules won't reintroduce a similar flawed behavior,
> > but it has a very large immediate effect through very small set of
> > changes.
>
> It's also an option that has reduced risk of breaking legitimate
> user/developer setups which may rely on @INC containing .
>
> So from a distribution point-of-view, it is more work than a single
> patch to Perl itself, but I think it is still preferable for us over
> removal of . from the default @INC.

This may help a bit in evaluating any potential fixes...

The attached systemtap script will display a message whenever something
on the system tries to load a Perl module using the '.' in @INC. It
shows the command line of the script, the directory it was running in,
and the module it was trying to load. It's much simpler to test with
globally than strace.

Install systemtap with:

apt-get install linux-headers-`uname -r` linux-image-`uname -r`-dbg systemtap

Then start it running as root with:

stap perl_inc.stap

And in another terminal run commands that directly or indirectly execute perl:

cd /tmp/
perldoc perlrun
apt-get update && apt-get upgrade
apt-get install --reinstall exim4-config exim4-daemon-heavy

You should see output from systemtap like this:

CMD: "/usr/bin/perl /usr/bin/perldoc perlrun" DIR: "/tmp" FILENAME: "./Encode/ConfigLocal.pm"
CMD: "/usr/bin/perl /usr/bin/perldoc perlrun" DIR: "/tmp" FILENAME: "./Pod/Perldoc/Toterm.pm"
CMD: "/usr/bin/perl -w /usr/bin/apt-show-versions -i" DIR: "/tmp" FILENAME: "./Log/Agent.pm"
CMD: "/usr/bin/perl -w /usr/sbin/dpkg-preconfigure --apt" DIR: "/tmp" FILENAME: "./Encode/ConfigLocal.pm"
...

The modules that pop out the most on my system with simple perl -c tests are:

Encode::ConfigLocal (via Encode)
Log::Agent (via Storable)
Locale::Maketext::Lexicon (via Local::Maketext::Simple)
Mo::builder and Mo::default (via YAML::Mo)

Other ones that show up repeatedly when actually running different Perl scripts:

Pod::Perldoc::ToXXXX (via Pod::Perldoc's find_good_formatter_class())
Net::LocalConfig (via Net::Config)
Term::ReadLine::XXXX (via Term::ReadLine)
IO::Uncompress::XXXX (via IO::Uncompress::AnyUncompress)

CC: John Lightsey <lightsey [...] debian.org>, demerphq <demerphq [...] gmail.com>, toddr [...] cpan.org, carnil [...] debian.org, "perl5-security-report [...] perl.org" <perl5-security-report [...] perl.org>, Florian Weimer <fw [...] deneb.enyo.de>
Date: Mon, 25 Apr 2016 09:01:59 +0100
From: Dave Mitchell <davem [...] iabyn.com>
To: Steve Hay <steve.m.hay [...] googlemail.com>
Subject: Re: [perl #127834] Flaws in Perl code due to unsafe module load path
Download (untitled) / with headers
text/plain 692b
On Sun, Apr 24, 2016 at 01:16:33AM +0100, Steve Hay via perl5-security-report wrote: Show quoted text
> There has been discussion in this ticket about which version(s) of perl to > apply any fixes to, and I'm wondering whether it's worth delaying the > release of 5.22.2, which is otherwise due to go ahead tomorrow (24th)? > > Does anyone know if any fixes are sufficiently close for that to be > sensible and whether there are any plans for 5.24.0 to be delayed?
I think we're quite a ways off yet having a clear plan about to what do, so I would suggest releasing 5.22.2 now; we can always push out a 5.22.3 if necessary. -- This is a great day for France! -- Nixon at Charles De Gaulle's funeral
Date: Tue, 26 Apr 2016 17:59:41 +0100
From: Steve Hay via perl5-security-report <perl5-security-report [...] perl.org>
Subject: Re: [perl #127834] Flaws in Perl code due to unsafe module load path
To: Dave Mitchell <davem [...] iabyn.com>
CC: John Lightsey <lightsey [...] debian.org>, demerphq <demerphq [...] gmail.com>, Todd Rinaldo <toddr [...] cpan.org>, carnil [...] debian.org, "perl5-security-report [...] perl.org" <perl5-security-report [...] perl.org>, Florian Weimer <fw [...] deneb.enyo.de>
Download (untitled) / with headers
text/plain 848b
On 25 April 2016 at 09:01, Dave Mitchell <davem@iabyn.com> wrote: Show quoted text
> On Sun, Apr 24, 2016 at 01:16:33AM +0100, Steve Hay via perl5-security-report wrote:
>> There has been discussion in this ticket about which version(s) of perl to >> apply any fixes to, and I'm wondering whether it's worth delaying the >> release of 5.22.2, which is otherwise due to go ahead tomorrow (24th)? >> >> Does anyone know if any fixes are sufficiently close for that to be >> sensible and whether there are any plans for 5.24.0 to be delayed?
> > I think we're quite a ways off yet having a clear plan about to what do, > so I would suggest releasing 5.22.2 now; we can always push out a 5.22.3 > if necessary. >
Ok, thanks for confirmation. I will release 5.22.2 this week, or Saturday at the latest. And I'll be happy to make 5.22.3 with the fix whenever required.
Date: Wed, 27 Apr 2016 16:54:10 +0100
To: John Lightsey <lightsey [...] debian.org>
CC: Florian Weimer <fw [...] deneb.enyo.de>, demerphq <demerphq [...] gmail.com>, "perl5-security-report [...] perl.org" <perl5-security-report [...] perl.org>, carnil [...] debian.org, toddr [...] cpan.org
From: Dave Mitchell <davem [...] iabyn.com>
Subject: Re: [perl #127834] Flaws in Perl code due to unsafe module load path
Download (untitled) / with headers
text/plain 7.5k
I've been doing some more pondering about this "." in @INC malarkey. The way I see it is that the end-goal is for it be be usual for perl to be built with "." excluded. But this is a way off yet as it breaks everything. In the interim, we'd like ideally to present a spectrum of build options for perl which vary the balance of the risks of insecurity verses breakage; people can choose how strict they want their perl to be built as, and the default we select for perl can be make stricter over time. Todd's current patch represents something at the stricter end of the spectrum: it removes "." from @INC completely, but in recognition that: * the perl module build process often relies on ".", * the end-user can't easily fix the perl modules, it makes MakeMaker, cpan etc set an environment var which basically tells perl, "hey, we're doing a module install, reinstate '.'". I'd like to make two further proposals as to what to do at the other end of the spectrum. Here, we include ".", but don't honour it under certain limited circumstances - namely those circumstances which are likely to be exploitable. Both these proposals assume that the "." added by the perl executable itself during startup is specially flagged in some way, meaning that require et al can distinguish it from any other "." in @INC that the script may have added itself. This means that its possible to explicitly override the behaviours I'm about to suggest if the script wants to. First, a mutation of my earlier idea of not including "." if running as root (which has various issues that people pointed out). Instead, how about: when require has located a file using the @INC search path, and the matching @INC entry was the system's ".": then before loading it, check whether the file is owned by either root or the process's euid. If neither, it croaks with some sort of "refuse to load insecure module" error. This should stop most cases of bad files under /tmp, root running a script in another user's home directory etc. It shouldn't affect module builds, assuming the same user runs 'make' as unzipped the distribution tarball. It will still load those files if the script does "use lib '.'"etc, since that "." in @INC is detected as being a different "." from the one perl itself added at startup. I don't know what analogue methods could be used on win and VMS and regards uid and file ownership. I also don;t know whether ACLs on UNIXy platforms will make a difference. My second proposal: since the main issue is *optional* requires, make it so that if require is is about to load a module using the system's "." in @INC, then if require is wrapped in an eval (as determined by scanning the current context stack), then croak. I have a PoC private branch which does just this. I made it so that it only dies for a require with a constant arg, e.g. for require Foo::Bar; require "t/Foo.pm" but not for require $foo; With the const restriction, my PoC branch was able to build and install Moose and its ~45 dependencies. A third thing to do, in the middle of the spectrum, would be to issue a warning each time a module is loaded via the system's ".". This would help people fix up problematic scripts or modules in preparation for moving to a "."-less environment. In summary the spectrum would be something like: 1. current situation: "." always added to @INC apart from in taint or setuid mode. 2. As (1), but require would refuse to honour the system "." entry in a few specific cases, and would croak instead (eval { require }, wrong file ownership). An explicit -I. or "use lib '.'" would always be honoured. 3. As (2),but warn when the system's "." succeeds; 4. Remove "." from @INC completely, but add it back in when we think we're building a module (Todd's patch) 5. as (4), but remove the mechanism to re-add ".". This might be useful for e.g. a specialised secure linux distribution who take their own responsibility for fixing up and building any modules that come bundled with the OS. I can envisage us releasing 5.24.0 with, and patching older perls with, some variant of (2). I don't yet know whether we should include both mechanisms (file ownership and eval detection) or whether one is superior and good enough - I'm swinging towards the ownership option right now, as it seems very simple. Then post 5.24.0, blead gets the full works, selectable by suitable #defines or Configure options, meaning that 5.26.0 can be built in varying levels of strictness. Maybe this could also be back-ported to maint releases? Some thoughts about Todd's current branch. 1. Like others, adding a new, highly-specific environment variable, PERL_USE_UNSAFE_INC, makes me twitchy. How about instead: we add a new perl switch, -J, which is exactly the same as -I, except that it *appends* to @INC rather than prepending. This sounds reasonably general-purpose and useful in its own right. Then the effect of setting PERL_USE_UNSAFE_INC in MakeMaker etc can be achieved more of less equivalently with : $ENV{PERL5OPT} .= ' -J.' if $] >= 5.024000 The main issue is when setting this in places like MakeMaker and the cpan executable, whether some parts of the build process invoked from there would want to run a sub-process using a different perl (and version) than that currently running? If so the child could croak with "Unrecognized switch: -J". 2) should perl also special-case Makefile.PL and Build.PL? That is to say, if the name of the executable perl is about to execute looks like one of those two, should it add back "."? Otherwise a lot of distributions will fail to build if done manually (rather than via cpan), e.g. $ perl Makefile.PL since things like 'use inc::Module::Install' in the script will fail. 3) should the MakeMaker and cpan hacks only set the PERL_USE_UNSAFE_INC / PERL5OPT env var if $Config{inc_dot or whatever} has the right value? Thus a perl built with the fully-fascist option wouldn't be adding -J. to PERL5OPT or whatever. 4) I'm a bit puzzled why PERL_USE_UNSAFE_INC is set in the cpan executable rather than in CPAN.pm? 5) I'm also a bit puzzled why MakeMaker sets PERL_USE_UNSAFE_INC=1 in MM_Unix.pm when it calls out to perl? Isn't this already covered by the $ENV{PERL_USE_UNSAFE_INC} = 1 in MakeMaker.pm? Some other general thoughts. I think I'm in favour of also patching common dual-lived modules that we bundle with perl which have this issue (Storable, Encode etc), since they may end up getting installed on older perls which don't have any of the workarounds, thus strengthening (slightly) older installations. But perhaps only after 5.24.0? But in those modules, the localisation of @INC to remove "." should be done in such a way that's it possible for the script to override this with an explicit "use lib '.'" or similar. So for example it might only remove the *last* ".", e.g. something along the lines of: { my $seen = 0; local @INC = reverse grep !$seen && $_ eq "." && ($seen=1), reverse @INC; eval { require Optional::Module } } We should also do an audit of core modules and similarly fix up any that appear to be loading optional modules. Both Tony and Leon seemed keen to hide the unsafe_inc Configure option "a little deeper", e.g. make it done with -Accflags=-D... rather than as a Configure option. I don't yet have a strong opinion either way, but I would be interested to hear arguments for and against. Should all scripts that come bundled with the perl core remove "." (if possible)? I think probably yes. -- My Dad used to say 'always fight fire with fire', which is probably why he got thrown out of the fire brigade.
Subject: Re: [perl #127834] Flaws in Perl code due to unsafe module load path
From: Zefram <zefram [...] fysh.org>
To: "perl5-security-report [...] perl.org" <perl5-security-report [...] perl.org>
CC: John Lightsey <lightsey [...] debian.org>, Florian Weimer <fw [...] deneb.enyo.de>, carnil [...] debian.org
Date: Wed, 27 Apr 2016 18:00:29 +0100
Download (untitled) / with headers
text/plain 3.4k
Dave Mitchell wrote: Show quoted text
> In the interim, we'd like ideally to present a spectrum of >build options for perl which vary the balance of the risks of insecurity >verses breakage;
Maybe. Show quoted text
>Both these proposals assume that the "." added by the perl executable >itself during startup is specially flagged in some way,
It's recognisable by being at the very end of @INC. Both lib.pm and -I prepend. It would be rather uncomfortable to add any flag other than this. Show quoted text
> when require has located a file using the @INC search path, and the >matching @INC entry was the system's ".": then before loading it, >check whether the file is owned by either root or the process's euid.
For this general approach, this semantic is not sufficient. root might well have dangerous code in a file without intending for Perl to load it as an optional module. You need to verify the whole lookup from name to code, i.e., you need to also check ownership of each directory in the chain, starting from "." and going down to the directory containing the purported module file. It's also good to check permissions of each entity, and this check alone would rule out loading anything from /tmp. I'm ambivalent about whether this kind of semantic is a good idea. On one hand, with my tightened version there are still ways to surprise a user. On the other hand, tarballs for CPAN dists are liable to be extracted with ownerships from the author's machine (if installing as root), so that even the flimsiest ownership checks would prevent loading things bundled in the dist. Show quoted text
> I also don;t know whether ACLs on UNIXy >platforms will make a difference.
One ought to check the ACL if one is checking permissions. This is not difficult. Show quoted text
>My second proposal: since the main issue is *optional* requires, make it >so that if require is is about to load a module using the system's "." in >@INC, then if require is wrapped in an eval (as determined by scanning the >current context stack), then croak.
This strikes me as too much magic. The semantics are surprising, and break basic code composability. Show quoted text
>A third thing to do, in the middle of the spectrum, would be to issue >a warning each time a module is loaded via the system's ".". This would >help people fix up problematic scripts or modules in preparation for >moving to a "."-less environment.
That's the *only* thing this option is good for, and it doesn't seem the kind of thing that one can decide at Perl build time. An environment variable would be a better way of controlling such a warning. Show quoted text
> whether some parts of the build process invoked from there >would want to run a sub-process using a different perl (and version) than that >currently running?
No, that doesn't happen. Show quoted text
>2) should perl also special-case Makefile.PL and Build.PL?
No, that would be way too magical. Show quoted text
>But in those modules, the localisation of @INC to remove "." should be >done in such a way that's it possible for the script to override >this with an explicit "use lib '.'" or similar.
Recognising the automatic "." by it being at the end of @INC satisfies this requirement. Show quoted text
>only remove the *last* ".",
That breaks "use lib '.'" if the automatic "." is not being added, due to taint or configuration. The criterion has to be to only remove a "." from the very end of @INC. Show quoted text
>Should all scripts that come bundled with the perl core remove > "." (if possible)? I think probably yes.
Yes. I think all Perl scripts should. -zefram
Date: Thu, 28 Apr 2016 15:48:14 -0500
CC: John Lightsey <lightsey [...] debian.org>, Florian Weimer <fw [...] deneb.enyo.de>, demerphq <demerphq [...] gmail.com>, "perl5-security-report [...] perl.org" <perl5-security-report [...] perl.org>, carnil [...] debian.org, Todd Rinaldo <toddr [...] cpan.org>
To: Dave Mitchell <davem [...] iabyn.com>
Subject: Re: [perl #127834] Flaws in Perl code due to unsafe module load path
From: "Craig A. Berry" <craig.a.berry [...] gmail.com>
Download (untitled) / with headers
text/plain 2.2k
On Wed, Apr 27, 2016 at 10:54 AM, Dave Mitchell <davem@iabyn.com> wrote: Show quoted text
> First, a mutation of my earlier idea of not including "." if running as > root (which has various issues that people pointed out). Instead, how > about: when require has located a file using the @INC search path, and the > matching @INC entry was the system's ".": then before loading it, > check whether the file is owned by either root or the process's euid. If > neither, it croaks with some sort of "refuse to load insecure module" > error. This should stop most cases of bad files under /tmp, root running > a script in another user's home directory etc. It shouldn't affect > module builds, assuming the same user runs 'make' as unzipped the > distribution tarball. It will still load those files if the script > does "use lib '.'"etc, since that "." in @INC is detected as being a > different "." from the one perl itself added at startup.
There would also have to be a writability check, wouldn't there? If I own a file but the file or the directory it's in have world (or maybe even group) write access, can't someone rewrite it with malicious content while preserving my ownership? Show quoted text
> I don't know what analogue methods could be used on win and VMS and > regards uid and file ownership.
Ownership and permissions should map pretty easily, but "am I root?" is harder. However, the number of VMS and Windows systems that run vendor-suppled Perl scripts with elevated privileges as part of standard operations (e.g., installers) is going to be tiny to nonexistent compared to Unixy systems that do so. Therefore I think a solution that's not completely portable on first iteration is probably acceptable in the short run. Let's put a finger in the dike where the worst breach is likely to occur while we look for places to put the other nine fingers. Show quoted text
> I also don;t know whether ACLs on UNIXy > platforms will make a difference.
I think ACLs on any OS are going to be a challenge because the question is not "do I have access via ACL?" but "can all of the users and groups who have write access via ACL be trusted not to leave a bomb for me to step on?". Making sure no one at all has write access via ACL may be the safest and simplest thing (not that it's particularly easy to do cross-platform).
RT-Send-CC: rt-deliver-to-perl5-security-report [...] rt.perl.org
Download (untitled) / with headers
text/plain 2.1k
On Wed Apr 27 09:05:32 2016, davem wrote: Show quoted text
> Both Tony and Leon seemed keen to hide the unsafe_inc Configure option > "a > little deeper", e.g. make it done with -Accflags=-D... rather than as > a > Configure option. I don't yet have a strong opinion either way, but I > would be interested to hear arguments for and against.
My attitude is if this is a security fix, then lets fix it - don't provide an explicit build-time mechanism to put the '.' back in, but make the builder require a little knowledge. I don't think perl needs more build variants. As with -DNO_TAINT_SUPPORT, a perl built with such an option is not supported by p5p. By simply removing it early in the 5.25 series we provide plenty[1] of time for downstream users to adjust their code to add '.' back in where needed. The idea of making the '.' we add magic so it doesn't work in a limited set of recognizable security issues strikes me as a rabbit hole we don't want to jump into, since there's always going to be another issue that we didn't pick up that's going to bite someone. In terms of whether we provide an environment variable beyond PERL5LIB to add '.' back in... The simple cases that occurred to me: - Module::Build Makefile.PL scripts and similar, - scripts designed to be run from a particular working directory with supporting modules below them struck me as *less* likely to fail with '.' in at the front of @INC (as with PERL5LIB), which is why I dislike the PERL_USE_UNSAFE_INC=1 solution, I didn't see a practical case where it matters (probably a failure of imagination). If we're going to provide a mechanism to add '.' at the end of @INC controlled by an environment variable, something like PERL5PUSHLIB=. seems to me to be a more general solution and perhaps useful in some extra cases. As for 5.24 and earlier... I don't think we can simply remove '.' from @INC, and it may end up meaning that any code that wants to work with 5.24 and earlier *and* avoid loading optional modules from the current directory will need to remove that final '.' itself. This particular bug can bite Imager too, since it can load file handling modules at runtime. Tony [1] we'd want to announce it on blogs.perl.org and possibly other places
Date: Tue, 3 May 2016 13:32:39 -0500
To: Dave Mitchell <davem [...] iabyn.com>
CC: John Lightsey <lightsey [...] debian.org>, Florian Weimer <fw [...] deneb.enyo.de>, demerphq <demerphq [...] gmail.com>, "perl5-security-report [...] perl.org" <perl5-security-report [...] perl.org>, carnil [...] debian.org, team [...] security.debian.org
From: Todd Rinaldo <toddr [...] cpanel.net>
Subject: Re: [perl #127834] Flaws in Perl code due to unsafe module load path
Download (untitled) / with headers
text/plain 4.3k
Show quoted text
> On Apr 27, 2016, at 10:54 AM, Dave Mitchell <davem@iabyn.com> wrote: > > I've been doing some more pondering about this "." in @INC malarkey. > > 2. As (1), but require would refuse to honour the system "." entry in a few > specific cases, and would croak instead (eval { require }, wrong file > ownership). An explicit -I. or "use lib '.'" would always be honoured.
I really like this idea. I don't think the use lib inside a eval is particularly likely so I wouldn't even special case this. This seems like a viable backport option. Once one enters the eval block, ideally you wouldn't want to strip . from @INC unless require is going to happen, which means require needs to somehow know it's inside an eval. If that's easily done, this could potentially be a small patch that could be easily backported to previous major versions of Perl. Or to rephrase: Don't try "." if it's at the end of @INC and you're in an eval. Show quoted text
> 3. As (2),but warn when the system's "." succeeds;
Meh. This just emits unexpected noise on a legacy version of Perl. The noise could have unexpected side effects. I'm not sure that's desirable. Show quoted text
> I can envisage us releasing 5.24.0 with, and patching older perls with, > some variant of (2). I don't yet know whether we should include both > mechanisms (file ownership and eval detection) or whether one is superior > and good enough - I'm swinging towards the ownership option right now, as > it seems very simple. Then post 5.24.0, blead gets the full works, > selectable by suitable #defines or Configure options, meaning that > 5.26.0 can be built in varying levels of strictness. Maybe this could > also be back-ported to maint releases?
IMO, the ownership check is very OS specific and you're going to spend quite a bit of time debugging it after you post the CVE. There's also the question of properly validating the entire directory tree. This isn't really something in Perl's wheel house and introducing it for a backport seems problematic. I would suggest holding this in the wings in case a problem comes up with the eval approach. Show quoted text
> Some thoughts about Todd's current branch.
These are good ideas but I'd I'd prefer discussing this in the public ticket since they do not apply to 5.24 and below. Show quoted text
> I think I'm in favour of also patching common dual-lived modules that we > bundle with perl which have this issue (Storable, Encode etc), since they > may end up getting installed on older perls which don't have any of the > workarounds, thus strengthening (slightly) older installations. But > perhaps only after 5.24.0?
+1. I think fixing both core modules and patching Perl (if it can be simplified enough) should be done together as part of the initial public disclosure. I think this needs to be done after 5.24.0 goes out. Show quoted text
> But in those modules, the localisation of @INC to remove "." should be > done in such a way that's it possible for the script to override > this with an explicit "use lib '.'" or similar. So for example it might > only remove the *last* ".", e.g. something along the lines of: > > { > my $seen = 0; > local @INC = > reverse grep !$seen && $_ eq "." && ($seen=1), reverse @INC; > eval { require Optional::Module } > }
or eval { local @INC = @INC; pop @INC if($INC[$#INC] eq '.'); require Optional::Module } or: If people really want to overcome the use lib "." problem, they could do use lib "./" and overcome the above issue. Seriously, though, who the heck needs this behavior in production code? Show quoted text
> > We should also do an audit of core modules and similarly fix up any that > appear to be loading optional modules.
+1 This sounds like a viable proposal to me about how you fix the reported problem for legacy versions of Perl. To summarize: 1. Patch eval blocks to skip "." at the end of @INC in use/require/do. 2. Patch modules shipped with Perl that try to load optional modules. 3. Patch perl scripts installed during make install which depend on . in @INC. 4. Update dual life modules on CPAN. I realize there is action at a distance / magic going on in this fix. I would argue there always was. I see this as a trade off. Yes, we're changing the magic. But the magic to load optional modules from . was probably rarely used in production. And the work around to anything this breaks is to fix it in the script by using the optional module prior to loading Storable/Encode/etc. Todd
CC: John Lightsey <lightsey [...] debian.org>, "perl5-security-report [...] perl.org" <perl5-security-report [...] perl.org>, carnil [...] debian.org, fw [...] deneb.enyo.de, toddr [...] cpan.org
To: demerphq <demerphq [...] gmail.com>
Subject: Re: [perl #127834] Flaws in Perl code due to unsafe module load path
From: Ricardo Signes <perl.security [...] rjbs.manxome.org>
Date: Mon, 9 May 2016 08:36:48 -0400
Download (untitled) / with headers
text/plain 665b
* demerphq <demerphq@gmail.com> [2016-04-16T09:57:07] Show quoted text
> I worry that discussing the fix for 5.26 in a public thread is a good > idea actually.
I think this thread might as well be in public, but I leave it to the rest of the team to decide whether they agree with that. I am considering leaving the security list now, or at least reading its mail a lot less readily. One thing I wanted to make sure had been considered: removing "." by default from @INC will break every Module::Install-based dist on the CPAN -- over 10% of the CPAN by my last count, a month ago. Users can't upgrade their local Module::Install to fix it, it doesn't work that way. -- rjbs
Download signature.asc
application/pgp-signature 473b

Message body not shown because it is not plain text.

CC: demerphq <demerphq [...] gmail.com>, John Lightsey <lightsey [...] debian.org>, "perl5-security-report [...] perl.org" <perl5-security-report [...] perl.org>, carnil [...] debian.org, fw [...] deneb.enyo.de, toddr [...] cpan.org
To: Ricardo Signes <perl.security [...] rjbs.manxome.org>
From: Dave Mitchell <davem [...] iabyn.com>
Subject: Re: [perl #127834] Flaws in Perl code due to unsafe module load path
Date: Tue, 10 May 2016 11:15:21 +0100
Download (untitled) / with headers
text/plain 813b
On Mon, May 09, 2016 at 08:36:48AM -0400, Ricardo Signes wrote: Show quoted text
> * demerphq <demerphq@gmail.com> [2016-04-16T09:57:07]
> > I worry that discussing the fix for 5.26 in a public thread is a good > > idea actually.
> > I think this thread might as well be in public
Given that the nature of this bug is that (possibly many) UNIX-like admin scripts intended to be run by root can be used to give any non-root user super-user privileges if that script happens to be run while root is chdired to an unsafe directory such as /tmp (as was demonstrated with apt-get), and given that (as far as I'm aware) this is not yet generally publicly known, I think we most definitely should not make this public until full fixes are available. -- "Emacs isn't a bad OS once you get used to it. It just lacks a decent editor."
From: Salvatore Bonaccorso <carnil [...] debian.org>
Subject: Re: [perl #127834] Flaws in Perl code due to unsafe module load path
To: Dave Mitchell <davem [...] iabyn.com>
CC: Ricardo Signes <perl.security [...] rjbs.manxome.org>, demerphq <demerphq [...] gmail.com>, John Lightsey <lightsey [...] debian.org>, "perl5-security-report [...] perl.org" <perl5-security-report [...] perl.org>, carnil [...] debian.org, fw [...] deneb.enyo.de, toddr [...] cpan.org
Date: Tue, 10 May 2016 14:07:15 +0200
Hi all, On Tue, May 10, 2016 at 11:15:21AM +0100, Dave Mitchell wrote: Show quoted text
> On Mon, May 09, 2016 at 08:36:48AM -0400, Ricardo Signes wrote:
> > * demerphq <demerphq@gmail.com> [2016-04-16T09:57:07]
> > > I worry that discussing the fix for 5.26 in a public thread is a good > > > idea actually.
> > > > I think this thread might as well be in public
> > Given that the nature of this bug is that (possibly many) UNIX-like admin > scripts intended to be run by root can be used to give any non-root user > super-user privileges if that script happens to be run while root is > chdired to an unsafe directory such as /tmp (as was demonstrated with > apt-get), and given that (as far as I'm aware) this is not yet generally > publicly known, I think we most definitely should not make this public > until full fixes are available.
Agree on it. Additionally (separately) we probably need to look at if in Debian we want to address the apt tools cases separately independently how the solution on Perl's side will look. Florian what do you think? Salvatore
Date: Tue, 10 May 2016 09:56:16 -0500
CC: Ricardo Signes <perl.security [...] rjbs.manxome.org>, demerphq <demerphq [...] gmail.com>, "perl5-security-report [...] perl.org" <perl5-security-report [...] perl.org>, fw [...] deneb.enyo.de, toddr [...] cpan.org
To: Salvatore Bonaccorso <carnil [...] debian.org>, Dave Mitchell <davem [...] iabyn.com>
From: John Lightsey <lightsey [...] debian.org>
Subject: Re: [perl #127834] Flaws in Perl code due to unsafe module load path
Download (untitled) / with headers
text/plain 1.9k
On Tue, 2016-05-10 at 14:07 +0200, Salvatore Bonaccorso wrote: Show quoted text
> Hi all, > > On Tue, May 10, 2016 at 11:15:21AM +0100, Dave Mitchell wrote:
> > On Mon, May 09, 2016 at 08:36:48AM -0400, Ricardo Signes wrote:
> > > * demerphq <demerphq@gmail.com> [2016-04-16T09:57:07]
> > > > I worry that discussing the fix for 5.26 in a public thread is a good > > > > idea actually.
> > >  > > > I think this thread might as well be in public
> >  > > Given that the nature of this bug is that (possibly many) UNIX-like admin > > scripts intended to be run by root can be used to give any non-root user > > super-user privileges if that script happens to be run while root is > > chdired to an unsafe directory such as /tmp (as was demonstrated with > > apt-get), and given that (as far as I'm aware) this is not yet generally > > publicly known, I think we most definitely should not make this public > > until full fixes are available.
> > Agree on it. > > Additionally (separately) we probably need to look at if in Debian we > want to address the apt tools cases separately independently how the > solution on Perl's side will look. Florian what do you think? >
Was there ever a clear decision on how @INC related vulnerabilities should be fixed for existing deployments of Perl? The various discussions seemed to die off without any decision on this. 1) Fix the Perl core for older versions of Perl. Multiple options for this were discussed. 2) Fix modules that load other optional modules without sanitizing @INC. 3) Fix scripts individually that load modules that have or inherit this behavior. 4) Do nothing and leave it as a risk for end users. It would really help get this progressing if the Perl security team made a clear decision about where to assign responsibility for the vulnerabilities in versions of Perl before 5.26. For instance, how does the Perl security team plan to fix perldoc in 5.22? All of the various components (script, modules, interpreter) are under p5p's control in this case. Which do you intend to patch?
Download signature.asc
application/pgp-signature 819b

Message body not shown because it is not plain text.

CC: Salvatore Bonaccorso <carnil [...] debian.org>, Dave Mitchell <davem [...] iabyn.com>, Ricardo Signes <perl.security [...] rjbs.manxome.org>, demerphq <demerphq [...] gmail.com>, "perl5-security-report [...] perl.org" <perl5-security-report [...] perl.org>, fw [...] deneb.enyo.de, toddr [...] cpan.org
To: John Lightsey <lightsey [...] debian.org>
From: Sawyer X <xsawyerx [...] gmail.com>
Subject: Re: [perl #127834] Flaws in Perl code due to unsafe module load path
Date: Tue, 10 May 2016 18:36:24 +0200
Download (untitled) / with headers
text/plain 2.1k
A quick side-note: Has anyone contacted Mitre to assign a CVE to it? On Tue, May 10, 2016 at 4:56 PM, John Lightsey <lightsey@debian.org> wrote: Show quoted text
> On Tue, 2016-05-10 at 14:07 +0200, Salvatore Bonaccorso wrote:
>> Hi all, >> >> On Tue, May 10, 2016 at 11:15:21AM +0100, Dave Mitchell wrote:
>> > On Mon, May 09, 2016 at 08:36:48AM -0400, Ricardo Signes wrote:
>> > > * demerphq <demerphq@gmail.com> [2016-04-16T09:57:07]
>> > > > I worry that discussing the fix for 5.26 in a public thread is a good >> > > > idea actually.
>> > > >> > > I think this thread might as well be in public
>> > >> > Given that the nature of this bug is that (possibly many) UNIX-like admin >> > scripts intended to be run by root can be used to give any non-root user >> > super-user privileges if that script happens to be run while root is >> > chdired to an unsafe directory such as /tmp (as was demonstrated with >> > apt-get), and given that (as far as I'm aware) this is not yet generally >> > publicly known, I think we most definitely should not make this public >> > until full fixes are available.
>> >> Agree on it. >> >> Additionally (separately) we probably need to look at if in Debian we >> want to address the apt tools cases separately independently how the >> solution on Perl's side will look. Florian what do you think? >>
> > Was there ever a clear decision on how @INC related vulnerabilities should be > fixed for existing deployments of Perl? The various discussions seemed to die > off without any decision on this. > > 1) Fix the Perl core for older versions of Perl. Multiple options for this were > discussed. > > 2) Fix modules that load other optional modules without sanitizing @INC. > > 3) Fix scripts individually that load modules that have or inherit this > behavior. > > 4) Do nothing and leave it as a risk for end users. > > It would really help get this progressing if the Perl security team made a clear > decision about where to assign responsibility for the vulnerabilities in > versions of Perl before 5.26. > > For instance, how does the Perl security team plan to fix perldoc in 5.22? All > of the various components (script, modules, interpreter) are under p5p's control > in this case. Which do you intend to patch?
From: Todd Rinaldo <toddr [...] cpanel.net>
Subject: Re: [perl #127834] Flaws in Perl code due to unsafe module load path
CC: John Lightsey <lightsey [...] debian.org>, Salvatore Bonaccorso <carnil [...] debian.org>, Dave Mitchell <davem [...] iabyn.com>, Ricardo Signes <perl.security [...] rjbs.manxome.org>, demerphq <demerphq [...] gmail.com>, "perl5-security-report [...] perl.org" <perl5-security-report [...] perl.org>, fw [...] deneb.enyo.de, toddr [...] cpan.org
To: Sawyer X <xsawyerx [...] gmail.com>
Date: Tue, 10 May 2016 11:41:04 -0500
Download (untitled) / with headers
text/plain 2.6k
Sawyer, Wouldn't it first require p5p to state their position? If you're saying it's the script writer's problem, then this is the Debian Security team's issue to address. To my knowledge they have the ability to issue CVE numbers also. Given they're involved with this you could probably just ask them for it depending on the decision. Todd Show quoted text
> On May 10, 2016, at 11:36 AM, Sawyer X <xsawyerx@gmail.com> wrote: > > A quick side-note: Has anyone contacted Mitre to assign a CVE to it? > > On Tue, May 10, 2016 at 4:56 PM, John Lightsey <lightsey@debian.org> wrote:
>> On Tue, 2016-05-10 at 14:07 +0200, Salvatore Bonaccorso wrote:
>>> Hi all, >>> >>> On Tue, May 10, 2016 at 11:15:21AM +0100, Dave Mitchell wrote:
>>>> On Mon, May 09, 2016 at 08:36:48AM -0400, Ricardo Signes wrote:
>>>>> * demerphq <demerphq@gmail.com> [2016-04-16T09:57:07]
>>>>>> I worry that discussing the fix for 5.26 in a public thread is a good >>>>>> idea actually.
>>>>> >>>>> I think this thread might as well be in public
>>>> >>>> Given that the nature of this bug is that (possibly many) UNIX-like admin >>>> scripts intended to be run by root can be used to give any non-root user >>>> super-user privileges if that script happens to be run while root is >>>> chdired to an unsafe directory such as /tmp (as was demonstrated with >>>> apt-get), and given that (as far as I'm aware) this is not yet generally >>>> publicly known, I think we most definitely should not make this public >>>> until full fixes are available.
>>> >>> Agree on it. >>> >>> Additionally (separately) we probably need to look at if in Debian we >>> want to address the apt tools cases separately independently how the >>> solution on Perl's side will look. Florian what do you think? >>>
>> >> Was there ever a clear decision on how @INC related vulnerabilities should be >> fixed for existing deployments of Perl? The various discussions seemed to die >> off without any decision on this. >> >> 1) Fix the Perl core for older versions of Perl. Multiple options for this were >> discussed. >> >> 2) Fix modules that load other optional modules without sanitizing @INC. >> >> 3) Fix scripts individually that load modules that have or inherit this >> behavior. >> >> 4) Do nothing and leave it as a risk for end users. >> >> It would really help get this progressing if the Perl security team made a clear >> decision about where to assign responsibility for the vulnerabilities in >> versions of Perl before 5.26. >> >> For instance, how does the Perl security team plan to fix perldoc in 5.22? All >> of the various components (script, modules, interpreter) are under p5p's control >> in this case. Which do you intend to patch?
From: Sawyer X <xsawyerx [...] gmail.com>
Subject: Re: [perl #127834] Flaws in Perl code due to unsafe module load path
CC: John Lightsey <lightsey [...] debian.org>, Salvatore Bonaccorso <carnil [...] debian.org>, Dave Mitchell <davem [...] iabyn.com>, Ricardo Signes <perl.security [...] rjbs.manxome.org>, demerphq <demerphq [...] gmail.com>, "perl5-security-report [...] perl.org" <perl5-security-report [...] perl.org>, fw [...] deneb.enyo.de, toddr [...] cpan.org
To: Todd Rinaldo <toddr [...] cpanel.net>
Date: Tue, 10 May 2016 18:44:35 +0200
Download (untitled) / with headers
text/plain 2.8k
I just want to make sure I have all my ducks in a row. :) On Tue, May 10, 2016 at 6:41 PM, Todd Rinaldo <toddr@cpanel.net> wrote: Show quoted text
> Sawyer, > > Wouldn't it first require p5p to state their position? If you're saying it's the script writer's problem, then this is the Debian Security team's issue to address. To my knowledge they have the ability to issue CVE numbers also. Given they're involved with this you could probably just ask them for it depending on the decision. > > Todd >
>> On May 10, 2016, at 11:36 AM, Sawyer X <xsawyerx@gmail.com> wrote: >> >> A quick side-note: Has anyone contacted Mitre to assign a CVE to it? >> >> On Tue, May 10, 2016 at 4:56 PM, John Lightsey <lightsey@debian.org> wrote:
>>> On Tue, 2016-05-10 at 14:07 +0200, Salvatore Bonaccorso wrote:
>>>> Hi all, >>>> >>>> On Tue, May 10, 2016 at 11:15:21AM +0100, Dave Mitchell wrote:
>>>>> On Mon, May 09, 2016 at 08:36:48AM -0400, Ricardo Signes wrote:
>>>>>> * demerphq <demerphq@gmail.com> [2016-04-16T09:57:07]
>>>>>>> I worry that discussing the fix for 5.26 in a public thread is a good >>>>>>> idea actually.
>>>>>> >>>>>> I think this thread might as well be in public
>>>>> >>>>> Given that the nature of this bug is that (possibly many) UNIX-like admin >>>>> scripts intended to be run by root can be used to give any non-root user >>>>> super-user privileges if that script happens to be run while root is >>>>> chdired to an unsafe directory such as /tmp (as was demonstrated with >>>>> apt-get), and given that (as far as I'm aware) this is not yet generally >>>>> publicly known, I think we most definitely should not make this public >>>>> until full fixes are available.
>>>> >>>> Agree on it. >>>> >>>> Additionally (separately) we probably need to look at if in Debian we >>>> want to address the apt tools cases separately independently how the >>>> solution on Perl's side will look. Florian what do you think? >>>>
>>> >>> Was there ever a clear decision on how @INC related vulnerabilities should be >>> fixed for existing deployments of Perl? The various discussions seemed to die >>> off without any decision on this. >>> >>> 1) Fix the Perl core for older versions of Perl. Multiple options for this were >>> discussed. >>> >>> 2) Fix modules that load other optional modules without sanitizing @INC. >>> >>> 3) Fix scripts individually that load modules that have or inherit this >>> behavior. >>> >>> 4) Do nothing and leave it as a risk for end users. >>> >>> It would really help get this progressing if the Perl security team made a clear >>> decision about where to assign responsibility for the vulnerabilities in >>> versions of Perl before 5.26. >>> >>> For instance, how does the Perl security team plan to fix perldoc in 5.22? All >>> of the various components (script, modules, interpreter) are under p5p's control >>> in this case. Which do you intend to patch?
>
Date: Tue, 10 May 2016 19:03:35 +0200
Subject: Re: [perl #127834] Flaws in Perl code due to unsafe module load path
From: Florian Weimer <fw [...] deneb.enyo.de>
CC: carnil [...] debian.org, lightsey [...] debian.org, toddr [...] cpan.org
To: "Sawyer X via RT" <perl5-security-report [...] perl.org>
Download (untitled) / with headers
text/plain 333b
* Sawyer X. via: Show quoted text
> A quick side-note: Has anyone contacted Mitre to assign a CVE to it?
Debian can assign CVE IDs as needed, but we'd need agreement before that where the bug actually lies (Perl proper, scripts not sanitizing the environment, or scripts and libraries doing unsafe things). Florian (for the Debian security team)
RT-Send-CC: rt-deliver-to-perl5-security-report [...] rt.perl.org
Download (untitled) / with headers
text/plain 1.7k
I apologize it took me this long to reply. I wanted to read through everything thoroughly. I think we have two different directions here: Solving the current situation (5.24 and below) and solving this for future versions (5.26 and above). The latter (future versions) is discussed in public already. Considering the gravity of this issue for released versions, I would like to keep the security issue retained until the various distributors have a chance to respond properly. As for solutions, I think there is at least an agreement on fixing scripts in Perl core. Did I understand this correctly? When it comes to changing modules in core, I agree with Zefram that modules are not the correct place to patch this problem, but I do consider any change which drastically reduces such security risks for users (demonstrated by John) a viable option. Other than the theoretical concept of separation of concerns, I would like to know if anyone has any practical objection to changing core modules. Continuing with the idea of patching modules, I think we should consider not only core modules, but also core CPAN modules not under our purview in order to minimize the security risk for users of CPAN modules as a whole. This would mainly require addressing the maintainers for their assistance. Coordination would not be simple, but we could go through a reasonable cascading schedule just like with other security problems. I would be happy to hear any opinions about this option. Are there any objections to this? Excluding all solution ideas for future versions mentioned here, the main option I seem to see here (please correct me if I'm wrong) would be checking permissions. How viable would it be to: 1. Implement it, and 2. Provide it in older versions of Perl? How much did I miss? How much did I misunderstand?
From: John Lightsey <lightsey [...] debian.org>
Subject: Re: [perl #127834] Flaws in Perl code due to unsafe module load path
To: perl5-security-report [...] perl.org, carnil [...] debian.org, fw [...] deneb.enyo.de, toddr [...] cpan.org
Date: Sat, 14 May 2016 10:16:56 -0500
Download (untitled) / with headers
text/plain 4.2k
On Thu, 2016-05-12 at 20:34 -0700, Sawyer X via RT wrote: Show quoted text
> I apologize it took me this long to reply. I wanted to read through everything > thoroughly. > > I think we have two different directions here: Solving the current situation > (5.24 and below) and solving this for future versions (5.26 and above). The > latter (future versions) is discussed in public already. Considering the > gravity of this issue for released versions, I would like to keep the security > issue retained until the various distributors have a chance to respond > properly. > > As for solutions, I think there is at least an agreement on fixing scripts in > Perl core. Did I understand this correctly? > > When it comes to changing modules in core, I agree with Zefram that modules > are not the correct place to patch this problem, but I do consider any change > which drastically reduces such security risks for users (demonstrated by John) > a viable option. Other than the theoretical concept of separation of concerns, > I would like to know if anyone has any practical objection to changing core > modules. > > Continuing with the idea of patching modules, I think we should consider not > only core modules, but also core CPAN modules not under our purview in order > to minimize the security risk for users of CPAN modules as a whole. This would > mainly require addressing the maintainers for their assistance. Coordination > would not be simple, but we could go through a reasonable cascading schedule > just like with other security problems. I would be happy to hear any opinions > about this option. Are there any objections to this?
I think it's best to focus on the modules in core and the explanation of the problem that is being fixed in the first pass. It's difficult to get many developers to fix vulnerabilities that are only exploitable locally. Many developers are dismissive of these types of vulnerabilities and will simply refuse to fix them. If you try to coordinate a simultaneous fix too widely, you'll end up waiting on developers that don't consider the attack valid. For example, when cPanel reported Storable attacks to the Perl security team years ago and were told that Storable would not be "fixed" to be safe for untrusted inputs, it made several other codebases vulnerable by virtue of using Storable in this role. I reported many of these flaws and the fix rate was better when I referenced p5p's statements on the subject and better still after I publicly released weaponized attacks for some of the fixed software and used the weaponized attacks as examples. For security folks, releasing weaponized attacks seems like a counterproductive behavior, but in my experience, developers are very unlikely to fix any novel types of attack without seeing examples of it weaponized. IMHO, the best course of action overall is to get the codebases under perl- security and debian-security's control in order enough to discuss the attacks publicly so that the Perl ecosystem as a whole will start to internalize and correct the problem. Show quoted text
> > Excluding all solution ideas for future versions mentioned here, the main > option I seem to see here (please correct me if I'm wrong) would be checking > permissions. How viable would it be to: 1. Implement it, and 2. Provide it in > older versions of Perl?
By "checking permissions", you're referring to the idea of changing module load behavior directly in the Perl interpreter, right? That seemed like an unrealistic option to me. The behavior as described would leave other attack scenarios open, would be complicated to implement correctly, and would be difficult to explain to developers encountering it. The other option of changing module load behavior inside an eval sounds much better to me as a backportable fix, but my guess is that it'll break CPAN even more than the PERL_USE_UNSAFE_INC approach does. I might be wrong though...perhaps someone can test Dave Mitchell's patch that uses this approach? Show quoted text
> > How much did I miss? How much did I misunderstand?
Seems pretty complete to me, but I'm still not entirely clear whether you're saying the way forward (for 5.24 and earlier) is to patch the modules or patch the interpreter. If you're strongly leaning towards the "patch the modules" approach, I can spend some time getting a better list of exactly what would need to be patched in core Perl to make this work.
Download signature.asc
application/pgp-signature 819b

Message body not shown because it is not plain text.

CC: perl5-security-report [...] perl.org, carnil [...] debian.org, fw [...] deneb.enyo.de, toddr [...] cpan.org
To: John Lightsey <lightsey [...] debian.org>
From: Todd E Rinaldo <toddr [...] cpanel.net>
Subject: Re: [perl #127834] Flaws in Perl code due to unsafe module load path
Date: Sat, 14 May 2016 10:58:42 -0500
Download (untitled) / with headers
text/plain 4.6k
So I don't Warnock (https://en.wikipedia.org/wiki/Warnock%27s_dilemma) this discussion, I agree with John's reply. 

On May 14, 2016, at 10:16 AM, John Lightsey <lightsey@debian.org> wrote:

Show quoted text
On Thu, 2016-05-12 at 20:34 -0700, Sawyer X via RT wrote:
I apologize it took me this long to reply. I wanted to read through everything
thoroughly.

I think we have two different directions here: Solving the current situation
(5.24 and below) and solving this for future versions (5.26 and above). The
latter (future versions) is discussed in public already. Considering the
gravity of this issue for released versions, I would like to keep the security
issue retained until the various distributors have a chance to respond
properly.

As for solutions, I think there is at least an agreement on fixing scripts in
Perl core. Did I understand this correctly?

When it comes to changing modules in core, I agree with Zefram that modules
are not the correct place to patch this problem, but I do consider any change
which drastically reduces such security risks for users (demonstrated by John)
a viable option. Other than the theoretical concept of separation of concerns,
I would like to know if anyone has any practical objection to changing core
modules.

Continuing with the idea of patching modules, I think we should consider not
only core modules, but also core CPAN modules not under our purview in order
to minimize the security risk for users of CPAN modules as a whole. This would
mainly require addressing the maintainers for their assistance. Coordination
would not be simple, but we could go through a reasonable cascading schedule
just like with other security problems. I would be happy to hear any opinions
about this option. Are there any objections to this?

I think it's best to focus on the modules in core and the explanation of the
problem that is being fixed in the first pass. It's difficult to get many
developers to fix vulnerabilities that are only exploitable locally. Many
developers are dismissive of these types of vulnerabilities and will simply
refuse to fix them.

If you try to coordinate a simultaneous fix too widely, you'll end up waiting on
developers that don't consider the attack valid.

For example, when cPanel reported Storable attacks to the Perl security team
years ago and were told that Storable would not be "fixed" to be safe for
untrusted inputs, it made several other codebases vulnerable by virtue of using
Storable in this role. I reported many of these flaws and the fix rate was
better when I referenced p5p's statements on the subject and better still after
I publicly released weaponized attacks for some of the fixed software and used
the weaponized attacks as examples.

For security folks, releasing weaponized attacks seems like a counterproductive
behavior, but in my experience, developers are very unlikely to fix any novel
types of attack without seeing examples of it weaponized.

IMHO, the best course of action overall is to get the codebases under perl-
security and debian-security's control in order enough to discuss the attacks
publicly so that the Perl ecosystem as a whole will start to internalize and
correct the problem.


Excluding all solution ideas for future versions mentioned here, the main
option I seem to see here (please correct me if I'm wrong) would be checking
permissions. How viable would it be to: 1. Implement it, and 2. Provide it in
older versions of Perl?

By "checking permissions", you're referring to the idea of changing module load
behavior directly in the Perl interpreter, right? That seemed like an
unrealistic option to me. The behavior as described would leave other attack
scenarios open, would be complicated to implement correctly, and would be
difficult to explain to developers encountering it.

The other option of changing module load behavior inside an eval sounds much
better to me as a backportable fix, but my guess is that it'll break CPAN even
more than the PERL_USE_UNSAFE_INC approach does. I might be wrong
though...perhaps someone can test Dave Mitchell's patch that uses this approach?


How much did I miss? How much did I misunderstand?

Seems pretty complete to me, but I'm still not entirely clear whether you're
saying the way forward (for 5.24 and earlier) is to patch the modules or patch
the interpreter.

If you're strongly leaning towards the "patch the modules" approach, I can spend
some time getting a better list of exactly what would need to be patched in core
Perl to make this work.
Download smime.p7s
application/pkcs7-signature 4.5k

Message body not shown because it is not plain text.

Date: Sat, 14 May 2016 17:26:26 +0100
Subject: Re: [perl #127834] Flaws in Perl code due to unsafe module load path
From: Dave Mitchell <davem [...] iabyn.com>
CC: "perl5-security-report [...] perl.org" <perl5-security-report [...] perl.org>, John Lightsey <lightsey [...] debian.org>, Florian Weimer <fw [...] deneb.enyo.de>, carnil [...] debian.org
To: Zefram <zefram [...] fysh.org>
Download (untitled) / with headers
text/plain 4.4k
On Wed, Apr 27, 2016 at 06:00:29PM +0100, Zefram wrote: Show quoted text
> >Both these proposals assume that the "." added by the perl executable > >itself during startup is specially flagged in some way,
> > It's recognisable by being at the very end of @INC. Both lib.pm and > -I prepend. It would be rather uncomfortable to add any flag other > than this.
But it's quite likely once we start issuing perls that with an appropriate build option remove '.' completely, that some modules and code will *append* a dot to work round this, e.g. with lines like BEGIN { push @INC, '.' } so that a dot at the end supplied by the user rather than perl will become more common. If we start under some circumstances ignoring dot just because it's at the end, then we would defeat the user's intent in that BEGIN {}. I suppose we could just tell people that that need to append '.' twice to be sure. Show quoted text
> > when require has located a file using the @INC search path, and the > >matching @INC entry was the system's ".": then before loading it, > >check whether the file is owned by either root or the process's euid.
> > For this general approach, this semantic is not sufficient. root might > well have dangerous code in a file without intending for Perl to load it > as an optional module. You need to verify the whole lookup from name > to code, i.e., you need to also check ownership of each directory in > the chain, starting from "." and going down to the directory containing > the purported module file. It's also good to check permissions of each > entity, and this check alone would rule out loading anything from /tmp.
I don't see why checking permissions in addition to ownership, and checking parent dirs as well as the final file, will make any significant difference. Can you come up with a plausible scenario where the extra checks will avoid a false +ve/-ve? Bear in mind that we don't need to trap all possible bad module loads, only the ones who's names correspond to likely optionally loaded modules. Similarly, I don't think it's necessary for perl to check whether the module file is world-writeable. If that's the case, then its a security issue of the site's own making, and has very little to do with whether perl has '.' in its path. Show quoted text
> I'm ambivalent about whether this kind of semantic is a good idea. On one > hand, with my tightened version there are still ways to surprise a user. > On the other hand, tarballs for CPAN dists are liable to be extracted > with ownerships from the author's machine (if installing as root), so > that even the flimsiest ownership checks would prevent loading things > bundled in the dist.
Discouraging people from untarring and building CPAN distributions as root is probably a good thing anyway. Show quoted text
> >My second proposal: since the main issue is *optional* requires, make it > >so that if require is is about to load a module using the system's "." in > >@INC, then if require is wrapped in an eval (as determined by scanning the > >current context stack), then croak.
> > This strikes me as too much magic. The semantics are surprising, and > break basic code composability.
Given that we're trying to solve the extremely difficult issue of making perl secure without at the same time breaking everything in sight, a tricksy, magic approach could well be justified here. Can you think of anything *better* to do in the short term? Show quoted text
>
> > whether some parts of the build process invoked from there > >would want to run a sub-process using a different perl (and version) than that > >currently running?
> > No, that doesn't happen.
Having thought some more, yes it could. Consider for example a CPAN module like DBD::mysql, whose Makefile.PL runs the external command mysql_config to determine the system's MySQL configuration. If that happens to be a perl script, then it will likely be executed using the OS's /usr/bin/perl, which may well differ from (and be older than) the perl that's executing Makefile.PL. Show quoted text
> >2) should perl also special-case Makefile.PL and Build.PL?
> > No, that would be way too magical.
Again, consider my comment above about extreme circumstances requiring extreme measures. Without it, but with Todd's "mostly remove dot" build option, many CPAN modules could no longer be built by hand (as opposed to via the cpan executable for example) unless -I. was manually added to the "perl Makefile.PL" command line. -- "There's something wrong with our bloody ships today, Chatfield." -- Admiral Beatty at the Battle of Jutland, 31st May 1916.
To: Todd Rinaldo <toddr [...] cpanel.net>
CC: John Lightsey <lightsey [...] debian.org>, Florian Weimer <fw [...] deneb.enyo.de>, demerphq <demerphq [...] gmail.com>, "perl5-security-report [...] perl.org" <perl5-security-report [...] perl.org>, carnil [...] debian.org, team [...] security.debian.org
From: Dave Mitchell <davem [...] iabyn.com>
Subject: Re: [perl #127834] Flaws in Perl code due to unsafe module load path
Date: Sat, 14 May 2016 17:37:55 +0100
Download (untitled) / with headers
text/plain 2.2k
On Tue, May 03, 2016 at 01:32:39PM -0500, Todd Rinaldo wrote: Show quoted text
>
> > On Apr 27, 2016, at 10:54 AM, Dave Mitchell <davem@iabyn.com> wrote: > > > > I've been doing some more pondering about this "." in @INC malarkey. > > > > 2. As (1), but require would refuse to honour the system "." entry in a few > > specific cases, and would croak instead (eval { require }, wrong file > > ownership). An explicit -I. or "use lib '.'" would always be honoured.
> > I really like this idea. I don't think the use lib inside a eval is > particularly likely so I wouldn't even special case this.
I'm not sure what exactly here that you don't think needs special-casing. Show quoted text
> This seems > like a viable backport option. Once one enters the eval block, ideally > you wouldn't want to strip . from @INC unless require is going to > happen, which means require needs to somehow know it's inside an eval. > If that's easily done, this could potentially be a small patch that > could be easily backported to previous major versions of Perl. > > Or to rephrase: Don't try "." if it's at the end of @INC and you're in an eval.
It's a lot more complex than that. For example technically speaking, "use Foo" ends up calling require within an eval: the use gets converted to 'BEGIN { require Foo; Foo->import}', and BEGINs are executed within an eval scope to trap errors. But my private branch seems to cope with most edge cases. Show quoted text
> IMO, the ownership check is very OS specific and you're going to spend > quite a bit of time debugging it after you post the CVE. There's also > the question of properly validating the entire directory tree. This > isn't really something in Perl's wheel house and introducing it for a > backport seems problematic. I would suggest holding this in the wings in > case a problem comes up with the eval approach.
Ownership and uid as concepts are fairly standard across all UNIX-like platforms. We'd just have to do something different for Windows and VMS (and ignore any really weird platforms). As I said in a my earlier email to Zefram, I don't currently see any extra advantage in validating the whole tree. -- More than any other time in history, mankind faces a crossroads. One path leads to despair and utter hopelessness. The other, to total extinction. Let us pray we have the wisdom to choose correctly. -- Woody Allen
Date: Sat, 14 May 2016 18:56:48 +0100
To: "perl5-security-report [...] perl.org" <perl5-security-report [...] perl.org>, John Lightsey <lightsey [...] debian.org>, Florian Weimer <fw [...] deneb.enyo.de>, carnil [...] debian.org
Subject: Re: [perl #127834] Flaws in Perl code due to unsafe module load path
From: Zefram <zefram [...] fysh.org>
Download (untitled) / with headers
text/plain 5.8k
Dave Mitchell wrote: Show quoted text
> I suppose we could just tell people that that need to append '.' >twice to be sure.
I'd rather issue that advice than make '@INC = map { "$_" } @INC' surprisingly turn a restricted final "." into an unrestricted one. Surprises, where unavoidable, should be in the safe direction, and as you noted there probably isn't much existing code that would be surprised by an appended "." being restricted. Show quoted text
>I don't see why checking permissions in addition to ownership, and >checking parent dirs as well as the final file, will make any significant >difference.
... Show quoted text
>Bear in mind that we don't need to trap all possible bad module loads, >only the ones who's names correspond to likely optionally loaded modules.
You're implying that we don't need to worry about bad code existing in files whose names are not likely optional module loads. It is necessary to check directories precisely in order to make that true. If you don't check directories, an attacker can take code that exists in a root-owned file of any innocuous name and make it available in a root-owned file of a name likely to be loaded. $ ls -l /etc/.../evil.not_a_module -rw-r--r-- 1 root root 71416 Oct 5 2014 /etc/.../evil.not_a_module $ mkdir -m755 /tmp/Log $ ln /etc/.../evil.not_a_module /tmp/Log/Agent.pm $ ls -l /tmp/Log/Agent.pm -rw-r--r-- 2 root root 71416 Oct 5 2014 /tmp/Log/Agent.pm This requires that the evil file exist on the same filesystem as a directory to which the attacker can write and into which root might chdir. It doesn't have to be /tmp; it could be the attacker's home directory, for example. In any case this isn't much of a limitation, especially with the reasonably common arrangement of everything being on one filesystem. Symlinks can have much the same effect if you don't check symlink ownership, and don't have the cross-filesystem restriction. (Interestingly, Linux 3.6 has optional restrictions on creating hard links and on following symlinks which, if enabled, break this class of attack. You can't generally rely on such restrictions existing.) In the example above, an ownership check applied to parent directories would prevent loading the evil file as Log::Agent, by spotting that /tmp/Log is owned by the attacker. It's not much more difficult to confound that check, getting a fully root-owned ancestry. World-writable root-owned directories, such as /tmp, are readily available, and so all that's required is to make the path to the evil file consist only of those directories. If there is an optional-load module name that contains only a single component, the evil file can be linked directly into /tmp under the required name. For multi-component names, /tmp can be symlinked into itself under arbitrarily many names, if the module loader isn't checking symlink ownership. $ ln -s . /tmp/Log $ ln /etc/.../evil.not_a_module /tmp/Agent.pm $ ls -lLd /tmp /tmp/Log /tmp/Log/Agent.pm drwxrwxrwt 91 root root 167936 May 14 18:28 /tmp drwxrwxrwt 91 root root 167936 May 14 18:28 /tmp/Log -rw-r--r-- 2 root root 71416 Oct 5 2014 /tmp/Log/Agent.pm To defeat this attack requires checking the permissions, rejecting the directories on the grounds that they're writable by untrusted users. Show quoted text
>Similarly, I don't think it's necessary for perl to check whether the >module file is world-writeable.
Of your objections to my paranoia, this is the closest to being reasonable. If we didn't have the naming problems for which it is necessary to check ownership and permissions of the directories, then it would indeed take quite a contrived situation for permissions on the file to be an issue. In the world where we do have naming issues, the possibility of a world-writable root-owned regular file makes it way easier to come up with a file of evil content. Traditionally some such files do persistently exist, such as /var/run/utmp, though I see that one's group restricted on my (Debian) machine. (A group-writable file is still an attack vector: it just requires cracking the group before using the module loading attack to upgrade to root.) Some are liable to intermittently exist in /tmp. Obviously, once a writable root-owned file is discovered, one can write evil content into it and then use it as the evil file in any variation of the linking attack that I showed above. But, as with the linking attack using an unwritable evil file, this attack would be prevented by checking ownership and permissions on the directories, not requiring a permission check on the module file itself. For permissions on the module file to be an issue, it would have to be root-owned and intentionally under a module-like name, though with root intending it to have innocuous content. I can't come up with a likely scenario for this that wouldn't also have the possibility of getting an unwritable file with evil content, a situation against which we can't protect by this kind of restriction. (They're why we'd want to remove "." from @INC entirely.) But I wouldn't be at all surprised if an attacker managed to create such a situation; it's a rather obvious class of possibilities. It would be foolish to omit the check, especially when having applied the equivalent check to the ancestor directories. Show quoted text
>tricksy, magic approach could well be justified here. Can you think of >anything *better* to do in the short term?
The range of modules performing optional module loads is not very great. If we want to have "." disregarded for all optional module loads, we could add logic to each of them without too much effort. Show quoted text
>Again, consider my comment above about extreme circumstances requiring >extreme measures. Without it, but with Todd's "mostly remove dot" >build option, many CPAN modules could no longer be built by hand (as >opposed to via the cpan executable for example) unless -I. was >manually added to the "perl Makefile.PL" command line.
I'd be happier with "perl -I. Makefile.PL" becoming the standard incantation. -zefram
RT-Send-CC: rt-deliver-to-perl5-security-report [...] rt.perl.org
Download (untitled) / with headers
text/plain 6.1k
On Sat May 14 08:17:37 2016, lightsey@debian.org wrote: Show quoted text
> On Thu, 2016-05-12 at 20:34 -0700, Sawyer X via RT wrote:
> > I apologize it took me this long to reply. I wanted to read through > > everything > > thoroughly. > > > > I think we have two different directions here: Solving the current > > situation > > (5.24 and below) and solving this for future versions (5.26 and > > above). The > > latter (future versions) is discussed in public already. Considering > > the > > gravity of this issue for released versions, I would like to keep the > > security > > issue retained until the various distributors have a chance to > > respond > > properly. > > > > As for solutions, I think there is at least an agreement on fixing > > scripts in > > Perl core. Did I understand this correctly? > > > > When it comes to changing modules in core, I agree with Zefram that > > modules > > are not the correct place to patch this problem, but I do consider > > any change > > which drastically reduces such security risks for users (demonstrated > > by John) > > a viable option. Other than the theoretical concept of separation of > > concerns, > > I would like to know if anyone has any practical objection to > > changing core > > modules. > > > > Continuing with the idea of patching modules, I think we should > > consider not > > only core modules, but also core CPAN modules not under our purview > > in order > > to minimize the security risk for users of CPAN modules as a whole. > > This would > > mainly require addressing the maintainers for their assistance. > > Coordination > > would not be simple, but we could go through a reasonable cascading > > schedule > > just like with other security problems. I would be happy to hear any > > opinions > > about this option. Are there any objections to this?
> > I think it's best to focus on the modules in core and the explanation > of the > problem that is being fixed in the first pass. It's difficult to get > many > developers to fix vulnerabilities that are only exploitable locally. > Many > developers are dismissive of these types of vulnerabilities and will > simply > refuse to fix them. > > If you try to coordinate a simultaneous fix too widely, you'll end up > waiting on > developers that don't consider the attack valid. > > For example, when cPanel reported Storable attacks to the Perl > security team > years ago and were told that Storable would not be "fixed" to be safe > for > untrusted inputs, it made several other codebases vulnerable by virtue > of using > Storable in this role. I reported many of these flaws and the fix rate > was > better when I referenced p5p's statements on the subject and better > still after > I publicly released weaponized attacks for some of the fixed software > and used > the weaponized attacks as examples. > > For security folks, releasing weaponized attacks seems like a > counterproductive > behavior, but in my experience, developers are very unlikely to fix > any novel > types of attack without seeing examples of it weaponized. > > IMHO, the best course of action overall is to get the codebases under > perl- > security and debian-security's control in order enough to discuss the > attacks > publicly so that the Perl ecosystem as a whole will start to > internalize and > correct the problem.
I'm sorry you had a bad experience reporting security issues in the past. I understand the practicality of first solving this at the perl core level. Let's proceed with solving it there first. We can provide comments and push for additional fixes in CPAN afterwards. Show quoted text
>
> > > > Excluding all solution ideas for future versions mentioned here, the > > main > > option I seem to see here (please correct me if I'm wrong) would be > > checking > > permissions. How viable would it be to: 1. Implement it, and 2. > > Provide it in > > older versions of Perl?
> > By "checking permissions", you're referring to the idea of changing > module load > behavior directly in the Perl interpreter, right? That seemed like an > unrealistic option to me. The behavior as described would leave other > attack > scenarios open, would be complicated to implement correctly, and would > be > difficult to explain to developers encountering it.
Can you please elaborate on the other attack scenarios this would leave open? Show quoted text
> > The other option of changing module load behavior inside an eval > sounds much > better to me as a backportable fix, but my guess is that it'll break > CPAN even > more than the PERL_USE_UNSAFE_INC approach does. I might be wrong > though...perhaps someone can test Dave Mitchell's patch that uses this > approach?
Breakage should be avoided as much as possible. Dave, having suggested this fix, do you also see this as a back-portable fix? Show quoted text
>
> > > > How much did I miss? How much did I misunderstand?
> > Seems pretty complete to me, but I'm still not entirely clear whether > you're > saying the way forward (for 5.24 and earlier) is to patch the modules > or patch > the interpreter. > > If you're strongly leaning towards the "patch the modules" approach, I > can spend > some time getting a better list of exactly what would need to be > patched in core > Perl to make this work.
The way I see it is: * We need to decide on a long-term fix to be back-ported. * We patch core modules to be dot-agnostic and release. * We merge our long-term fix for back-porting and release a new version of 5.22 and 5.24. * Distributors release new versions of fixed perls. * Coordinate fixes of major CPAN distributions to be dot-agnostic as well. I've laid these out as would be chronologically reasonable, but I'm not sure that's absolutely correct. Please correct the order if it's wrong. However, note that deciding on a long-term fix should definitely happen *before* patching core modules and releasing them, because once those are released, it makes it easier to learn what can be exploited and why. Perhaps we should also consider making an additional release of older unsupported perls with this patch. I know this issue is exhausting, but I think it is critical and I would be happy if we could resolve this (at least for past and existing releases - i.e., 5.24 and under) before 5.25.2 comes out (June 20th), so we could start working on the solution for future versions (5.25.2 or 5.25.3 and above).
From: John Lightsey <lightsey [...] debian.org>
Subject: Re: [perl #127834] Flaws in Perl code due to unsafe module load path
To: perl5-security-report [...] perl.org, carnil [...] debian.org, fw [...] deneb.enyo.de, toddr [...] cpan.org
Date: Thu, 26 May 2016 11:49:38 -0500
Download (untitled) / with headers
text/plain 1.8k
On Wed, 2016-05-25 at 12:22 -0700, Sawyer X via RT wrote: Show quoted text
> On Sat May 14 08:17:37 2016, lightsey@debian.org wrote:
Show quoted text
> > > > > > Excluding all solution ideas for future versions mentioned here, the > > > main > > > option I seem to see here (please correct me if I'm wrong) would be > > > checking > > > permissions. How viable would it be to: 1. Implement it, and 2. > > > Provide it in > > > older versions of Perl?
> >  > > By "checking permissions", you're referring to the idea of changing > > module load > > behavior directly in the Perl interpreter, right? That seemed like an > > unrealistic option to me. The behavior as described would leave other > > attack > > scenarios open, would be complicated to implement correctly, and would > > be > > difficult to explain to developers encountering it.
> > > Can you please elaborate on the other attack scenarios this would leave open?
I may have missed pieces of the logic discussed earlier, but the core seemed to be: when running as root, check the ownership and permissions leading up to the module. Attack for that is simply "when not running as root". If you add "when not running as root", then the the path sanitization becomes the main issue. You can create a file owned by root with restrictive permissions with arbitrary code in it like this: perl -e '%ENV = ("package FOO;#" => qq{\nqx{wall hello world};\n1;\n__END__\n}); print "Injection at /proc/$$/environ\n\n";exec "/usr/bin/passwd";' To prevent loading that as the target perl module you'd need to do the same type of directory walk that suphp does. You either disallow all symlinks in the path and require locked down permissions for every directory, or you walk through the path step by step using chdir() or openat() testing each inode along the way. It's possible to do these types of checks correctly, but they're slow and complicated.
Download signature.asc
application/pgp-signature 819b

Message body not shown because it is not plain text.

Date: Fri, 27 May 2016 10:55:30 +0200
Subject: Re: [perl #127834] Flaws in Perl code due to unsafe module load path
From: Salvatore Bonaccorso <carnil [...] debian.org>
To: John Lightsey via RT <perl5-security-report [...] perl.org>
CC: carnil [...] debian.org, fw [...] deneb.enyo.de, toddr [...] cpan.org, team [...] security.debian.org, dom [...] earth.li, ntyni [...] debian.org
Download (untitled) / with headers
text/plain 2.5k
Hi all, On Thu, May 26, 2016 at 09:50:19AM -0700, John Lightsey via RT wrote: Show quoted text
> On Wed, 2016-05-25 at 12:22 -0700, Sawyer X via RT wrote:
> > On Sat May 14 08:17:37 2016, lightsey@debian.org wrote:
>
> > > > > > > > Excluding all solution ideas for future versions mentioned here, the > > > > main > > > > option I seem to see here (please correct me if I'm wrong) would be > > > > checking > > > > permissions. How viable would it be to: 1. Implement it, and 2. > > > > Provide it in > > > > older versions of Perl?
> > >  > > > By "checking permissions", you're referring to the idea of changing > > > module load > > > behavior directly in the Perl interpreter, right? That seemed like an > > > unrealistic option to me. The behavior as described would leave other > > > attack > > > scenarios open, would be complicated to implement correctly, and would > > > be > > > difficult to explain to developers encountering it.
> > > > > > Can you please elaborate on the other attack scenarios this would leave open?
> > I may have missed pieces of the logic discussed earlier, but the core seemed to > be: when running as root, check the ownership and permissions leading up to the > module. > > Attack for that is simply "when not running as root". > > If you add "when not running as root", then the the path sanitization becomes > the main issue. You can create a file owned by root with restrictive permissions > with arbitrary code in it like this: > > perl -e '%ENV = ("package FOO;#" => qq{\nqx{wall hello > world};\n1;\n__END__\n}); print "Injection at /proc/$$/environ\n\n";exec > "/usr/bin/passwd";' > > To prevent loading that as the target perl module you'd need to do the same type > of directory walk that suphp does. You either disallow all symlinks in the path > and require locked down permissions for every directory, or you walk through the > path step by step using chdir() or openat() testing each inode along the way. > > It's possible to do these types of checks correctly, but they're slow and > complicated.
FTR, it is unfortunate but the problem was independently now raised in a public IRC channel again, just tomorrow in #debian-perl. [10:03] < ansgar> ntyni: I found another reason why "." in @INC sucks: chmod a-rwx .; perl -MSbuild::Exception [10:07] < ansgar> I guess one should never call any perl script in /tmp... [10:08] < ansgar> Unless one is the sole user with permissions to write there and all data is trusted ;) FTR, I just added Dominic Hargreaves, and Niko Tyni to the loop as well, who are the Debian perl maintainers. Regards, Salvatore
RT-Send-CC: rt-deliver-to-perl5-security-report [...] rt.perl.org
Download (untitled) / with headers
text/plain 225b
On Fri May 27 01:55:56 2016, carnil@debian.org wrote: Show quoted text
> FTR, I just added Dominic Hargreaves, and Niko Tyni to the loop as > well, who > are the Debian perl maintainers.
I've added them to the CC list for the ticket. Tony
RT-Send-CC: rt-deliver-to-perl5-security-report [...] rt.perl.org
Download (untitled) / with headers
text/plain 927b
A summary of the various proposed solutions for 5.25 onwards: 1) Add a -Dfortify_inc Configure option to remove . from @INC and then let the toolchain and the user: a) set PERL_USE_UNSAFE_INC environment variable as a flag to add . at the back b) add . to PERL5LIB to add it at the front c) add -J. to PERL5OPTS to add it at the back d) add . to PERL5PUSHLIB to add it at the back e) let Makefile.PL and Build.PL be magic script names that add . at the back 2) Add a -Dunsafe_inc Configure option that's the inverse of 1) 3) Remove . from @INC, requiring some effort (-Accflags=...) to put it back, combined with the options from 1) (a harder to use version of 2) 4) Make . at the end of @INC special/magic so that we: a) perform security checks on curdir to decide if code can safely load from it b) croak if the . entry is used when require is called within an eval c) b), but warn instead of croaking
RT-Send-CC: rt-deliver-to-perl5-security-report [...] rt.perl.org
Download (untitled) / with headers
text/plain 2.7k
On Sun Jun 19 19:10:54 2016, tonyc wrote: Show quoted text
> A summary of the various proposed solutions for 5.25 onwards: > > 1) Add a -Dfortify_inc Configure option to remove . from @INC and then > let the toolchain and the user:
I'm not fond of this, since it gives us yet another build option to support. As a perl build option CPAN authors will likely be asked to support perl's built with this option, so from a CPAN point of view authors will still need to perform work to support it. Show quoted text
> a) set PERL_USE_UNSAFE_INC environment variable as a flag to add . at > the back
This feels like a hack to me. Show quoted text
> b) add . to PERL5LIB to add it at the front
This is my preference. Show quoted text
> c) add -J. to PERL5OPTS to add it at the back
As John pointed out this will cause problems if older versions of perl happen to be called with that in the environment. Show quoted text
> d) add . to PERL5PUSHLIB to add it at the back
This is my second preference - it allows a user or tool to provide the same environment as before (. at the end) without breaking older perls. I'm just not sure if there's any case where it's an improvement over PERL5LIB. Show quoted text
> e) let Makefile.PL and Build.PL be magic script names that add . at > the back
Too much magic for me. For automated installs the toolchain can be modified to do one of the above, for manual installs where the author used Module::Build, the user can supply -I. or use one of mechanisms above manually. Show quoted text
> 2) Add a -Dunsafe_inc Configure option that's the inverse of 1) > > 3) Remove . from @INC, requiring some effort (-Accflags=...) to put it > back, combined with the options from 1) (a harder to use version of 2)
Combined with b) above this is my preference. This is a "remove the band-aid all at once" option. It's also KISS. Perhaps it would be delayed after a release with option 1) or 2). Show quoted text
> 4) Make . at the end of @INC special/magic so that we:
I'd originally thought actual magic on the . entry when this was first discussed, but as Zefram pointed out it's easy to lose such magic, so it could be done based on the . being last in @INC. In any case it's not my preference. Show quoted text
> a) perform security checks on curdir to decide if code can safely > load from it
There were a few possible checks discussed, but they were all either non-portable, didn't take the possibility of ACLs into account, or didn't cover all of the possibile attacks. I think this done correctly would be over-complex, difficult to test properly and due to the complexity, probably broken anyway. Show quoted text
> b) croak if the . entry is used when require is called within an eval
If I happen to be in the wrong directory when running a system tool, the tool crashes. Show quoted text
> c) b), but warn instead of croaking
Since it's only a warning an attacker's exploit isn't prevented. Tony
RT-Send-CC: rt-deliver-to-perl5-security-report [...] rt.perl.org
Proposed patches for maint-5.24. The first patch applies to maint-5.22 cleanly. Tony
Subject: 0001-perl-127834-remove-.-from-the-end-of-INC-if-complex-.patch
From e9c5e1acb2364b7a6d4ce7b997bfca5b60781605 Mon Sep 17 00:00:00 2001 From: Tony Cook <tony@develop-help.com> Date: Tue, 21 Jun 2016 10:02:02 +1000 Subject: (perl #127834) remove . from the end of @INC if complex modules are loaded While currently Encode and Storable are know to attempt to load modules not included in the core, updates to other modules may lead to those also attempting to load new modules, so be safe and remove . for those as well. --- cpan/Archive-Tar/bin/ptar | 1 + cpan/Archive-Tar/bin/ptardiff | 1 + cpan/Archive-Tar/bin/ptargrep | 1 + cpan/CPAN/scripts/cpan | 1 + cpan/Digest-SHA/shasum | 1 + cpan/Encode/bin/enc2xs | 1 + cpan/Encode/bin/encguess | 1 + cpan/Encode/bin/piconv | 1 + cpan/Encode/bin/ucmlint | 1 + cpan/Encode/bin/unidump | 1 + cpan/ExtUtils-MakeMaker/bin/instmodsh | 1 + cpan/IO-Compress/bin/zipdetails | 1 + cpan/JSON-PP/bin/json_pp | 1 + cpan/Test-Harness/bin/prove | 1 + dist/ExtUtils-ParseXS/lib/ExtUtils/xsubpp | 1 + dist/Module-CoreList/corelist | 1 + ext/Pod-Html/bin/pod2html | 1 + utils/c2ph.PL | 1 + utils/h2ph.PL | 1 + utils/h2xs.PL | 1 + utils/libnetcfg.PL | 1 + utils/perlbug.PL | 1 + utils/perldoc.PL | 5 ++++- utils/perlivp.PL | 2 ++ utils/splain.PL | 6 ++++++ 25 files changed, 34 insertions(+), 1 deletion(-) diff --git a/cpan/Archive-Tar/bin/ptar b/cpan/Archive-Tar/bin/ptar index 0eaffa7..9dc6402 100644 --- a/cpan/Archive-Tar/bin/ptar +++ b/cpan/Archive-Tar/bin/ptar @@ -1,6 +1,7 @@ #!/usr/bin/perl use strict; +BEGIN { pop @INC if $INC[-1] eq '.' } use File::Find; use Getopt::Std; use Archive::Tar; diff --git a/cpan/Archive-Tar/bin/ptardiff b/cpan/Archive-Tar/bin/ptardiff index 66bd859..4668fa6 100644 --- a/cpan/Archive-Tar/bin/ptardiff +++ b/cpan/Archive-Tar/bin/ptardiff @@ -1,5 +1,6 @@ #!/usr/bin/perl +BEGIN { pop @INC if $INC[-1] eq '.' } use strict; use Archive::Tar; use Getopt::Std; diff --git a/cpan/Archive-Tar/bin/ptargrep b/cpan/Archive-Tar/bin/ptargrep index 1a320f1..8dc6b4f 100644 --- a/cpan/Archive-Tar/bin/ptargrep +++ b/cpan/Archive-Tar/bin/ptargrep @@ -4,6 +4,7 @@ # archive. See 'ptargrep --help' for more documentation. # +BEGIN { pop @INC if $INC[-1] eq '.' } use strict; use warnings; diff --git a/cpan/CPAN/scripts/cpan b/cpan/CPAN/scripts/cpan index 5f4320e..ccba47e 100644 --- a/cpan/CPAN/scripts/cpan +++ b/cpan/CPAN/scripts/cpan @@ -1,5 +1,6 @@ #!/usr/local/bin/perl +BEGIN { pop @INC if $INC[-1] eq '.' } use strict; use vars qw($VERSION); diff --git a/cpan/Digest-SHA/shasum b/cpan/Digest-SHA/shasum index 14ddd60..62a2b0e 100644 --- a/cpan/Digest-SHA/shasum +++ b/cpan/Digest-SHA/shasum @@ -13,6 +13,7 @@ ## "-0" option for reading bit strings, and ## "-p" option for portable digests (to be deprecated). +BEGIN { pop @INC if $INC[-1] eq '.' } use strict; use warnings; use Fcntl; diff --git a/cpan/Encode/bin/enc2xs b/cpan/Encode/bin/enc2xs index ec4732c..f8d9f52 100644 --- a/cpan/Encode/bin/enc2xs +++ b/cpan/Encode/bin/enc2xs @@ -4,6 +4,7 @@ BEGIN { # with $ENV{PERL_CORE} set # In case we need it in future... require Config; import Config; + pop @INC if $INC[-1] eq '.'; } use strict; use warnings; diff --git a/cpan/Encode/bin/encguess b/cpan/Encode/bin/encguess index 5d7ac80..0be5c7c 100644 --- a/cpan/Encode/bin/encguess +++ b/cpan/Encode/bin/encguess @@ -1,5 +1,6 @@ #!./perl use 5.008001; +BEGIN { pop @INC if $INC[-1] eq '.' } use strict; use warnings; use Encode; diff --git a/cpan/Encode/bin/piconv b/cpan/Encode/bin/piconv index c1dad9e..60b2a59 100644 --- a/cpan/Encode/bin/piconv +++ b/cpan/Encode/bin/piconv @@ -1,6 +1,7 @@ #!./perl # $Id: piconv,v 2.7 2014/05/31 09:48:48 dankogai Exp $ # +BEGIN { pop @INC if $INC[-1] eq '.' } use 5.8.0; use strict; use Encode ; diff --git a/cpan/Encode/bin/ucmlint b/cpan/Encode/bin/ucmlint index 622376d..25e0d67 100644 --- a/cpan/Encode/bin/ucmlint +++ b/cpan/Encode/bin/ucmlint @@ -3,6 +3,7 @@ # $Id: ucmlint,v 2.2 2008/03/12 09:51:11 dankogai Exp $ # +BEGIN { pop @INC if $INC[-1] eq '.' } use strict; our $VERSION = do { my @r = (q$Revision: 2.2 $ =~ /\d+/g); sprintf "%d."."%02d" x $#r, @r }; diff --git a/cpan/Encode/bin/unidump b/cpan/Encode/bin/unidump index ae0da30..f190827 100644 --- a/cpan/Encode/bin/unidump +++ b/cpan/Encode/bin/unidump @@ -1,5 +1,6 @@ #!./perl +BEGIN { pop @INC if $INC[-1] eq '.' } use strict; use Encode; use Getopt::Std; diff --git a/cpan/ExtUtils-MakeMaker/bin/instmodsh b/cpan/ExtUtils-MakeMaker/bin/instmodsh index 8b9aa95..ab0f9d1 100644 --- a/cpan/ExtUtils-MakeMaker/bin/instmodsh +++ b/cpan/ExtUtils-MakeMaker/bin/instmodsh @@ -1,5 +1,6 @@ #!/usr/bin/perl -w +BEGIN { pop @INC if $INC[-1] eq '.' } use strict; use IO::File; use ExtUtils::Packlist; diff --git a/cpan/IO-Compress/bin/zipdetails b/cpan/IO-Compress/bin/zipdetails index 0249850..1b9c70a 100644 --- a/cpan/IO-Compress/bin/zipdetails +++ b/cpan/IO-Compress/bin/zipdetails @@ -5,6 +5,7 @@ # Display info on the contents of a Zip file # +BEGIN { pop @INC if $INC[-1] eq '.' } use strict; use warnings ; diff --git a/cpan/JSON-PP/bin/json_pp b/cpan/JSON-PP/bin/json_pp index df9d243..896cd2f 100644 --- a/cpan/JSON-PP/bin/json_pp +++ b/cpan/JSON-PP/bin/json_pp @@ -1,5 +1,6 @@ #!/usr/bin/perl +BEGIN { pop @INC if $INC[-1] eq '.' } use strict; use Getopt::Long; diff --git a/cpan/Test-Harness/bin/prove b/cpan/Test-Harness/bin/prove index 6637cc4..d71b238 100644 --- a/cpan/Test-Harness/bin/prove +++ b/cpan/Test-Harness/bin/prove @@ -1,5 +1,6 @@ #!/usr/bin/perl -w +BEGIN { pop @INC if $INC[-1] eq '.' } use strict; use warnings; use App::Prove; diff --git a/dist/ExtUtils-ParseXS/lib/ExtUtils/xsubpp b/dist/ExtUtils-ParseXS/lib/ExtUtils/xsubpp index e2ac71a..d596cdf 100644 --- a/dist/ExtUtils-ParseXS/lib/ExtUtils/xsubpp +++ b/dist/ExtUtils-ParseXS/lib/ExtUtils/xsubpp @@ -1,5 +1,6 @@ #!perl use 5.006; +BEGIN { pop @INC if $INC[-1] eq '.' } use strict; eval { require ExtUtils::ParseXS; diff --git a/dist/Module-CoreList/corelist b/dist/Module-CoreList/corelist index aa4a945..bbe61cc 100644 --- a/dist/Module-CoreList/corelist +++ b/dist/Module-CoreList/corelist @@ -130,6 +130,7 @@ requested perl versions. =cut +BEGIN { pop @INC if $INC[-1] eq '.' } use Module::CoreList; use Getopt::Long qw(:config no_ignore_case); use Pod::Usage; diff --git a/ext/Pod-Html/bin/pod2html b/ext/Pod-Html/bin/pod2html index b022859..7d1d232 100644 --- a/ext/Pod-Html/bin/pod2html +++ b/ext/Pod-Html/bin/pod2html @@ -216,6 +216,7 @@ This program is distributed under the Artistic License. =cut +BEGIN { pop @INC if $INC[-1] eq '.' } use Pod::Html; pod2html @ARGV; diff --git a/utils/c2ph.PL b/utils/c2ph.PL index 466223c..ea87a6f 100644 --- a/utils/c2ph.PL +++ b/utils/c2ph.PL @@ -280,6 +280,7 @@ Anyway, here it is. Should run on perl v4 or greater. Maybe less. $RCSID = '$Id: c2ph,v 1.7 95/10/28 10:41:47 tchrist Exp Locker: tchrist $'; +BEGIN { pop @INC if $INC[-1] eq '.' } use File::Temp; ###################################################################### diff --git a/utils/h2ph.PL b/utils/h2ph.PL index d082f22..780bba9 100644 --- a/utils/h2ph.PL +++ b/utils/h2ph.PL @@ -1,5 +1,6 @@ #!/usr/local/bin/perl +BEGIN { pop @INC if $INC[-1] eq '.' } use Config; use File::Basename qw(basename dirname); use Cwd; diff --git a/utils/h2xs.PL b/utils/h2xs.PL index 4cb0943..8ad4e10 100644 --- a/utils/h2xs.PL +++ b/utils/h2xs.PL @@ -1,5 +1,6 @@ #!/usr/local/bin/perl +BEGIN { pop @INC if $INC[-1] eq '.' } use Config; use File::Basename qw(&basename &dirname); use Cwd; diff --git a/utils/libnetcfg.PL b/utils/libnetcfg.PL index 59a2de8..26d2f99 100644 --- a/utils/libnetcfg.PL +++ b/utils/libnetcfg.PL @@ -97,6 +97,7 @@ Jarkko Hietaniemi, conversion into libnetcfg for inclusion into Perl 5.8. # $Id: Configure,v 1.8 1997/03/04 09:22:32 gbarr Exp $ +BEGIN { pop @INC if $INC[-1] eq '.' } use strict; use IO::File; use Getopt::Std; diff --git a/utils/perlbug.PL b/utils/perlbug.PL index 885785a..ae8c343 100644 --- a/utils/perlbug.PL +++ b/utils/perlbug.PL @@ -57,6 +57,7 @@ print OUT <<'!NO!SUBS!'; my @patches = Config::local_patches(); my $patch_tags = join "", map /(\S+)/ ? "+$1 " : (), @patches; +BEGIN { pop @INC if $INC[-1] eq '.' } use warnings; use strict; use Config; diff --git a/utils/perldoc.PL b/utils/perldoc.PL index e201de9..cd60bd4 100644 --- a/utils/perldoc.PL +++ b/utils/perldoc.PL @@ -44,7 +44,10 @@ $Config{startperl} # This "$file" file was generated by "$0" require 5; -BEGIN { \$^W = 1 if \$ENV{'PERLDOCDEBUG'} } +BEGIN { + \$^W = 1 if \$ENV{'PERLDOCDEBUG'}; + pop \@INC if \$INC[-1] eq '.'; +} use Pod::Perldoc; exit( Pod::Perldoc->run() ); diff --git a/utils/perlivp.PL b/utils/perlivp.PL index c2f0a11..e522913 100644 --- a/utils/perlivp.PL +++ b/utils/perlivp.PL @@ -39,6 +39,8 @@ print OUT "\n# perlivp $^V\n"; print OUT <<'!NO!SUBS!'; +BEGIN { pop @INC if $INC[-1] eq '.' } + sub usage { warn "@_\n" if @_; print << " EOUSAGE"; diff --git a/utils/splain.PL b/utils/splain.PL index 9c70b61..cae84a0 100644 --- a/utils/splain.PL +++ b/utils/splain.PL @@ -38,6 +38,12 @@ $Config{startperl} if \$running_under_some_shell; !GROK!THIS! +print <<'!NO!SUBS!'; + +BEGIN { pop @INC if $INC[-1] eq '.' } + +!NO!SUBS! + while (<IN>) { print OUT unless /^package diagnostics/; } -- 2.1.4
Subject: 0002-perl-127834-bump-versions-of-modules-in-dists-we-upd.patch

Message body is not shown because it is too large.

Date: Thu, 23 Jun 2016 01:06:18 +0100
CC: carnil [...] debian.org, fw [...] deneb.enyo.de, lightsey [...] debian.org, toddr [...] cpan.org, ntyni [...] debian.org
To: Tony Cook via RT <perl5-security-report [...] perl.org>
From: Dominic Hargreaves <dom [...] earth.li>
Subject: Re: [perl #127834] Flaws in Perl code due to unsafe module load path
Download (untitled) / with headers
text/plain 3.3k
On Mon, Jun 20, 2016 at 05:47:57PM -0700, Tony Cook via RT wrote: Show quoted text
> Proposed patches for maint-5.24. > > The first patch applies to maint-5.22 cleanly.
Thank you for sending these patches. Would it be fair to say that this is a statement that for the perl core, the problem shall by fixed in scripts and not in intermediate modules? For Debian, given the payoffs previously mentioned (90% fixage just by patching Encode and Storable) I think that we must do that too. Patching just the tools we know about (apt-show-versions and dpkg-preconfigure) and leaving Encode and Storable alone is verging on reckless, since we can be almost sure that we're leaving vulnerable scripts which we could protect (and it's almost certainly not practical to patch all of them). John identified the following other modules to be patched in his email of 21st April: Encode::ConfigLocal (via Encode) Log::Agent (via Storable) Locale::Maketext::Lexicon (via Local::Maketext::Simple) Mo::builder and Mo::default (via YAML::Mo) Other ones that show up repeatedly when actually running different Perl scripts: Pod::Perldoc::ToXXXX (via Pod::Perldoc's find_good_formatter_class()) Net::LocalConfig (via Net::Config) Term::ReadLine::XXXX (via Term::ReadLine) IO::Uncompress::XXXX (via IO::Uncompress::AnyUncompress) This seems to be a small enough set of patches and come very close to fixing the problem. I would actually argue that we should *also* fix the scripts we know about (John mentioned apt-show-versions and dpkg-preconfigure) as an example, since it seems quite likely that other specific instances of this vulnerability will be found in other parts of the ecosystem and they may need to be patched at the script level. Doing this in a coordinated way in Debian is feasible: - perl core patched with Tony's patches - the above modules patched (in the perl package and dual-lived packages) - the above scripts in Debian system tools patched John: can you help identify any other problematic scripts or modules that should be considered? On the p5p side, extending my above reasoning suggests that Encode and Storable should be fixed in core too (together with coordinated CPAN releases). At the same time as that happens, perl script authors and CPAN authors should be advised to check their exposure. Can simple simple checks be released as part of the disclosure to help this? Are there other CPAN distributions with modules or scripts that should also be fixed as part of this coordinated disclosure? This disclosure should happen as soon as possible, because the *real* fix will take some time to work through, and should be applied to perl 5.26 (and possibly Debian's next release, which will freeze at the end of this calendar year). I agree with Tony (in his other message) that the "remove the band-aid all at once" option is correct, for that part. I'm not clear about how much work is needed there on top of the existing public patchset from Todd. As a straw-man suggestion for the disclosure date, how about one month from now, 23rd July? That should give us time to resolve the remaining details above and produce the necessary patches. Several of the relevant Debian people will be meeting at Debconf in just over a week and will, I hope, be able to work together on the problem, so it would be good to have a clear aim by then. Does the above timeframe give enough time for other vendors to be notified? Thanks, Dominic. (for the Debian perl maintainers)
Date: Thu, 23 Jun 2016 09:07:02 +0200
Subject: Re: [perl #127834] Flaws in Perl code due to unsafe module load path
From: demerphq <demerphq [...] gmail.com>
To: Dominic Hargreaves <dom [...] earth.li>
CC: Tony Cook via RT <perl5-security-report [...] perl.org>, carnil [...] debian.org, Florian Weimer <fw [...] deneb.enyo.de>, John Lightsey <lightsey [...] debian.org>, Todd Rinaldo <toddr [...] cpan.org>, Niko Tyni <ntyni [...] debian.org>
Download (untitled) / with headers
text/plain 1.5k
On 23 June 2016 at 02:06, Dominic Hargreaves <dom@earth.li> wrote: Show quoted text
> On Mon, Jun 20, 2016 at 05:47:57PM -0700, Tony Cook via RT wrote:
>> Proposed patches for maint-5.24. >> >> The first patch applies to maint-5.22 cleanly.
> > Thank you for sending these patches. Would it be fair to say that this > is a statement that for the perl core, the problem shall by fixed in > scripts and not in intermediate modules?
For what its worth, I read it as a first step only. I think the long term fix will involve removing "." from @INC by default, but we haven't decided on the right way to do it. IOW, I think the point we are making is that patching the modules you speak of might fix 90% of the known cases in known scripts, but it wont really solve the general problem, and we would like to solve that. FWIW, at $work we have patched out "." from @INC using a sitecustomize.pl script. I wonder if this is an option for Debian. For instance if the Debian perl was configured to use sitecustomize.pl you could have it filter out "." from @INC on your own, based on the presence or absence of an ENV var. Not an ideal solution but one you could use to achieve a holistic solution to this class of problem. I admit to not knowing the full security ramifications of enabling sitecustomize.pl, and/or how it can be secured. I would assume the Debian team has more competent people than me to assess that route. Anyway, only Sawyer can make a definitive statement on our policy about this. Patches are "just" work product as we figure out the best thing to do to get from here to there. cheers, Yves
RT-Send-CC: rt-deliver-to-perl5-security-report [...] rt.perl.org
On Wed Jun 22 17:06:38 2016, dom wrote: Show quoted text
> On Mon, Jun 20, 2016 at 05:47:57PM -0700, Tony Cook via RT wrote:
> > Proposed patches for maint-5.24. > > > > The first patch applies to maint-5.22 cleanly.
> > Thank you for sending these patches. Would it be fair to say that this > is a statement that for the perl core, the problem shall by fixed in > scripts and not in intermediate modules?
No, my aim was try to make some progress (any progress) on the issue. Sawyer and I have since discussed this ticket and I will also be patching modules included in maint and blead to locally remove that final . from @INC when loading optional modules. Show quoted text
> For Debian, given the payoffs previously mentioned (90% fixage > just by patching Encode and Storable) I think that we must do that > too. > Patching just the tools we know about (apt-show-versions > and dpkg-preconfigure) and leaving Encode and Storable alone is > verging on reckless, since we can be almost sure that we're leaving > vulnerable scripts which we could protect (and it's almost certainly > not practical to patch all of them). > > John identified the following other modules to be patched in his email > of 21st April: > > Encode::ConfigLocal (via Encode) > Log::Agent (via Storable) > Locale::Maketext::Lexicon (via Local::Maketext::Simple) > Mo::builder and Mo::default (via YAML::Mo) > > Other ones that show up repeatedly when actually running different > Perl scripts: > > Pod::Perldoc::ToXXXX (via Pod::Perldoc's find_good_formatter_class()) > Net::LocalConfig (via Net::Config) > Term::ReadLine::XXXX (via Term::ReadLine) > IO::Uncompress::XXXX (via IO::Uncompress::AnyUncompress)
Test.pm attempts to load Algorithm::Diff, though this is probably hard to take advantage of. File::Spec::(Cygwin|Win32|VMS) attempt to load optional modules. Net::Ping attempts to load Net::Ping::External. perl5db.pl attempts to load PadWalker. base.pm optionally loads its argument, I'm not entirely sure what to do about this one, I can see it's argument being in the current directory fairly commonly. I haven't looked in detail at ext/ and cpan/ yet. Tony
Date: Thu, 23 Jun 2016 11:20:43 +0100
Subject: Re: [perl #127834] Flaws in Perl code due to unsafe module load path
From: Dominic Hargreaves <dom [...] earth.li>
To: yves orton via RT <perl5-security-report [...] perl.org>
CC: carnil [...] debian.org, fw [...] deneb.enyo.de, lightsey [...] debian.org, toddr [...] cpan.org, ntyni [...] debian.org
Download (untitled) / with headers
text/plain 5.6k
On Thu, Jun 23, 2016 at 12:07:31AM -0700, yves orton via RT wrote: Show quoted text
> On 23 June 2016 at 02:06, Dominic Hargreaves <dom@earth.li> wrote:
Show quoted text
> > Thank you for sending these patches. Would it be fair to say that this > > is a statement that for the perl core, the problem shall by fixed in > > scripts and not in intermediate modules?
> > For what its worth, I read it as a first step only. > > I think the long term fix will involve removing "." from @INC by > default, but we haven't decided on the right way to do it.
Right, I was unclear in my late night email composition :( In this sentence, I was only asking about the fix for maint-*. Show quoted text
> IOW, I think the point we are making is that patching the modules you > speak of might fix 90% of the known cases in known scripts, but it > wont really solve the general problem, and we would like to solve > that.
Absolutely. But we have to fix the 90% too on disclosure day. Show quoted text
> FWIW, at $work we have patched out "." from @INC using a > sitecustomize.pl script. I wonder if this is an option for Debian. For > instance if the Debian perl was configured to use sitecustomize.pl you > could have it filter out "." from @INC on your own, based on the > presence or absence of an ENV var. > > Not an ideal solution but one you could use to achieve a holistic > solution to this class of problem. I admit to not knowing the full > security ramifications of enabling sitecustomize.pl, and/or how it can > be secured. I would assume the Debian team has more competent people > than me to assess that route.
Thanks for this suggestion! I wasn't aware of sitecustomize.pl, and indeed perhaps that does give us additional options, given that it will allow more flexibility to try things out and configure things. Based on my limited knowledge of sitecustomize.pl (which more or less comes from [1]) I don't see much scope for mischief, if the code is kept simple. Debian people: based on the likely breakage to modules and user scripts, do you believe we should be considering removing . from @INC at a global level at disclosure time? I am prepared to entertain that suggestion, but it would probably generate quite a lot of heat. In order to answer this question we need a perl build which does this and start some mass rebuilds, though some real world testing would also be needed. It's possible that in 90% of Debian systems (likely ones where people are not actively developing perl modules, or using CPAN etc, all would be fine with the change enabled globally. The nice thing about the sitecustomize.pl approach is that it could be made a conffile; so it could be configured to take effect (giving 100% protection) if a user requests it at package install time (if it's indeed too invasive to enable by default). I think this would be more useful than being controlled solely by an environment variable, although a *temporary* environment variable fix (PERL_USE_UNSAFE_INC?) could still be supported. Show quoted text
> Anyway, only Sawyer can make a definitive statement on our policy > about this. Patches are "just" work product as we figure out the best > thing to do to get from here to there.
Indeed. My question was partly mischievous, in order to keep the discussion moving. On Thu, Jun 23, 2016 at 12:55:38AM -0700, Tony Cook via RT wrote: Show quoted text
> On Wed Jun 22 17:06:38 2016, dom wrote:
Show quoted text
> > Thank you for sending these patches. Would it be fair to say that this > > is a statement that for the perl core, the problem shall by fixed in > > scripts and not in intermediate modules?
> > No, my aim was try to make some progress (any progress) on the issue.
Yup. Show quoted text
> Sawyer and I have since discussed this ticket and I will also be > patching modules included in maint and blead to locally remove that > final . from @INC when loading optional modules.
Okay, that sounds like we're in agreement. Show quoted text
> > For Debian, given the payoffs previously mentioned (90% fixage > > just by patching Encode and Storable) I think that we must do that > > too. > > Patching just the tools we know about (apt-show-versions > > and dpkg-preconfigure) and leaving Encode and Storable alone is > > verging on reckless, since we can be almost sure that we're leaving > > vulnerable scripts which we could protect (and it's almost certainly > > not practical to patch all of them). > > > > John identified the following other modules to be patched in his email > > of 21st April: > > > > Encode::ConfigLocal (via Encode) > > Log::Agent (via Storable) > > Locale::Maketext::Lexicon (via Local::Maketext::Simple) > > Mo::builder and Mo::default (via YAML::Mo) > > > > Other ones that show up repeatedly when actually running different > > Perl scripts: > > > > Pod::Perldoc::ToXXXX (via Pod::Perldoc's find_good_formatter_class()) > > Net::LocalConfig (via Net::Config) > > Term::ReadLine::XXXX (via Term::ReadLine) > > IO::Uncompress::XXXX (via IO::Uncompress::AnyUncompress)
> > Test.pm attempts to load Algorithm::Diff, though this is probably > hard to take advantage of. > > File::Spec::(Cygwin|Win32|VMS) attempt to load optional modules. > > Net::Ping attempts to load Net::Ping::External. > > perl5db.pl attempts to load PadWalker. > > base.pm optionally loads its argument, I'm not entirely sure what > to do about this one, I can see it's argument being in the current > directory fairly commonly. > > I haven't looked in detail at ext/ and cpan/ yet.
Thanks for these additional data points, and indeed all your work on this issue, Tony. It seems like the problem does need to be attacked from all angles. I will try some experiments with the sitecustomize.pl route, probably not before Debconf. Thanks, Dominic. [1] <http://search.cpan.org/~rjbs/perl-5.24.0/pod/perlrun.pod> [2] apologies for the long silence from the Debian side
Date: Thu, 23 Jun 2016 12:25:16 +0200
Subject: Re: [perl #127834] Flaws in Perl code due to unsafe module load path
From: demerphq <demerphq [...] gmail.com>
CC: yves orton via RT <perl5-security-report [...] perl.org>, carnil [...] debian.org, Florian Weimer <fw [...] deneb.enyo.de>, John Lightsey <lightsey [...] debian.org>, Todd Rinaldo <toddr [...] cpan.org>, Niko Tyni <ntyni [...] debian.org>
To: Dominic Hargreaves <dom [...] earth.li>
Download (untitled) / with headers
text/plain 3.1k
On 23 June 2016 at 12:20, Dominic Hargreaves <dom@earth.li> wrote: Show quoted text
> On Thu, Jun 23, 2016 at 12:07:31AM -0700, yves orton via RT wrote:
>> On 23 June 2016 at 02:06, Dominic Hargreaves <dom@earth.li> wrote:
>
>> > Thank you for sending these patches. Would it be fair to say that this >> > is a statement that for the perl core, the problem shall by fixed in >> > scripts and not in intermediate modules?
>> >> For what its worth, I read it as a first step only. >> >> I think the long term fix will involve removing "." from @INC by >> default, but we haven't decided on the right way to do it.
> > Right, I was unclear in my late night email composition :( In this > sentence, I was only asking about the fix for maint-*. >
>> IOW, I think the point we are making is that patching the modules you >> speak of might fix 90% of the known cases in known scripts, but it >> wont really solve the general problem, and we would like to solve >> that.
> > Absolutely. But we have to fix the 90% too on disclosure day. >
>> FWIW, at $work we have patched out "." from @INC using a >> sitecustomize.pl script. I wonder if this is an option for Debian. For >> instance if the Debian perl was configured to use sitecustomize.pl you >> could have it filter out "." from @INC on your own, based on the >> presence or absence of an ENV var. >> >> Not an ideal solution but one you could use to achieve a holistic >> solution to this class of problem. I admit to not knowing the full >> security ramifications of enabling sitecustomize.pl, and/or how it can >> be secured. I would assume the Debian team has more competent people >> than me to assess that route.
> > Thanks for this suggestion! I wasn't aware of sitecustomize.pl, and > indeed perhaps that does give us additional options, given that it will > allow more flexibility to try things out and configure things. Based on > my limited knowledge of sitecustomize.pl (which more or less comes from > [1]) I don't see much scope for mischief, if the code is kept simple. > > Debian people: based on the likely breakage to modules and user scripts, > do you believe we should be considering removing . from @INC at a > global level at disclosure time? I am prepared to entertain that > suggestion, but it would probably generate quite a lot of heat. > > In order to answer this question we need a perl build which > does this and start some mass rebuilds, though some real world testing > would also be needed. It's possible that in 90% of Debian systems (likely > ones where people are not actively developing perl modules, or using > CPAN etc, all would be fine with the change enabled globally. > > The nice thing about the sitecustomize.pl approach is that it could be > made a conffile; so it could be configured to take effect (giving 100% > protection) if a user requests it at package install time (if it's indeed > too invasive to enable by default). I think this would be more useful > than being controlled solely by an environment variable, although a > *temporary* environment variable fix (PERL_USE_UNSAFE_INC?) could still > be supported.
Just to be clear, IIUIR whatever env var fix you did could also live in sitecustomize. Yves
Subject: Re: [perl #127834] Flaws in Perl code due to unsafe module load path
From: Leon Timmermans <fawaka [...] gmail.com>
CC: rt-deliver-to-perl5-security-report [...] rt.perl.org
To: "perl5-security-report [...] perl.org" <perl5-security-report [...] perl.org>
Date: Thu, 23 Jun 2016 13:55:55 +0200
Download (untitled) / with headers
text/plain 1.4k
On Mon, Jun 20, 2016 at 4:10 AM, Tony Cook via RT <perl5-security-report@perl.org> wrote:
Show quoted text
A summary of the various proposed solutions for 5.25 onwards:

1) Add a -Dfortify_inc Configure option to remove . from @INC and then
let the toolchain and the user:

 a) set PERL_USE_UNSAFE_INC environment variable as a flag to add . at
 the back

 b) add . to PERL5LIB to add it at the front

 c) add -J. to PERL5OPTS to add it at the back

 d) add . to PERL5PUSHLIB to add it at the back

 e) let Makefile.PL and Build.PL be magic script names that add . at
 the back

I think option d is the most elegant there; though I I'd prefer also having the -J command line option for symmetry. On one hand it allows us to achieve exactly what we want to achieve (and gives some opportunity for more), it doesn't break older perls and is easy to implement reliably.
 
Show quoted text
2) Add a -Dunsafe_inc Configure option that's the inverse of 1)

I would prefer this over option 1, in fact in the long term I consider it the only possible fix. That said, I think I would prefer a transitional period with option 1 for at least 5.26.
 
Show quoted text
4) Make . at the end of @INC special/magic so that we:

 a) perform security checks on curdir to decide if code can safely
 load from it

 b) croak if the . entry is used when require is called within an eval

 c) b), but warn instead of croaking

I suspect this would indeed not have the right value for money, sadly.

Leon

RT-Send-CC: rt-deliver-to-perl5-security-report [...] rt.perl.org
Download (untitled) / with headers
text/plain 2.3k
On Thu Jun 23 00:55:38 2016, tonyc wrote: Show quoted text
> On Wed Jun 22 17:06:38 2016, dom wrote:
> > On Mon, Jun 20, 2016 at 05:47:57PM -0700, Tony Cook via RT wrote:
> > > Proposed patches for maint-5.24. > > > > > > The first patch applies to maint-5.22 cleanly.
> > > > Thank you for sending these patches. Would it be fair to say that this > > is a statement that for the perl core, the problem shall by fixed in > > scripts and not in intermediate modules?
> > No, my aim was try to make some progress (any progress) on the issue. > > Sawyer and I have since discussed this ticket and I will also be > patching modules included in maint and blead to locally remove that > final . from @INC when loading optional modules. >
> > For Debian, given the payoffs previously mentioned (90% fixage > > just by patching Encode and Storable) I think that we must do that > > too. > > Patching just the tools we know about (apt-show-versions > > and dpkg-preconfigure) and leaving Encode and Storable alone is > > verging on reckless, since we can be almost sure that we're leaving > > vulnerable scripts which we could protect (and it's almost certainly > > not practical to patch all of them). > > > > John identified the following other modules to be patched in his email > > of 21st April: > > > > Encode::ConfigLocal (via Encode) > > Log::Agent (via Storable) > > Locale::Maketext::Lexicon (via Local::Maketext::Simple) > > Mo::builder and Mo::default (via YAML::Mo) > > > > Other ones that show up repeatedly when actually running different > > Perl scripts: > > > > Pod::Perldoc::ToXXXX (via Pod::Perldoc's find_good_formatter_class()) > > Net::LocalConfig (via Net::Config) > > Term::ReadLine::XXXX (via Term::ReadLine) > > IO::Uncompress::XXXX (via IO::Uncompress::AnyUncompress)
I think the attached covers all of these except YAML::Mo (which isn't part of the perl distribution. Show quoted text
> base.pm optionally loads its argument, I'm not entirely sure what > to do about this one, I can see it's argument being in the current > directory fairly commonly.
This is an issue for Module::Load and Module::Load::Conditional too, I think changing them to exclude . themselves would break back-compat for a maint release. Show quoted text
> I haven't looked in detail at ext/ and cpan/ yet.
I didn't find anything in ext/ or in lib/ other than perl5db.pl Committers: I've pushed this to the perlsec repo as tonyc/127834-sec-utils Tony
Subject: 0003-perl5db.pl-ensure-PadWalker-is-loaded-from-standard-.patch
From a38aa465d4eab26b1f1d6b17f8790b46d8b8ab9e Mon Sep 17 00:00:00 2001 From: Tony Cook <tony@develop-help.com> Date: Thu, 23 Jun 2016 10:41:48 +1000 Subject: [PATCH 3/8] perl5db.pl: ensure PadWalker is loaded from standard paths --- lib/perl5db.pl | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/lib/perl5db.pl b/lib/perl5db.pl index f26731b..99566a7 100644 --- a/lib/perl5db.pl +++ b/lib/perl5db.pl @@ -1951,7 +1951,10 @@ sub _DB__handle_y_command { = $obj->cmd_args =~ /\A(?:(\d*)\s*(.*))?\z/) { # See if we've got the necessary support. - if (!eval { require PadWalker; PadWalker->VERSION(0.08) }) { + if (!eval { + local @INC = @INC; + pop @INC if $INC[-1] eq '.'; + require PadWalker; PadWalker->VERSION(0.08) }) { my $Err = $@; _db_warn( $Err =~ /locate/ @@ -9441,7 +9444,10 @@ if PadWalker could be loaded. =cut - if (not $text =~ /::/ and eval { require PadWalker } ) { + if (not $text =~ /::/ and eval { + local @INC = @INC; + pop @INC if $INC[-1] eq '.'; + require PadWalker } ) { my $level = 1; while (1) { my @info = caller($level); -- 2.1.4
Subject: 0004-perl5db.pl-bump-perldb-VERSION.patch
From 5580db21cf470f20ca20f8bcdb0e32a234810420 Mon Sep 17 00:00:00 2001 From: Tony Cook <tony@develop-help.com> Date: Thu, 23 Jun 2016 16:09:24 +1000 Subject: [PATCH 4/8] perl5db.pl: bump perldb $VERSION --- lib/perl5db.pl | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lib/perl5db.pl b/lib/perl5db.pl index 99566a7..6dae6b0 100644 --- a/lib/perl5db.pl +++ b/lib/perl5db.pl @@ -528,7 +528,7 @@ BEGIN { # Debugger for Perl 5.00x; perl5db.pl patch level: use vars qw($VERSION $header); -$VERSION = '1.49_04'; +$VERSION = '1.49_05'; $header = "perl5db.pl version $VERSION"; -- 2.1.4
Subject: 0005-dist-remove-.-from-INC-when-loading-optional-modules.patch
From bba4e2c3279510343b1380b5655df6d5466595a7 Mon Sep 17 00:00:00 2001 From: Tony Cook <tony@develop-help.com> Date: Thu, 23 Jun 2016 14:06:40 +1000 Subject: [PATCH 5/8] dist/: remove . from @INC when loading optional modules I didn't update base.pm since that seems more likely to be loading modules *expected* to be in the current directory. Opinions welcome. --- dist/I18N-LangTags/lib/I18N/LangTags/Detect.pm | 2 ++ dist/IO/IO.pm | 2 ++ dist/Locale-Maketext/lib/Locale/Maketext.pm | 2 ++ dist/Net-Ping/lib/Net/Ping.pm | 6 +++++- dist/PathTools/Cwd.pm | 5 ++++- dist/PathTools/lib/File/Spec/Cygwin.pm | 6 +++++- dist/PathTools/lib/File/Spec/VMS.pm | 5 ++++- dist/PathTools/lib/File/Spec/Win32.pm | 6 +++++- dist/Storable/Storable.pm | 8 +++++++- dist/Test/lib/Test.pm | 7 ++++++- 10 files changed, 42 insertions(+), 7 deletions(-) diff --git a/dist/I18N-LangTags/lib/I18N/LangTags/Detect.pm b/dist/I18N-LangTags/lib/I18N/LangTags/Detect.pm index f13d546..e9c3aaa 100644 --- a/dist/I18N-LangTags/lib/I18N/LangTags/Detect.pm +++ b/dist/I18N-LangTags/lib/I18N/LangTags/Detect.pm @@ -145,6 +145,8 @@ sub _try_use { # Basically a wrapper around "require Modulename" print " About to use $module ...\n" if DEBUG; { local $SIG{'__DIE__'}; + local @INC = @INC; + pop @INC if $INC[-1] eq '.'; eval "require $module"; # used to be "use $module", but no point in that. } if($@) { diff --git a/dist/IO/IO.pm b/dist/IO/IO.pm index de3e991..833f1a2 100644 --- a/dist/IO/IO.pm +++ b/dist/IO/IO.pm @@ -18,6 +18,8 @@ sub import { my @l = @_ ? @_ : qw(Handle Seekable File Pipe Socket Dir); + local @INC = @INC; + pop @INC if $INC[-1] eq '.'; eval join("", map { "require IO::" . (/(\w+)/)[0] . ";\n" } @l) or croak $@; } diff --git a/dist/Locale-Maketext/lib/Locale/Maketext.pm b/dist/Locale-Maketext/lib/Locale/Maketext.pm index 24c31ea..facc32a 100644 --- a/dist/Locale-Maketext/lib/Locale/Maketext.pm +++ b/dist/Locale-Maketext/lib/Locale/Maketext.pm @@ -449,6 +449,8 @@ sub _try_use { # Basically a wrapper around "require Modulename" local $SIG{'__DIE__'}; local $@; + local @INC = @INC; + pop @INC if $INC[-1] eq '.'; eval "require $module"; # used to be "use $module", but no point in that. if($@) { diff --git a/dist/Net-Ping/lib/Net/Ping.pm b/dist/Net-Ping/lib/Net/Ping.pm index 2766c9e..c9cbd27 100644 --- a/dist/Net-Ping/lib/Net/Ping.pm +++ b/dist/Net-Ping/lib/Net/Ping.pm @@ -410,7 +410,11 @@ sub ping_external { $timeout # Seconds after which ping times out ) = @_; - eval { require Net::Ping::External; } + eval { + local @INC = @INC; + pop @INC if $INC[-1] eq '.'; + require Net::Ping::External; + } or croak('Protocol "external" not supported on your system: Net::Ping::External not found'); return Net::Ping::External::ping(ip => $ip, timeout => $timeout); } diff --git a/dist/PathTools/Cwd.pm b/dist/PathTools/Cwd.pm index e8b9f19..8df2ec5 100644 --- a/dist/PathTools/Cwd.pm +++ b/dist/PathTools/Cwd.pm @@ -40,7 +40,10 @@ if ($^O eq 'os2') { my $use_vms_feature; BEGIN { if ($^O eq 'VMS') { - if (eval { local $SIG{__DIE__}; require VMS::Feature; }) { + if (eval { local $SIG{__DIE__}; + local @INC = @INC; + pop @INC if $INC[-1] eq '.'; + require VMS::Feature; }) { $use_vms_feature = 1; } } diff --git a/dist/PathTools/lib/File/Spec/Cygwin.pm b/dist/PathTools/lib/File/Spec/Cygwin.pm index 2092eb8..6afb604 100644 --- a/dist/PathTools/lib/File/Spec/Cygwin.pm +++ b/dist/PathTools/lib/File/Spec/Cygwin.pm @@ -137,7 +137,11 @@ sub case_tolerant { if ($mntopts and ($mntopts =~ /,managed/)) { return 0; } - eval { require Win32API::File; } or return 1; + eval { + local @INC = @INC; + pop @INC if $INC[-1] eq '.'; + require Win32API::File; + } or return 1; my $osFsType = "\0"x256; my $osVolName = "\0"x256; my $ouFsFlags = 0; diff --git a/dist/PathTools/lib/File/Spec/VMS.pm b/dist/PathTools/lib/File/Spec/VMS.pm index 02cc0b0..0012fdc 100644 --- a/dist/PathTools/lib/File/Spec/VMS.pm +++ b/dist/PathTools/lib/File/Spec/VMS.pm @@ -39,7 +39,10 @@ via the C<DECC$FILENAME_UNIX_REPORT> CRTL feature. my $use_feature; BEGIN { - if (eval { local $SIG{__DIE__}; require VMS::Feature; }) { + if (eval { local $SIG{__DIE__}; + local @INC = @INC; + pop @INC if $INC[-1] eq '.'; + require VMS::Feature; }) { $use_feature = 1; } } diff --git a/dist/PathTools/lib/File/Spec/Win32.pm b/dist/PathTools/lib/File/Spec/Win32.pm index 1105b67..bfd7987 100644 --- a/dist/PathTools/lib/File/Spec/Win32.pm +++ b/dist/PathTools/lib/File/Spec/Win32.pm @@ -90,7 +90,11 @@ Default: 1 =cut sub case_tolerant { - eval { require Win32API::File; } or return 1; + eval { + local @INC = @INC; + pop @INC if $INC[-1] eq '.'; + require Win32API::File; + } or return 1; my $drive = shift || "C:"; my $osFsType = "\0"x256; my $osVolName = "\0"x256; diff --git a/dist/Storable/Storable.pm b/dist/Storable/Storable.pm index c8f6db1..541776d 100644 --- a/dist/Storable/Storable.pm +++ b/dist/Storable/Storable.pm @@ -25,7 +25,13 @@ use vars qw($canonical $forgive_me $VERSION); $VERSION = '2.56'; BEGIN { - if (eval { local $SIG{__DIE__}; require Log::Agent; 1 }) { + if (eval { + local $SIG{__DIE__}; + local @INC = @INC; + pop @INC if $INC[-1] eq '.'; + require Log::Agent; + 1; + }) { Log::Agent->import; } # diff --git a/dist/Test/lib/Test.pm b/dist/Test/lib/Test.pm index de20922..d75b0cc 100644 --- a/dist/Test/lib/Test.pm +++ b/dist/Test/lib/Test.pm @@ -505,7 +505,12 @@ sub _diff_complain { my($result, $expected, $detail, $prefix) = @_; return _diff_complain_external(@_) if $ENV{PERL_TEST_DIFF}; return _diff_complain_algdiff(@_) - if eval { require Algorithm::Diff; Algorithm::Diff->VERSION(1.15); 1; }; + if eval { + local @INC = @INC; + pop @INC if $INC[-1] eq '.'; + require Algorithm::Diff; Algorithm::Diff->VERSION(1.15); + 1; + }; $told_about_diff++ or print $TESTERR <<"EOT"; # $prefix (Install the Algorithm::Diff module to have differences in multiline -- 2.1.4
Subject: 0006-dist-bump-VERSION-as-needed.patch
From ad0af9a1a6e0f5e1945eb2095e4c1ff63772d302 Mon Sep 17 00:00:00 2001 From: Tony Cook <tony@develop-help.com> Date: Thu, 23 Jun 2016 16:11:48 +1000 Subject: [PATCH 6/8] dist/: bump $VERSION as needed --- dist/I18N-LangTags/lib/I18N/LangTags/Detect.pm | 2 +- dist/IO/IO.pm | 2 +- dist/Locale-Maketext/lib/Locale/Maketext.pm | 2 +- dist/Net-Ping/lib/Net/Ping.pm | 2 +- dist/PathTools/Cwd.pm | 2 +- dist/PathTools/lib/File/Spec.pm | 2 +- dist/PathTools/lib/File/Spec/Cygwin.pm | 2 +- dist/PathTools/lib/File/Spec/Epoc.pm | 2 +- dist/PathTools/lib/File/Spec/Functions.pm | 2 +- dist/PathTools/lib/File/Spec/Mac.pm | 2 +- dist/PathTools/lib/File/Spec/OS2.pm | 2 +- dist/PathTools/lib/File/Spec/Unix.pm | 2 +- dist/PathTools/lib/File/Spec/VMS.pm | 2 +- dist/PathTools/lib/File/Spec/Win32.pm | 2 +- dist/Storable/Storable.pm | 2 +- dist/Test/lib/Test.pm | 2 +- 16 files changed, 16 insertions(+), 16 deletions(-) diff --git a/dist/I18N-LangTags/lib/I18N/LangTags/Detect.pm b/dist/I18N-LangTags/lib/I18N/LangTags/Detect.pm index e9c3aaa..a877fbf 100644 --- a/dist/I18N-LangTags/lib/I18N/LangTags/Detect.pm +++ b/dist/I18N-LangTags/lib/I18N/LangTags/Detect.pm @@ -11,7 +11,7 @@ use vars qw( @ISA $VERSION $MATCH_SUPERS $USING_LANGUAGE_TAGS BEGIN { unless(defined &DEBUG) { *DEBUG = sub () {0} } } # define the constant 'DEBUG' at compile-time -$VERSION = "1.05"; +$VERSION = "1.05_01"; @ISA = (); use I18N::LangTags qw(alternate_language_tags locale2language_tag); diff --git a/dist/IO/IO.pm b/dist/IO/IO.pm index 833f1a2..44b312b 100644 --- a/dist/IO/IO.pm +++ b/dist/IO/IO.pm @@ -7,7 +7,7 @@ use Carp; use strict; use warnings; -our $VERSION = "1.36"; +our $VERSION = "1.36_01"; XSLoader::load 'IO', $VERSION; sub import { diff --git a/dist/Locale-Maketext/lib/Locale/Maketext.pm b/dist/Locale-Maketext/lib/Locale/Maketext.pm index facc32a..e73c149 100644 --- a/dist/Locale-Maketext/lib/Locale/Maketext.pm +++ b/dist/Locale-Maketext/lib/Locale/Maketext.pm @@ -27,7 +27,7 @@ BEGIN { } -$VERSION = '1.26'; +$VERSION = '1.26_01'; @ISA = (); $MATCH_SUPERS = 1; diff --git a/dist/Net-Ping/lib/Net/Ping.pm b/dist/Net-Ping/lib/Net/Ping.pm index c9cbd27..86b0dfd 100644 --- a/dist/Net-Ping/lib/Net/Ping.pm +++ b/dist/Net-Ping/lib/Net/Ping.pm @@ -17,7 +17,7 @@ use Time::HiRes; @ISA = qw(Exporter); @EXPORT = qw(pingecho); -$VERSION = "2.43"; +$VERSION = "2.43_01"; # Constants diff --git a/dist/PathTools/Cwd.pm b/dist/PathTools/Cwd.pm index 8df2ec5..3b63889 100644 --- a/dist/PathTools/Cwd.pm +++ b/dist/PathTools/Cwd.pm @@ -3,7 +3,7 @@ use strict; use Exporter; use vars qw(@ISA @EXPORT @EXPORT_OK $VERSION); -$VERSION = '3.63'; +$VERSION = '3.63_01'; my $xs_version = $VERSION; $VERSION =~ tr/_//d; diff --git a/dist/PathTools/lib/File/Spec.pm b/dist/PathTools/lib/File/Spec.pm index 32b987e..3ef0f33 100644 --- a/dist/PathTools/lib/File/Spec.pm +++ b/dist/PathTools/lib/File/Spec.pm @@ -3,7 +3,7 @@ package File::Spec; use strict; use vars qw(@ISA $VERSION); -$VERSION = '3.63'; +$VERSION = '3.63_01'; $VERSION =~ tr/_//d; my %module = (MacOS => 'Mac', diff --git a/dist/PathTools/lib/File/Spec/Cygwin.pm b/dist/PathTools/lib/File/Spec/Cygwin.pm index 6afb604..10b14c4 100644 --- a/dist/PathTools/lib/File/Spec/Cygwin.pm +++ b/dist/PathTools/lib/File/Spec/Cygwin.pm @@ -4,7 +4,7 @@ use strict; use vars qw(@ISA $VERSION); require File::Spec::Unix; -$VERSION = '3.63'; +$VERSION = '3.63_01'; $VERSION =~ tr/_//d; @ISA = qw(File::Spec::Unix); diff --git a/dist/PathTools/lib/File/Spec/Epoc.pm b/dist/PathTools/lib/File/Spec/Epoc.pm index 22f0192..9b9e1fa 100644 --- a/dist/PathTools/lib/File/Spec/Epoc.pm +++ b/dist/PathTools/lib/File/Spec/Epoc.pm @@ -3,7 +3,7 @@ package File::Spec::Epoc; use strict; use vars qw($VERSION @ISA); -$VERSION = '3.63'; +$VERSION = '3.63_01'; $VERSION =~ tr/_//d; require File::Spec::Unix; diff --git a/dist/PathTools/lib/File/Spec/Functions.pm b/dist/PathTools/lib/File/Spec/Functions.pm index af2c498..a4e1b1b 100644 --- a/dist/PathTools/lib/File/Spec/Functions.pm +++ b/dist/PathTools/lib/File/Spec/Functions.pm @@ -5,7 +5,7 @@ use strict; use vars qw(@ISA @EXPORT @EXPORT_OK %EXPORT_TAGS $VERSION); -$VERSION = '3.63'; +$VERSION = '3.63_01'; $VERSION =~ tr/_//d; require Exporter; diff --git a/dist/PathTools/lib/File/Spec/Mac.pm b/dist/PathTools/lib/File/Spec/Mac.pm index 52c3bfe..22424f3 100644 --- a/dist/PathTools/lib/File/Spec/Mac.pm +++ b/dist/PathTools/lib/File/Spec/Mac.pm @@ -4,7 +4,7 @@ use strict; use vars qw(@ISA $VERSION); require File::Spec::Unix; -$VERSION = '3.63'; +$VERSION = '3.63_01'; $VERSION =~ tr/_//d; @ISA = qw(File::Spec::Unix); diff --git a/dist/PathTools/lib/File/Spec/OS2.pm b/dist/PathTools/lib/File/Spec/OS2.pm index 804ecdb..0119042 100644 --- a/dist/PathTools/lib/File/Spec/OS2.pm +++ b/dist/PathTools/lib/File/Spec/OS2.pm @@ -4,7 +4,7 @@ use strict; use vars qw(@ISA $VERSION); require File::Spec::Unix; -$VERSION = '3.63'; +$VERSION = '3.63_01'; $VERSION =~ tr/_//d; @ISA = qw(File::Spec::Unix); diff --git a/dist/PathTools/lib/File/Spec/Unix.pm b/dist/PathTools/lib/File/Spec/Unix.pm index 3916a11..9598dbb 100644 --- a/dist/PathTools/lib/File/Spec/Unix.pm +++ b/dist/PathTools/lib/File/Spec/Unix.pm @@ -3,7 +3,7 @@ package File::Spec::Unix; use strict; use vars qw($VERSION); -$VERSION = '3.63'; +$VERSION = '3.63_01'; my $xs_version = $VERSION; $VERSION =~ tr/_//d; diff --git a/dist/PathTools/lib/File/Spec/VMS.pm b/dist/PathTools/lib/File/Spec/VMS.pm index 0012fdc..c0cc1e5 100644 --- a/dist/PathTools/lib/File/Spec/VMS.pm +++ b/dist/PathTools/lib/File/Spec/VMS.pm @@ -4,7 +4,7 @@ use strict; use vars qw(@ISA $VERSION); require File::Spec::Unix; -$VERSION = '3.63'; +$VERSION = '3.63_01'; $VERSION =~ tr/_//d; @ISA = qw(File::Spec::Unix); diff --git a/dist/PathTools/lib/File/Spec/Win32.pm b/dist/PathTools/lib/File/Spec/Win32.pm index bfd7987..578d61b 100644 --- a/dist/PathTools/lib/File/Spec/Win32.pm +++ b/dist/PathTools/lib/File/Spec/Win32.pm @@ -5,7 +5,7 @@ use strict; use vars qw(@ISA $VERSION); require File::Spec::Unix; -$VERSION = '3.63'; +$VERSION = '3.63_01'; $VERSION =~ tr/_//d; @ISA = qw(File::Spec::Unix); diff --git a/dist/Storable/Storable.pm b/dist/Storable/Storable.pm index 541776d..5823b93 100644 --- a/dist/Storable/Storable.pm +++ b/dist/Storable/Storable.pm @@ -22,7 +22,7 @@ package Storable; @ISA = qw(Exporter); use vars qw($canonical $forgive_me $VERSION); -$VERSION = '2.56'; +$VERSION = '2.56_01'; BEGIN { if (eval { diff --git a/dist/Test/lib/Test.pm b/dist/Test/lib/Test.pm index d75b0cc..3350517 100644 --- a/dist/Test/lib/Test.pm +++ b/dist/Test/lib/Test.pm @@ -20,7 +20,7 @@ sub _reset_globals { $planned = 0; } -$VERSION = '1.28'; +$VERSION = '1.28_01'; require Exporter; @ISA=('Exporter'); -- 2.1.4
Subject: 0007-cpan-remove-.-from-INC-when-loading-optional-modules.patch
From ac3018533c70bdc0b003178ab360bc720a8f4144 Mon Sep 17 00:00:00 2001 From: Tony Cook <tony@develop-help.com> Date: Mon, 27 Jun 2016 16:21:21 +1000 Subject: [PATCH 7/8] cpan/: remove . from @INC when loading optional modules --- cpan/CPAN/lib/App/Cpan.pm | 21 ++++++++++++++++----- cpan/CPAN/lib/CPAN.pm | 4 ++++ cpan/Digest/Digest.pm | 6 +++++- cpan/Encode/Encode.pm | 2 ++ cpan/ExtUtils-MakeMaker/lib/ExtUtils/Command.pm | 5 ++++- cpan/File-Fetch/lib/File/Fetch.pm | 2 ++ cpan/HTTP-Tiny/lib/HTTP/Tiny.pm | 4 ++++ cpan/IO-Compress/lib/IO/Uncompress/AnyUncompress.pm | 2 ++ cpan/IPC-Cmd/lib/IPC/Cmd.pm | 4 ++++ .../lib/Locale/Maketext/Simple.pm | 7 ++++++- cpan/Memoize/Memoize.pm | 6 +++++- cpan/Pod-Perldoc/lib/Pod/Perldoc.pm | 5 +++++ cpan/bignum/lib/bigint.pm | 2 ++ cpan/bignum/lib/bignum.pm | 2 ++ cpan/bignum/lib/bigrat.pm | 2 ++ 15 files changed, 65 insertions(+), 9 deletions(-) diff --git a/cpan/CPAN/lib/App/Cpan.pm b/cpan/CPAN/lib/App/Cpan.pm index e8c9bb7..3fac04d 100644 --- a/cpan/CPAN/lib/App/Cpan.pm +++ b/cpan/CPAN/lib/App/Cpan.pm @@ -530,9 +530,20 @@ sub AUTOLOAD { 1 } sub DESTROY { 1 } } +# load a module without searching the default entry for the current +# directory +sub _safe_load_module { + my $name = shift; + + local @INC = @INC; + pop @INC if $INC[-1] eq '.'; + + eval "require $name; 1"; +} + sub _init_logger { - my $log4perl_loaded = eval "require Log::Log4perl; 1"; + my $log4perl_loaded = _safe_load_module("Log::Log4perl"); unless( $log4perl_loaded ) { @@ -993,7 +1004,7 @@ sub _load_local_lib # -I { $logger->debug( "Loading local::lib" ); - my $rc = eval { require local::lib; 1; }; + my $rc = _safe_load_module("local::lib"); unless( $rc ) { $logger->die( "Could not load local::lib" ); } @@ -1121,7 +1132,7 @@ sub _get_file { my $path = shift; - my $loaded = eval "require LWP::Simple; 1;"; + my $loaded = _safe_load_module("LWP::Simple"); croak "You need LWP::Simple to use features that fetch files from CPAN\n" unless $loaded; @@ -1143,7 +1154,7 @@ sub _gitify { my $args = shift; - my $loaded = eval "require Archive::Extract; 1;"; + my $loaded = _safe_load_module("Archive::Extract"); croak "You need Archive::Extract to use features that gitify distributions\n" unless $loaded; @@ -1207,7 +1218,7 @@ sub _show_Changes sub _get_changes_file { croak "Reading Changes files requires LWP::Simple and URI\n" - unless eval "require LWP::Simple; require URI; 1"; + unless _safe_load_module("LWP::Simple") && _safe_load_module("URI"); my $url = shift; diff --git a/cpan/CPAN/lib/CPAN.pm b/cpan/CPAN/lib/CPAN.pm index f4544f0..25bf349 100644 --- a/cpan/CPAN/lib/CPAN.pm +++ b/cpan/CPAN/lib/CPAN.pm @@ -1104,6 +1104,8 @@ sub has_usable { ] }; if ($usable->{$mod}) { + local @INC = @INC; + pop @INC if $INC[-1] eq '.'; for my $c (0..$#{$usable->{$mod}}) { my $code = $usable->{$mod}[$c]; my $ret = eval { &$code() }; @@ -1146,6 +1148,8 @@ sub has_inst { $CPAN::META->{dontload_hash}{$mod}||=1; # unsafe meta access, ok return 0; } + local @INC = @INC; + pop @INC if $INC[-1] eq '.'; my $file = $mod; my $obj; $file =~ s|::|/|g; diff --git a/cpan/Digest/Digest.pm b/cpan/Digest/Digest.pm index c3355a8..299e25e 100644 --- a/cpan/Digest/Digest.pm +++ b/cpan/Digest/Digest.pm @@ -38,7 +38,11 @@ sub new unless (exists ${"$class\::"}{"VERSION"}) { my $pm_file = $class . ".pm"; $pm_file =~ s{::}{/}g; - eval { require $pm_file }; + eval { + local @INC = @INC; + pop @INC if $INC[-1] eq '.'; + require $pm_file + }; if ($@) { $err ||= $@; next; diff --git a/cpan/Encode/Encode.pm b/cpan/Encode/Encode.pm index d2ac30f..dce6c54 100644 --- a/cpan/Encode/Encode.pm +++ b/cpan/Encode/Encode.pm @@ -56,6 +56,8 @@ require Encode::Config; eval { local $SIG{__DIE__}; local $SIG{__WARN__}; + local @INC = @INC; + pop @INC if $INC[-1] eq '.'; require Encode::ConfigLocal; }; diff --git a/cpan/ExtUtils-MakeMaker/lib/ExtUtils/Command.pm b/cpan/ExtUtils-MakeMaker/lib/ExtUtils/Command.pm index 4cc8d62..34e85de 100644 --- a/cpan/ExtUtils-MakeMaker/lib/ExtUtils/Command.pm +++ b/cpan/ExtUtils-MakeMaker/lib/ExtUtils/Command.pm @@ -20,7 +20,10 @@ if( $Is_VMS ) { my $vms_efs; my $vms_case; - if (eval { local $SIG{__DIE__}; require VMS::Feature; }) { + if (eval { local $SIG{__DIE__}; + local @INC = @INC; + pop @INC if $INC[-1] eq '.'; + require VMS::Feature; }) { $vms_unix_rpt = VMS::Feature::current("filename_unix_report"); $vms_efs = VMS::Feature::current("efs_charset"); $vms_case = VMS::Feature::current("efs_case_preserve"); diff --git a/cpan/File-Fetch/lib/File/Fetch.pm b/cpan/File-Fetch/lib/File/Fetch.pm index 7d6a263..660fb42 100644 --- a/cpan/File-Fetch/lib/File/Fetch.pm +++ b/cpan/File-Fetch/lib/File/Fetch.pm @@ -567,6 +567,8 @@ sub _lwp_fetch { }; + local @INC = @INC; + pop @INC if $INC[-1] eq '.'; unless( can_load( modules => $use_list ) ) { $METHOD_FAIL->{'lwp'} = 1; return; diff --git a/cpan/HTTP-Tiny/lib/HTTP/Tiny.pm b/cpan/HTTP-Tiny/lib/HTTP/Tiny.pm index 52887d1..8b62a27 100644 --- a/cpan/HTTP-Tiny/lib/HTTP/Tiny.pm +++ b/cpan/HTTP-Tiny/lib/HTTP/Tiny.pm @@ -485,6 +485,8 @@ sub can_ssl { my($ok, $reason) = (1, ''); # Need IO::Socket::SSL 1.42 for SSL_create_ctx_callback + local @INC = @INC; + pop @INC if $INC[-1] eq '.'; unless (eval {require IO::Socket::SSL; IO::Socket::SSL->VERSION(1.42)}) { $ok = 0; $reason .= qq/IO::Socket::SSL 1.42 must be installed for https support\n/; @@ -1441,6 +1443,8 @@ sub _find_CA_file { return $self->{SSL_options}->{SSL_ca_file}; } + local @INC = @INC; + pop @INC if $INC[-1] eq '.'; return Mozilla::CA::SSL_ca_file() if eval { require Mozilla::CA; 1 }; diff --git a/cpan/IO-Compress/lib/IO/Uncompress/AnyUncompress.pm b/cpan/IO-Compress/lib/IO/Uncompress/AnyUncompress.pm index eab3459..92a04a4 100644 --- a/cpan/IO-Compress/lib/IO/Uncompress/AnyUncompress.pm +++ b/cpan/IO-Compress/lib/IO/Uncompress/AnyUncompress.pm @@ -27,6 +27,8 @@ Exporter::export_ok_tags('all'); BEGIN { + local @INC = @INC; + pop @INC if $INC[-1] eq '.'; eval ' use IO::Uncompress::Adapter::Inflate 2.069 ;'; eval ' use IO::Uncompress::Adapter::Bunzip2 2.069 ;'; eval ' use IO::Uncompress::Adapter::LZO 2.069 ;'; diff --git a/cpan/IPC-Cmd/lib/IPC/Cmd.pm b/cpan/IPC-Cmd/lib/IPC/Cmd.pm index 6a82bdf..84ad0a0 100644 --- a/cpan/IPC-Cmd/lib/IPC/Cmd.pm +++ b/cpan/IPC-Cmd/lib/IPC/Cmd.pm @@ -142,6 +142,8 @@ sub can_use_ipc_run { return if IS_WIN98; ### if we don't have ipc::run, we obviously can't use it. + local @INC = @INC; + pop @INC if $INC[-1] eq '.'; return unless can_load( modules => { 'IPC::Run' => '0.55' }, verbose => ($WARN && $verbose), @@ -169,6 +171,8 @@ sub can_use_ipc_open3 { ### IPC::Open3 works on every non-VMS platform, but it can't ### capture buffers on win32 :( + local @INC = @INC; + pop @INC if $INC[-1] eq '.'; return unless can_load( modules => { map {$_ => '0.0'} qw|IPC::Open3 IO::Select Symbol| }, verbose => ($WARN && $verbose), diff --git a/cpan/Locale-Maketext-Simple/lib/Locale/Maketext/Simple.pm b/cpan/Locale-Maketext-Simple/lib/Locale/Maketext/Simple.pm index 30760f3..9465c52 100644 --- a/cpan/Locale-Maketext-Simple/lib/Locale/Maketext/Simple.pm +++ b/cpan/Locale-Maketext-Simple/lib/Locale/Maketext/Simple.pm @@ -134,7 +134,12 @@ sub load_loc { my $pkg = join('::', grep { defined and length } $args{Class}, $args{Subclass}); return $Loc{$pkg} if exists $Loc{$pkg}; - eval { require Locale::Maketext::Lexicon; 1 } or return; + eval { + local @INC = @INC; + pop @INC if $INC[-1] eq '.'; + require Locale::Maketext::Lexicon; + 1 + } or return; $Locale::Maketext::Lexicon::VERSION > 0.20 or return; eval { require File::Spec; 1 } or return; diff --git a/cpan/Memoize/Memoize.pm b/cpan/Memoize/Memoize.pm index 9a58c4a..b566f21 100644 --- a/cpan/Memoize/Memoize.pm +++ b/cpan/Memoize/Memoize.pm @@ -184,7 +184,11 @@ sub _my_tie { } my $modulefile = $module . '.pm'; $modulefile =~ s{::}{/}g; - eval { require $modulefile }; + eval { + local @INC = @INC; + pop @INC if $INC[-1] eq '.'; + require $modulefile + }; if ($@) { croak "Memoize: Couldn't load hash tie module `$module': $@; aborting"; } diff --git a/cpan/Pod-Perldoc/lib/Pod/Perldoc.pm b/cpan/Pod-Perldoc/lib/Pod/Perldoc.pm index 84f6624..d35d0a0 100644 --- a/cpan/Pod-Perldoc/lib/Pod/Perldoc.pm +++ b/cpan/Pod-Perldoc/lib/Pod/Perldoc.pm @@ -575,6 +575,9 @@ sub find_good_formatter_class { my @class_list = @{ $self->{'formatter_classes'} || [] }; $self->die( "WHAT? Nothing in the formatter class list!?" ) unless @class_list; + local @INC = @INC; + pop @INC if $INC[-1] eq '.'; + my $good_class_found; foreach my $c (@class_list) { DEBUG > 4 and print "Trying to load $c...\n"; @@ -1006,6 +1009,8 @@ sub new_translator { # $tr = $self->new_translator($lang); my $self = shift; my $lang = shift; + local @INC = @INC; + pop @INC if $INC[-1] eq '.'; my $pack = 'POD2::' . uc($lang); eval "require $pack"; if ( !$@ && $pack->can('new') ) { diff --git a/cpan/bignum/lib/bigint.pm b/cpan/bignum/lib/bigint.pm index a47191e..e8ad732 100644 --- a/cpan/bignum/lib/bigint.pm +++ b/cpan/bignum/lib/bigint.pm @@ -315,6 +315,8 @@ sub import { } else { # see if we can find Math::BigInt::Lite if (!defined $a && !defined $p) { # rounding won't work to well + local @INC = @INC; + pop @INC if $INC[-1] eq '.'; if (eval { require Math::BigInt::Lite; 1 }) { @import = (); # :constant in Lite, not MBI Math::BigInt::Lite->import(':constant'); diff --git a/cpan/bignum/lib/bignum.pm b/cpan/bignum/lib/bignum.pm index 90d5db5..b7449d9 100644 --- a/cpan/bignum/lib/bignum.pm +++ b/cpan/bignum/lib/bignum.pm @@ -157,6 +157,8 @@ sub import { else { # see if we can find Math::BigInt::Lite if (!defined $a && !defined $p) { # rounding won't work to well + local @INC = @INC; + pop @INC if $INC[-1] eq '.'; if (eval { require Math::BigInt::Lite; 1 }) { @import = (); # :constant in Lite, not MBI Math::BigInt::Lite->import(':constant'); diff --git a/cpan/bignum/lib/bigrat.pm b/cpan/bignum/lib/bigrat.pm index 79fe84d..a4489e8 100644 --- a/cpan/bignum/lib/bigrat.pm +++ b/cpan/bignum/lib/bigrat.pm @@ -150,6 +150,8 @@ sub import { else { # see if we can find Math::BigInt::Lite if (!defined $a && !defined $p) { # rounding won't work to well + local @INC = @INC; + pop @INC if $INC[-1] eq '.'; if (eval { require Math::BigInt::Lite; 1 }) { @import = (); # :constant in Lite, not MBI Math::BigInt::Lite->import(':constant'); -- 2.1.4
Subject: 0008-cpan-bump-VERSION-as-needed.patch
From 34abb34830876e6538dd2b164de1ac92e068882d Mon Sep 17 00:00:00 2001 From: Tony Cook <tony@develop-help.com> Date: Mon, 27 Jun 2016 16:35:02 +1000 Subject: [PATCH 8/8] cpan/: bump $VERSION as needed --- cpan/CPAN/lib/App/Cpan.pm | 2 +- cpan/Digest/Digest.pm | 2 +- cpan/File-Fetch/lib/File/Fetch.pm | 2 +- cpan/HTTP-Tiny/lib/HTTP/Tiny.pm | 2 +- cpan/IPC-Cmd/lib/IPC/Cmd.pm | 2 +- cpan/Locale-Maketext-Simple/lib/Locale/Maketext/Simple.pm | 2 +- cpan/Memoize/Memoize.pm | 2 +- cpan/Pod-Perldoc/lib/Pod/Perldoc.pm | 2 +- cpan/bignum/lib/Math/BigFloat/Trace.pm | 2 +- cpan/bignum/lib/Math/BigInt/Trace.pm | 2 +- cpan/bignum/lib/bigint.pm | 2 +- cpan/bignum/lib/bignum.pm | 2 +- cpan/bignum/lib/bigrat.pm | 2 +- 13 files changed, 13 insertions(+), 13 deletions(-) diff --git a/cpan/CPAN/lib/App/Cpan.pm b/cpan/CPAN/lib/App/Cpan.pm index 3fac04d..94607d9 100644 --- a/cpan/CPAN/lib/App/Cpan.pm +++ b/cpan/CPAN/lib/App/Cpan.pm @@ -6,7 +6,7 @@ use vars qw($VERSION); use if $] < 5.008 => 'IO::Scalar'; -$VERSION = '1.63'; +$VERSION = '1.63_01'; =head1 NAME diff --git a/cpan/Digest/Digest.pm b/cpan/Digest/Digest.pm index 299e25e..16dae9d 100644 --- a/cpan/Digest/Digest.pm +++ b/cpan/Digest/Digest.pm @@ -3,7 +3,7 @@ package Digest; use strict; use vars qw($VERSION %MMAP $AUTOLOAD); -$VERSION = "1.17"; +$VERSION = "1.17_01"; %MMAP = ( "SHA-1" => [["Digest::SHA", 1], "Digest::SHA1", ["Digest::SHA2", 1]], diff --git a/cpan/File-Fetch/lib/File/Fetch.pm b/cpan/File-Fetch/lib/File/Fetch.pm index 660fb42..9a94a13 100644 --- a/cpan/File-Fetch/lib/File/Fetch.pm +++ b/cpan/File-Fetch/lib/File/Fetch.pm @@ -22,7 +22,7 @@ use vars qw[ $VERBOSE $PREFER_BIN $FROM_EMAIL $USER_AGENT $FTP_PASSIVE $TIMEOUT $DEBUG $WARN $FORCEIPV4 ]; -$VERSION = '0.48'; +$VERSION = '0.48_01'; $VERSION = eval $VERSION; # avoid warnings with development releases $PREFER_BIN = 0; # XXX TODO implement $FROM_EMAIL = 'File-Fetch@example.com'; diff --git a/cpan/HTTP-Tiny/lib/HTTP/Tiny.pm b/cpan/HTTP-Tiny/lib/HTTP/Tiny.pm index 8b62a27..f9e5184 100644 --- a/cpan/HTTP-Tiny/lib/HTTP/Tiny.pm +++ b/cpan/HTTP-Tiny/lib/HTTP/Tiny.pm @@ -4,7 +4,7 @@ use strict; use warnings; # ABSTRACT: A small, simple, correct HTTP/1.1 client -our $VERSION = '0.056'; +our $VERSION = '0.056_001'; use Carp (); diff --git a/cpan/IPC-Cmd/lib/IPC/Cmd.pm b/cpan/IPC-Cmd/lib/IPC/Cmd.pm index 84ad0a0..4705f04 100644 --- a/cpan/IPC-Cmd/lib/IPC/Cmd.pm +++ b/cpan/IPC-Cmd/lib/IPC/Cmd.pm @@ -18,7 +18,7 @@ BEGIN { $HAVE_MONOTONIC ]; - $VERSION = '0.92'; + $VERSION = '0.92_01'; $VERBOSE = 0; $DEBUG = 0; $WARN = 1; diff --git a/cpan/Locale-Maketext-Simple/lib/Locale/Maketext/Simple.pm b/cpan/Locale-Maketext-Simple/lib/Locale/Maketext/Simple.pm index 9465c52..9e61670 100644 --- a/cpan/Locale-Maketext-Simple/lib/Locale/Maketext/Simple.pm +++ b/cpan/Locale-Maketext-Simple/lib/Locale/Maketext/Simple.pm @@ -1,5 +1,5 @@ package Locale::Maketext::Simple; -$Locale::Maketext::Simple::VERSION = '0.21'; +$Locale::Maketext::Simple::VERSION = '0.21_01'; use strict; use 5.005; diff --git a/cpan/Memoize/Memoize.pm b/cpan/Memoize/Memoize.pm index b566f21..f4e6522 100644 --- a/cpan/Memoize/Memoize.pm +++ b/cpan/Memoize/Memoize.pm @@ -9,7 +9,7 @@ # write to mjd-perl-memoize+@plover.com for a license. package Memoize; -$VERSION = '1.03'; +$VERSION = '1.03_01'; # Compile-time constants sub SCALAR () { 0 } diff --git a/cpan/Pod-Perldoc/lib/Pod/Perldoc.pm b/cpan/Pod-Perldoc/lib/Pod/Perldoc.pm index d35d0a0..787353b 100644 --- a/cpan/Pod-Perldoc/lib/Pod/Perldoc.pm +++ b/cpan/Pod-Perldoc/lib/Pod/Perldoc.pm @@ -12,7 +12,7 @@ use File::Spec::Functions qw(catfile catdir splitdir); use vars qw($VERSION @Pagers $Bindir $Pod2man $Temp_Files_Created $Temp_File_Lifetime ); -$VERSION = '3.25_02'; # patched in perl5.git +$VERSION = '3.25_03'; # patched in perl5.git $VERSION =~ s/_//; #.......................................................................... diff --git a/cpan/bignum/lib/Math/BigFloat/Trace.pm b/cpan/bignum/lib/Math/BigFloat/Trace.pm index 5e043f5..634d967 100644 --- a/cpan/bignum/lib/Math/BigFloat/Trace.pm +++ b/cpan/bignum/lib/Math/BigFloat/Trace.pm @@ -13,7 +13,7 @@ our ($PACKAGE, @EXPORT_OK, $accuracy, $precision, $round_mode, $div_scale); our @ISA = qw(Exporter Math::BigFloat); -our $VERSION = '0.42'; +our $VERSION = '0.42_01'; use overload; # inherit overload from BigFloat diff --git a/cpan/bignum/lib/Math/BigInt/Trace.pm b/cpan/bignum/lib/Math/BigInt/Trace.pm index 646c05f..4e47497 100644 --- a/cpan/bignum/lib/Math/BigInt/Trace.pm +++ b/cpan/bignum/lib/Math/BigInt/Trace.pm @@ -13,7 +13,7 @@ our ($PACKAGE, @EXPORT_OK, $accuracy, $precision, $round_mode, $div_scale); our @ISA = qw(Exporter Math::BigInt); -our $VERSION = '0.42'; +our $VERSION = '0.42_01'; use overload; # inherit overload from BigInt diff --git a/cpan/bignum/lib/bigint.pm b/cpan/bignum/lib/bigint.pm index e8ad732..bc1ebe3 100644 --- a/cpan/bignum/lib/bigint.pm +++ b/cpan/bignum/lib/bigint.pm @@ -4,7 +4,7 @@ use 5.006; use strict; use warnings; -our $VERSION = '0.42'; +our $VERSION = '0.42_01'; use Exporter; our @ISA = qw( Exporter ); diff --git a/cpan/bignum/lib/bignum.pm b/cpan/bignum/lib/bignum.pm index b7449d9..394b147 100644 --- a/cpan/bignum/lib/bignum.pm +++ b/cpan/bignum/lib/bignum.pm @@ -4,7 +4,7 @@ use 5.006; use strict; use warnings; -our $VERSION = '0.42'; +our $VERSION = '0.42_01'; use Exporter; our @ISA = qw( bigint ); diff --git a/cpan/bignum/lib/bigrat.pm b/cpan/bignum/lib/bigrat.pm index a4489e8..260973b 100644 --- a/cpan/bignum/lib/bigrat.pm +++ b/cpan/bignum/lib/bigrat.pm @@ -4,7 +4,7 @@ use 5.006; use strict; use warnings; -our $VERSION = '0.42'; +our $VERSION = '0.42_01'; use Exporter; our @ISA = qw( bigint ); -- 2.1.4
RT-Send-CC: rt-deliver-to-perl5-security-report [...] rt.perl.org
On Mon Jun 27 00:01:05 2016, tonyc wrote: Show quoted text
> On Thu Jun 23 00:55:38 2016, tonyc wrote:
> > On Wed Jun 22 17:06:38 2016, dom wrote:
> > > On Mon, Jun 20, 2016 at 05:47:57PM -0700, Tony Cook via RT wrote:
> > > > Proposed patches for maint-5.24. > > > > > > > > The first patch applies to maint-5.22 cleanly.
> > > > > > Thank you for sending these patches. Would it be fair to say that > > > this > > > is a statement that for the perl core, the problem shall by fixed > > > in > > > scripts and not in intermediate modules?
> > > > No, my aim was try to make some progress (any progress) on the issue. > > > > Sawyer and I have since discussed this ticket and I will also be > > patching modules included in maint and blead to locally remove that > > final . from @INC when loading optional modules. > >
> > > For Debian, given the payoffs previously mentioned (90% fixage > > > just by patching Encode and Storable) I think that we must do that > > > too. > > > Patching just the tools we know about (apt-show-versions > > > and dpkg-preconfigure) and leaving Encode and Storable alone is > > > verging on reckless, since we can be almost sure that we're leaving > > > vulnerable scripts which we could protect (and it's almost > > > certainly > > > not practical to patch all of them). > > > > > > John identified the following other modules to be patched in his > > > email > > > of 21st April: > > > > > > Encode::ConfigLocal (via Encode) > > > Log::Agent (via Storable) > > > Locale::Maketext::Lexicon (via Local::Maketext::Simple) > > > Mo::builder and Mo::default (via YAML::Mo) > > > > > > Other ones that show up repeatedly when actually running different > > > Perl scripts: > > > > > > Pod::Perldoc::ToXXXX (via Pod::Perldoc's > > > find_good_formatter_class()) > > > Net::LocalConfig (via Net::Config) > > > Term::ReadLine::XXXX (via Term::ReadLine) > > > IO::Uncompress::XXXX (via IO::Uncompress::AnyUncompress)
> > I think the attached covers all of these except YAML::Mo (which isn't > part of the perl distribution. >
> > base.pm optionally loads its argument, I'm not entirely sure what > > to do about this one, I can see it's argument being in the current > > directory fairly commonly.
> > This is an issue for Module::Load and Module::Load::Conditional too, I > think > changing them to exclude . themselves would break back-compat for a > maint > release. >
> > I haven't looked in detail at ext/ and cpan/ yet.
> > I didn't find anything in ext/ or in lib/ other than perl5db.pl > > Committers: I've pushed this to the perlsec repo as tonyc/127834-sec- > utils > > Tony
Thank you for the work, Tony. To summarize where we are now: Tony provided patches for core utilities and core modules. Now we have the following things to resolve: * Verifying the solution John and Todd, could you please review the patches? We will also need a +1 from at least one more core dev. Can anyone step up, please? * Requesting a CVE This is a bit tricky. For perl to request a CVE, I would prefer we agree it is a perl security bug. There seems to be disagreement here. My worry is that since this is debatable, the discussion could take some time which I would rather not spend delaying this. We will already have to coordinate release with vendors. My suggestion is that Debian request a CVE (if possible), and in case this is revised again in the perl core (5.26+), perl could either reference this CVE as "We decided to resolve this in core as well", or introduce a new CVE referencing this. Either way, we have at least a few more months before that. If Debian cannot request a CVE, we will. * Deciding on a date of disclosure I agree somewhere near end of July is good, but I will need to contact vendors to verify. I will do that tomorrow. * Prepare and release maintenance versions Steve Hay is in charge of this. We should at least make sure to coordinate upstream and vendor releases. Did I miss anything? Does anyone have any comments? Can we hear from our reporters, Debian representative, and at least another core developer approving the solution? Thank you.
RT-Send-CC: rt-deliver-to-perl5-security-report [...] rt.perl.org
Download (untitled) / with headers
text/plain 994b
On Mon Jun 27 00:01:05 2016, tonyc wrote: Show quoted text
> I think the attached covers all of these except YAML::Mo (which isn't > part of the perl distribution. >
> > base.pm optionally loads its argument, I'm not entirely sure what > > to do about this one, I can see it's argument being in the current > > directory fairly commonly.
> > This is an issue for Module::Load and Module::Load::Conditional too, I > think > changing them to exclude . themselves would break back-compat for a > maint > release. >
> > I haven't looked in detail at ext/ and cpan/ yet.
> > I didn't find anything in ext/ or in lib/ other than perl5db.pl > > Committers: I've pushed this to the perlsec repo as tonyc/127834-sec- > utils
That branch now also includes the CUSTOMIZED updates. I've also backported the changes to maint-5.22, which are in tonyc/127834-dot-in-inc-5.22 in the perlsec repo. I've attached both patch series here (using format-patch --stdout instead of individual files for all our sanities). Tony
Subject: maint-5.22-dot-in-inc.patch

Message body is not shown because it is too large.

Subject: maint-5.24-dot-in-inc.patch

Message body is not shown because it is too large.

Date: Wed, 29 Jun 2016 23:06:56 -0500
CC: dom [...] earth.li, ntyni [...] debian.org
To: perl5-security-report [...] perl.org, carnil [...] debian.org, fw [...] deneb.enyo.de, toddr [...] cpan.org
From: John Lightsey <lightsey [...] debian.org>
Subject: Re: [perl #127834] Flaws in Perl code due to unsafe module load path
Download (untitled) / with headers
text/plain 588b
On Wed, 2016-06-29 at 17:51 -0700, Tony Cook via RT wrote: Show quoted text
>  > > That branch now also includes the CUSTOMIZED updates. > > I've also backported the changes to maint-5.22, which are in tonyc/127834-dot- > in-inc-5.22 in the perlsec repo. > > I've attached both patch series here (using format-patch --stdout instead of > individual files for all our sanities). >
Excellent, thanks. I upgraded two identically configured VMs to 5.22 tonight to do some testing with these changes. I should have time tomorrow evening to patch one with these changes and do comparisons of the behavior.
Download signature.asc
application/pgp-signature 819b

Message body not shown because it is not plain text.

Date: Thu, 30 Jun 2016 09:21:30 +0200
Subject: Re: [perl #127834] Flaws in Perl code due to unsafe module load path
From: Salvatore Bonaccorso <carnil [...] debian.org>
CC: carnil [...] debian.org, fw [...] deneb.enyo.de, lightsey [...] debian.org, toddr [...] cpan.org, dom [...] earth.li, ntyni [...] debian.org
To: Sawyer X via RT <perl5-security-report [...] perl.org>
Hi, On Wed, Jun 29, 2016 at 02:59:59PM -0700, Sawyer X via RT wrote: Show quoted text
> * Requesting a CVE > > This is a bit tricky. For perl to request a CVE, I would prefer we > agree it is a perl security bug. There seems to be disagreement > here. My worry is that since this is debatable, the discussion could > take some time which I would rather not spend delaying this. We will > already have to coordinate release with vendors. > > My suggestion is that Debian request a CVE (if possible), and in > case this is revised again in the perl core (5.26+), perl could > either reference this CVE as "We decided to resolve this in core as > well", or introduce a new CVE referencing this. Either way, we have > at least a few more months before that. > > If Debian cannot request a CVE, we will.
I think we just could assign a CVE from the pool assigned to Debian. I can take and assign one as needed for the "Perls unsafe module load path / . included in @INC" issue. Question to Florian Weimer (as well Debian's security team member): Fine if we just pick one from the 2016-CVEs? Regards, Salvatore
Date: Thu, 30 Jun 2016 09:37:41 +0200
To: Salvatore Bonaccorso <carnil [...] debian.org>
CC: Sawyer X via RT <perl5-security-report [...] perl.org>, lightsey [...] debian.org, toddr [...] cpan.org, dom [...] earth.li, ntyni [...] debian.org
Subject: Re: [perl #127834] Flaws in Perl code due to unsafe module load path
From: Florian Weimer <fw [...] deneb.enyo.de>
Download (untitled) / with headers
text/plain 210b
* Salvatore Bonaccorso: Show quoted text
> Question to Florian Weimer (as well Debian's security team member): > Fine if we just pick one from the 2016-CVEs?
Salvatore, I see no problem with that. Please go ahead. Florian
Subject: Re: [perl #127834] Flaws in Perl code due to unsafe module load path
From: Salvatore Bonaccorso <carnil [...] debian.org>
To: Sawyer X via RT <perl5-security-report [...] perl.org>
CC: fw [...] deneb.enyo.de, lightsey [...] debian.org, toddr [...] cpan.org, dom [...] earth.li, ntyni [...] debian.org
Date: Thu, 30 Jun 2016 09:54:00 +0200
Download (untitled) / with headers
text/plain 1.1k
Hi, On Thu, Jun 30, 2016 at 09:21:30AM +0200, Salvatore Bonaccorso wrote: Show quoted text
> Hi, > > On Wed, Jun 29, 2016 at 02:59:59PM -0700, Sawyer X via RT wrote:
> > * Requesting a CVE > > > > This is a bit tricky. For perl to request a CVE, I would prefer we > > agree it is a perl security bug. There seems to be disagreement > > here. My worry is that since this is debatable, the discussion could > > take some time which I would rather not spend delaying this. We will > > already have to coordinate release with vendors. > > > > My suggestion is that Debian request a CVE (if possible), and in > > case this is revised again in the perl core (5.26+), perl could > > either reference this CVE as "We decided to resolve this in core as > > well", or introduce a new CVE referencing this. Either way, we have > > at least a few more months before that. > > > > If Debian cannot request a CVE, we will.
> > I think we just could assign a CVE from the pool assigned to Debian. I > can take and assign one as needed for the "Perl's unsafe module load > path / . included in @INC" issue.
Okay, got confirmation from Florian. Please use CVE-2016-1238. Regards, Salvatore
Download signature.asc
application/pgp-signature 819b

Message body not shown because it is not plain text.

RT-Send-CC: rt-deliver-to-perl5-security-report [...] rt.perl.org
Download (untitled) / with headers
text/plain 1.4k
On Thu Jun 30 00:54:40 2016, carnil@debian.org wrote: Show quoted text
> Hi, > > On Thu, Jun 30, 2016 at 09:21:30AM +0200, Salvatore Bonaccorso wrote:
> > Hi, > > > > On Wed, Jun 29, 2016 at 02:59:59PM -0700, Sawyer X via RT wrote:
> > > * Requesting a CVE > > > > > > This is a bit tricky. For perl to request a CVE, I would prefer we > > > agree it is a perl security bug. There seems to be disagreement > > > here. My worry is that since this is debatable, the discussion could > > > take some time which I would rather not spend delaying this. We will > > > already have to coordinate release with vendors. > > > > > > My suggestion is that Debian request a CVE (if possible), and in > > > case this is revised again in the perl core (5.26+), perl could > > > either reference this CVE as "We decided to resolve this in core as > > > well", or introduce a new CVE referencing this. Either way, we have > > > at least a few more months before that. > > > > > > If Debian cannot request a CVE, we will.
> > > > I think we just could assign a CVE from the pool assigned to Debian. I > > can take and assign one as needed for the "Perl's unsafe module load > > path / . included in @INC" issue.
> > Okay, got confirmation from Florian. > > Please use CVE-2016-1238. > > Regards, > Salvatore
Thanks, guys! Steve, would it be possible to align the next maint releases (5.24, 5.22, and possibly 5.20) to the end of the month? On the schedule, 5.24.1 seems to be slotted for July anyway.
Subject: Re: [perl #127834] Flaws in Perl code due to unsafe module load path
From: Steve Hay via perl5-security-report <perl5-security-report [...] perl.org>
CC: rt-deliver-to-perl5-security-report [...] rt.perl.org
To: perl5-security-report [...] perl.org
Date: Thu, 30 Jun 2016 18:05:12 +0100
Download (untitled) / with headers
text/plain 2.3k
On 30 June 2016 at 09:28, Sawyer X via RT <perl5-security-report@perl.org> wrote: Show quoted text
> On Thu Jun 30 00:54:40 2016, carnil@debian.org wrote:
>> Hi, >> >> On Thu, Jun 30, 2016 at 09:21:30AM +0200, Salvatore Bonaccorso wrote:
>> > Hi, >> > >> > On Wed, Jun 29, 2016 at 02:59:59PM -0700, Sawyer X via RT wrote:
>> > > * Requesting a CVE >> > > >> > > This is a bit tricky. For perl to request a CVE, I would prefer we >> > > agree it is a perl security bug. There seems to be disagreement >> > > here. My worry is that since this is debatable, the discussion could >> > > take some time which I would rather not spend delaying this. We will >> > > already have to coordinate release with vendors. >> > > >> > > My suggestion is that Debian request a CVE (if possible), and in >> > > case this is revised again in the perl core (5.26+), perl could >> > > either reference this CVE as "We decided to resolve this in core as >> > > well", or introduce a new CVE referencing this. Either way, we have >> > > at least a few more months before that. >> > > >> > > If Debian cannot request a CVE, we will.
>> > >> > I think we just could assign a CVE from the pool assigned to Debian. I >> > can take and assign one as needed for the "Perl's unsafe module load >> > path / . included in @INC" issue.
>> >> Okay, got confirmation from Florian. >> >> Please use CVE-2016-1238. >> >> Regards, >> Salvatore
> > Thanks, guys! > > Steve, would it be possible to align the next maint releases (5.24, 5.22, and possibly 5.20) to the end of the month? On the schedule, 5.24.1 seems to be slotted for July anyway. >
It would be possible, but we undertook not to make maint releases at the same time as a blead-final (.0) release in the wake of 5.24.0 and 5.22.2 being produced at almost the same time, because it gave problems for maintainers of perl distros like Strawberry Perl. Presumably multiple simultaneous maint releases would cause the same problems. Would it be better to do 5.24.1 first, and then move onto 5.22.3 after that's done and dusted? i.e. wait until 5.24.1 (final) is uploaded before putting out a 5.22.3-RC1. And likewise delay 5.20.3 until after 5.22.3 is done. Or does a need for simultaneuous releases on security grounds outweigh any concerns over headaches that we might cause perl packagers? (Releases would be unlikely to be exactly simultaneous anyway, given that they would all have to go through RC phases, which could have varying lengths.)
Date: Fri, 1 Jul 2016 12:52:41 +0100
Subject: Re: [perl #127834] Flaws in Perl code due to unsafe module load path
From: Dave Mitchell <davem [...] iabyn.com>
CC: rt-deliver-to-perl5-security-report [...] rt.perl.org
To: Tony Cook via RT <perl5-security-report [...] perl.org>
Download (untitled) / with headers
text/plain 1.5k
On Wed, Jun 29, 2016 at 05:51:59PM -0700, Tony Cook via RT wrote: Show quoted text
> > Committers: I've pushed this to the perlsec repo as tonyc/127834-sec- > > utils
> > That branch now also includes the CUSTOMIZED updates. > > I've also backported the changes to maint-5.22, which are in tonyc/127834-dot-in-inc-5.22 in the perlsec repo.
Can I just clarify what the current overall plan is (from the perl end). IIUC the current view is: 1) around the disclosure time we make new releases of the current maint branches (5.24.x, 5.22.x), along with blead, that: a) don't alter the @INC behaviour of the perl binary; b) modify all scripts bundled with the perl core to strip dot from @INC at startup; c) modify bundled modules to temporarily strip dot from @INC when loading optional modules. The idea being that this is good enough to stop most (but not all) attack vectors. For example 3rd party scripts using non-core modules that do optional loads (either the script or the module) would still be vulnerable. If someone wants a maint perl built without dot by default, we advise to build with usesitecustomize then create a $sitelibexp/sitecustomize.pl that trips @INC. 2) Then at some later point (e.g. 5.26.0) we change the perl binary to not include dot by default, and update CPAN.pm etc to set, say, PERL5LIB=. to avoid breaking module building. The exact details still TBA. Does this sound right? -- The Enterprise successfully ferries an alien VIP from one place to another without serious incident. -- Things That Never Happen in "Star Trek" #7
To: perl5-security-report [...] perl.org
Subject: Re: [perl #127834] Flaws in Perl code due to unsafe module load path
From: Zefram <zefram [...] fysh.org>
Date: Fri, 1 Jul 2016 16:29:05 +0100
Download (untitled) / with headers
text/plain 544b
Steve Hay via perl5-security-report wrote: Show quoted text
>It would be possible, but we undertook not to make maint releases at >the same time as a blead-final (.0) release
... Show quoted text
>Or does a need for simultaneuous releases on security grounds outweigh >any concerns over headaches that we might cause perl packagers?
In this case, the security issue compels us to make all the relevant releases simultaneously (or very nearly so), at the same time that the issue is publicly disclosed. This has to outweigh the inconvenience to downstream packagers. -zefram
Date: Fri, 1 Jul 2016 09:46:05 -0600
Subject: Re: [perl #127834] Flaws in Perl code due to unsafe module load path
From: Karl Williamson <public [...] khwilliamson.com>
CC: rt-deliver-to-perl5-security-report [...] rt.perl.org
To: Steve Hay <steve.m.hay [...] googlemail.com>, perl5-security-report [...] perl.org
On 06/30/2016 11:05 AM, Steve Hay via perl5-security-report wrote: Show quoted text
> On 30 June 2016 at 09:28, Sawyer X via RT > <perl5-security-report@perl.org> wrote:
>> On Thu Jun 30 00:54:40 2016, carnil@debian.org wrote:
>>> Hi, >>> >>> On Thu, Jun 30, 2016 at 09:21:30AM +0200, Salvatore Bonaccorso wrote:
>>>> Hi, >>>> >>>> On Wed, Jun 29, 2016 at 02:59:59PM -0700, Sawyer X via RT wrote:
>>>>> * Requesting a CVE >>>>> >>>>> This is a bit tricky. For perl to request a CVE, I would prefer we >>>>> agree it is a perl security bug. There seems to be disagreement >>>>> here. My worry is that since this is debatable, the discussion could >>>>> take some time which I would rather not spend delaying this. We will >>>>> already have to coordinate release with vendors. >>>>> >>>>> My suggestion is that Debian request a CVE (if possible), and in >>>>> case this is revised again in the perl core (5.26+), perl could >>>>> either reference this CVE as "We decided to resolve this in core as >>>>> well", or introduce a new CVE referencing this. Either way, we have >>>>> at least a few more months before that. >>>>> >>>>> If Debian cannot request a CVE, we will.
>>>> >>>> I think we just could assign a CVE from the pool assigned to Debian. I >>>> can take and assign one as needed for the "Perl's unsafe module load >>>> path / . included in @INC" issue.
>>> >>> Okay, got confirmation from Florian. >>> >>> Please use CVE-2016-1238. >>> >>> Regards, >>> Salvatore
>> >> Thanks, guys! >> >> Steve, would it be possible to align the next maint releases (5.24, 5.22, and possibly 5.20) to the end of the month? On the schedule, 5.24.1 seems to be slotted for July anyway. >>
> > It would be possible, but we undertook not to make maint releases at > the same time as a blead-final (.0) release in the wake of 5.24.0 and > 5.22.2 being produced at almost the same time, because it gave > problems for maintainers of perl distros like Strawberry Perl. > Presumably multiple simultaneous maint releases would cause the same > problems. > > Would it be better to do 5.24.1 first, and then move onto 5.22.3 after > that's done and dusted? i.e. wait until 5.24.1 (final) is uploaded > before putting out a 5.22.3-RC1. And likewise delay 5.20.3 until after > 5.22.3 is done. > > Or does a need for simultaneuous releases on security grounds outweigh > any concerns over headaches that we might cause perl packagers? > > (Releases would be unlikely to be exactly simultaneous anyway, given > that they would all have to go through RC phases, which could have > varying lengths.) > >
Based on my not having much knowledge of where things stand, I think we should release as simultaneously as possible, and let the downstream people prioritize as they see fit. Some, for example, may not have even released 5.24, so us deciding for them that that should be their highest priority is wrong. They likely would prioritize based on their estimate as to the popularity of the maintenance releases at the moment. Known downstream vendors should be notified in advance that a security update is coming, and when.
Date: Fri, 1 Jul 2016 11:00:23 -0500
CC: Salvatore Bonaccorso <carnil [...] debian.org>, Florian Weimer <fw [...] deneb.enyo.de>, lightsey [...] debian.org, toddr [...] cpan.org, dom [...] earth.li, ntyni [...] debian.org
To: perl5-security-report [...] perl.org
From: Todd Rinaldo <toddr [...] cpanel.net>
Subject: Re: [perl #127834] Flaws in Perl code due to unsafe module load path
Download (untitled) / with headers
text/plain 3.3k
Show quoted text
> On Jul 1, 2016, at 10:46 AM, karl williamson via RT <perl5-security-report@perl.org> wrote: > > On 06/30/2016 11:05 AM, Steve Hay via perl5-security-report wrote:
>> On 30 June 2016 at 09:28, Sawyer X via RT >> <perl5-security-report@perl.org> wrote:
>>> On Thu Jun 30 00:54:40 2016, carnil@debian.org wrote:
>>>> Hi, >>>> >>>> On Thu, Jun 30, 2016 at 09:21:30AM +0200, Salvatore Bonaccorso wrote:
>>>>> Hi, >>>>> >>>>> On Wed, Jun 29, 2016 at 02:59:59PM -0700, Sawyer X via RT wrote:
>>>>>> * Requesting a CVE >>>>>> >>>>>> This is a bit tricky. For perl to request a CVE, I would prefer we >>>>>> agree it is a perl security bug. There seems to be disagreement >>>>>> here. My worry is that since this is debatable, the discussion could >>>>>> take some time which I would rather not spend delaying this. We will >>>>>> already have to coordinate release with vendors. >>>>>> >>>>>> My suggestion is that Debian request a CVE (if possible), and in >>>>>> case this is revised again in the perl core (5.26+), perl could >>>>>> either reference this CVE as "We decided to resolve this in core as >>>>>> well", or introduce a new CVE referencing this. Either way, we have >>>>>> at least a few more months before that. >>>>>> >>>>>> If Debian cannot request a CVE, we will.
>>>>> >>>>> I think we just could assign a CVE from the pool assigned to Debian. I >>>>> can take and assign one as needed for the "Perl's unsafe module load >>>>> path / . included in @INC" issue.
>>>> >>>> Okay, got confirmation from Florian. >>>> >>>> Please use CVE-2016-1238. >>>> >>>> Regards, >>>> Salvatore
>>> >>> Thanks, guys! >>> >>> Steve, would it be possible to align the next maint releases (5.24, 5.22, and possibly 5.20) to the end of the month? On the schedule, 5.24.1 seems to be slotted for July anyway. >>>
>> >> It would be possible, but we undertook not to make maint releases at >> the same time as a blead-final (.0) release in the wake of 5.24.0 and >> 5.22.2 being produced at almost the same time, because it gave >> problems for maintainers of perl distros like Strawberry Perl. >> Presumably multiple simultaneous maint releases would cause the same >> problems. >> >> Would it be better to do 5.24.1 first, and then move onto 5.22.3 after >> that's done and dusted? i.e. wait until 5.24.1 (final) is uploaded >> before putting out a 5.22.3-RC1. And likewise delay 5.20.3 until after >> 5.22.3 is done. >> >> Or does a need for simultaneuous releases on security grounds outweigh >> any concerns over headaches that we might cause perl packagers? >> >> (Releases would be unlikely to be exactly simultaneous anyway, given >> that they would all have to go through RC phases, which could have >> varying lengths.) >> >>
> > Based on my not having much knowledge of where things stand, I think we > should release as simultaneously as possible, and let the downstream > people prioritize as they see fit. Some, for example, may not have even > released 5.24, so us deciding for them that that should be their highest > priority is wrong. They likely would prioritize based on their estimate > as to the popularity of the maintenance releases at the moment. > > Known downstream vendors should be notified in advance that a security > update is coming, and when. > >
We also need to identify which dual life modules need releasing same day. I would expect this to provide the most impact on day one anyway. Todd
Subject: Re: [perl #127834] Flaws in Perl code due to unsafe module load path
From: Todd Rinaldo <toddr [...] cpanel.net>
CC: Salvatore Bonaccorso <carnil [...] debian.org>, Florian Weimer <fw [...] deneb.enyo.de>, John Lightsey <lightsey [...] debian.org>, dom [...] earth.li, ntyni [...] debian.org
To: perl5-security-report [...] perl.org
Date: Fri, 1 Jul 2016 11:32:35 -0500
Download (untitled) / with headers
text/plain 2.1k

Show quoted text
On Jul 1, 2016, at 6:53 AM, Dave Mitchell via RT <perl5-security-report@perl.org> wrote:

On Wed, Jun 29, 2016 at 05:51:59PM -0700, Tony Cook via RT wrote:
Committers: I've pushed this to the perlsec repo as tonyc/127834-sec-
utils

That branch now also includes the CUSTOMIZED updates.

I've also backported the changes to maint-5.22, which are in tonyc/127834-dot-in-inc-5.22 in the perlsec repo.

Can I just clarify what the current overall plan is (from the perl end).

IIUC the current view is:

1) around the disclosure time we make new releases of the current maint
branches (5.24.x, 5.22.x), along with blead, that:
a) don't alter the @INC behaviour of the perl binary;
b) modify all scripts bundled with the perl core to strip dot from @INC
  at startup;
c) modify bundled modules to temporarily strip dot from @INC when loading
  optional modules.

The idea being that this is good enough to stop most (but not all) attack
vectors. For example 3rd party scripts using non-core modules that
do optional loads (either the script or the module) would still be
vulnerable.

If someone wants a maint perl built without dot by default, we advise
to build with usesitecustomize then create a $sitelibexp/sitecustomize.pl
that trips @INC.

2) Then at some later point (e.g. 5.26.0) we change the perl binary to
not include dot by default, and update CPAN.pm etc to set, say,
PERL5LIB=. to avoid breaking module building. The exact details still TBA.

Does this sound right?

Concerning point 2, yes. I would prefer we have this discussion in public here:


The problem is that no further discussions can happen until we publicly disclose the legacy issue. I am anxious for this to happen soon because once we action 127810 in blead, there will likely be CPAN followup that'll need to happen and I hope to facilitate this. The scope of CPAN work is HIGHLY dependent on the decisions made for blead so no work can proceed until we have that chat.

/me goes back to sitting on his hands :)

Todd


Date: Fri, 1 Jul 2016 11:58:29 -0500
To: perl5-security-report [...] perl.org
CC: carnil [...] debian.org, fw [...] deneb.enyo.de, lightsey [...] debian.org, toddr [...] cpan.org, dom [...] earth.li, ntyni [...] debian.org
From: Todd Rinaldo <toddr [...] cpanel.net>
Subject: Re: [perl #127834] Flaws in Perl code due to unsafe module load path
Download (untitled) / with headers
text/plain 4.7k
Show quoted text
> On Jun 29, 2016, at 4:59 PM, Sawyer X via RT <perl5-security-report@perl.org> wrote: > > On Mon Jun 27 00:01:05 2016, tonyc wrote:
>> On Thu Jun 23 00:55:38 2016, tonyc wrote:
>>> On Wed Jun 22 17:06:38 2016, dom wrote:
>>>> On Mon, Jun 20, 2016 at 05:47:57PM -0700, Tony Cook via RT wrote:
>>>>> Proposed patches for maint-5.24. >>>>> >>>>> The first patch applies to maint-5.22 cleanly.
>>>> >>>> Thank you for sending these patches. Would it be fair to say that >>>> this >>>> is a statement that for the perl core, the problem shall by fixed >>>> in >>>> scripts and not in intermediate modules?
>>> >>> No, my aim was try to make some progress (any progress) on the issue. >>> >>> Sawyer and I have since discussed this ticket and I will also be >>> patching modules included in maint and blead to locally remove that >>> final . from @INC when loading optional modules. >>>
>>>> For Debian, given the payoffs previously mentioned (90% fixage >>>> just by patching Encode and Storable) I think that we must do that >>>> too. >>>> Patching just the tools we know about (apt-show-versions >>>> and dpkg-preconfigure) and leaving Encode and Storable alone is >>>> verging on reckless, since we can be almost sure that we're leaving >>>> vulnerable scripts which we could protect (and it's almost >>>> certainly >>>> not practical to patch all of them). >>>> >>>> John identified the following other modules to be patched in his >>>> email >>>> of 21st April: >>>> >>>> Encode::ConfigLocal (via Encode) >>>> Log::Agent (via Storable) >>>> Locale::Maketext::Lexicon (via Local::Maketext::Simple) >>>> Mo::builder and Mo::default (via YAML::Mo) >>>> >>>> Other ones that show up repeatedly when actually running different >>>> Perl scripts: >>>> >>>> Pod::Perldoc::ToXXXX (via Pod::Perldoc's >>>> find_good_formatter_class()) >>>> Net::LocalConfig (via Net::Config) >>>> Term::ReadLine::XXXX (via Term::ReadLine) >>>> IO::Uncompress::XXXX (via IO::Uncompress::AnyUncompress)
>> >> I think the attached covers all of these except YAML::Mo (which isn't >> part of the perl distribution. >>
>>> base.pm optionally loads its argument, I'm not entirely sure what >>> to do about this one, I can see it's argument being in the current >>> directory fairly commonly.
>> >> This is an issue for Module::Load and Module::Load::Conditional too, I >> think >> changing them to exclude . themselves would break back-compat for a >> maint >> release. >>
>>> I haven't looked in detail at ext/ and cpan/ yet.
>> >> I didn't find anything in ext/ or in lib/ other than perl5db.pl >> >> Committers: I've pushed this to the perlsec repo as tonyc/127834-sec- >> utils >> >> Tony
> > > Thank you for the work, Tony. > > > To summarize where we are now: > > Tony provided patches for core utilities and core modules. Now we have the following things to resolve: > > * Verifying the solution > > John and Todd, could you please review the patches? > > We will also need a +1 from at least one more core dev. Can anyone step up, please? > > * Requesting a CVE > > This is a bit tricky. For perl to request a CVE, I would prefer we agree it is a perl security bug. There seems to be disagreement here. My worry is that since this is debatable, the discussion could take some time which I would rather not spend delaying this. We will already have to coordinate release with vendors. > > My suggestion is that Debian request a CVE (if possible), and in case this is revised again in the perl core (5.26+), perl could either reference this CVE as "We decided to resolve this in core as well", or introduce a new CVE referencing this. Either way, we have at least a few more months before that. > > If Debian cannot request a CVE, we will. > > * Deciding on a date of disclosure > > I agree somewhere near end of July is good, but I will need to contact vendors to verify. I will do that tomorrow. > > * Prepare and release maintenance versions > > Steve Hay is in charge of this. We should at least make sure to coordinate upstream and vendor releases. > > > Did I miss anything? Does anyone have any comments? > > Can we hear from our reporters, Debian representative, and at least another core developer approving the solution? > > Thank you.
So we're all on the same page, these are the proposed commits I think we should have at this point? $>git log --oneline maint-5.24.. 1f1ad78 cpan/: bump $VERSION as needed 28af955 cpan/: remove . from @INC when loading optional modules bbc8856 dist/: bump $VERSION as needed cfbf450 dist/: remove . from @INC when loading optional modules 67f0edc perl5db.pl: bump perldb $VERSION d496b2a perl5db.pl: ensure PadWalker is loaded from standard paths 3582b81 (perl #127834) bump versions of modules in dists we updated a utility in da73919 (perl #127834) remove . from the end of @INC if complex modules are loaded
Date: Sat, 2 Jul 2016 19:52:16 +1000
CC: perl5-security-report [...] perl.org, carnil [...] debian.org, fw [...] deneb.enyo.de, lightsey [...] debian.org, toddr [...] cpan.org, dom [...] earth.li, ntyni [...] debian.org
To: Todd Rinaldo <toddr [...] cpanel.net>
From: Tony Cook <tony [...] develop-help.com>
Subject: Re: [perl #127834] Flaws in Perl code due to unsafe module load path
Download (untitled) / with headers
text/plain 868b
On Fri, Jul 01, 2016 at 11:58:29AM -0500, Todd Rinaldo wrote: Show quoted text
> So we're all on the same page, these are the proposed commits I think we should have at this point? > > $>git log --oneline maint-5.24.. > 1f1ad78 cpan/: bump $VERSION as needed > 28af955 cpan/: remove . from @INC when loading optional modules > bbc8856 dist/: bump $VERSION as needed > cfbf450 dist/: remove . from @INC when loading optional modules > 67f0edc perl5db.pl: bump perldb $VERSION > d496b2a perl5db.pl: ensure PadWalker is loaded from standard paths > 3582b81 (perl #127834) bump versions of modules in dists we updated a utility in > da73919 (perl #127834) remove . from the end of @INC if complex modules are loaded > > >
There should also be a (perl #127834) update CUSTOMIZED entries for each branch (included in the maint-5.2[24]-dot-in-inc.patch files I attached.) Tony
Subject: Re: [perl #127834] Flaws in Perl code due to unsafe module load path
From: John Lightsey <john [...] nixnuts.net>
CC: dom [...] earth.li, ntyni [...] debian.org
To: perl5-security-report [...] perl.org, carnil [...] debian.org, fw [...] deneb.enyo.de, toddr [...] cpan.org
Date: Sat, 02 Jul 2016 20:01:37 -0500
Download (untitled) / with headers
text/plain 2.1k
I had plenty of time today to finish testing with the 5.22 patch set. I did several passed trying to get as many /usr/(s)bin/ Perl scripts as possible installed and fuzzing them a bit to see how they'd behave. Total Perl scripts in /usr/bin and /usr/sbin: 423 Vulnerable before patch: 170  (40.2%) Vulnerable after patch:  16    (3.8%) These still show up with perl -c: /usr/bin/alias_manager     Sys/Syslog/Win32.pm     MIME/Charset/Defaults.pm     Unicode/LineBreak/Defaults.pm     Locale/gettext_xs.pm     MIME/EncWords/Defaults.pm /usr/bin/bts     Net/LocalCfg.pm /usr/bin/desktop2menu     File/DesktopEntry.pm /usr/bin/dkimproxy-sign     Net/LibIDN.pm     Net/DNS/Resolver/linux.pm /usr/bin/dkimproxy-verify     Net/LibIDN.pm     Net/DNS/Resolver/linux.pm /usr/bin/spfquery     Net/LibIDN.pm     Net/DNS/Resolver/linux.pm /usr/bin/spfquery.mail-spf-perl     Net/LibIDN.pm     Net/DNS/Resolver/linux.pm /usr/sbin/spfd     Net/LibIDN.pm     Net/DNS/Resolver/linux.pm /usr/sbin/spfd.mail-spf-perl     Net/LibIDN.pm     Net/DNS/Resolver/linux.pm /usr/bin/cpan2deb     Mo/builder.pm     Mo/default.pm /usr/bin/cpan2dsc     Mo/builder.pm     Mo/default.pm /usr/bin/dh-make-perl     Mo/builder.pm     Mo/default.pm /usr/bin/duck     (script has a bad use lib line) /usr/bin/ftpwatch     Net/LocalCfg.pm /usr/bin/pwget     Net/LocalCfg.pm /usr/bin/sbuild     Sbuild/Exception/Base.pm I didn't include these in the totals above since I couldn't get a proper prepatch count, but these also show up as unfixed with flags like --help: /usr/bin/dbiproxy     RPC/PlServer.pm /usr/sbin/eximstats     GD/Graph/pie.pm     GD/Graph/linespoints.pm /usr/bin/dyndns     Sys/Syslog/Win32.pm /usr/bin/spellintian     Net/LibIDN.pm     Net/DNS/Resolver/linux.pm Notes: The frequent Net::LibIDN and Net::DNS::Resolver::linux combination seems to come from Net::DNS::Resolver. Net::LocalCfg is coming from Net::Config which is core in 5.22 and not included in the patchset. Aside from these two modules (and possibly the Mo ones from YAML::Mo) it's probably simpler to fix the rest in the affected scripts.
Download signature.asc
application/pgp-signature 819b

Message body not shown because it is not plain text.

RT-Send-CC: rt-deliver-to-perl5-security-report [...] rt.perl.org
Download (untitled) / with headers
text/plain 551b
On Sat Jul 02 02:54:52 2016, tonyc wrote: Show quoted text
> On Fri, Jul 01, 2016 at 11:58:29AM -0500, Todd Rinaldo wrote:
> > So we're all on the same page, these are the proposed commits I think > > we should have at this point?
> There should also be a > > (perl #127834) update CUSTOMIZED entries
I'll probably end up squashing these to some extent, the fixes are separate from the version bumps to simplify backporting, cpan/ is separate from dist/ to give me a managable chunk of work and the perl5db.pl change was discovered when I went through lib/. Tony
RT-Send-CC: rt-deliver-to-perl5-security-report [...] rt.perl.org
Download (untitled) / with headers
text/plain 1.5k
On Fri Jul 01 04:53:26 2016, davem wrote: Show quoted text
> On Wed, Jun 29, 2016 at 05:51:59PM -0700, Tony Cook via RT wrote:
> > > Committers: I've pushed this to the perlsec repo as tonyc/127834- > > > sec- > > > utils
> > > > That branch now also includes the CUSTOMIZED updates. > > > > I've also backported the changes to maint-5.22, which are in > > tonyc/127834-dot-in-inc-5.22 in the perlsec repo.
> > Can I just clarify what the current overall plan is (from the perl > end). > > IIUC the current view is: > > 1) around the disclosure time we make new releases of the current > maint > branches (5.24.x, 5.22.x), along with blead, that: > a) don't alter the @INC behaviour of the perl binary; > b) modify all scripts bundled with the perl core to strip dot from > @INC > at startup; > c) modify bundled modules to temporarily strip dot from @INC when > loading > optional modules. > > The idea being that this is good enough to stop most (but not all) > attack > vectors. For example 3rd party scripts using non-core modules that > do optional loads (either the script or the module) would still be > vulnerable. > > If someone wants a maint perl built without dot by default, we advise > to build with usesitecustomize then create a > $sitelibexp/sitecustomize.pl > that trips @INC.
I think that's correct. Show quoted text
> 2) Then at some later point (e.g. 5.26.0) we change the perl binary to > not include dot by default, and update CPAN.pm etc to set, say, > PERL5LIB=. to avoid breaking module building. The exact details still > TBA.
I don't know what the final solution for blead will be. Tony
RT-Send-CC: rt-deliver-to-perl5-security-report [...] rt.perl.org
Download (untitled) / with headers
text/plain 440b
On Sat Jul 02 18:02:19 2016, john@nixnuts.net wrote: Show quoted text
> I had plenty of time today to finish testing with the 5.22 patch set.
Thanks. ... Show quoted text
>     Sys/Syslog/Win32.pm
... Show quoted text
>     Net/LocalCfg.pm
Show quoted text
> Net::LocalCfg is coming from Net::Config which is core in 5.22 and not > included > in the patchset.
Sys::Syslog is also included in core. Updated patchsets attached. I squashed the changed back into the appropriate existing commits. Tony
Subject: maint-5.22-dot-in-inc.patch

Message body is not shown because it is too large.

Subject: maint-5.24-dot-in-inc.patch

Message body is not shown because it is too large.

From: Dominic Hargreaves <dom [...] earth.li>
Subject: Re: [perl #127834] Flaws in Perl code due to unsafe module load path
CC: carnil [...] debian.org, fw [...] deneb.enyo.de, lightsey [...] debian.org, toddr [...] cpan.org, ntyni [...] debian.org
To: Sawyer X via RT <perl5-security-report [...] perl.org>
Date: Tue, 5 Jul 2016 12:16:53 +0200
Download (untitled) / with headers
text/plain 4.1k
On Wed, Jun 29, 2016 at 02:59:59PM -0700, Sawyer X via RT wrote: Show quoted text
> To summarize where we are now: > > Tony provided patches for core utilities and core modules. Now we have the following things to resolve: > > * Verifying the solution > > John and Todd, could you please review the patches? > > We will also need a +1 from at least one more core dev. Can anyone step up, please? > > * Requesting a CVE > > This is a bit tricky. For perl to request a CVE, I would prefer we agree it is a perl security bug. There seems to be disagreement here. My worry is that since this is debatable, the discussion could take some time which I would rather not spend delaying this. We will already have to coordinate release with vendors. > > My suggestion is that Debian request a CVE (if possible), and in case this is revised again in the perl core (5.26+), perl could either reference this CVE as "We decided to resolve this in core as well", or introduce a new CVE referencing this. Either way, we have at least a few more months before that. > > If Debian cannot request a CVE, we will.
My understanding is that this CVE will be used at the very least to refer to the upcoming maint releases, and also the Debian fixes for the issue (which will be based on those)? At this stage it would seem proper to use the same CVE when fixing the issue in blead/5.26 by stripping . out of @INC by default, but I don't see a need to fix that in stone if there is some reason not to. However I was a little surprised to read your 'in case this is revised again' above as I thought that there was consensus on this thread that we should indeed do this, with one of the options in the public RT ticket. Show quoted text
> * Deciding on a date of disclosure > > I agree somewhere near end of July is good, but I will need to contact vendors to verify. I will do that tomorrow.
Out of interest, has this already happened? The impact on Debian-derived systems (of which Ubuntu is the most widely-installed) is clearly high, and we would want to work with those teams if possible, to avoid duplicate work (Ubuntu folk would be welcome to contact me and Niko about a fix if they are informed directly). I believe that you contact vendors directly rather than via the distros list <http://oss-security.openwall.org/wiki/mailing-lists/distros> (which appears to have a 14 day maximum disclosure) but nevertheless, making contact and setting a timeline sooner rather than later would be best. Show quoted text
> * Prepare and release maintenance versions > > Steve Hay is in charge of this. We should at least make sure to coordinate upstream and vendor releases.
Yes, I agree. Show quoted text
> Did I miss anything? Does anyone have any comments? > > Can we hear from our reporters, Debian representative, and at least another core developer approving the solution?
Salvatore (for the Debian security team), Niko and I (as Debian perl maintainers) met yesterday and are generally happy with the plan you have proposed. We intend to coordinate updates for our supported releases, and the end of July seems to be an appropriate timescale for this. The releases in question are: Debian unstable/testing: perl 5.22 Debian stable: perl 5.20 Debian oldstable (semi-supported): perl 5.14 We would like to additionally remove . from @INC by default, with a clear notice to users that it can be re-enabled in the advisory. This will be done via the sitecustomize route (which will be somewhat modified so that the file will pulled in from /etc rather than /usr/local, so that it can be handled via the conffile mechanism). We suspect/hope that the impact on Debian-provided software will be minimal, but clearly end-user installed software will be affected. Given the widespread impact of the vulnerability, and the relatively small proportion of users we expect to affected, this seems like the right balance. Our plan is to work on updated packages in the next few days (during DebConf) and perform both automated testing, to make sure that we don't break package builds, and what manual testing we can. We'd definitely appreciate John's help on this verification part. (By the way, thank you John for sending that extensive analysis a few days ago, which has given us the confidence to proceed down this route). Thanks, Dominic.
RT-Send-CC: rt-deliver-to-perl5-security-report [...] rt.perl.org
Download (untitled) / with headers
text/plain 3.8k
On Tue Jul 05 03:17:25 2016, dom wrote: Show quoted text
> On Wed, Jun 29, 2016 at 02:59:59PM -0700, Sawyer X via RT wrote:
> > To summarize where we are now: > > > > Tony provided patches for core utilities and core modules. Now we > > have the following things to resolve: > > > > * Verifying the solution > > > > John and Todd, could you please review the patches? > > > > We will also need a +1 from at least one more core dev. Can anyone > > step up, please? > > > > * Requesting a CVE > > > > This is a bit tricky. For perl to request a CVE, I would prefer we > > agree it is a perl security bug. There seems to be disagreement here. > > My worry is that since this is debatable, the discussion could take > > some time which I would rather not spend delaying this. We will > > already have to coordinate release with vendors. > > > > My suggestion is that Debian request a CVE (if possible), and in case > > this is revised again in the perl core (5.26+), perl could either > > reference this CVE as "We decided to resolve this in core as well", > > or introduce a new CVE referencing this. Either way, we have at least > > a few more months before that. > > > > If Debian cannot request a CVE, we will.
> > My understanding is that this CVE will be used at the very least to > refer to the upcoming maint releases, and also the Debian fixes for > the issue (which will be based on those)? > > At this stage it would seem proper to use the same CVE when > fixing the issue in blead/5.26 by stripping . out of @INC by default, > but I don't see a need to fix that in stone if there is some reason > not to. > However I was a little surprised to read your 'in case this is revised > again' above as I thought that there was consensus on this thread that > we should indeed do this, with one of the options in the public RT > ticket.
I believe we could reference the CVE but will not need a new CVE. Additionally, any future change (dropping . from @INC) can arguably be a different CVE. I think it would be easier to simply consider the future fix a security fix related to this CVE. Show quoted text
>
> > * Deciding on a date of disclosure > > > > I agree somewhere near end of July is good, but I will need to > > contact vendors to verify. I will do that tomorrow.
> > Out of interest, has this already happened? The impact on Debian- > derived > systems (of which Ubuntu is the most widely-installed) is clearly > high, > and we would want to work with those teams if possible, to avoid > duplicate work (Ubuntu folk would be welcome to contact me and Niko > about a fix if they are informed directly).
I'm sorry to say this has not happened yet. It will happen tomorrow morning CEST time. Show quoted text
> > I believe that you contact vendors directly rather than via the > distros list <http://oss-security.openwall.org/wiki/mailing- > lists/distros> > (which appears to have a 14 day maximum disclosure) but nevertheless, > making contact and setting a timeline sooner rather than later would > be best.
We will be roughly providing a three-week disclosure period. If the list is set to 14 days, this would be longer. I believe that's good enough for distributions to sort things out to provide any feedback on problems they might have with it. Show quoted text
>
> > * Prepare and release maintenance versions > > > > Steve Hay is in charge of this. We should at least make sure to > > coordinate upstream and vendor releases.
> > Yes, I agree. >
> > Did I miss anything? Does anyone have any comments? > > > > Can we hear from our reporters, Debian representative, and at least > > another core developer approving the solution?
> > Salvatore (for the Debian security team), Niko and I (as Debian > perl maintainers) met yesterday and are generally happy with the plan > you > have proposed. We intend to coordinate updates for our supported > releases, and the end of July seems to be an appropriate timescale for > this. [...]
Thank you very much to all the assistance and help!
Subject: Re: [perl #127834] Flaws in Perl code due to unsafe module load path
To: Sawyer X via RT <perl5-security-report [...] perl.org>
From: Dominic Hargreaves <dom [...] earth.li>
Date: Wed, 13 Jul 2016 00:22:03 +0200
CC: carnil [...] debian.org, fw [...] deneb.enyo.de, lightsey [...] debian.org, toddr [...] cpan.org, ntyni [...] debian.org
Download (untitled) / with headers
text/plain 2.6k
On Tue, Jul 05, 2016 at 03:34:32PM -0700, Sawyer X via RT wrote: Show quoted text
> On Tue Jul 05 03:17:25 2016, dom wrote:
Show quoted text
> I'm sorry to say this has not happened yet. It will happen tomorrow morning CEST time.
Thanks - Salvatore confirmed that this happened with public disclosure on 25th July (note: it would be useful nearer the time to fix on rough UTC timeframe too). Show quoted text
> > Salvatore (for the Debian security team), Niko and I (as Debian > > perl maintainers) met yesterday and are generally happy with the plan > > you > > have proposed. We intend to coordinate updates for our supported > > releases, and the end of July seems to be an appropriate timescale for > > this. [...]
> > > Thank you very much to all the assistance and help!
I'll spare this thread the details of our internal preparation except in as much as i might help generally. We have test-rebuilt ~ 3,000 packages as follows: run 1: just . removed from @INC in sitecustomize.pl - 808 failures run 2: add patches to Extutils-Makemaker to set PERL_USE_UNSAFE_INC and update sitecustomize to honour it - 315 failures (interrupted before the end at 'libs[..]') run 3: add to debhelper and cdbs [debian development helpers] a call to perl -I. {Makefile,Build}.PL - 181 failures Most of the rest probably relate to "perl Makefile.PL" being hardcoded in debian/rules files, but a full analysis is TBC. It's possible that we might be able to reduce this down some more by some other tricks including exporting PERL_USE_UNSAFE_INC through the build system, but we're not sure yet. And of course this doesn't test the runtime behaviour of scripts, which is more difficult to test systematically; and in particular if . is being kept in the test suite environments, trouble is almost guaranteed. We're still on the fence about whether we can disable remove . from @INC by default in our security updates, so we're definitely working on the belt and braces fix, hence: Based on John's list of known vulnerable modules, we also identified a set of 7 extra packages in Debian to be updated at the same time. We had a specific query about base.pm. This was, I understand, deliberately left unfixed in Tony's patchset, however we have a known vulnerability (if "only" in a development tool, and not the worse case where chdir /tmp is involved) in a Debian specific package perl -MSbuild::Exception. This turns out to be via lib/Exception/Class.pm:use base qw($isa); Given this, should the decision to leave base.pm alone be reviewed? I'm not sure about the impact of changing it. (Alternatively, presumably Exception::Class could be patched, but that feels like patching around the problem). Thanks, Dominic.
Date: Fri, 15 Jul 2016 15:31:50 +0200
CC: Sawyer X via RT <perl5-security-report [...] perl.org>, Salvatore Bonaccorso <carnil [...] debian.org>, fw [...] deneb.enyo.de, John Lightsey <lightsey [...] debian.org>, Todd Rinaldo <toddr [...] cpan.org>, ntyni [...] debian.org
From: Sawyer X <xsawyerx [...] gmail.com>
To: Dominic Hargreaves <dom [...] earth.li>
Subject: Re: [perl #127834] Flaws in Perl code due to unsafe module load path
Download (untitled) / with headers
text/plain 2.6k
On Wed, Jul 13, 2016 at 12:22 AM, Dominic Hargreaves <dom@earth.li> wrote: Show quoted text
> On Tue, Jul 05, 2016 at 03:34:32PM -0700, Sawyer X via RT wrote:
>> On Tue Jul 05 03:17:25 2016, dom wrote:
>> > Salvatore (for the Debian security team), Niko and I (as Debian >> > perl maintainers) met yesterday and are generally happy with the plan >> > you >> > have proposed. We intend to coordinate updates for our supported >> > releases, and the end of July seems to be an appropriate timescale for >> > this. [...]
>> >> >> Thank you very much to all the assistance and help!
> > I'll spare this thread the details of our internal preparation except > in as much as i might help generally. We have test-rebuilt ~ 3,000 > packages as follows: > > run 1: just . removed from @INC in sitecustomize.pl > - 808 failures > run 2: add patches to Extutils-Makemaker to set PERL_USE_UNSAFE_INC and > update sitecustomize to honour it > - 315 failures (interrupted before the end at 'libs[..]') > run 3: add to debhelper and cdbs [debian development helpers] a call > to perl -I. {Makefile,Build}.PL > - 181 failures > > Most of the rest probably relate to "perl Makefile.PL" being hardcoded > in debian/rules files, but a full analysis is TBC.
Any chance you can provide some of the test failures output, so we could investigate? We're coming close on this and I would like us to review any failures in case there's a chance we can make to it. Show quoted text
> [...] > > We're still on the fence about whether we can disable remove . from @INC > by default in our security updates, so we're definitely working on the > belt and braces fix, hence: > > Based on John's list of known vulnerable modules, we also identified a > set of 7 extra packages in Debian to be updated at the same time.
Which? Show quoted text
> > We had a specific query about base.pm. This was, I understand, > deliberately left unfixed in Tony's patchset, however we have a known > vulnerability (if "only" in a development tool, and not the worse case > where chdir /tmp is involved) in a Debian specific package > perl -MSbuild::Exception. This turns out to be via > lib/Exception/Class.pm:use base qw($isa); > > Given this, should the decision to leave base.pm alone be reviewed? > I'm not sure about the impact of changing it. (Alternatively, > presumably Exception::Class could be patched, but that feels like > patching around the problem).
Tony's patch added the following note about base.pm: I didn't update base.pm since that seems more likely to be loading modules *expected* to be in the current directory. Opinions welcome. Does anyone have any opinion on this or experience with this behavior of base.pm?
From: Zefram <zefram [...] fysh.org>
Subject: Re: [perl #127834] Flaws in Perl code due to unsafe module load path
To: perl5-security-report [...] perl.org, Salvatore Bonaccorso <carnil [...] debian.org>, fw [...] deneb.enyo.de, John Lightsey <lightsey [...] debian.org>, ntyni [...] debian.org
Date: Fri, 15 Jul 2016 17:42:32 +0100
Download (untitled) / with headers
text/plain 1.5k
Sawyer X wrote: Show quoted text
>Tony's patch added the following note about base.pm: > > I didn't update base.pm since that seems more likely to be loading > modules *expected* to be in the current directory. Opinions > welcome.
base.pm is no more likely to be used to load a module in the current directory than is ordinary direct module loading. The programmer writing a "use base" invocation has exactly the same view of the module's expected location that ey would if writing a direct "use" invocation. The thing that's different about base.pm is that it's *optional* module loading, which makes it especially vulnerable to this security problem. It's intended to handle aspects of inheritance other than the module loading, and the programmer can intentionally use base.pm for those purposes to set up inheritance from a package that doesn't exist as a separate module but is defined by some module being loaded by other means. Generally the programmer knows whether an actual module load is needed, but this static knowledge doesn't get encoded into the "use base" invocation. In the Perlish way, this ignored static knowledge gets replaced by dynamic discovery of whether the module exists. The practical upshot is that in some programs base.pm goes looking for modules that should *never* be found, so will always get to "." in the search path. Those would be the module names of choice for an attacker looking to exploit the vulnerability. Something definitely needs to be done about uses of base.pm that are intended to not find a module. -zefram
From: Todd Rinaldo <toddr [...] cpanel.net>
To: perl5-security-report [...] perl.org
Subject: Re: [perl #127834] Flaws in Perl code due to unsafe module load path
CC: Salvatore Bonaccorso <carnil [...] debian.org>, fw [...] deneb.enyo.de, lightsey [...] debian.org, toddr [...] cpan.org, dom [...] earth.li, ntyni [...] debian.org
Date: Fri, 15 Jul 2016 13:54:42 -0500
Download (untitled) / with headers
text/plain 1.9k
Show quoted text
> On Jul 15, 2016, at 11:42 AM, Zefram via RT <perl5-security-report@perl.org> wrote: > > Sawyer X wrote:
>> Tony's patch added the following note about base.pm: >> >> I didn't update base.pm since that seems more likely to be loading >> modules *expected* to be in the current directory. Opinions >> welcome.
> > base.pm is no more likely to be used to load a module in the current > directory than is ordinary direct module loading. The programmer writing > a "use base" invocation has exactly the same view of the module's expected > location that ey would if writing a direct "use" invocation. > > The thing that's different about base.pm is that it's *optional* module > loading, which makes it especially vulnerable to this security problem. > It's intended to handle aspects of inheritance other than the module > loading, and the programmer can intentionally use base.pm for those > purposes to set up inheritance from a package that doesn't exist as > a separate module but is defined by some module being loaded by other > means. Generally the programmer knows whether an actual module load > is needed, but this static knowledge doesn't get encoded into the "use > base" invocation. In the Perlish way, this ignored static knowledge gets > replaced by dynamic discovery of whether the module exists. The practical > upshot is that in some programs base.pm goes looking for modules that > should *never* be found, so will always get to "." in the search path. > Those would be the module names of choice for an attacker looking to > exploit the vulnerability. > > Something definitely needs to be done about uses of base.pm that are > intended to not find a module. >
I'm for patching base.pm to not include . in @INC when it tries to runtime load a module. Everything we're doing has the risk of having rare side effects when some script is depending on this behavior. But all of it can be fixed when it is come across by the script writer explicitly manipulating @INC for their needs. Todd
To: Todd Rinaldo <toddr [...] cpanel.net>
Subject: Re: [perl #127834] Flaws in Perl code due to unsafe module load path
From: Sawyer X <xsawyerx [...] gmail.com>
CC: Tony Cook via RT <perl5-security-report [...] perl.org>, Salvatore Bonaccorso <carnil [...] debian.org>, fw [...] deneb.enyo.de, John Lightsey <lightsey [...] debian.org>, Todd Rinaldo <toddr [...] cpan.org>, Dominic Hargreaves <dom [...] earth.li>, ntyni [...] debian.org
Date: Sat, 16 Jul 2016 12:34:29 +0200
Download (untitled) / with headers
text/plain 2.2k
On Fri, Jul 15, 2016 at 8:54 PM, Todd Rinaldo <toddr@cpanel.net> wrote: Show quoted text
>
>> On Jul 15, 2016, at 11:42 AM, Zefram via RT <perl5-security-report@perl.org> wrote: >> >> Sawyer X wrote:
>>> Tony's patch added the following note about base.pm: >>> >>> I didn't update base.pm since that seems more likely to be loading >>> modules *expected* to be in the current directory. Opinions >>> welcome.
>> >> base.pm is no more likely to be used to load a module in the current >> directory than is ordinary direct module loading. The programmer writing >> a "use base" invocation has exactly the same view of the module's expected >> location that ey would if writing a direct "use" invocation. >> >> The thing that's different about base.pm is that it's *optional* module >> loading, which makes it especially vulnerable to this security problem. >> It's intended to handle aspects of inheritance other than the module >> loading, and the programmer can intentionally use base.pm for those >> purposes to set up inheritance from a package that doesn't exist as >> a separate module but is defined by some module being loaded by other >> means. Generally the programmer knows whether an actual module load >> is needed, but this static knowledge doesn't get encoded into the "use >> base" invocation. In the Perlish way, this ignored static knowledge gets >> replaced by dynamic discovery of whether the module exists. The practical >> upshot is that in some programs base.pm goes looking for modules that >> should *never* be found, so will always get to "." in the search path. >> Those would be the module names of choice for an attacker looking to >> exploit the vulnerability. >> >> Something definitely needs to be done about uses of base.pm that are >> intended to not find a module. >>
> > I'm for patching base.pm to not include . in @INC when it tries to runtime load a module. > > Everything we're doing has the risk of having rare side effects when some script is depending on this behavior. But all of it can be fixed when it is come across by the script writer explicitly manipulating @INC for their needs.
Does anyone have any suggestion on how to handle base.pm? Zefram, do you think treating it in the same way would work, or does it need further logic to handle that specific case of runtime loading a module?
To: Todd Rinaldo <toddr [...] cpanel.net>, Tony Cook via RT <perl5-security-report [...] perl.org>, Salvatore Bonaccorso <carnil [...] debian.org>, fw [...] deneb.enyo.de, John Lightsey <lightsey [...] debian.org>, Todd Rinaldo <toddr [...] cpan.org>, Dominic Hargreaves <dom [...] earth.li>, ntyni [...] debian.org
Subject: Re: [perl #127834] Flaws in Perl code due to unsafe module load path
From: Zefram <zefram [...] fysh.org>
Date: Sat, 16 Jul 2016 15:43:10 +0100
Download (untitled) / with headers
text/plain 573b
Sawyer X wrote: Show quoted text
>Does anyone have any suggestion on how to handle base.pm? Zefram, do >you think treating it in the same way would work,
It would be sensible to treat it the same as other cases of optional module loading, having it locally remove the final "." from @INC. However, because it's used for a relatively large number of module loadings, because the programmer of the invoking code doesn't think of them as optional, this is likely to throw up more problem cases (of modules intended to be loaded from ".") than other optional-module-loading modules. -zefram
Subject: Re: [perl #127834] Flaws in Perl code due to unsafe module load path
From: Steve Hay via perl5-security-report <perl5-security-report [...] perl.org>
Date: Sat, 16 Jul 2016 21:33:33 +0100
CC: Sawyer X via RT <perl5-security-report [...] perl.org>, carnil [...] debian.org, Florian Weimer <fw [...] deneb.enyo.de>, John Lightsey <lightsey [...] debian.org>, Todd Rinaldo <toddr [...] cpan.org>, Niko Tyni <ntyni [...] debian.org>
To: Dominic Hargreaves <dom [...] earth.li>
Download (untitled) / with headers
text/plain 1.1k
On 12 July 2016 at 23:22, Dominic Hargreaves <dom@earth.li> wrote: Show quoted text
> On Tue, Jul 05, 2016 at 03:34:32PM -0700, Sawyer X via RT wrote:
>> On Tue Jul 05 03:17:25 2016, dom wrote:
>
>> I'm sorry to say this has not happened yet. It will happen tomorrow morning CEST time.
> > Thanks - Salvatore confirmed that this happened with public disclosure > on 25th July (note: it would be useful nearer the time to fix on rough > UTC timeframe too). >
FYI: The current maint release plan is: 1. Sunday 17th: Release 5.22.3-RC1 and 5.24.1-RC1 with more or less what is currently in maint-5.22 and maint-5.24 respectively. 2. Monday 25th: Release 5.22.3-RCx and 5.24.2-RCx (where 'x' is hopefully 2, but could be higher if any problems were found in the RC1s that necessitated more RCs already) containing these security patches. 3. Soon after (I'm thinking maybe Saturday 30th): Release 5.22.3 and 5.24.1 The exact date of the final release can't be predicted for sure because it depends on what, if any, problems are found in the RCs released on 25th. Please do let me know what UTC time disclosure will occur on 25th so that I can upload and announce the RCs to roughly coincide with that.
To: Dominic Hargreaves <dom [...] earth.li>
CC: Sawyer X via RT <perl5-security-report [...] perl.org>, carnil [...] debian.org, Florian Weimer <fw [...] deneb.enyo.de>, John Lightsey <lightsey [...] debian.org>, Todd Rinaldo <toddr [...] cpan.org>, Niko Tyni <ntyni [...] debian.org>
Date: Sun, 17 Jul 2016 19:22:38 +0100
Subject: Re: [perl #127834] Flaws in Perl code due to unsafe module load path
From: Steve Hay via perl5-security-report <perl5-security-report [...] perl.org>
Download (untitled) / with headers
text/plain 1.8k
On 16 July 2016 at 21:33, Steve Hay <steve.m.hay@googlemail.com> wrote: Show quoted text
> On 12 July 2016 at 23:22, Dominic Hargreaves <dom@earth.li> wrote:
>> On Tue, Jul 05, 2016 at 03:34:32PM -0700, Sawyer X via RT wrote:
>>> On Tue Jul 05 03:17:25 2016, dom wrote:
>>
>>> I'm sorry to say this has not happened yet. It will happen tomorrow morning CEST time.
>> >> Thanks - Salvatore confirmed that this happened with public disclosure >> on 25th July (note: it would be useful nearer the time to fix on rough >> UTC timeframe too). >>
> > FYI: The current maint release plan is: > > 1. Sunday 17th: Release 5.22.3-RC1 and 5.24.1-RC1 with more or less > what is currently in maint-5.22 and maint-5.24 respectively. > > 2. Monday 25th: Release 5.22.3-RCx and 5.24.2-RCx (where 'x' is > hopefully 2, but could be higher if any problems were found in the > RC1s that necessitated more RCs already) containing these security > patches. > > 3. Soon after (I'm thinking maybe Saturday 30th): Release 5.22.3 and 5.24.1 > > The exact date of the final release can't be predicted for sure > because it depends on what, if any, problems are found in the RCs > released on 25th. > > Please do let me know what UTC time disclosure will occur on 25th so > that I can upload and announce the RCs to roughly coincide with that.
I'm just finalizing the RC1 releases, but a tester on #p5p has asked whether 08e3451d7b3b714ad63a27f1b9c2a23ee75d15ee should be included (in an RC2)? I'm generally avoiding pulling anything else into these releases but this one is somewhat related, being a fix for https://rt.perl.org/Ticket/Display.html?id=128528 (XSLoader may load relative paths). Does anyone here have any feelings either way whether it should be included? (If I do pull it in then I would also pull in the related 5993d6620f29d22b0a72701f4f0fdacff3d25460 and a651dcdf6a9151150dcf0fb6b18849d3e39b0811).
CC: Dominic Hargreaves <dom [...] earth.li>, Sawyer X via RT <perl5-security-report [...] perl.org>, Salvatore Bonaccorso <carnil [...] debian.org>, Florian Weimer <fw [...] deneb.enyo.de>, John Lightsey <lightsey [...] debian.org>, Todd Rinaldo <toddr [...] cpan.org>, Niko Tyni <ntyni [...] debian.org>
Date: Sun, 17 Jul 2016 20:41:57 +0200
To: Steve Hay <steve.m.hay [...] googlemail.com>
Subject: Re: [perl #127834] Flaws in Perl code due to unsafe module load path
From: Sawyer X <xsawyerx [...] gmail.com>
On Sun, Jul 17, 2016 at 8:22 PM, Steve Hay via perl5-security-report <perl5-security-report@perl.org> wrote: Show quoted text
> On 16 July 2016 at 21:33, Steve Hay <steve.m.hay@googlemail.com> wrote:
>> On 12 July 2016 at 23:22, Dominic Hargreaves <dom@earth.li> wrote:
>>> On Tue, Jul 05, 2016 at 03:34:32PM -0700, Sawyer X via RT wrote:
>>>> On Tue Jul 05 03:17:25 2016, dom wrote:
>>>
>>>> I'm sorry to say this has not happened yet. It will happen tomorrow morning CEST time.
>>> >>> Thanks - Salvatore confirmed that this happened with public disclosure >>> on 25th July (note: it would be useful nearer the time to fix on rough >>> UTC timeframe too). >>>
>> >> FYI: The current maint release plan is: >> >> 1. Sunday 17th: Release 5.22.3-RC1 and 5.24.1-RC1 with more or less >> what is currently in maint-5.22 and maint-5.24 respectively. >> >> 2. Monday 25th: Release 5.22.3-RCx and 5.24.2-RCx (where 'x' is >> hopefully 2, but could be higher if any problems were found in the >> RC1s that necessitated more RCs already) containing these security >> patches. >> >> 3. Soon after (I'm thinking maybe Saturday 30th): Release 5.22.3 and 5.24.1 >> >> The exact date of the final release can't be predicted for sure >> because it depends on what, if any, problems are found in the RCs >> released on 25th. >> >> Please do let me know what UTC time disclosure will occur on 25th so >> that I can upload and announce the RCs to roughly coincide with that.
> > I'm just finalizing the RC1 releases, but a tester on #p5p has asked > whether 08e3451d7b3b714ad63a27f1b9c2a23ee75d15ee should be included > (in an RC2)? I'm generally avoiding pulling anything else into these > releases but this one is somewhat related, being a fix for > https://rt.perl.org/Ticket/Display.html?id=128528 (XSLoader may load > relative paths). > > Does anyone here have any feelings either way whether it should be included? > > (If I do pull it in then I would also pull in the related > 5993d6620f29d22b0a72701f4f0fdacff3d25460 and > a651dcdf6a9151150dcf0fb6b18849d3e39b0811).
My gut feeling is yes, but I would love to hear from others.
From: Karl Williamson <public [...] khwilliamson.com>
To: Sawyer X <xsawyerx [...] gmail.com>, Steve Hay <steve.m.hay [...] googlemail.com>
Subject: Re: [perl #127834] Flaws in Perl code due to unsafe module load path
CC: Dominic Hargreaves <dom [...] earth.li>, Sawyer X via RT <perl5-security-report [...] perl.org>, Salvatore Bonaccorso <carnil [...] debian.org>, Florian Weimer <fw [...] deneb.enyo.de>, John Lightsey <lightsey [...] debian.org>, Todd Rinaldo <toddr [...] cpan.org>, Niko Tyni <ntyni [...] debian.org>
Date: Sun, 17 Jul 2016 21:55:34 -0600
Download (untitled) / with headers
text/plain 2.3k
On 07/17/2016 12:41 PM, Sawyer X wrote: Show quoted text
> On Sun, Jul 17, 2016 at 8:22 PM, Steve Hay via perl5-security-report > <perl5-security-report@perl.org> wrote:
>> On 16 July 2016 at 21:33, Steve Hay <steve.m.hay@googlemail.com> wrote:
>>> On 12 July 2016 at 23:22, Dominic Hargreaves <dom@earth.li> wrote:
>>>> On Tue, Jul 05, 2016 at 03:34:32PM -0700, Sawyer X via RT wrote:
>>>>> On Tue Jul 05 03:17:25 2016, dom wrote:
>>>>
>>>>> I'm sorry to say this has not happened yet. It will happen tomorrow morning CEST time.
>>>> >>>> Thanks - Salvatore confirmed that this happened with public disclosure >>>> on 25th July (note: it would be useful nearer the time to fix on rough >>>> UTC timeframe too). >>>>
>>> >>> FYI: The current maint release plan is: >>> >>> 1. Sunday 17th: Release 5.22.3-RC1 and 5.24.1-RC1 with more or less >>> what is currently in maint-5.22 and maint-5.24 respectively. >>> >>> 2. Monday 25th: Release 5.22.3-RCx and 5.24.2-RCx (where 'x' is >>> hopefully 2, but could be higher if any problems were found in the >>> RC1s that necessitated more RCs already) containing these security >>> patches. >>> >>> 3. Soon after (I'm thinking maybe Saturday 30th): Release 5.22.3 and 5.24.1 >>> >>> The exact date of the final release can't be predicted for sure >>> because it depends on what, if any, problems are found in the RCs >>> released on 25th. >>> >>> Please do let me know what UTC time disclosure will occur on 25th so >>> that I can upload and announce the RCs to roughly coincide with that.
>> >> I'm just finalizing the RC1 releases, but a tester on #p5p has asked >> whether 08e3451d7b3b714ad63a27f1b9c2a23ee75d15ee should be included >> (in an RC2)? I'm generally avoiding pulling anything else into these >> releases but this one is somewhat related, being a fix for >> https://rt.perl.org/Ticket/Display.html?id=128528 (XSLoader may load >> relative paths). >> >> Does anyone here have any feelings either way whether it should be included? >> >> (If I do pull it in then I would also pull in the related >> 5993d6620f29d22b0a72701f4f0fdacff3d25460 and >> a651dcdf6a9151150dcf0fb6b18849d3e39b0811).
> > My gut feeling is yes, but I would love to hear from others. >
My gut feeling is no, but don't listen to that. Instead to decide, you should carefully evaluate the risk entailed versus the gain, informed by the fact that 5.14.2 is coming fast on the heels of .1
CC: Todd Rinaldo <toddr [...] cpanel.net>, Tony Cook via RT <perl5-security-report [...] perl.org>, Salvatore Bonaccorso <carnil [...] debian.org>, fw [...] deneb.enyo.de, John Lightsey <lightsey [...] debian.org>, Todd Rinaldo <toddr [...] cpan.org>, Dominic Hargreaves <dom [...] earth.li>, ntyni [...] debian.org
Date: Mon, 18 Jul 2016 15:06:14 +1000
To: Sawyer X <xsawyerx [...] gmail.com>
Subject: Re: [perl #127834] Flaws in Perl code due to unsafe module load path
From: Tony Cook <tony [...] develop-help.com>
Download (untitled) / with headers
text/plain 1.7k
On Sat, Jul 16, 2016 at 12:34:29PM +0200, Sawyer X wrote: Show quoted text
> On Fri, Jul 15, 2016 at 8:54 PM, Todd Rinaldo <toddr@cpanel.net> wrote:
> >
> >> On Jul 15, 2016, at 11:42 AM, Zefram via RT <perl5-security-report@perl.org> wrote:
> > I'm for patching base.pm to not include . in @INC when it tries to runtime load a module. > > > > Everything we're doing has the risk of having rare side effects when some script is depending on this behavior. But all of it can be fixed when it is come across by the script writer explicitly manipulating @INC for their needs.
> > Does anyone have any suggestion on how to handle base.pm? Zefram, do > you think treating it in the same way would work, or does it need > further logic to handle that specific case of runtime loading a > module?
Zefram has covered the logic as to why base.pm is special - it's used for loading both optional and non-optional modules. The harder issue is how many end users have code defining base classes with base.pm that load the base class from the current directory, I don't know a way to find out without removing '.' from @INC. Other than leaving the possible hole open I can see two basic solutions: a) remove the . as suggested - this will break code and end-users will need to either set PERL5LIB or add <use lib '.'> to their code. b) make base.pm follow parent.pm and error if a class file cannot be found (unless -norequire is supplied), (this will probably break more code) A more complex solution: c) require that optional loads for base.pm from current directory be flagged as with -norequire for parent.pm (this may break less code) I can see any of the above breaking back-compatibility promises for maint. I'm not sure what promises Debian (or other distributors) make for back-compat within a release. Tony
CC: Sawyer X <xsawyerx [...] gmail.com>, Todd Rinaldo <toddr [...] cpanel.net>, Tony Cook via RT <perl5-security-report [...] perl.org>, Salvatore Bonaccorso <carnil [...] debian.org>, fw [...] deneb.enyo.de, John Lightsey <lightsey [...] debian.org>, Todd Rinaldo <toddr [...] cpan.org>, Dominic Hargreaves <dom [...] earth.li>, ntyni [...] debian.org
Date: Mon, 18 Jul 2016 06:36:50 +0100
Subject: Re: [perl #127834] Flaws in Perl code due to unsafe module load path
To: Tony Cook <tony [...] develop-help.com>
From: Zefram <zefram [...] fysh.org>
Download (untitled) / with headers
text/plain 2.4k
Tony Cook wrote: Show quoted text
>a) remove the . as suggested - this will break code and end-users will >need to either set PERL5LIB or add <use lib '.'> to their code.
I think we have to do this. We've already decided to do this for loads that are actually optional at runtime; this is just affecting a larger number of users. The impact isn't too bad: the breakage is fairly obvious (missing class), and the fix easy. Actually, "use lib '.'" is not the fix to promote here. That's the appropriate fix for an intentionally-optional load of a module that intentionally may come from ".". As I explained, uses of base.pm are almost never intended as optional loads: they're intended as either mandatory loads or non-loads. Most affected base.pm-using programs ought to be fixed by changing their base.pm usage to parent.pm. With or without "-norequire", according to whether the module load is intended. The base.pm documentation already describes it as "discouraged" in favour of parent.pm. The only exception is when using fields.pm. Show quoted text
>b) make base.pm follow parent.pm and error if a class file cannot be >found (unless -norequire is supplied), (this will probably break more >code)
This would break all uses of base.pm on classes defined other than by their own module. That's probably more users than are deliberately loading modules from ".". It's also a much bigger change in behaviour, not really compatible with the intent of base.pm as previously defined. We should not do this. Show quoted text
>c) require that optional loads for base.pm from current directory be >flagged as with -norequire for parent.pm (this may break less code)
We could usefully have both "-require" and "-norequire" flags for base.pm. The former would make the load mandatory, and permit loading from "." if it's in @INC. The latter would suppress the attempt at loading completely. The default in the absence of either flag would have to be the present optional loading, with the modification of not permitting loading from the implicit ".". We could then discourage the use of base.pm with neither flag. This would provide a clean fix for people using fields.pm. Show quoted text
>I can see any of the above breaking back-compatibility promises for >maint.
They do all break some backcompat, but we've already decided to break compatibility for optional module loads in respect of ".". (a), (c), and my proposed extension thereof break backcompat only in the way we've already decided upon. (b) would be a greater breakage, not necessary for the security issue. -zefram
CC: Sawyer X <xsawyerx [...] gmail.com>, Todd Rinaldo <toddr [...] cpanel.net>, Tony Cook via RT <perl5-security-report [...] perl.org>, Salvatore Bonaccorso <carnil [...] debian.org>, John Lightsey <lightsey [...] debian.org>, Todd Rinaldo <toddr [...] cpan.org>, Dominic Hargreaves <dom [...] earth.li>, ntyni [...] debian.org
Date: Mon, 18 Jul 2016 13:25:31 +0200
To: Tony Cook <tony [...] develop-help.com>
Subject: Re: [perl #127834] Flaws in Perl code due to unsafe module load path
From: Florian Weimer <fw [...] deneb.enyo.de>
Download (untitled) / with headers
text/plain 1.1k
* Tony Cook: Show quoted text
> Zefram has covered the logic as to why base.pm is special - it's used > for loading both optional and non-optional modules. > > The harder issue is how many end users have code defining base classes > with base.pm that load the base class from the current directory, I > don't know a way to find out without removing '.' from @INC. > > Other than leaving the possible hole open I can see two basic > solutions: > > a) remove the . as suggested - this will break code and end-users will > need to either set PERL5LIB or add <use lib '.'> to their code. > > b) make base.pm follow parent.pm and error if a class file cannot be > found (unless -norequire is supplied), (this will probably break more > code) > > A more complex solution: > > c) require that optional loads for base.pm from current directory be > flagged as with -norequire for parent.pm (this may break less code)
What about Load a file from the current directory only if the current directory is listed in @INC, or it is a subdirectory of a directory in @INC. ? Would this cover a significant portion of the failures you saw? It looks fairly safe to me. Thanks, Florian
To: Florian Weimer <fw [...] deneb.enyo.de>
Subject: Re: [perl #127834] Flaws in Perl code due to unsafe module load path
From: Zefram <zefram [...] fysh.org>
CC: Tony Cook <tony [...] develop-help.com>, Sawyer X <xsawyerx [...] gmail.com>, Todd Rinaldo <toddr [...] cpanel.net>, Tony Cook via RT <perl5-security-report [...] perl.org>, Salvatore Bonaccorso <carnil [...] debian.org>, John Lightsey <lightsey [...] debian.org>, Todd Rinaldo <toddr [...] cpan.org>, Dominic Hargreaves <dom [...] earth.li>, ntyni [...] debian.org
Date: Mon, 18 Jul 2016 12:39:04 +0100
Florian Weimer wrote: Show quoted text
>What about > > Load a file from the current directory only if the current directory > is listed in @INC, or it is a subdirectory of a directory in @INC.
Not a useful criterion; misses the point of the problem we have. The problem is specifically that the current directory is *always* listed in @INC by default, as "." as the last element. When we speak of whether we'll load a module from the current directory, we're really concerned with whether we'll honour that particular @INC entry. If the current directory is somehow listed in @INC as some other entry, then either that's a default library directory, which is OK, or it's been explicitly added to @INC, which is also OK. In either of those cases we'll honour that OK @INC entry in the normal way. Subdirectory relationships are not good to throw into the mix. Allowing loading from an unexpected directory is only slightly ameliorated by it being a subdirectory of an expected directory. It would provide modules under unexpected names. -zefram
From: Florian Weimer <fw [...] deneb.enyo.de>
Subject: Re: [perl #127834] Flaws in Perl code due to unsafe module load path
To: Zefram <zefram [...] fysh.org>
Date: Mon, 18 Jul 2016 13:47:42 +0200
CC: Tony Cook <tony [...] develop-help.com>, Sawyer X <xsawyerx [...] gmail.com>, Todd Rinaldo <toddr [...] cpanel.net>, Tony Cook via RT <perl5-security-report [...] perl.org>, Salvatore Bonaccorso <carnil [...] debian.org>, John Lightsey <lightsey [...] debian.org>, Todd Rinaldo <toddr [...] cpan.org>, Dominic Hargreaves <dom [...] earth.li>, ntyni [...] debian.org
Show quoted text
> Florian Weimer wrote:
>>What about >> >> Load a file from the current directory only if the current directory >> is listed in @INC, or it is a subdirectory of a directory in @INC.
> > Not a useful criterion; misses the point of the problem we have. > The problem is specifically that the current directory is *always* > listed in @INC by default, as "." as the last element. When we speak > of whether we'll load a module from the current directory, we're really > concerned with whether we'll honour that particular @INC entry. > > If the current directory is somehow listed in @INC as some other entry, > then either that's a default library directory, which is OK, or it's > been explicitly added to @INC, which is also OK. In either of those > cases we'll honour that OK @INC entry in the normal way.
Yes, you are right. I was under the impression that some of the failures are caused by A/B.pm (A::B) containing use base 'C'; and expecting to load A/C.pm (A::C). But that really isn't a relevant scenario.
From: Todd Rinaldo <toddr [...] cpanel.net>
To: Tony Cook <tony [...] develop-help.com>
Subject: Re: [perl #127834] Flaws in Perl code due to unsafe module load path
CC: Sawyer X <xsawyerx [...] gmail.com>, Tony Cook via RT <perl5-security-report [...] perl.org>, Salvatore Bonaccorso <carnil [...] debian.org>, fw [...] deneb.enyo.de, John Lightsey <lightsey [...] debian.org>, Todd Rinaldo <toddr [...] cpan.org>, Dominic Hargreaves <dom [...] earth.li>, ntyni [...] debian.org
Date: Mon, 18 Jul 2016 10:30:01 -0500
Download (untitled) / with headers
text/plain 1.6k
Show quoted text
> On Jul 18, 2016, at 12:06 AM, Tony Cook <tony@develop-help.com> wrote: > > On Sat, Jul 16, 2016 at 12:34:29PM +0200, Sawyer X wrote:
>> On Fri, Jul 15, 2016 at 8:54 PM, Todd Rinaldo <toddr@cpanel.net> wrote:
>>>
>>>> On Jul 15, 2016, at 11:42 AM, Zefram via RT <perl5-security-report@perl.org> wrote:
>>> I'm for patching base.pm to not include . in @INC when it tries to runtime load a module. >>> >>> Everything we're doing has the risk of having rare side effects when some script is depending on this behavior. But all of it can be fixed when it is come across by the script writer explicitly manipulating @INC for their needs.
>> >> Does anyone have any suggestion on how to handle base.pm? Zefram, do >> you think treating it in the same way would work, or does it need >> further logic to handle that specific case of runtime loading a >> module?
> > Zefram has covered the logic as to why base.pm is special - it's used > for loading both optional and non-optional modules. > > The harder issue is how many end users have code defining base classes > with base.pm that load the base class from the current directory, I > don't know a way to find out without removing '.' from @INC. > > Other than leaving the possible hole open I can see two basic > solutions: > > a) remove the . as suggested - this will break code and end-users will > need to either set PERL5LIB or add <use lib '.'> to their code.
I can anectdotally tell you we've been running without . in @INC now for 6+ months/ we use many CPAN modules. We have not had to patch a single module so base will work right. Honestly I struggle to come up with a scenario where I would want to end up counting on cwd to determine what modules base loads. Todd
Download signature.asc
application/pgp-signature 842b

Message body not shown because it is not plain text.

From: John Lightsey <lightsey [...] debian.org>
To: Todd Rinaldo <toddr [...] cpanel.net>, Tony Cook <tony [...] develop-help.com>
Subject: Re: [perl #127834] Flaws in Perl code due to unsafe module load path
CC: Sawyer X <xsawyerx [...] gmail.com>, Tony Cook via RT <perl5-security-report [...] perl.org>, Salvatore Bonaccorso <carnil [...] debian.org>, fw [...] deneb.enyo.de, Todd Rinaldo <toddr [...] cpan.org>, Dominic Hargreaves <dom [...] earth.li>, ntyni [...] debian.org
Date: Mon, 18 Jul 2016 10:53:13 -0500
Download (untitled) / with headers
text/plain 2.3k
On Mon, 2016-07-18 at 10:30 -0500, Todd Rinaldo wrote: Show quoted text
> > On Jul 18, 2016, at 12:06 AM, Tony Cook <tony@develop-help.com> wrote: > >  > > On Sat, Jul 16, 2016 at 12:34:29PM +0200, Sawyer X wrote:
> >> On Fri, Jul 15, 2016 at 8:54 PM, Todd Rinaldo <toddr@cpanel.net> wrote:
> >>> 
> >>>> On Jul 15, 2016, at 11:42 AM, Zefram via RT <perl5-security-report@perl.o
> rg> wrote:
> >>> I'm for patching base.pm to not include . in @INC when it tries to runtime
> load a module.
> >>>  > >>> Everything we're doing has the risk of having rare side effects when some
> script is depending on this behavior. But all of it can be fixed when it is > come across by the script writer explicitly manipulating @INC for their needs.
> >>  > >> Does anyone have any suggestion on how to handle base.pm? Zefram, do > >> you think treating it in the same way would work, or does it need > >> further logic to handle that specific case of runtime loading a > >> module?
> >  > > Zefram has covered the logic as to why base.pm is special - it's used > > for loading both optional and non-optional modules. > >  > > The harder issue is how many end users have code defining base classes > > with base.pm that load the base class from the current directory, I > > don't know a way to find out without removing '.' from @INC. > >  > > Other than leaving the possible hole open I can see two basic > > solutions: > >  > > a) remove the . as suggested - this will break code and end-users will > > need to either set PERL5LIB or add <use lib '.'> to their code.
> > I can anectdotally tell you we've been running without . in @INC now for 6+ > months/ we use many CPAN modules. We have not had to patch a single module so > base will work right. > > Honestly I struggle to come up with a scenario where I would want to end up > counting on cwd to determine what modules base loads. > 
This may not be true for module build systems though. Unit tests and module installers may end up doing a "use base" that gets loaded from the current directory. The USE_UNSAFE_INC patches are leaving the '.' in @INC in these scenarios to avoid this kind of problem. Personally, I'd prefer to see the '.' removed for base, but it does seem more likely to cause problems than most of the other modules that have been changed. They'll be trivial regressions to fix no doubt, but still regressions.
Download signature.asc
application/pgp-signature 819b

Message body not shown because it is not plain text.

Date: Mon, 18 Jul 2016 19:08:56 +0200
CC: Todd Rinaldo <toddr [...] cpanel.net>, Tony Cook <tony [...] develop-help.com>, Tony Cook via RT <perl5-security-report [...] perl.org>, Salvatore Bonaccorso <carnil [...] debian.org>, Florian Weimer <fw [...] deneb.enyo.de>, Todd Rinaldo <toddr [...] cpan.org>, Dominic Hargreaves <dom [...] earth.li>, Niko Tyni <ntyni [...] debian.org>
Subject: Re: [perl #127834] Flaws in Perl code due to unsafe module load path
To: John Lightsey <lightsey [...] debian.org>
From: Sawyer X <xsawyerx [...] gmail.com>
Download (untitled) / with headers
text/plain 2.6k
On Mon, Jul 18, 2016 at 5:53 PM, John Lightsey <lightsey@debian.org> wrote: Show quoted text
> > On Mon, 2016-07-18 at 10:30 -0500, Todd Rinaldo wrote:
> > > On Jul 18, 2016, at 12:06 AM, Tony Cook <tony@develop-help.com> wrote: > > > > > > On Sat, Jul 16, 2016 at 12:34:29PM +0200, Sawyer X wrote:
> > >> On Fri, Jul 15, 2016 at 8:54 PM, Todd Rinaldo <toddr@cpanel.net> wrote:
> > >>>
> > >>>> On Jul 15, 2016, at 11:42 AM, Zefram via RT <perl5-security-report@perl.o
> > rg> wrote:
> > >>> I'm for patching base.pm to not include . in @INC when it tries to runtime
> > load a module.
> > >>> > > >>> Everything we're doing has the risk of having rare side effects when some
> > script is depending on this behavior. But all of it can be fixed when it is > > come across by the script writer explicitly manipulating @INC for their needs.
> > >> > > >> Does anyone have any suggestion on how to handle base.pm? Zefram, do > > >> you think treating it in the same way would work, or does it need > > >> further logic to handle that specific case of runtime loading a > > >> module?
> > > > > > Zefram has covered the logic as to why base.pm is special - it's used > > > for loading both optional and non-optional modules. > > > > > > The harder issue is how many end users have code defining base classes > > > with base.pm that load the base class from the current directory, I > > > don't know a way to find out without removing '.' from @INC. > > > > > > Other than leaving the possible hole open I can see two basic > > > solutions: > > > > > > a) remove the . as suggested - this will break code and end-users will > > > need to either set PERL5LIB or add <use lib '.'> to their code.
> > > > I can anectdotally tell you we've been running without . in @INC now for 6+ > > months/ we use many CPAN modules. We have not had to patch a single module so > > base will work right. > > > > Honestly I struggle to come up with a scenario where I would want to end up > > counting on cwd to determine what modules base loads. > >
> > This may not be true for module build systems though. Unit tests and module > installers may end up doing a "use base" that gets loaded from the current > directory. The USE_UNSAFE_INC patches are leaving the '.' in @INC in these > scenarios to avoid this kind of problem. > > Personally, I'd prefer to see the '.' removed for base, but it does seem more > likely to cause problems than most of the other modules that have been changed. > They'll be trivial regressions to fix no doubt, but still regressions.
Perhaps if we involve a smoker and run some smoke tests on this possible change? We don't have that much time to make this change because the disclosure date is inching close.
Date: Mon, 18 Jul 2016 17:59:04 -0500
CC: Todd Rinaldo <toddr [...] cpanel.net>, Tony Cook <tony [...] develop-help.com>, Tony Cook via RT <perl5-security-report [...] perl.org>, Salvatore Bonaccorso <carnil [...] debian.org>, Florian Weimer <fw [...] deneb.enyo.de>, Todd Rinaldo <toddr [...] cpan.org>, Dominic Hargreaves <dom [...] earth.li>, Niko Tyni <ntyni [...] debian.org>
To: Sawyer X <xsawyerx [...] gmail.com>
Subject: Re: [perl #127834] Flaws in Perl code due to unsafe module load path
From: John Lightsey <lightsey [...] debian.org>
Download (untitled) / with headers
text/plain 3.1k
On Mon, 2016-07-18 at 19:08 +0200, Sawyer X wrote: Show quoted text
> On Mon, Jul 18, 2016 at 5:53 PM, John Lightsey <lightsey@debian.org> wrote:
> > > > On Mon, 2016-07-18 at 10:30 -0500, Todd Rinaldo wrote:
> > > > On Jul 18, 2016, at 12:06 AM, Tony Cook <tony@develop-help.com> wrote: > > > > > > > > On Sat, Jul 16, 2016 at 12:34:29PM +0200, Sawyer X wrote:
> > > >> On Fri, Jul 15, 2016 at 8:54 PM, Todd Rinaldo <toddr@cpanel.net> wrote:
> > > >>>
> > > >>>> On Jul 15, 2016, at 11:42 AM, Zefram via RT
> > > rg> wrote:
> > > >>> I'm for patching base.pm to not include . in @INC when it tries to runtime
> > > load a module.
> > > >>> > > > >>> Everything we're doing has the risk of having rare side effects when some
> > > script is depending on this behavior. But all of it can be fixed when it is > > > come across by the script writer explicitly manipulating @INC for their needs.
> > > >> > > > >> Does anyone have any suggestion on how to handle base.pm? Zefram, do > > > >> you think treating it in the same way would work, or does it need > > > >> further logic to handle that specific case of runtime loading a > > > >> module?
> > > > > > > > Zefram has covered the logic as to why base.pm is special - it's used > > > > for loading both optional and non-optional modules. > > > > > > > > The harder issue is how many end users have code defining base classes > > > > with base.pm that load the base class from the current directory, I > > > > don't know a way to find out without removing '.' from @INC. > > > > > > > > Other than leaving the possible hole open I can see two basic > > > > solutions: > > > > > > > > a) remove the . as suggested - this will break code and end-users will > > > > need to either set PERL5LIB or add to their code.
> > > > > > I can anectdotally tell you we've been running without . in @INC now for 6+ > > > months/ we use many CPAN modules. We have not had to patch a single module so > > > base will work right. > > > > > > Honestly I struggle to come up with a scenario where I would want to end up > > > counting on cwd to determine what modules base loads. > > >
> > > > This may not be true for module build systems though. Unit tests and module > > installers may end up doing a "use base" that gets loaded from the current > > directory. The USE_UNSAFE_INC patches are leaving the '.' in @INC in these > > scenarios to avoid this kind of problem. > > > > Personally, I'd prefer to see the '.' removed for base, but it does seem more > > likely to cause problems than most of the other modules that have been changed. > > They'll be trivial regressions to fix no doubt, but still regressions.
> > > Perhaps if we involve a smoker and run some smoke tests on this possible change? > > We don't have that much time to make this change because the > disclosure date is inching close.
Todd and I sat down and grepped around for the types of failures this would cause in build tools and unit tests. It's a rare problem from what we can tell, but are a handful of places where it breaks existing code. grep.cpan.me shows 21 modules on CPAN that will likely fail to build if the 'base' behavior changes: http://grep.cpan.me/?q=use%20base%20.%2A%5B%27%22%20%2F%5Dt%3A%3A
Download signature.asc
application/pgp-signature 819b

Message body not shown because it is not plain text.

To: John Lightsey <lightsey [...] debian.org>
Subject: Re: [perl #127834] Flaws in Perl code due to unsafe module load path
From: Tony Cook <tony [...] develop-help.com>
CC: Sawyer X <xsawyerx [...] gmail.com>, Todd Rinaldo <toddr [...] cpanel.net>, Tony Cook via RT <perl5-security-report [...] perl.org>, Salvatore Bonaccorso <carnil [...] debian.org>, Florian Weimer <fw [...] deneb.enyo.de>, Todd Rinaldo <toddr [...] cpan.org>, Dominic Hargreaves <dom [...] earth.li>, Niko Tyni <ntyni [...] debian.org>
Date: Tue, 19 Jul 2016 10:03:26 +1000
Download (untitled) / with headers
text/plain 691b
On Mon, Jul 18, 2016 at 05:59:04PM -0500, John Lightsey wrote: Show quoted text
> Todd and I sat down and grepped around for the types of failures this would > cause in build tools and unit tests. It's a rare problem from what we can tell, > but are a handful of places where it breaks existing code. > > grep.cpan.me shows 21 modules on CPAN that will likely fail to build if the > 'base' behavior changes: > > http://grep.cpan.me/?q=use%20base%20.%2A%5B%27%22%20%2F%5Dt%3A%3A
My issue isn't so much with it breaking CPAN modules (though it looks like it might break some), but with it breaking end user applications. I'm updating the patch sets to remove . from @INC when base.pm loads modules. Tony
RT-Send-CC: rt-deliver-to-perl5-security-report [...] rt.perl.org
Download (untitled) / with headers
text/plain 222b
On Mon Jul 18 17:05:21 2016, tonyc wrote: Show quoted text
> I'm updating the patch sets to remove . from @INC when base.pm loads > modules.
Attached. The 5.24 set also includes a possible perldelta note for your debating pleasure. Tony
Subject: maint-5.22-dot-in-inc.patch

Message body is not shown because it is too large.

Subject: maint-5.24-dot-in-inc.patch

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 442b
On Mon Jul 18 18:39:05 2016, tonyc wrote: Show quoted text
> On Mon Jul 18 17:05:21 2016, tonyc wrote:
> > I'm updating the patch sets to remove . from @INC when base.pm loads > > modules.
> > Attached. > > The 5.24 set also includes a possible perldelta note for your debating > pleasure. > > Tony
Thank you for preparing this, Tony! Is there an agreement on this being a suitable solution? I'd like to send it as an update to the various distributors.
Date: Tue, 19 Jul 2016 15:34:18 +0100
From: Dominic Hargreaves <dom [...] earth.li>
CC: Sawyer X via RT <perl5-security-report [...] perl.org>, Salvatore Bonaccorso <carnil [...] debian.org>, fw [...] deneb.enyo.de, John Lightsey <lightsey [...] debian.org>, Todd Rinaldo <toddr [...] cpan.org>, ntyni [...] debian.org
Subject: Re: [perl #127834] Flaws in Perl code due to unsafe module load path
To: Sawyer X <xsawyerx [...] gmail.com>
Download (untitled) / with headers
text/plain 3.5k
On Fri, Jul 15, 2016 at 03:31:50PM +0200, Sawyer X wrote: Show quoted text
> On Wed, Jul 13, 2016 at 12:22 AM, Dominic Hargreaves <dom@earth.li> wrote:
> > On Tue, Jul 05, 2016 at 03:34:32PM -0700, Sawyer X via RT wrote:
> >> On Tue Jul 05 03:17:25 2016, dom wrote:
> >> > Salvatore (for the Debian security team), Niko and I (as Debian > >> > perl maintainers) met yesterday and are generally happy with the plan > >> > you > >> > have proposed. We intend to coordinate updates for our supported > >> > releases, and the end of July seems to be an appropriate timescale for > >> > this. [...]
> >> > >> > >> Thank you very much to all the assistance and help!
> > > > I'll spare this thread the details of our internal preparation except > > in as much as i might help generally. We have test-rebuilt ~ 3,000 > > packages as follows: > > > > run 1: just . removed from @INC in sitecustomize.pl > > - 808 failures > > run 2: add patches to Extutils-Makemaker to set PERL_USE_UNSAFE_INC and > > update sitecustomize to honour it > > - 315 failures (interrupted before the end at 'libs[..]') > > run 3: add to debhelper and cdbs [debian development helpers] a call > > to perl -I. {Makefile,Build}.PL > > - 181 failures > > > > Most of the rest probably relate to "perl Makefile.PL" being hardcoded > > in debian/rules files, but a full analysis is TBC.
> > Any chance you can provide some of the test failures output, so we > could investigate? We're coming close on this and I would like us to > review any failures in case there's a chance we can make to it.
Sorry for the delay. The logs are here, although I suspect there is a not a lot of insights applicable to upstream. https://people.debian.org/~dom/tmp/perlsec/aey0Oow5/logs/ Show quoted text
> > [...] > > > > We're still on the fence about whether we can disable remove . from @INC > > by default in our security updates, so we're definitely working on the > > belt and braces fix, hence: > > > > Based on John's list of known vulnerable modules, we also identified a > > set of 7 extra packages in Debian to be updated at the same time.
> > Which?
libsys-syslog-perl Sys::Syslog::Win32 (see core version, dual-life in jessie) mime-charset-perl MIME/Charset/Defaults.pm lib/MIME/Charset.pm:eval { require MIME::Charset::Defaults; }; libunicode-linebreak-perl Unicode/LineBreak/Defaults.pm lib/Unicode/LineBreak.pm:eval { require Unicode::LineBreak::Defaults; }; libintl-perl Locale/gettext_xs.pm lib/Locale/Messages.pm: eval "require Locale::gettext_xs"; libmime-encwords-perl MIME/EncWords/Defaults.pm lib/MIME/EncWords.pm:eval { require MIME::EncWords::Defaults; }; Net/LocalCfg.pm (patched in core, not dual-life) devscripts File/DesktopEntry.pm scripts/desktop2menu.pl: eval { require File::DesktopEntry; }; libnet-dns-perl Net/DNS/Resolver/linux.pm Net/LibIDN.pm lib/Net/DNS/Domain.pm:use constant LIBIDN => UTF8 && defined eval 'require Net::LibIDN'; lib/Net/DNS/Resolver.pm:use constant CONFIG => defined eval "require Net::DNS::Resolver::$^O"; lots of other require() calls for optional modules libexception-class-perl lib/Exception/Class.pm:use base qw($isa); what to do about base.pm ? libdbix-class-perl RPC/PlServer.pm dbiproxy.PL: require RPC::PlServer::Test; dbiproxy.PL: require DBD::mysql; exim4 GD/Graph/pie.pm GD/Graph/linespoints.pm eval { require GD::Graph::pie; }; eval { require GD::Graph::linespoints; }; eval { require Spreadsheet::WriteExcel; }; dh-make-perl Mo/builder.pm Mo/default.pm ?? maybe libyaml-perl / YAML::Mo? can't reproduce Not sure how I got 7 there as there are clearly a few more. Cheers, Dominic.
To: Steve Hay via RT <perl5-security-report [...] perl.org>
From: Dominic Hargreaves <dom [...] earth.li>
Subject: Re: [perl #127834] Flaws in Perl code due to unsafe module load path
CC: carnil [...] debian.org, fw [...] deneb.enyo.de, lightsey [...] debian.org, toddr [...] cpan.org, ntyni [...] debian.org
Date: Tue, 19 Jul 2016 15:36:15 +0100
Download (untitled) / with headers
text/plain 2.1k
On Sun, Jul 17, 2016 at 11:23:03AM -0700, Steve Hay via RT wrote: Show quoted text
> On 16 July 2016 at 21:33, Steve Hay <steve.m.hay@googlemail.com> wrote:
> > On 12 July 2016 at 23:22, Dominic Hargreaves <dom@earth.li> wrote:
> >> On Tue, Jul 05, 2016 at 03:34:32PM -0700, Sawyer X via RT wrote:
> >>> On Tue Jul 05 03:17:25 2016, dom wrote:
> >>
> >>> I'm sorry to say this has not happened yet. It will happen tomorrow morning CEST time.
> >> > >> Thanks - Salvatore confirmed that this happened with public disclosure > >> on 25th July (note: it would be useful nearer the time to fix on rough > >> UTC timeframe too). > >>
> > > > FYI: The current maint release plan is: > > > > 1. Sunday 17th: Release 5.22.3-RC1 and 5.24.1-RC1 with more or less > > what is currently in maint-5.22 and maint-5.24 respectively. > > > > 2. Monday 25th: Release 5.22.3-RCx and 5.24.2-RCx (where 'x' is > > hopefully 2, but could be higher if any problems were found in the > > RC1s that necessitated more RCs already) containing these security > > patches. > > > > 3. Soon after (I'm thinking maybe Saturday 30th): Release 5.22.3 and 5.24.1 > > > > The exact date of the final release can't be predicted for sure > > because it depends on what, if any, problems are found in the RCs > > released on 25th. > > > > Please do let me know what UTC time disclosure will occur on 25th so > > that I can upload and announce the RCs to roughly coincide with that.
> > I'm just finalizing the RC1 releases, but a tester on #p5p has asked > whether 08e3451d7b3b714ad63a27f1b9c2a23ee75d15ee should be included > (in an RC2)? I'm generally avoiding pulling anything else into these > releases but this one is somewhat related, being a fix for > https://rt.perl.org/Ticket/Display.html?id=128528 (XSLoader may load > relative paths). > > Does anyone here have any feelings either way whether it should be included? > > (If I do pull it in then I would also pull in the related > 5993d6620f29d22b0a72701f4f0fdacff3d25460 and > a651dcdf6a9151150dcf0fb6b18849d3e39b0811).
FWIW, we included that in Debian unstable already, and will include it in our security release on the unembargo date. Dominic.
To: Tony Cook via RT <perl5-security-report [...] perl.org>
CC: carnil [...] debian.org, fw [...] deneb.enyo.de, lightsey [...] debian.org, toddr [...] cpan.org, ntyni [...] debian.org
Subject: Re: [perl #127834] Flaws in Perl code due to unsafe module load path
From: Dominic Hargreaves <dom [...] earth.li>
Date: Tue, 19 Jul 2016 15:37:59 +0100
On Sun, Jul 17, 2016 at 10:09:03PM -0700, Tony Cook via RT wrote: Show quoted text
> On Sat, Jul 16, 2016 at 12:34:29PM +0200, Sawyer X wrote:
> > On Fri, Jul 15, 2016 at 8:54 PM, Todd Rinaldo <toddr@cpanel.net> wrote:
> > >
> > >> On Jul 15, 2016, at 11:42 AM, Zefram via RT <perl5-security-report@perl.org> wrote:
> > > I'm for patching base.pm to not include . in @INC when it tries to runtime load a module. > > > > > > Everything we're doing has the risk of having rare side effects when some script is depending on this behavior. But all of it can be fixed when it is come across by the script writer explicitly manipulating @INC for their needs.
> > > > Does anyone have any suggestion on how to handle base.pm? Zefram, do > > you think treating it in the same way would work, or does it need > > further logic to handle that specific case of runtime loading a > > module?
> > Zefram has covered the logic as to why base.pm is special - it's used > for loading both optional and non-optional modules. > > The harder issue is how many end users have code defining base classes > with base.pm that load the base class from the current directory, I > don't know a way to find out without removing '.' from @INC. > > Other than leaving the possible hole open I can see two basic > solutions: > > a) remove the . as suggested - this will break code and end-users will > need to either set PERL5LIB or add <use lib '.'> to their code. > > b) make base.pm follow parent.pm and error if a class file cannot be > found (unless -norequire is supplied), (this will probably break more > code) > > A more complex solution: > > c) require that optional loads for base.pm from current directory be > flagged as with -norequire for parent.pm (this may break less code) > > I can see any of the above breaking back-compatibility promises for > maint. > > I'm not sure what promises Debian (or other distributors) make for > back-compat within a release.
Debian's promises are roughly equivalent to p5p's, and I'm happy with the subsequent decision (a) here, on the basis that the breakage is justified for safety. Dominic.
Date: Tue, 19 Jul 2016 15:47:20 +0100
To: Sawyer X <xsawyerx [...] gmail.com>
From: Dominic Hargreaves <dom [...] earth.li>
Subject: Re: [perl #127834] Flaws in Perl code due to unsafe module load path
CC: Sawyer X via RT <perl5-security-report [...] perl.org>, Salvatore Bonaccorso <carnil [...] debian.org>, fw [...] deneb.enyo.de, John Lightsey <lightsey [...] debian.org>, Todd Rinaldo <toddr [...] cpan.org>, ntyni [...] debian.org
Download (untitled) / with headers
text/plain 1.8k
On Tue, Jul 19, 2016 at 03:34:18PM +0100, Dominic Hargreaves wrote: Show quoted text
> On Fri, Jul 15, 2016 at 03:31:50PM +0200, Sawyer X wrote:
> > On Wed, Jul 13, 2016 at 12:22 AM, Dominic Hargreaves <dom@earth.li> wrote:
Show quoted text
> > > I'll spare this thread the details of our internal preparation except > > > in as much as i might help generally. We have test-rebuilt ~ 3,000 > > > packages as follows: > > > > > > run 1: just . removed from @INC in sitecustomize.pl > > > - 808 failures > > > run 2: add patches to Extutils-Makemaker to set PERL_USE_UNSAFE_INC and > > > update sitecustomize to honour it > > > - 315 failures (interrupted before the end at 'libs[..]') > > > run 3: add to debhelper and cdbs [debian development helpers] a call > > > to perl -I. {Makefile,Build}.PL > > > - 181 failures > > > > > > Most of the rest probably relate to "perl Makefile.PL" being hardcoded > > > in debian/rules files, but a full analysis is TBC.
> > > > Any chance you can provide some of the test failures output, so we > > could investigate? We're coming close on this and I would like us to > > review any failures in case there's a chance we can make to it.
> > Sorry for the delay. The logs are here, although I suspect there is > a not a lot of insights applicable to upstream. > > https://people.debian.org/~dom/tmp/perlsec/aey0Oow5/logs/
Sorry, I should have expanded this a little. I expect that most of the failures are either "expected" because Makefile.PL or similar have not been invoked with -I. (because sometimes the invocation is hard-coded in debian/rules). Because of tedious technicalities the build environment only has IPv6 connectivity and that too seems to have caused some spurious breakge (eg in perl itself). I am going to work through the failures now and see if I can draw any meaningful conclusions about Debian's plans. Dominic.
To: Sawyer X <xsawyerx [...] gmail.com>
From: Dominic Hargreaves <dom [...] earth.li>
CC: Sawyer X via RT <perl5-security-report [...] perl.org>, Salvatore Bonaccorso <carnil [...] debian.org>, fw [...] deneb.enyo.de, John Lightsey <lightsey [...] debian.org>, Todd Rinaldo <toddr [...] cpan.org>, ntyni [...] debian.org
Subject: Re: [perl #127834] Flaws in Perl code due to unsafe module load path
Date: Tue, 19 Jul 2016 16:23:19 +0100
Download (untitled) / with headers
text/plain 2.1k
On Tue, Jul 19, 2016 at 03:34:18PM +0100, Dominic Hargreaves wrote: Show quoted text
> On Fri, Jul 15, 2016 at 03:31:50PM +0200, Sawyer X wrote:
> > On Wed, Jul 13, 2016 at 12:22 AM, Dominic Hargreaves <dom@earth.li> wrote:
Show quoted text
> > > Based on John's list of known vulnerable modules, we also identified a > > > set of 7 extra packages in Debian to be updated at the same time.
> > > > Which?
> > libsys-syslog-perl Sys::Syslog::Win32 (see core version, dual-life in jessie) > > mime-charset-perl MIME/Charset/Defaults.pm > lib/MIME/Charset.pm:eval { require MIME::Charset::Defaults; }; > > libunicode-linebreak-perl Unicode/LineBreak/Defaults.pm > lib/Unicode/LineBreak.pm:eval { require Unicode::LineBreak::Defaults; }; > > libintl-perl Locale/gettext_xs.pm > lib/Locale/Messages.pm: eval "require Locale::gettext_xs"; > > libmime-encwords-perl MIME/EncWords/Defaults.pm > lib/MIME/EncWords.pm:eval { require MIME::EncWords::Defaults; }; > > Net/LocalCfg.pm (patched in core, not dual-life) > > devscripts File/DesktopEntry.pm > scripts/desktop2menu.pl: eval { require File::DesktopEntry; }; > > libnet-dns-perl Net/DNS/Resolver/linux.pm Net/LibIDN.pm > lib/Net/DNS/Domain.pm:use constant LIBIDN => UTF8 && defined eval 'require Net::LibIDN'; > lib/Net/DNS/Resolver.pm:use constant CONFIG => defined eval "require Net::DNS::Resolver::$^O"; > lots of other require() calls for optional modules > > libexception-class-perl > lib/Exception/Class.pm:use base qw($isa); > what to do about base.pm ? > > libdbix-class-perl RPC/PlServer.pm > dbiproxy.PL: require RPC::PlServer::Test; > dbiproxy.PL: require DBD::mysql; > > exim4 GD/Graph/pie.pm GD/Graph/linespoints.pm > eval { require GD::Graph::pie; }; > eval { require GD::Graph::linespoints; }; > eval { require Spreadsheet::WriteExcel; }; > > dh-make-perl Mo/builder.pm Mo/default.pm ?? > maybe libyaml-perl / YAML::Mo? can't reproduce
I meant to add - at least for the CPAN modules above, can the perl security team help by preparing patches for these modules (I guess the full set of vulnerable modules on CPAN is rather larger - I'm not sure I know what the current plan is for communicating these issues with out of tree module authors)? Thanks, Dominic.
Date: Tue, 19 Jul 2016 14:51:07 -0500
From: Todd Rinaldo <toddr [...] cpanel.net>
Subject: Re: [perl #127834] Flaws in Perl code due to unsafe module load path
CC: carnil [...] debian.org, fw [...] deneb.enyo.de, lightsey [...] debian.org, toddr [...] cpan.org, dom [...] earth.li, ntyni [...] debian.org
To: Tony Cook via RT <perl5-security-report [...] perl.org>
Download (untitled) / with headers
text/plain 855b
Show quoted text
> On Jul 18, 2016, at 8:39 PM, Tony Cook via RT <perl5-security-report@perl.org> wrote: > > On Mon Jul 18 17:05:21 2016, tonyc wrote:
>> I'm updating the patch sets to remove . from @INC when base.pm loads >> modules.
> > Attached. > > The 5.24 set also includes a possible perldelta note for your debating pleasure. >
The patches were a little confusing to apply since it's hard to tell which are the 5.22 patches and which are the 5.24 patches. I think I have applied them correctly. Tony: Please confirm there are currently 10 commits in your previous email against 5.24? Not necessarily addressed to Tony: It appears we are altering between 28 dual life modules. What are the plans for a coordinated release of these to CPAN? I expect some are somewhat lagging on CPAN right now so in some cases they may not be trivial to publish. Todd
To: perl5-security-report [...] perl.org, carnil [...] debian.org, fw [...] deneb.enyo.de, toddr [...] cpan.org
From: John Lightsey <lightsey [...] debian.org>
CC: dom [...] earth.li, ntyni [...] debian.org
Subject: Re: [perl #127834] Flaws in Perl code due to unsafe module load path
Date: Tue, 19 Jul 2016 18:46:36 -0500
Download (untitled) / with headers
text/plain 1.4k
On Tue, 2016-07-19 at 02:52 -0700, Sawyer X via RT wrote: Show quoted text
> On Mon Jul 18 18:39:05 2016, tonyc wrote:
> > On Mon Jul 18 17:05:21 2016, tonyc wrote:
> > > I'm updating the patch sets to remove . from @INC when base.pm loads > > > modules.
> >  > > Attached. > >  > > The 5.24 set also includes a possible perldelta note for your debating > > pleasure. > >  > > Tony
> > Thank you for preparing this, Tony! > > Is there an agreement on this being a suitable solution? > > I'd like to send it as an update to the various distributors.
IMHO, these patches do everything that it's reasonably possible to do in the core Perl code to mitigate the problem until 5.26. For comparison, my last test run with the 5.22 patches was: Total Perl scripts in /usr/bin and /usr/sbin: 423 Vulnerable before patch: 170  (40.2%) Vulnerable after patch:  16    (3.8%) Now I'm getting: Vulnerable after patch:  11    (2.6%) The remaining module loads that show up are all happening through scripts and modules outside of core Perl: Net::DNS           -> Net::LibIDN Net::DNS::Resolver -> Net::DNS::Resolver::linux YAML::Mo           -> Mo::builder and Mo::default Locale::Messages   -> Locale::gettext_xs MIME::Charset      -> MIME::Charset::Defaults MIME::EncWords     -> MIME::EncWords::Defaults Unicode::LineBreak -> Unicode::LineBreak::Defaults eximstats          -> GD::Graph::pie and GD::Graph::linespoints dbiproxy           -> RPC::PlServer
Download signature.asc
application/pgp-signature 819b

Message body not shown because it is not plain text.

RT-Send-CC: rt-deliver-to-perl5-security-report [...] rt.perl.org
Download (untitled) / with headers
text/plain 2.6k
On Tue Jul 19 12:51:35 2016, toddr@cpanel.net wrote: Show quoted text
>
> > On Jul 18, 2016, at 8:39 PM, Tony Cook via RT <perl5-security- > > report@perl.org> wrote: > > > > On Mon Jul 18 17:05:21 2016, tonyc wrote:
> >> I'm updating the patch sets to remove . from @INC when base.pm loads > >> modules.
> > > > Attached. > > > > The 5.24 set also includes a possible perldelta note for your > > debating pleasure. > >
> > The patches were a little confusing to apply since it's hard to tell > which are the 5.22 patches and which are the 5.24 patches. I think I > have applied them correctly.
They have the branch names in the filenames. Show quoted text
> > Tony: Please confirm there are currently 10 commits in your previous > email against 5.24?
$ git status On branch 127834-sec-utils nothing to commit, working directory clean $ git log --oneline origin/maint-5.24..HEAD | wc -l 10 Yes, 10. $ git checkout 127834-dot-in-inc-5.22 Switched to branch '127834-dot-in-inc-5.22' Your branch is ahead of 'origin/maint-5.22' by 9 commits. (use "git push" to publish your local commits) You have new mail in /var/mail/tony $ git log --oneline origin/maint-5.22..HEAD | wc -l 9 And 9 for the other. Much of the 5.24 patch will also need to be ported forward to blead, but blead moves fast, so I've put it off. It will also depend on exactly what changes we make to blead for 5.26, eg. core tools won't need to be updated if we remove . entirely. Tony 5.24 changes: 55c5333 (perl #127834) perldelta for . in @INC changes 763ec09 (perl #127834) update CUSTOMIZED entries b05161f cpan/: bump $VERSION as needed 866c31d cpan/: remove . from @INC when loading optional modules d34125e dist/: bump $VERSION as needed 948c049 dist/: remove . from @INC when loading optional modules ae683ee perl5db.pl: bump perldb $VERSION 408d39e perl5db.pl: ensure PadWalker is loaded from standard paths 3ae4d17 (perl #127834) bump versions of modules in dists we updated a utility in 53556b0 (perl #127834) remove . from the end of @INC if complex modules are loaded 5.22 changes: 69be295 (perl #127834) update CUSTOMIZED entries c297c60 cpan/: bump $VERSION as needed 5f1ed7b cpan/: remove . from @INC when loading optional modules 59313a7 dist/: bump $VERSION as needed 5c56b9e dist/: remove . from @INC when loading optional modules 9758ea4 perl5db.pl: bump perldb $VERSION ddca27a perl5db.pl: ensure PadWalker is loaded from standard paths 483eb0e (perl #127834) bump versions of modules in dists we updated a utility in 6caeb66 (perl #127834) remove . from the end of @INC if complex modules are loaded They were rebase on maint-5.24 at 7682ed29a1a27848f952c4d878fd57f25b603d57 and maint-5.22 at 89b0fe36d9428d64eb6c6cf73223d8e122e1ec01.
To: perl5-security-report [...] perl.org, carnil [...] debian.org, fw [...] deneb.enyo.de, toddr [...] cpan.org
Subject: Re: [perl #127834] Flaws in Perl code due to unsafe module load path
CC: dom [...] earth.li, ntyni [...] debian.org
From: John Lightsey <lightsey [...] debian.org>
Date: Tue, 19 Jul 2016 22:54:12 -0500
Download (untitled) / with headers
text/plain 569b
On Mon, 2016-07-18 at 18:39 -0700, Tony Cook via RT wrote: Show quoted text
> On Mon Jul 18 17:05:21 2016, tonyc wrote:
> > I'm updating the patch sets to remove . from @INC when base.pm loads > > modules.
> > Attached. > > The 5.24 set also includes a possible perldelta note for your debating > pleasure. >
I noticed while trying to backport the 5.22 patch to 5.14 that the way the utils/xxx.PL scripts have been updated is inconsistent. Some of the changes are adding filtering to the script created by the PL and some of the changes are filtering @INC in the PL script instead.
Download signature.asc
application/pgp-signature 819b

Message body not shown because it is not plain text.

Date: Wed, 20 Jul 2016 16:28:13 -0500
CC: dom [...] earth.li, ntyni [...] debian.org
Subject: Re: [perl #127834] Flaws in Perl code due to unsafe module load path
From: John Lightsey <lightsey [...] debian.org>
To: perl5-security-report [...] perl.org, carnil [...] debian.org, fw [...] deneb.enyo.de, toddr [...] cpan.org
Download (untitled) / with headers
text/plain 793b
On Tue, 2016-07-19 at 22:54 -0500, John Lightsey wrote: Show quoted text
> On Mon, 2016-07-18 at 18:39 -0700, Tony Cook via RT wrote:
Show quoted text
> > The 5.24 set also includes a possible perldelta note for your debating > > pleasure. > > 
> > I noticed while trying to backport the 5.22 patch to 5.14 that the way the > utils/xxx.PL scripts have been updated is inconsistent. Some of the changes > are adding filtering to the script created by the PL and some of the changes > are filtering @INC in the PL script instead.
This problem seems to be limited to utils/h2ph.PL and utils/h2xs.PL in the 5.22 and 5.24 versions of the patch. As I was backporting the remainder of the changes I also noticed that the cpan/File-Fetch/lib/File/Fetch.pm changes are only filtering one of the five can_load() calls in this file.
Download signature.asc
application/pgp-signature 819b

Message body not shown because it is not plain text.

RT-Send-CC: rt-deliver-to-perl5-security-report [...] rt.perl.org
Download (untitled) / with headers
text/plain 1.2k
On Wed Jul 20 14:28:47 2016, lightsey@debian.org wrote: Show quoted text
> On Tue, 2016-07-19 at 22:54 -0500, John Lightsey wrote:
> > I noticed while trying to backport the 5.22 patch to 5.14 that the > > way the > > utils/xxx.PL scripts have been updated is inconsistent. Some of the > > changes > > are adding filtering to the script created by the PL and some of the > > changes > > are filtering @INC in the PL script instead.
> > This problem seems to be limited to utils/h2ph.PL and utils/h2xs.PL in > the 5.22 > and 5.24 versions of the patch.
Thanks, fixed in the attached updates. Show quoted text
> As I was backporting the remainder of the changes I also noticed that > the > cpan/File-Fetch/lib/File/Fetch.pm changes are only filtering one of > the five > can_load() calls in this file.
When I originally wrote the patches I skipped adding the "local ... pop if ..." code when the optional module was included in core. In the File::Fetch case mistakenly didn't update the load attempt for HTTP::Lite. The attached patch adds the filtering for all can_load()s in File::Fetch, but there are other cases where modules are doing optional module loads of modules which are included in core, should those also be updated? eg. Archive::Tar::Constant Tony
RT-Send-CC: rt-deliver-to-perl5-security-report [...] rt.perl.org
Download (untitled) / with headers
text/plain 131b
On Wed Jul 20 18:54:09 2016, tonyc wrote: Show quoted text
> Thanks, fixed in the attached updates.
... Show quoted text
> The attached patch ...
Attachments. Tony
Subject: maint-5.22-dot-in-inc.patch

Message body is not shown because it is too large.

Subject: maint-5.24-dot-in-inc.patch

Message body is not shown because it is too large.

To: perl5-security-report [...] perl.org, carnil [...] debian.org, fw [...] deneb.enyo.de, toddr [...] cpan.org
CC: dom [...] earth.li, ntyni [...] debian.org
Subject: Re: [perl #127834] Flaws in Perl code due to unsafe module load path
From: John Lightsey <lightsey [...] debian.org>
Date: Thu, 21 Jul 2016 09:50:07 -0500
Download (untitled) / with headers
text/plain 1.6k
On Wed, 2016-07-20 at 18:54 -0700, Tony Cook via RT wrote: Show quoted text
> On Wed Jul 20 14:28:47 2016, lightsey@debian.org wrote:
> > On Tue, 2016-07-19 at 22:54 -0500, John Lightsey wrote:
> > > I noticed while trying to backport the 5.22 patch to 5.14 that the > > > way the > > > utils/xxx.PL scripts have been updated is inconsistent. Some of the > > > changes > > > are adding filtering to the script created by the PL and some of the > > > changes > > > are filtering @INC in the PL script instead.
> >  > > This problem seems to be limited to utils/h2ph.PL and utils/h2xs.PL in > > the 5.22 > > and 5.24 versions of the patch.
> > Thanks, fixed in the attached updates. >
> > As I was backporting the remainder of the changes I also noticed that > > the > > cpan/File-Fetch/lib/File/Fetch.pm changes are only filtering one of > > the five > > can_load() calls in this file.
> > When I originally wrote the patches I skipped adding the "local ... > pop if ..." code when the optional module was included in core. > > In the File::Fetch case mistakenly didn't update the load attempt for > HTTP::Lite. > > The attached patch adds the filtering for all can_load()s in File::Fetch, > but there are other cases where modules are doing optional module loads > of modules which are included in core, should those also be updated? > > eg. Archive::Tar::Constant
Ah, ok, just a mistake on my part. I didn't understand that some of these can_load() calls are for modules that are in core. I would agree that it makes sense to focus the changes on the module loads that are expected to fail because they're trying to load something outside of the core Perl module set. The added filtering in File::Fetch won't hurt in either case though.
Download signature.asc
application/pgp-signature 819b

Message body not shown because it is not plain text.

From: Dominic Hargreaves <dom [...] earth.li>
Subject: Re: [perl #127834] Flaws in Perl code due to unsafe module load path
CC: carnil [...] debian.org, fw [...] deneb.enyo.de, lightsey [...] debian.org, toddr [...] cpan.org, ntyni [...] debian.org
To: Steve Hay via RT <perl5-security-report [...] perl.org>
Date: Thu, 21 Jul 2016 17:35:39 +0100
Download (untitled) / with headers
text/plain 2.2k
On Sun, Jul 17, 2016 at 11:23:03AM -0700, Steve Hay via RT wrote: Show quoted text
> On 16 July 2016 at 21:33, Steve Hay <steve.m.hay@googlemail.com> wrote:
Show quoted text
> > FYI: The current maint release plan is: > > > > 1. Sunday 17th: Release 5.22.3-RC1 and 5.24.1-RC1 with more or less > > what is currently in maint-5.22 and maint-5.24 respectively. > > > > 2. Monday 25th: Release 5.22.3-RCx and 5.24.2-RCx (where 'x' is > > hopefully 2, but could be higher if any problems were found in the > > RC1s that necessitated more RCs already) containing these security > > patches. > > > > 3. Soon after (I'm thinking maybe Saturday 30th): Release 5.22.3 and 5.24.1 > > > > The exact date of the final release can't be predicted for sure > > because it depends on what, if any, problems are found in the RCs > > released on 25th. > > > > Please do let me know what UTC time disclosure will occur on 25th so > > that I can upload and announce the RCs to roughly coincide with that.
> > I'm just finalizing the RC1 releases, but a tester on #p5p has asked > whether 08e3451d7b3b714ad63a27f1b9c2a23ee75d15ee should be included > (in an RC2)? I'm generally avoiding pulling anything else into these > releases but this one is somewhat related, being a fix for > https://rt.perl.org/Ticket/Display.html?id=128528 (XSLoader may load > relative paths). > > Does anyone here have any feelings either way whether it should be included? > > (If I do pull it in then I would also pull in the related > 5993d6620f29d22b0a72701f4f0fdacff3d25460 and > a651dcdf6a9151150dcf0fb6b18849d3e39b0811).
I think Debian's plan was to include that in the release on Monday (for 5.20) although I think we've temporarily forgotten about that. I'm preparing a build including this patch now and will report any substantive test results. By the way, we have decided not to disable @INC by default quite yet. After applying all the various bulk changes we can we still have around 40 packages which don't build, plus a difficult to test impact on scripts (whether user installed or packaged). We're still going to provide a commented out sitecustomize script and encourage users to enable it if they are able, and try and push out the default change in a subsequent point release after some public QA efforts have taken place. Dominic.
Date: Fri, 22 Jul 2016 08:17:33 +0100
CC: Steve Hay via RT <perl5-security-report [...] perl.org>, carnil [...] debian.org, Florian Weimer <fw [...] deneb.enyo.de>, John Lightsey <lightsey [...] debian.org>, Todd Rinaldo <toddr [...] cpan.org>, Niko Tyni <ntyni [...] debian.org>
To: Dominic Hargreaves <dom [...] earth.li>
From: Steve Hay via perl5-security-report <perl5-security-report [...] perl.org>
Subject: Re: [perl #127834] Flaws in Perl code due to unsafe module load path
Download (untitled) / with headers
text/plain 2.1k
On 21 July 2016 at 17:35, Dominic Hargreaves <dom@earth.li> wrote: Show quoted text
> On Sun, Jul 17, 2016 at 11:23:03AM -0700, Steve Hay via RT wrote:
>> On 16 July 2016 at 21:33, Steve Hay <steve.m.hay@googlemail.com> wrote:
>
>> > FYI: The current maint release plan is: >> > >> > 1. Sunday 17th: Release 5.22.3-RC1 and 5.24.1-RC1 with more or less >> > what is currently in maint-5.22 and maint-5.24 respectively. >> > >> > 2. Monday 25th: Release 5.22.3-RCx and 5.24.2-RCx (where 'x' is >> > hopefully 2, but could be higher if any problems were found in the >> > RC1s that necessitated more RCs already) containing these security >> > patches. >> > >> > 3. Soon after (I'm thinking maybe Saturday 30th): Release 5.22.3 and 5.24.1 >> > >> > The exact date of the final release can't be predicted for sure >> > because it depends on what, if any, problems are found in the RCs >> > released on 25th. >> > >> > Please do let me know what UTC time disclosure will occur on 25th so >> > that I can upload and announce the RCs to roughly coincide with that.
>> >> I'm just finalizing the RC1 releases, but a tester on #p5p has asked >> whether 08e3451d7b3b714ad63a27f1b9c2a23ee75d15ee should be included >> (in an RC2)? I'm generally avoiding pulling anything else into these >> releases but this one is somewhat related, being a fix for >> https://rt.perl.org/Ticket/Display.html?id=128528 (XSLoader may load >> relative paths). >> >> Does anyone here have any feelings either way whether it should be included? >> >> (If I do pull it in then I would also pull in the related >> 5993d6620f29d22b0a72701f4f0fdacff3d25460 and >> a651dcdf6a9151150dcf0fb6b18849d3e39b0811).
> > I think Debian's plan was to include that in the release on Monday > (for 5.20) although I think we've temporarily forgotten about that. > I'm preparing a build including this patch now and will report any > substantive test results. >
Thanks. As you've probably seen by now, I've now pulled these XSLoader fixes into maint-5.22 and maint-5.24. I'm not planning on doing anything else on either maint branch for RC2, other than pull in the series of patches for this ticket (127834) itself sometime on Monday.
Date: Fri, 22 Jul 2016 11:01:50 -0500
To: Steve Hay via RT <perl5-security-report [...] perl.org>
CC: Dominic Hargreaves <dom [...] earth.li>, Salvatore Bonaccorso <carnil [...] debian.org>, Florian Weimer <fw [...] deneb.enyo.de>, John Lightsey <lightsey [...] debian.org>, Niko Tyni <ntyni [...] debian.org>, Steve Hay <steve.m.hay [...] googlemail.com>
Subject: Re: [perl #127834] Flaws in Perl code due to unsafe module load path
From: Todd Rinaldo <toddr [...] cpanel.net>
Download (untitled) / with headers
text/plain 3.1k

Show quoted text
On Jul 22, 2016, at 2:17 AM, Steve Hay <steve.m.hay@googlemail.com> wrote:

Thanks. As you've probably seen by now, I've now pulled these XSLoader
fixes into maint-5.22 and maint-5.24.

I'm not planning on doing anything else on either maint branch for
RC2, other than pull in the series of patches for this ticket (127834)
itself sometime on Monday.

I'm picking an arbitrary place to reply here. As I understand things the below email is what Sawyer intends to send out on Monday.

What I notice is missing is a statement of who needs to fix the remaining issues as a result of the flaw outlined in the disclosure. 

This is what I suggest should be added. Any opinions?

"While Perl Security has attempted to mitigate some of these problems by modifying Perl Modules, it is ultimately responsibility of the script writer to remove relative paths from @INC to assure the security / consistent behavior of their code regardless of what directory it executes from.

The following line when added to the top of Perl scripts should mitigate this problem. This assumes your code is not intentionally depending on paths relative to your current working directory:

BEGIN { @INC = grep { !m{^/}  @INC }"

Thanks,
Todd


--- THE EMAIL ---

... some intro here ...

The problem relates to Perl 5 ("perl") loading modules from the
includes directory array ("@INC") in which the last element is the
current directory ("."). That means that, when "perl" wants to load a
module (during first compilation or during lazy loading of a module in
run-time), perl will look for the module in the current directory at
the end, since '.' is the last include directory in its array of
include directories to seek. The issue is with requiring libraries
that are in "." but are not otherwise installed.

The major problem with this behavior is that it unexpectedly puts a
user at risk whenever they execute any Perl scripts from a directory
that is writable by other accounts on the system. For instance, if a
user is logged in as root and changes directory into /tmp or an
account's home directory, it is possible to now run any shell commands
that are written in C, Python or Ruby without fear.

The same isn't true for any shell commands that are written in Perl,
since a significant proportion of Perl scripts will execute code in
the current working directory whenever they are run. For example, if a
user on a shared system creates the file /tmp/Pod/Perldoc/Toterm.pm,
and then I log in as root, change directory to /tmp, and run "perldoc
perlrun", it will execute the code they have placed in the file.

The most severe example discovered on Debian is that apt-get will load
and execute the /tmp/Log/Agent.pm file regardless of the directory it
is started from since it automatically changes directory to /tmp.

This is present in perl versions 5.24 and below. We will be making
additional maintenance releases of 5.24, 5.22 (current supported
versions), and (as an exception, probably) 5.20 (which is no longer
officially supported) which will include the fix for it.

The fix, supplied in the attached patches, is to check if the last
entry of @INC is "." and if so, to remove it as an included path.
Date: Fri, 22 Jul 2016 11:43:23 -0500
To: Todd Rinaldo <toddr [...] cpanel.net>
CC: Steve Hay via RT <perl5-security-report [...] perl.org>, Dominic Hargreaves <dom [...] earth.li>, Salvatore Bonaccorso <carnil [...] debian.org>, Florian Weimer <fw [...] deneb.enyo.de>, John Lightsey <lightsey [...] debian.org>, Niko Tyni <ntyni [...] debian.org>, Steve Hay <steve.m.hay [...] googlemail.com>
Subject: Re: [perl #127834] Flaws in Perl code due to unsafe module load path
From: "Craig A. Berry" <craig.a.berry [...] gmail.com>
Download (untitled) / with headers
text/plain 294b
On Fri, Jul 22, 2016 at 11:01 AM, Todd Rinaldo <toddr@cpanel.net> wrote: Show quoted text
> BEGIN { @INC = grep { !m{^/} @INC }"
That particular code will not work on Windows, where @INC typically has entries such as "C:/Perl64/lib". I believe the recent XSLoader fix had something to handle this pattern.
To: Steve Hay via RT <perl5-security-report [...] perl.org>
From: Zefram <zefram [...] fysh.org>
Subject: Re: [perl #127834] Flaws in Perl code due to unsafe module load path
CC: Todd Rinaldo <toddr [...] cpanel.net>, Dominic Hargreaves <dom [...] earth.li>, Salvatore Bonaccorso <carnil [...] debian.org>, Florian Weimer <fw [...] deneb.enyo.de>, John Lightsey <lightsey [...] debian.org>, Niko Tyni <ntyni [...] debian.org>, Steve Hay <steve.m.hay [...] googlemail.com>
Date: Sat, 23 Jul 2016 00:09:52 +0100
Download (untitled) / with headers
text/plain 893b
Todd Rinaldo wrote: Show quoted text
>BEGIN { @INC = grep { !m{^/} @INC }"
Why this arrangement? The problem we've been discussing is specifically with the implicit "." at the end of @INC, not with relative paths in general. Our threat model doesn't have control over PERL5LIB for the privileged execution of Perl programs. The formulation we've actually got in Tony's patch, which deals specifically with the "." entry, and which I'd expect us to promote, is BEGIN { pop @INC if $INC[-1] eq '.' } Your code is also missing a brace, and you've quoted it inconsistently. Show quoted text
>The fix, supplied in the attached patches, is to check if the last >entry of @INC is "." and if so, to remove it as an included path.
This ought to be more specific about where this fix gets applied. @INC gets modified globally at the start of any script, and locally anywhere that tries to load an optional module. -zefram
Date: Fri, 22 Jul 2016 18:20:38 -0500
To: Steve Hay via RT <perl5-security-report [...] perl.org>
Subject: Re: [perl #127834] Flaws in Perl code due to unsafe module load path
CC: Salvatore Bonaccorso <carnil [...] debian.org>, Florian Weimer <fw [...] deneb.enyo.de>, John Lightsey <lightsey [...] debian.org>, Todd Rinaldo <toddr [...] cpan.org>, dom [...] earth.li, ntyni [...] debian.org
From: Todd Rinaldo <toddr [...] cpanel.net>
Download (untitled) / with headers
text/plain 1.6k
Show quoted text
> On Jul 22, 2016, at 6:10 PM, Zefram via RT <perl5-security-report@perl.org> wrote: > > Todd Rinaldo wrote:
>> BEGIN { @INC = grep { !m{^/} @INC }"
> > Why this arrangement? The problem we've been discussing is specifically > with the implicit "." at the end of @INC, not with relative paths in > general. Our threat model doesn't have control over PERL5LIB for the > privileged execution of Perl programs. The formulation we've actually > got in Tony's patch, which deals specifically with the "." entry, and > which I'd expect us to promote, is
So the message I suggest giving is that relative paths in @INC is bad period. This is why I suggest the more aggressive @INC stripping. Ideally we should be doing this during our optional loads, but as we're altering modules not scripts for the most part, we can't make the assumptions a script writer could. The majority of mitigation has to be done by someone other than perl 5 security. My question is why you'd be ok with "./lib" in an @INC path. That's just as dangerous right? If you guys feel strongly about suggesting the pop @INC approach instead, I'm fine with at least some guidance to downstream. Show quoted text
> BEGIN { pop @INC if $INC[-1] eq '.' } > > Your code is also missing a brace, and you've quoted it inconsistently.
The quote was part of the suggested addendum to the announcement and not part of the code. Show quoted text
>
>> The fix, supplied in the attached patches, is to check if the last >> entry of @INC is "." and if so, to remove it as an included path.
> > This ought to be more specific about where this fix gets applied. > @INC gets modified globally at the start of any script, and locally > anywhere that tries to load an optional module. > > -zefram > >
Date: Sat, 23 Jul 2016 05:22:53 +0100
To: Steve Hay via RT <perl5-security-report [...] perl.org>
From: Zefram <zefram [...] fysh.org>
Subject: Re: [perl #127834] Flaws in Perl code due to unsafe module load path
CC: Todd Rinaldo <toddr [...] cpanel.net>, Salvatore Bonaccorso <carnil [...] debian.org>, Florian Weimer <fw [...] deneb.enyo.de>, John Lightsey <lightsey [...] debian.org>, Todd Rinaldo <toddr [...] cpan.org>, dom [...] earth.li, ntyni [...] debian.org
Download (untitled) / with headers
text/plain 335b
Todd Rinaldo wrote: Show quoted text
>So the message I suggest giving is that relative paths in @INC is bad period.
That's a decent message, but the way to deal with most relative paths in @INC is to not put them into @INC in the first place. The "." at the end of @INC is unique in being there by default, requiring effort to take it out. -zefram
Date: Sat, 23 Jul 2016 15:12:51 +0200
From: Sawyer X <xsawyerx [...] gmail.com>
CC: Steve Hay via RT <perl5-security-report [...] perl.org>, Todd Rinaldo <toddr [...] cpanel.net>, Salvatore Bonaccorso <carnil [...] debian.org>, Florian Weimer <fw [...] deneb.enyo.de>, John Lightsey <lightsey [...] debian.org>, Todd Rinaldo <toddr [...] cpan.org>, Dominic Hargreaves <dom [...] earth.li>, Niko Tyni <ntyni [...] debian.org>
Subject: Re: [perl #127834] Flaws in Perl code due to unsafe module load path
To: Zefram <zefram [...] fysh.org>
Download (untitled) / with headers
text/plain 648b
[Top-posted] I think a combination of these ideas would serve best: 1. The patch example of Tony's work as "This is the kind of change you should apply", and 2. A recommendation to not allow relative paths in @INC. Sounds good? On Sat, Jul 23, 2016 at 6:22 AM, Zefram <zefram@fysh.org> wrote: Show quoted text
> Todd Rinaldo wrote:
>>So the message I suggest giving is that relative paths in @INC is bad period.
> > That's a decent message, but the way to deal with most relative paths > in @INC is to not put them into @INC in the first place. The "." at > the end of @INC is unique in being there by default, requiring effort > to take it out. > > -zefram
CC: Steve Hay via RT <perl5-security-report [...] perl.org>, carnil [...] debian.org, Florian Weimer <fw [...] deneb.enyo.de>, John Lightsey <lightsey [...] debian.org>, Todd Rinaldo <toddr [...] cpan.org>, Niko Tyni <ntyni [...] debian.org>
Date: Sun, 24 Jul 2016 18:26:19 +0100
Subject: Re: [perl #127834] Flaws in Perl code due to unsafe module load path
From: Steve Hay via perl5-security-report <perl5-security-report [...] perl.org>
To: Dominic Hargreaves <dom [...] earth.li>
Download (untitled) / with headers
text/plain 3.9k
On 22 July 2016 at 08:17, Steve Hay <steve.m.hay@googlemail.com> wrote: Show quoted text
> On 21 July 2016 at 17:35, Dominic Hargreaves <dom@earth.li> wrote:
>> On Sun, Jul 17, 2016 at 11:23:03AM -0700, Steve Hay via RT wrote:
>>> On 16 July 2016 at 21:33, Steve Hay <steve.m.hay@googlemail.com> wrote:
>>
>>> > FYI: The current maint release plan is: >>> > >>> > 1. Sunday 17th: Release 5.22.3-RC1 and 5.24.1-RC1 with more or less >>> > what is currently in maint-5.22 and maint-5.24 respectively. >>> > >>> > 2. Monday 25th: Release 5.22.3-RCx and 5.24.2-RCx (where 'x' is >>> > hopefully 2, but could be higher if any problems were found in the >>> > RC1s that necessitated more RCs already) containing these security >>> > patches. >>> > >>> > 3. Soon after (I'm thinking maybe Saturday 30th): Release 5.22.3 and 5.24.1 >>> > >>> > The exact date of the final release can't be predicted for sure >>> > because it depends on what, if any, problems are found in the RCs >>> > released on 25th. >>> > >>> > Please do let me know what UTC time disclosure will occur on 25th so >>> > that I can upload and announce the RCs to roughly coincide with that.
>>> >>> I'm just finalizing the RC1 releases, but a tester on #p5p has asked >>> whether 08e3451d7b3b714ad63a27f1b9c2a23ee75d15ee should be included >>> (in an RC2)? I'm generally avoiding pulling anything else into these >>> releases but this one is somewhat related, being a fix for >>> https://rt.perl.org/Ticket/Display.html?id=128528 (XSLoader may load >>> relative paths). >>> >>> Does anyone here have any feelings either way whether it should be included? >>> >>> (If I do pull it in then I would also pull in the related >>> 5993d6620f29d22b0a72701f4f0fdacff3d25460 and >>> a651dcdf6a9151150dcf0fb6b18849d3e39b0811).
>> >> I think Debian's plan was to include that in the release on Monday >> (for 5.20) although I think we've temporarily forgotten about that. >> I'm preparing a build including this patch now and will report any >> substantive test results. >>
> > Thanks. As you've probably seen by now, I've now pulled these XSLoader > fixes into maint-5.22 and maint-5.24. > > I'm not planning on doing anything else on either maint branch for > RC2, other than pull in the series of patches for this ticket (127834) > itself sometime on Monday.
I need to start preparing RC2s for tomorrow (25th). If I've followed correctly, Tony's patches from 21 July are the current set that we will be releasing in RC2. For clarity these are: maint-5.22: 94c781b (perl #127834) update CUSTOMIZED entries 85a4b64 cpan/: bump $VERSION as needed 0eae8f5 cpan/: remove . from @INC when loading optional modules bfe2dd1 dist/: bump $VERSION as needed ac5b10a dist/: remove . from @INC when loading optional modules 211eea8 perl5db.pl: bump perldb $VERSION 8b4decb perl5db.pl: ensure PadWalker is loaded from standard paths bbf4359 (perl #127834) bump versions of modules in dists we updated a utility in b86ce83 (perl #127834) remove . from the end of @INC if complex modules are load (9 patches) maint-5.24: c335412 (perl #127834) perldelta for . in @INC changes 7ab93a5 (perl #127834) update CUSTOMIZED entries 8a05e1a cpan/: bump $VERSION as needed 53e2659 cpan/: remove . from @INC when loading optional modules 19c14a4 dist/: bump $VERSION as needed 14ae0d1 dist/: remove . from @INC when loading optional modules 31ff4ce perl5db.pl: bump perldb $VERSION 3f09f80 perl5db.pl: ensure PadWalker is loaded from standard paths daacd59 (perl #127834) bump versions of modules in dists we updated a utility in 07daf0f (perl #127834) remove . from the end of @INC if complex modules are load (10 patches) Presumably the same perldelta entry can be used for 5.22 as for 5.24? Please can someone confirm that these details are correct, and I will start getting things ready locally so that I'm ready to announce RC2s tomorrow. (Obviously I won't be pushing anything until the RC2 are made public.) Do we have any timeframes for disclosure and RC2 releases yet?
Date: Sun, 24 Jul 2016 20:32:37 +0100
To: Steve Hay <steve.m.hay [...] googlemail.com>
From: Dominic Hargreaves <dom [...] earth.li>
Subject: Re: [perl #127834] Flaws in Perl code due to unsafe module load path
CC: Steve Hay via RT <perl5-security-report [...] perl.org>, carnil [...] debian.org, Florian Weimer <fw [...] deneb.enyo.de>, John Lightsey <lightsey [...] debian.org>, Todd Rinaldo <toddr [...] cpan.org>, Niko Tyni <ntyni [...] debian.org>
Download (untitled) / with headers
text/plain 4.3k
On Sun, Jul 24, 2016 at 06:26:19PM +0100, Steve Hay wrote: Show quoted text
> On 22 July 2016 at 08:17, Steve Hay <steve.m.hay@googlemail.com> wrote:
> > On 21 July 2016 at 17:35, Dominic Hargreaves <dom@earth.li> wrote:
> >> On Sun, Jul 17, 2016 at 11:23:03AM -0700, Steve Hay via RT wrote:
> >>> On 16 July 2016 at 21:33, Steve Hay <steve.m.hay@googlemail.com> wrote:
> >>
> >>> > FYI: The current maint release plan is: > >>> > > >>> > 1. Sunday 17th: Release 5.22.3-RC1 and 5.24.1-RC1 with more or less > >>> > what is currently in maint-5.22 and maint-5.24 respectively. > >>> > > >>> > 2. Monday 25th: Release 5.22.3-RCx and 5.24.2-RCx (where 'x' is > >>> > hopefully 2, but could be higher if any problems were found in the > >>> > RC1s that necessitated more RCs already) containing these security > >>> > patches. > >>> > > >>> > 3. Soon after (I'm thinking maybe Saturday 30th): Release 5.22.3 and 5.24.1 > >>> > > >>> > The exact date of the final release can't be predicted for sure > >>> > because it depends on what, if any, problems are found in the RCs > >>> > released on 25th. > >>> > > >>> > Please do let me know what UTC time disclosure will occur on 25th so > >>> > that I can upload and announce the RCs to roughly coincide with that.
> >>> > >>> I'm just finalizing the RC1 releases, but a tester on #p5p has asked > >>> whether 08e3451d7b3b714ad63a27f1b9c2a23ee75d15ee should be included > >>> (in an RC2)? I'm generally avoiding pulling anything else into these > >>> releases but this one is somewhat related, being a fix for > >>> https://rt.perl.org/Ticket/Display.html?id=128528 (XSLoader may load > >>> relative paths). > >>> > >>> Does anyone here have any feelings either way whether it should be included? > >>> > >>> (If I do pull it in then I would also pull in the related > >>> 5993d6620f29d22b0a72701f4f0fdacff3d25460 and > >>> a651dcdf6a9151150dcf0fb6b18849d3e39b0811).
> >> > >> I think Debian's plan was to include that in the release on Monday > >> (for 5.20) although I think we've temporarily forgotten about that. > >> I'm preparing a build including this patch now and will report any > >> substantive test results. > >>
> > > > Thanks. As you've probably seen by now, I've now pulled these XSLoader > > fixes into maint-5.22 and maint-5.24. > > > > I'm not planning on doing anything else on either maint branch for > > RC2, other than pull in the series of patches for this ticket (127834) > > itself sometime on Monday.
> > I need to start preparing RC2s for tomorrow (25th). If I've followed > correctly, Tony's patches from 21 July are the current set that we > will be releasing in RC2. For clarity these are: > > maint-5.22: > 94c781b (perl #127834) update CUSTOMIZED entries > 85a4b64 cpan/: bump $VERSION as needed > 0eae8f5 cpan/: remove . from @INC when loading optional modules > bfe2dd1 dist/: bump $VERSION as needed > ac5b10a dist/: remove . from @INC when loading optional modules > 211eea8 perl5db.pl: bump perldb $VERSION > 8b4decb perl5db.pl: ensure PadWalker is loaded from standard paths > bbf4359 (perl #127834) bump versions of modules in dists we updated a utility in > b86ce83 (perl #127834) remove . from the end of @INC if complex modules are load > (9 patches) > > maint-5.24: > c335412 (perl #127834) perldelta for . in @INC changes > 7ab93a5 (perl #127834) update CUSTOMIZED entries > 8a05e1a cpan/: bump $VERSION as needed > 53e2659 cpan/: remove . from @INC when loading optional modules > 19c14a4 dist/: bump $VERSION as needed > 14ae0d1 dist/: remove . from @INC when loading optional modules > 31ff4ce perl5db.pl: bump perldb $VERSION > 3f09f80 perl5db.pl: ensure PadWalker is loaded from standard paths > daacd59 (perl #127834) bump versions of modules in dists we updated a utility in > 07daf0f (perl #127834) remove . from the end of @INC if complex modules are load > (10 patches) > > Presumably the same perldelta entry can be used for 5.22 as for 5.24? > > Please can someone confirm that these details are correct, and I will > start getting things ready locally so that I'm ready to announce RC2s > tomorrow. (Obviously I won't be pushing anything until the RC2 are > made public.) > > Do we have any timeframes for disclosure and RC2 releases yet?
I'm obviously not speaking with authority, but I agree with all the above. I'd also appreciate a decision about disclosure time tomorrow. Not first thing european time would be best as I will still have some work left on the Debian side tomorrow morning. Thanks, Dominic.
Date: Mon, 25 Jul 2016 00:18:19 +0200
From: Sawyer X <xsawyerx [...] gmail.com>
Subject: Re: [perl #127834] Flaws in Perl code due to unsafe module load path
CC: Steve Hay <steve.m.hay [...] googlemail.com>, Steve Hay via RT <perl5-security-report [...] perl.org>, Salvatore Bonaccorso <carnil [...] debian.org>, Florian Weimer <fw [...] deneb.enyo.de>, John Lightsey <lightsey [...] debian.org>, Todd Rinaldo <toddr [...] cpan.org>, Niko Tyni <ntyni [...] debian.org>
To: Dominic Hargreaves <dom [...] earth.li>
Download (untitled) / with headers
text/plain 4.7k
On Sun, Jul 24, 2016 at 9:32 PM, Dominic Hargreaves <dom@earth.li> wrote: Show quoted text
> On Sun, Jul 24, 2016 at 06:26:19PM +0100, Steve Hay wrote:
>> On 22 July 2016 at 08:17, Steve Hay <steve.m.hay@googlemail.com> wrote:
>> > On 21 July 2016 at 17:35, Dominic Hargreaves <dom@earth.li> wrote:
>> >> On Sun, Jul 17, 2016 at 11:23:03AM -0700, Steve Hay via RT wrote:
>> >>> On 16 July 2016 at 21:33, Steve Hay <steve.m.hay@googlemail.com> wrote:
>> >>
>> >>> > FYI: The current maint release plan is: >> >>> > >> >>> > 1. Sunday 17th: Release 5.22.3-RC1 and 5.24.1-RC1 with more or less >> >>> > what is currently in maint-5.22 and maint-5.24 respectively. >> >>> > >> >>> > 2. Monday 25th: Release 5.22.3-RCx and 5.24.2-RCx (where 'x' is >> >>> > hopefully 2, but could be higher if any problems were found in the >> >>> > RC1s that necessitated more RCs already) containing these security >> >>> > patches. >> >>> > >> >>> > 3. Soon after (I'm thinking maybe Saturday 30th): Release 5.22.3 and 5.24.1 >> >>> > >> >>> > The exact date of the final release can't be predicted for sure >> >>> > because it depends on what, if any, problems are found in the RCs >> >>> > released on 25th. >> >>> > >> >>> > Please do let me know what UTC time disclosure will occur on 25th so >> >>> > that I can upload and announce the RCs to roughly coincide with that.
>> >>> >> >>> I'm just finalizing the RC1 releases, but a tester on #p5p has asked >> >>> whether 08e3451d7b3b714ad63a27f1b9c2a23ee75d15ee should be included >> >>> (in an RC2)? I'm generally avoiding pulling anything else into these >> >>> releases but this one is somewhat related, being a fix for >> >>> https://rt.perl.org/Ticket/Display.html?id=128528 (XSLoader may load >> >>> relative paths). >> >>> >> >>> Does anyone here have any feelings either way whether it should be included? >> >>> >> >>> (If I do pull it in then I would also pull in the related >> >>> 5993d6620f29d22b0a72701f4f0fdacff3d25460 and >> >>> a651dcdf6a9151150dcf0fb6b18849d3e39b0811).
>> >> >> >> I think Debian's plan was to include that in the release on Monday >> >> (for 5.20) although I think we've temporarily forgotten about that. >> >> I'm preparing a build including this patch now and will report any >> >> substantive test results. >> >>
>> > >> > Thanks. As you've probably seen by now, I've now pulled these XSLoader >> > fixes into maint-5.22 and maint-5.24. >> > >> > I'm not planning on doing anything else on either maint branch for >> > RC2, other than pull in the series of patches for this ticket (127834) >> > itself sometime on Monday.
>> >> I need to start preparing RC2s for tomorrow (25th). If I've followed >> correctly, Tony's patches from 21 July are the current set that we >> will be releasing in RC2. For clarity these are: >> >> maint-5.22: >> 94c781b (perl #127834) update CUSTOMIZED entries >> 85a4b64 cpan/: bump $VERSION as needed >> 0eae8f5 cpan/: remove . from @INC when loading optional modules >> bfe2dd1 dist/: bump $VERSION as needed >> ac5b10a dist/: remove . from @INC when loading optional modules >> 211eea8 perl5db.pl: bump perldb $VERSION >> 8b4decb perl5db.pl: ensure PadWalker is loaded from standard paths >> bbf4359 (perl #127834) bump versions of modules in dists we updated a utility in >> b86ce83 (perl #127834) remove . from the end of @INC if complex modules are load >> (9 patches) >> >> maint-5.24: >> c335412 (perl #127834) perldelta for . in @INC changes >> 7ab93a5 (perl #127834) update CUSTOMIZED entries >> 8a05e1a cpan/: bump $VERSION as needed >> 53e2659 cpan/: remove . from @INC when loading optional modules >> 19c14a4 dist/: bump $VERSION as needed >> 14ae0d1 dist/: remove . from @INC when loading optional modules >> 31ff4ce perl5db.pl: bump perldb $VERSION >> 3f09f80 perl5db.pl: ensure PadWalker is loaded from standard paths >> daacd59 (perl #127834) bump versions of modules in dists we updated a utility in >> 07daf0f (perl #127834) remove . from the end of @INC if complex modules are load >> (10 patches) >> >> Presumably the same perldelta entry can be used for 5.22 as for 5.24? >> >> Please can someone confirm that these details are correct, and I will >> start getting things ready locally so that I'm ready to announce RC2s >> tomorrow. (Obviously I won't be pushing anything until the RC2 are >> made public.) >> >> Do we have any timeframes for disclosure and RC2 releases yet?
> > I'm obviously not speaking with authority, but I agree with all the > above. I'd also appreciate a decision about disclosure time > tomorrow. Not first thing european time would be best as I will still > have some work left on the Debian side tomorrow morning.
I would probably opt for afternoon European time because it's working hours for both EU and US. Japan, however, will already be night-time. Does anyone have a particular preference?
Date: Sun, 24 Jul 2016 18:06:08 -0500
From: John Lightsey <lightsey [...] debian.org>
Subject: Re: [perl #127834] Flaws in Perl code due to unsafe module load path
CC: dom [...] earth.li, ntyni [...] debian.org
To: perl5-security-report [...] perl.org, carnil [...] debian.org, fw [...] deneb.enyo.de, toddr [...] cpan.org
Download (untitled) / with headers
text/plain 462b
One other think that might be worth mentioning. I've done a fair amount of testing now with the 5.14 update that cPanel will be shipping and the 5.20 update that Debian will be shipping. The only regressions I've noticed have been due to the localization of @INC in base.pm. If a class loaded by base.pm attempts to manipulate @INC, it's modifying the localized copy rather than the global copy. It might be worth mentioning this in the announcement at least.
Download signature.asc
application/pgp-signature 819b

Message body not shown because it is not plain text.

Date: Mon, 25 Jul 2016 01:04:19 +0100
CC: Todd Rinaldo <toddr [...] cpan.org>, Dominic Hargreaves <dom [...] earth.li>, John Lightsey <lightsey [...] debian.org>, Niko Tyni <ntyni [...] debian.org>, Florian Weimer <fw [...] deneb.enyo.de>, Salvatore Bonaccorso <carnil [...] debian.org>, Steve Hay via RT <perl5-security-report [...] perl.org>
To: Sawyer X <xsawyerx [...] gmail.com>
From: Steve Hay via perl5-security-report <perl5-security-report [...] perl.org>
Subject: Re: [perl #127834] Flaws in Perl code due to unsafe module load path
Download (untitled) / with headers
text/plain 5.1k

On 24 Jul 2016 23:18, "Sawyer X" <xsawyerx@gmail.com> wrote:
Show quoted text

>
> On Sun, Jul 24, 2016 at 9:32 PM, Dominic Hargreaves <dom@earth.li> wrote:
> > On Sun, Jul 24, 2016 at 06:26:19PM +0100, Steve Hay wrote:
> >> On 22 July 2016 at 08:17, Steve Hay <steve.m.hay@googlemail.com> wrote:
> >> > On 21 July 2016 at 17:35, Dominic Hargreaves <dom@earth.li> wrote:
> >> >> On Sun, Jul 17, 2016 at 11:23:03AM -0700, Steve Hay via RT wrote:
> >> >>> On 16 July 2016 at 21:33, Steve Hay <steve.m.hay@googlemail.com> wrote:
> >> >>
> >> >>> > FYI: The current maint release plan is:
> >> >>> >
> >> >>> > 1. Sunday 17th: Release 5.22.3-RC1 and 5.24.1-RC1 with more or less
> >> >>> > what is currently in maint-5.22 and maint-5.24 respectively.
> >> >>> >
> >> >>> > 2. Monday 25th: Release 5.22.3-RCx and 5.24.2-RCx (where 'x' is
> >> >>> > hopefully 2, but could be higher if any problems were found in the
> >> >>> > RC1s that necessitated more RCs already) containing these security
> >> >>> > patches.
> >> >>> >
> >> >>> > 3. Soon after (I'm thinking maybe Saturday 30th): Release 5.22.3 and 5.24.1
> >> >>> >
> >> >>> > The exact date of the final release can't be predicted for sure
> >> >>> > because it depends on what, if any, problems are found in the RCs
> >> >>> > released on 25th.
> >> >>> >
> >> >>> > Please do let me know what UTC time disclosure will occur on 25th so
> >> >>> > that I can upload and announce the RCs to roughly coincide with that.
> >> >>>
> >> >>> I'm just finalizing the RC1 releases, but a tester on #p5p has asked
> >> >>> whether 08e3451d7b3b714ad63a27f1b9c2a23ee75d15ee should be included
> >> >>> (in an RC2)? I'm generally avoiding pulling anything else into these
> >> >>> releases but this one is somewhat related, being a fix for
> >> >>> https://rt.perl.org/Ticket/Display.html?id=128528 (XSLoader may load
> >> >>> relative paths).
> >> >>>
> >> >>> Does anyone here have any feelings either way whether it should be included?
> >> >>>
> >> >>> (If I do pull it in then I would also pull in the related
> >> >>> 5993d6620f29d22b0a72701f4f0fdacff3d25460 and
> >> >>> a651dcdf6a9151150dcf0fb6b18849d3e39b0811).
> >> >>
> >> >> I think Debian's plan was to include that in the release on Monday
> >> >> (for 5.20) although I think we've temporarily forgotten about that.
> >> >> I'm preparing a build including this patch now and will report any
> >> >> substantive test results.
> >> >>
> >> >
> >> > Thanks. As you've probably seen by now, I've now pulled these XSLoader
> >> > fixes into maint-5.22 and maint-5.24.
> >> >
> >> > I'm not planning on doing anything else on either maint branch for
> >> > RC2, other than pull in the series of patches for this ticket (127834)
> >> > itself sometime on Monday.
> >>
> >> I need to start preparing RC2s for tomorrow (25th). If I've followed
> >> correctly, Tony's patches from 21 July are the current set that we
> >> will be releasing in RC2. For clarity these are:
> >>
> >> maint-5.22:
> >> 94c781b (perl #127834) update CUSTOMIZED entries
> >> 85a4b64 cpan/: bump $VERSION as needed
> >> 0eae8f5 cpan/: remove . from @INC when loading optional modules
> >> bfe2dd1 dist/: bump $VERSION as needed
> >> ac5b10a dist/: remove . from @INC when loading optional modules
> >> 211eea8 perl5db.pl: bump perldb $VERSION
> >> 8b4decb perl5db.pl: ensure PadWalker is loaded from standard paths
> >> bbf4359 (perl #127834) bump versions of modules in dists we updated a utility in
> >> b86ce83 (perl #127834) remove . from the end of @INC if complex modules are load
> >> (9 patches)
> >>
> >> maint-5.24:
> >> c335412 (perl #127834) perldelta for . in @INC changes
> >> 7ab93a5 (perl #127834) update CUSTOMIZED entries
> >> 8a05e1a cpan/: bump $VERSION as needed
> >> 53e2659 cpan/: remove . from @INC when loading optional modules
> >> 19c14a4 dist/: bump $VERSION as needed
> >> 14ae0d1 dist/: remove . from @INC when loading optional modules
> >> 31ff4ce perl5db.pl: bump perldb $VERSION
> >> 3f09f80 perl5db.pl: ensure PadWalker is loaded from standard paths
> >> daacd59 (perl #127834) bump versions of modules in dists we updated a utility in
> >> 07daf0f (perl #127834) remove . from the end of @INC if complex modules are load
> >> (10 patches)
> >>
> >> Presumably the same perldelta entry can be used for 5.22 as for 5.24?
> >>
> >> Please can someone confirm that these details are correct, and I will
> >> start getting things ready locally so that I'm ready to announce RC2s
> >> tomorrow. (Obviously I won't be pushing anything until the RC2 are
> >> made public.)
> >>
> >> Do we have any timeframes for disclosure and RC2 releases yet?
> >
> > I'm obviously not speaking with authority, but I agree with all the
> > above. I'd also appreciate a decision about disclosure time
> > tomorrow. Not first thing european time would be best as I will still
> > have some work left on the Debian side tomorrow morning.
>
> I would probably opt for afternoon European time because it's working
> hours for both EU and US. Japan, however, will already be night-time.
> Does anyone have a particular preference?

Afternoon European time is fine with me. I've no particular preference exactly what time, but I'll put forward 3pm CEST (2pm BST for me) as a suggestion.

Date: Mon, 25 Jul 2016 11:44:45 +1000
To: Tony Cook via RT <perl5-security-report [...] perl.org>
From: Tony Cook <tony [...] develop-help.com>
Subject: Re: [perl #127834] Flaws in Perl code due to unsafe module load path
CC: ;, rt-deliver-to-perl5-security-report [...] rt.perl.org
Download (untitled) / with headers
text/plain 1.3k
On Wed, Jul 20, 2016 at 06:54:09PM -0700, Tony Cook via RT wrote: Show quoted text
> The attached patch ...
John suggested we mention that modifications to @INC by modules loaded by base.pm will be reverted when @INC is restored, the attached patch fixes that. It also explains *why* we're removing . from @INC temporarily. It adds a reason *not* to set PERL5LIB to . It also discusses how to protect your own code from the issue. Finally it fixes a bad squash, which I squashed the File::Fetch customized.dat updates into the perldelta commit. It contains no code changes relative to the previous patchset. One other thing to consider is this section from the 5.24 perldelta (and presumably 5.22): Show quoted text
>>>
=head1 Incompatible Changes There are no changes intentionally incompatible with Perl 5.24.0. If any exist, they are bugs, and we request that you submit a report. See L</Reporting Bugs> below. <<< The two security changes in these releases are backward incompatible, especially the change to base.pm, so perhaps this should change to read: Show quoted text
>>>
Beyond the security changes above there are no changes intentionally incompatible with Perl 5.24.0. If any exist, they are bugs, and we request that you submit a report. See L</Reporting Bugs> below. <<< Steve: the 5.22 change set doesn't include the perldelta update since I expected more discussion, so it will need to be cherry-picked or copied back. Tony
From: Dominic Hargreaves <dom [...] earth.li>
Subject: Re: [perl #127834] Flaws in Perl code due to unsafe module load path
CC: carnil [...] debian.org, fw [...] deneb.enyo.de, lightsey [...] debian.org, toddr [...] cpan.org, ntyni [...] debian.org
To: Tony Cook via RT <perl5-security-report [...] perl.org>
Date: Mon, 25 Jul 2016 08:37:49 +0100
Download (untitled) / with headers
text/plain 909b
On Sun, Jul 24, 2016 at 06:45:21PM -0700, Tony Cook via RT wrote: Show quoted text
> On Wed, Jul 20, 2016 at 06:54:09PM -0700, Tony Cook via RT wrote:
> > The attached patch ...
> > John suggested we mention that modifications to @INC by modules loaded > by base.pm will be reverted when @INC is restored, the attached patch > fixes that. > > It also explains *why* we're removing . from @INC temporarily. > > It adds a reason *not* to set PERL5LIB to . > > It also discusses how to protect your own code from the issue. > > Finally it fixes a bad squash, which I squashed the File::Fetch > customized.dat updates into the perldelta commit. > > It contains no code changes relative to the previous patchset.
Hi Tony, I don't see any attachments to this email (though I suspect they aren't particularly relevant to Debian, as we are communicating this via a security advisory rather than perldelta). Thanks, Dominic.
RT-Send-CC: rt-deliver-to-perl5-security-report [...] rt.perl.org
Download (untitled) / with headers
text/plain 247b
On Mon Jul 25 00:38:18 2016, dom wrote: Show quoted text
> I don't see any attachments to this email (though I suspect they aren't > particularly relevant to Debian, as we are communicating this via > a security advisory rather than perldelta).
Here it is. Tony
Subject: maint-5.24-dot-in-inc.patch

Message body is not shown because it is too large.

Date: Mon, 25 Jul 2016 11:19:20 +0100
To: John Lightsey via RT <perl5-security-report [...] perl.org>
From: Dominic Hargreaves <dom [...] earth.li>
CC: carnil [...] debian.org, fw [...] deneb.enyo.de, toddr [...] cpan.org, ntyni [...] debian.org
Subject: Re: [perl #127834] Flaws in Perl code due to unsafe module load path
Download (untitled) / with headers
text/plain 1.4k
On Tue, Jul 19, 2016 at 04:47:19PM -0700, John Lightsey via RT wrote: Show quoted text
> For comparison, my last test run with the 5.22 patches was: > > Total Perl scripts in /usr/bin and /usr/sbin: 423 > Vulnerable before patch: 170  (40.2%) > Vulnerable after patch:  16    (3.8%) > > Now I'm getting: > Vulnerable after patch:  11    (2.6%) > > The remaining module loads that show up are all happening through scripts and > modules outside of core Perl: > > Net::DNS           -> Net::LibIDN > Net::DNS::Resolver -> Net::DNS::Resolver::linux > YAML::Mo           -> Mo::builder and Mo::default > Locale::Messages   -> Locale::gettext_xs > MIME::Charset      -> MIME::Charset::Defaults > MIME::EncWords     -> MIME::EncWords::Defaults > Unicode::LineBreak -> Unicode::LineBreak::Defaults > eximstats          -> GD::Graph::pie and GD::Graph::linespoints > dbiproxy           -> RPC::PlServer
Thanks John, I've fixed most of these in updates now queued for release as part of the security update for Debian stable later today. I've put a handful of those (not all because I don't have access to the machine I did some of the builds on right now) in the usual place. If you have a chance to sanity check the changes that'd be great. dbiproxy only tries to load RPC::PlServer when --test is specified, and it's not wrapped in an eval, so I don't think that justifies an update. YAML::Mo is a mystery to me - I assume the obfuscated/autogenerated code is guilty... Dominic.
To: Tony Cook <tony [...] develop-help.com>
Subject: Re: [perl #127834] Flaws in Perl code due to unsafe module load path
From: Steve Hay via perl5-security-report <perl5-security-report [...] perl.org>
CC: Tony Cook via RT <perl5-security-report [...] perl.org>, rt-deliver-to-perl5-security-report [...] rt.perl.org
Date: Mon, 25 Jul 2016 14:35:57 +0100
Download (untitled) / with headers
text/plain 1.6k
On 25 July 2016 at 02:44, Tony Cook <tony@develop-help.com> wrote: Show quoted text
> On Wed, Jul 20, 2016 at 06:54:09PM -0700, Tony Cook via RT wrote:
>> The attached patch ...
> > John suggested we mention that modifications to @INC by modules loaded > by base.pm will be reverted when @INC is restored, the attached patch > fixes that. > > It also explains *why* we're removing . from @INC temporarily. > > It adds a reason *not* to set PERL5LIB to . > > It also discusses how to protect your own code from the issue. > > Finally it fixes a bad squash, which I squashed the File::Fetch > customized.dat updates into the perldelta commit. > > It contains no code changes relative to the previous patchset. > > One other thing to consider is this section from the 5.24 perldelta > (and presumably 5.22): >
>>>>
> > =head1 Incompatible Changes > > There are no changes intentionally incompatible with Perl 5.24.0. If any > exist, they are bugs, and we request that you submit a report. See > L</Reporting Bugs> below. > > <<< > > The two security changes in these releases are backward incompatible, > especially the change to base.pm, so perhaps this should change to read: >
>>>>
> > Beyond the security changes above there are no changes intentionally > incompatible with Perl 5.24.0. If any exist, they are bugs, and we > request that you submit a report. See L</Reporting Bugs> below. > > <<<
Good point. Done. Show quoted text
> > Steve: the 5.22 change set doesn't include the perldelta update since > I expected more discussion, so it will need to be cherry-picked or > copied back. >
All perldelta changes copied back to maint-5.22. Thanks for all your work on this. It made my life much easier today :-)
RT-Send-CC: rt-deliver-to-perl5-security-report [...] rt.perl.org
Download (untitled) / with headers
text/plain 249b
I've just pulled the libnet change into my libnet repo, but am wondering if other changes are required to libnet modules too -- see my comment at https://github.com/steve-m-hay/perl-libnet/pull/29 What was the criteria for what code needs updating?
RT-Send-CC: rt-deliver-to-perl5-security-report [...] rt.perl.org
Download (untitled) / with headers
text/plain 115b
Hi, everyone. Peter Rabbitson provided a different workaround for base.pm: https://github.com/Perl/perl5/pull/10.
To: Sawyer X via RT <perl5-security-report [...] perl.org>
Subject: Re: [perl #127834] Flaws in Perl code due to unsafe module load path
From: Zefram <zefram [...] fysh.org>
Date: Fri, 12 Aug 2016 23:00:37 +0100
Download (untitled) / with headers
text/plain 804b
Sawyer X via RT wrote: Show quoted text
>Peter Rabbitson provided a different workaround for base.pm: https://github.com/Perl/perl5/pull/10.
There is some merit to the idea of not fully localising @INC, using a custom scope guard to restore the "." without otherwise restoring @INC. No one previously came up with this idea in the closed discussion. If we like it, we should probably do it for the other optional-load modules too where we're localising @INC. I'm dubious about the idea of checking that $INC[-1] is still in its former state, but not sure what should be done instead. One of the comments on that PR has an error in blessing \$INC[-1]: this would bless the actual element of @INC, which is both unwanted in itself and also screws up the later comparison of the blessed value against $INC[-1]. -zefram
Subject: Re: [perl #127834] Flaws in Perl code due to unsafe module load path
Date: Sat, 13 Aug 2016 20:58:20 +0200
From: Sawyer X <xsawyerx [...] gmail.com>
CC: Sawyer X via RT <perl5-security-report [...] perl.org>
Download (untitled) / with headers
text/plain 834b
Thank you, Zefram. On Sat, Aug 13, 2016 at 12:00 AM, Zefram <zefram@fysh.org> wrote: Show quoted text
> Sawyer X via RT wrote:
>>Peter Rabbitson provided a different workaround for base.pm: https://github.com/Perl/perl5/pull/10.
> > There is some merit to the idea of not fully localising @INC, using a > custom scope guard to restore the "." without otherwise restoring @INC. > No one previously came up with this idea in the closed discussion. > If we like it, we should probably do it for the other optional-load > modules too where we're localising @INC.
It seems to me like a less disruptive solution, which I favor. I'd be happy to hear additional comments about this. Are others in favor or against? Show quoted text
> I'm dubious about the idea of checking that $INC[-1] is still in its > former state, but not sure what should be done instead.
I agree.
To: Steve Hay via RT <perl5-security-report [...] perl.org>
Subject: Re: [perl #127834] Flaws in Perl code due to unsafe module load path
Date: Sat, 13 Aug 2016 15:12:23 -0500
CC: Salvatore Bonaccorso <carnil [...] debian.org>, Florian Weimer <fw [...] deneb.enyo.de>, John Lightsey <lightsey [...] debian.org>, Todd Rinaldo <toddr [...] cpan.org>, Dominic Hargreaves <dom [...] earth.li>, Niko Tyni <ntyni [...] debian.org>
From: Todd Rinaldo <toddr [...] cpanel.net>
Download (untitled) / with headers
text/plain 1.2k
Show quoted text
> On Aug 13, 2016, at 1:59 PM, Sawyer X via RT <perl5-security-report@perl.org> wrote: > > Thank you, Zefram. > > On Sat, Aug 13, 2016 at 12:00 AM, Zefram <zefram@fysh.org> wrote:
>> Sawyer X via RT wrote:
>>> Peter Rabbitson provided a different workaround for base.pm: https://github.com/Perl/perl5/pull/10.
>> >> There is some merit to the idea of not fully localising @INC, using a >> custom scope guard to restore the "." without otherwise restoring @INC. >> No one previously came up with this idea in the closed discussion. >> If we like it, we should probably do it for the other optional-load >> modules too where we're localising @INC.
> > It seems to me like a less disruptive solution, which I favor. > > I'd be happy to hear additional comments about this. Are others in > favor or against?
Since: 1. The modifications to base.pm have caused multiple problems 2. We have no known exploits against base.pm 3. p5p policy seems to state that the responsibility of protecting against . in @INC is with the script owner, not the module. I recommend we just take out the planned changes for base.pm. The changes to modules were always there to mitigate the majority of problems so it seems like the spirit of the CVE can still be achieved by doing nothing to base.pm. Todd
Subject: Re: [perl #127834] Flaws in Perl code due to unsafe module load path
To: Todd Rinaldo <toddr [...] cpanel.net>
Date: Sat, 13 Aug 2016 21:59:45 +0100
From: Zefram <zefram [...] fysh.org>
CC: Steve Hay via RT <perl5-security-report [...] perl.org>, Salvatore Bonaccorso <carnil [...] debian.org>, Florian Weimer <fw [...] deneb.enyo.de>, John Lightsey <lightsey [...] debian.org>, Todd Rinaldo <toddr [...] cpan.org>, Dominic Hargreaves <dom [...] earth.li>, Niko Tyni <ntyni [...] debian.org>
Download (untitled) / with headers
text/plain 529b
Todd Rinaldo wrote: Show quoted text
>2. We have no known exploits against base.pm
Not a good criterion. Any use of base.pm to declare a base class that is already defined, and so doesn't exist as a module, yields a guaranteed attempt to load a non-existent module. That's an intended way of using base.pm. Exploits will be readily available. Show quoted text
>3. p5p policy seems to state that the responsibility of protecting >against . in @INC is with the script owner, not the module.
Our policy on this one has been to defend in both places. -zefram
From: Niko Tyni <ntyni [...] debian.org>
CC: carnil [...] debian.org, fw [...] deneb.enyo.de, lightsey [...] debian.org, toddr [...] cpan.org, dom [...] earth.li
Date: Sun, 14 Aug 2016 11:31:54 +0300
To: Todd Rinaldo via RT <perl5-security-report [...] perl.org>
Subject: Re: [perl #127834] Flaws in Perl code due to unsafe module load path
Download (untitled) / with headers
text/plain 924b
On Sat, Aug 13, 2016 at 01:13:09PM -0700, Todd Rinaldo via RT wrote: Show quoted text
> 2. We have no known exploits against base.pm
As noticed by Ansgar Burchardt: $ echo 'print "Oh hai.\n";' >MyException.pm $ echo 'use Exception::Class ("MyException","AnotherException"=>{isa=>"MyException"})' > foo $ perl foo Oh hai. Exception::Class does 'use base "MyException"' when creating the AnotherException class, but a MyException.pm file is not expected to exist at all. We know of at least one real /usr/bin application in Debian that is/was vulnerable to cwd attacks because of this (our security update included the early patch modifying base.pm to ignore cwd, so that's not the case any longer on up to date systems.) Also, it looks like anything using (for instance) Object::InsideOut would be automatically vulnerable as it uses Exception::Class in this manner. I'm sure there are others. -- Niko Tyni ntyni@debian.org
Subject: Re: [perl #127834] Flaws in Perl code due to unsafe module load path
To: Niko Tyni <ntyni [...] debian.org>
From: Sawyer X <xsawyerx [...] gmail.com>
CC: Todd Rinaldo via RT <perl5-security-report [...] perl.org>, Salvatore Bonaccorso <carnil [...] debian.org>, Florian Weimer <fw [...] deneb.enyo.de>, John Lightsey <lightsey [...] debian.org>, Todd Rinaldo <toddr [...] cpan.org>, Dominic Hargreaves <dom [...] earth.li>
Date: Sun, 14 Aug 2016 10:58:35 +0200
On Sun, Aug 14, 2016 at 10:31 AM, Niko Tyni <ntyni@debian.org> wrote: Show quoted text
> > On Sat, Aug 13, 2016 at 01:13:09PM -0700, Todd Rinaldo via RT wrote: >
> > 2. We have no known exploits against base.pm
> > As noticed by Ansgar Burchardt: > > $ echo 'print "Oh hai.\n";' >MyException.pm > $ echo 'use Exception::Class ("MyException","AnotherException"=>{isa=>"MyException"})' > foo > $ perl foo > Oh hai. > > Exception::Class does 'use base "MyException"' when creating the > AnotherException class, but a MyException.pm file is not expected to > exist at all. > > We know of at least one real /usr/bin application in Debian that is/was > vulnerable to cwd attacks because of this (our security update included > the early patch modifying base.pm to ignore cwd, so that's not the case > any longer on up to date systems.) > > Also, it looks like anything using (for instance) Object::InsideOut would > be automatically vulnerable as it uses Exception::Class in this manner. > I'm sure there are others.
Niko, can you please try Ribasushi's patch and see if it still mitigates the cases you know sufficiently?
From: Niko Tyni <ntyni [...] debian.org>
CC: carnil [...] debian.org, fw [...] deneb.enyo.de, lightsey [...] debian.org, toddr [...] cpan.org, dom [...] earth.li
Date: Sun, 14 Aug 2016 12:28:49 +0300
To: Sawyer X via RT <perl5-security-report [...] perl.org>
Subject: Re: [perl #127834] Flaws in Perl code due to unsafe module load path
Download (untitled) / with headers
text/plain 824b
On Sun, Aug 14, 2016 at 01:59:19AM -0700, Sawyer X via RT wrote: Show quoted text
> On Sun, Aug 14, 2016 at 10:31 AM, Niko Tyni <ntyni@debian.org> wrote:
Show quoted text
> > We know of at least one real /usr/bin application in Debian that is/was > > vulnerable to cwd attacks because of this (our security update included > > the early patch modifying base.pm to ignore cwd, so that's not the case > > any longer on up to date systems.) > > > > Also, it looks like anything using (for instance) Object::InsideOut would > > be automatically vulnerable as it uses Exception::Class in this manner. > > I'm sure there are others.
> > Niko, can you please try Ribasushi's patch and see if it still > mitigates the cases you know sufficiently?
Yes, I tried it (f236830f) now and it seems to work just as well for those cases. -- Niko Tyni ntyni@debian.org
From: Sawyer X <xsawyerx [...] gmail.com>
CC: Sawyer X via RT <perl5-security-report [...] perl.org>, Salvatore Bonaccorso <carnil [...] debian.org>, Florian Weimer <fw [...] deneb.enyo.de>, John Lightsey <lightsey [...] debian.org>, Todd Rinaldo <toddr [...] cpan.org>, Dominic Hargreaves <dom [...] earth.li>
Date: Mon, 15 Aug 2016 18:42:34 +0200
To: Niko Tyni <ntyni [...] debian.org>
Subject: Re: [perl #127834] Flaws in Perl code due to unsafe module load path
Download (untitled) / with headers
text/plain 1.1k
On Sun, Aug 14, 2016 at 11:28 AM, Niko Tyni <ntyni@debian.org> wrote: Show quoted text
> On Sun, Aug 14, 2016 at 01:59:19AM -0700, Sawyer X via RT wrote:
>> On Sun, Aug 14, 2016 at 10:31 AM, Niko Tyni <ntyni@debian.org> wrote:
>
>> > We know of at least one real /usr/bin application in Debian that is/was >> > vulnerable to cwd attacks because of this (our security update included >> > the early patch modifying base.pm to ignore cwd, so that's not the case >> > any longer on up to date systems.) >> > >> > Also, it looks like anything using (for instance) Object::InsideOut would >> > be automatically vulnerable as it uses Exception::Class in this manner. >> > I'm sure there are others.
>> >> Niko, can you please try Ribasushi's patch and see if it still >> mitigates the cases you know sufficiently?
> > Yes, I tried it (f236830f) now and it seems to work just as well for > those cases.
Thank you, Niko. Today was supposed to be the day to open this RT ticket. Since we might change the solution for base.pm, I don't intend to reopen it today. I would like to make a decision about the in the next few days on this patch. Any additional comments?
To: Niko Tyni <ntyni [...] debian.org>
Subject: Re: [perl #127834] Flaws in Perl code due to unsafe module load path
Date: Sat, 20 Aug 2016 14:29:53 +0200
CC: Sawyer X via RT <perl5-security-report [...] perl.org>, Salvatore Bonaccorso <carnil [...] debian.org>, Florian Weimer <fw [...] deneb.enyo.de>, John Lightsey <lightsey [...] debian.org>, Todd Rinaldo <toddr [...] cpan.org>, Dominic Hargreaves <dom [...] earth.li>
From: Sawyer X <xsawyerx [...] gmail.com>
Download (untitled) / with headers
text/plain 1.4k
On Mon, Aug 15, 2016 at 6:42 PM, Sawyer X <xsawyerx@gmail.com> wrote: Show quoted text
> On Sun, Aug 14, 2016 at 11:28 AM, Niko Tyni <ntyni@debian.org> wrote:
>> On Sun, Aug 14, 2016 at 01:59:19AM -0700, Sawyer X via RT wrote:
>>> On Sun, Aug 14, 2016 at 10:31 AM, Niko Tyni <ntyni@debian.org> wrote:
>>
>>> > We know of at least one real /usr/bin application in Debian that is/was >>> > vulnerable to cwd attacks because of this (our security update included >>> > the early patch modifying base.pm to ignore cwd, so that's not the case >>> > any longer on up to date systems.) >>> > >>> > Also, it looks like anything using (for instance) Object::InsideOut would >>> > be automatically vulnerable as it uses Exception::Class in this manner. >>> > I'm sure there are others.
>>> >>> Niko, can you please try Ribasushi's patch and see if it still >>> mitigates the cases you know sufficiently?
>> >> Yes, I tried it (f236830f) now and it seems to work just as well for >> those cases.
> > Thank you, Niko. > > Today was supposed to be the day to open this RT ticket. Since we > might change the solution for base.pm, I don't intend to reopen it > today. > > I would like to make a decision about the in the next few days on this patch. > > Any additional comments?
To prevent this from being warnocked, let's set a time. Let's say, if by Tuesday there are no objections to the suggested base.pm patch, we will merge it. Sounds good? Take time to review it one last time, please.
To: Niko Tyni <ntyni [...] debian.org>
Subject: Re: [perl #127834] Flaws in Perl code due to unsafe module load path
CC: Sawyer X via RT <perl5-security-report [...] perl.org>, Salvatore Bonaccorso <carnil [...] debian.org>, Florian Weimer <fw [...] deneb.enyo.de>, John Lightsey <lightsey [...] debian.org>, Todd Rinaldo <toddr [...] cpan.org>, Dominic Hargreaves <dom [...] earth.li>
From: Sawyer X <xsawyerx [...] gmail.com>
Date: Thu, 25 Aug 2016 10:32:20 +0200
Download (untitled) / with headers
text/plain 528b
I know I had written about merging it earlier this week, but this was delayed in order to consider both the position of more people, and the option of reverting the patch from base.pm entirely, leaving it untouched. I wanted to ask, and please do find the time to reply, if anyone objects simply leaving base.pm untouched? (I had wanted to write it on the list as well, but I would first like comments from people working on it here). Todd is in favor of this, read here: http://nntp.perl.org/group/perl.perl5.porters/239295
To: Sawyer X <xsawyerx [...] gmail.com>
Subject: Re: [perl #127834] Flaws in Perl code due to unsafe module load path
CC: Niko Tyni <ntyni [...] debian.org>, Sawyer X via RT <perl5-security-report [...] perl.org>, Salvatore Bonaccorso <carnil [...] debian.org>, Florian Weimer <fw [...] deneb.enyo.de>, John Lightsey <lightsey [...] debian.org>, Todd Rinaldo <toddr [...] cpan.org>
From: Dominic Hargreaves <dom [...] earth.li>
Date: Thu, 25 Aug 2016 10:57:19 +0100
Download (untitled) / with headers
text/plain 1.8k
On Thu, Aug 25, 2016 at 10:32:20AM +0200, Sawyer X wrote: Show quoted text
> I know I had written about merging it earlier this week, but this was > delayed in order to consider both the position of more people, and the > option of reverting the patch from base.pm entirely, leaving it > untouched. > > I wanted to ask, and please do find the time to reply, if anyone > objects simply leaving base.pm untouched? > (I had wanted to write it on the list as well, but I would first like > comments from people working on it here). > > Todd is in favor of this, read here: > http://nntp.perl.org/group/perl.perl5.porters/239295
The reason that I think I spoke up for its inclusion originally was that we had a known vulnerability triggered by the 'use base' issue: Quoth I :-- "We had a specific query about base.pm. This was, I understand, deliberately left unfixed in Tony's patchset, however we have a known vulnerability (if "only" in a development tool, and not the worse case where chdir /tmp is involved) in a Debian specific package perl -MSbuild::Exception. This turns out to be via lib/Exception/Class.pm:use base qw($isa); Given this, should the decision to leave base.pm alone be reviewed? I'm not sure about the impact of changing it. (Alternatively, presumably Exception::Class could be patched, but that feels like patching around the problem)." Can someone suggest a fix that could be applied to Exception::Class instead? The other thing I can offer is an observation that the problematic base.pm patch has been included in Debian stable for some weeks now and the only documented issue has been this one from Chris Travers: <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=833030>. This isn't to say that things don't need to be improved, of course, but if the patch is reverted entirely then Debian will need to decide whether to follow suit or not... Thanks, Dominic.
From: John Lightsey <lightsey [...] debian.org>
CC: Niko Tyni <ntyni [...] debian.org>, Sawyer X via RT <perl5-security-report [...] perl.org>, Salvatore Bonaccorso <carnil [...] debian.org>, Florian Weimer <fw [...] deneb.enyo.de>, Todd Rinaldo <toddr [...] cpan.org>
Date: Thu, 25 Aug 2016 09:57:27 -0500
To: Dominic Hargreaves <dom [...] earth.li>, Sawyer X <xsawyerx [...] gmail.com>
Subject: Re: [perl #127834] Flaws in Perl code due to unsafe module load path
Download (untitled) / with headers
text/plain 2.1k
On Thu, 2016-08-25 at 10:57 +0100, Dominic Hargreaves wrote: Show quoted text
> On Thu, Aug 25, 2016 at 10:32:20AM +0200, Sawyer X wrote:
> > Todd is in favor of this, read here: > > http://nntp.perl.org/group/perl.perl5.porters/239295
> > The reason that I think I spoke up for its inclusion originally was that > we had a known vulnerability triggered by the 'use base' issue: > > Quoth I :-- > > "We had a specific query about base.pm. This was, I understand, > deliberately left unfixed in Tony's patchset, however we have a known > vulnerability (if "only" in a development tool, and not the worse case > where chdir /tmp is involved) in a Debian specific package > perl -MSbuild::Exception. This turns out to be via > lib/Exception/Class.pm:use base qw($isa); > > Given this, should the decision to leave base.pm alone be reviewed? > I'm not sure about the impact of changing it. (Alternatively, > presumably Exception::Class could be patched, but that feels like > patching around the problem)." > > Can someone suggest a fix that could be applied to Exception::Class > instead? >
I'll unpatch base.pm on my Debian test system, see which scripts flip from the "fixed" column back to the "broken" column, and see what can be done to fix them in a more direct fashion. Show quoted text
> The other thing I can offer is an observation that the problematic  > base.pm patch has been included in Debian stable for some weeks now and > the only documented issue has been this one from Chris Travers: > <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=833030>. This isn't > to say that things don't need to be improved, of course, but if the patch > is reverted entirely then Debian will need to decide whether to follow > suit or not... > 
We also ran into problems with the base.pm change when it was applied to the older versions of cPanel that didn't have the USE_UNSAFE_INC patches. The problems were trivial to work around, but changing base.pm did cause some obscure regressions for us. IMHO, it seems better to not change base.pm in hindsight. It's the only part of the changeset that seems to be generating complaints, and it had less of an effect in "fixing" scripts than most of the other module changes.
Download signature.asc
application/pgp-signature 801b

Message body not shown because it is not plain text.

To: Dominic Hargreaves <dom [...] earth.li>, Sawyer X <xsawyerx [...] gmail.com>
Subject: Re: [perl #127834] Flaws in Perl code due to unsafe module load path
Date: Thu, 25 Aug 2016 13:17:52 -0500
From: John Lightsey <lightsey [...] debian.org>
CC: Niko Tyni <ntyni [...] debian.org>, Sawyer X via RT <perl5-security-report [...] perl.org>, Salvatore Bonaccorso <carnil [...] debian.org>, Florian Weimer <fw [...] deneb.enyo.de>, Todd Rinaldo <toddr [...] cpan.org>
Download (untitled) / with headers
text/plain 1.1k
On Thu, 2016-08-25 at 09:57 -0500, John Lightsey wrote: Show quoted text
> On Thu, 2016-08-25 at 10:57 +0100, Dominic Hargreaves wrote:
> > On Thu, Aug 25, 2016 at 10:32:20AM +0200, Sawyer X wrote: > > Can someone suggest a fix that could be applied to Exception::Class > > instead? > > 
> > I'll unpatch base.pm on my Debian test system, see which scripts flip from the > "fixed" column back to the "broken" column, and see what can be done to fix > them > in a more direct fashion.
These numbers are for a Debian stable test system with every Perl script I could realistically get installed in place. Total scripts: 1381 Fixed by initial CVE-2016-1238 updates: 398 Still problematic after initial CVE-2016-1238 updates: 103 Problematic after reverting base.pm changes: 113 So, there were 10 scripts in this set that become vulnerable again without the base.pm change. Out of those 10, only the sbuild script is vulnerable because of the "use base" line in Exception::Class. I confirmed this by adding the same "local @INC" logic to Exception::Class directly. It seems more appropriate to filter @INC in the sbuild script where there are clearly no side effects than to do so in Exception::Class.
Download signature.asc
application/pgp-signature 801b

Message body not shown because it is not plain text.

To: John Lightsey via RT <perl5-security-report [...] perl.org>
Subject: Re: [perl #127834] Flaws in Perl code due to unsafe module load path
Date: Thu, 25 Aug 2016 22:34:21 +0300
From: Niko Tyni <ntyni [...] debian.org>
CC: carnil [...] debian.org, fw [...] deneb.enyo.de, toddr [...] cpan.org, dom [...] earth.li
Download (untitled) / with headers
text/plain 1.8k
On Thu, Aug 25, 2016 at 11:18:37AM -0700, John Lightsey via RT wrote: Show quoted text
> On Thu, 2016-08-25 at 09:57 -0500, John Lightsey wrote:
> > On Thu, 2016-08-25 at 10:57 +0100, Dominic Hargreaves wrote:
> > > On Thu, Aug 25, 2016 at 10:32:20AM +0200, Sawyer X wrote: > > > Can someone suggest a fix that could be applied to Exception::Class > > > instead? > > > 
> > > > I'll unpatch base.pm on my Debian test system, see which scripts flip from the > > "fixed" column back to the "broken" column, and see what can be done to fix > > them > > in a more direct fashion.
> > These numbers are for a Debian stable test system with every Perl script I could > realistically get installed in place.
Show quoted text
> Total scripts: 1381 > Fixed by initial CVE-2016-1238 updates: 398 > Still problematic after initial CVE-2016-1238 updates: 103 > Problematic after reverting base.pm changes: 113 > > So, there were 10 scripts in this set that become vulnerable again without the > base.pm change. Out of those 10, only the sbuild script is vulnerable because of > the "use base" line in Exception::Class. I confirmed this by adding the same > "local @INC" logic to Exception::Class directly.
Thanks for testing this. Those numbers are surprisingly small, and indeed seem to support reverting the base.pm changes and filtering @INC in code that uses base.pm in an unsafe way. FWIW my quick search found two more Exception::Class "victims" outside the current stable release: /usr/bin/erlsvc (package erlsvc, only Debian testing/unstable) and /usr/bin/simba (package simba, Debian oldstable and unstable, via libropkg-perl). Show quoted text
> It seems more appropriate to filter @INC in the sbuild script where there are > clearly no side effects than to do so in Exception::Class.
That doesn't sound right to me. So not only programs using base.pm in an unsafe way need to filter @INC, but also programs (recursively) using any libraries doing that? -- Niko Tyni ntyni@debian.org
Date: Thu, 25 Aug 2016 21:03:41 -0500
From: John Lightsey <lightsey [...] debian.org>
CC: dom [...] earth.li
To: perl5-security-report [...] perl.org, carnil [...] debian.org, fw [...] deneb.enyo.de, toddr [...] cpan.org
Subject: Re: [perl #127834] Flaws in Perl code due to unsafe module load path
Download (untitled) / with headers
text/plain 1.2k
On Thu, 2016-08-25 at 12:35 -0700, Niko Tyni via RT wrote: Show quoted text
> On Thu, Aug 25, 2016 at 11:18:37AM -0700, John Lightsey via RT wrote:
> > It seems more appropriate to filter @INC in the sbuild script where there
> are
> > clearly no side effects than to do so in Exception::Class.
> > That doesn't sound right to me. So not only programs using base.pm in > an unsafe way need to filter @INC, but also programs (recursively) > using any libraries doing that?
Yes, this is why it's going to take quite a while to get rid of this problem definitively. If I write a script with Perl 5.24 and earlier that gets installed into PATH and has this behavior of searching modules relative to the current working directory, I as the script author am ultimately responsible for mitigating the risk by filtering the '.' from @INC. The filtering in modules dramatically reduce the overall number of scripts that exhibit this behavior, but filtering at the module level can't definitively fix the problem for all scripts. The changeset for this CVE follows this logic. It fixes vulnerabilities in the scripts shipped with core Perl by adding @INC filtering at the script level and additionally helps reduce the overall number of scripts outside of core Perl that have similar issues through the module changes.
Download signature.asc
application/pgp-signature 801b

Message body not shown because it is not plain text.

Date: Fri, 26 Aug 2016 17:11:01 +0100
From: Zefram <zefram [...] fysh.org>
CC: Niko Tyni <ntyni [...] debian.org>, Sawyer X via RT <perl5-security-report [...] perl.org>, Salvatore Bonaccorso <carnil [...] debian.org>, Florian Weimer <fw [...] deneb.enyo.de>, John Lightsey <lightsey [...] debian.org>, Todd Rinaldo <toddr [...] cpan.org>, Dominic Hargreaves <dom [...] earth.li>
Subject: Re: [perl #127834] Flaws in Perl code due to unsafe module load path
To: Sawyer X <xsawyerx [...] gmail.com>
Download (untitled) / with headers
text/plain 2.4k
There has been some talk on the open p5p list of removing the @INC munging from base.pm altogether, leaving it as it was before this issue arose. I somewhat disagree with removing it per se, and I very much disagree with removing it selectively from base.pm. The open discussion has pointed out -- as did I early in this closed discussion -- that the top-level program is the *right* place to fix @INC. We should certainly add fixes at top level for programs that we know are affected. To fix only there would be a coherent position. However, in this closed discussion we quite reasonably reached the conclusion that these direct fixes wouldn't reach sufficiently many affected programs. To munge @INC in modules that perform optional module loading is a practical measure, in order to fix most DarkPAN programs as well. The case for this munging stands; the inconvenience of having @INC frobbed in the wrong place is justified by the substantial security gain. As for base.pm versus other optional-loading modules, it is crazy to treat base.pm as an exception, particularly in this direction. base.pm causes especially many vulnerabilities, for a wider range of module names, and with less opportunity to mitigate the risk by installing optional modules. base.pm should certainly not be made less cautious than other optional-loading modules; if there is to be any distinction between optional-loading modules then base.pm should be *more* cautious than most. It would be most sensible for us to treat them all the same, putting the same @INC munging (or none) into all modules that perform optional module loading. As for the form of @INC munging, I definitely prefer Ribasushi's concept over a straight "local @INC". Having pondered the conditional dot restoration logic a bit, I think the dot should initially be removed unless there's more than one dot at the end of @INC, and then for restoration the dot should be re-appended unless there is now a dot at the end. The position this takes is that any @INC entry can be changed by a module, and the dot still be restored, but restoration mustn't take us to a double-dot situation that would defeat later dot removal. The double-dot condition on removing the dot is then to avoid a dot removal that would be ineffective and (by suppressing restoration) break the localisation of the munging. This munging logic is a bit much to replicate between all modules that need it. We should try to factor it out somewhere. -zefram
Subject: Re: [perl #127834] Flaws in Perl code due to unsafe module load path
From: Sawyer X <xsawyerx [...] gmail.com>
CC: Niko Tyni <ntyni [...] debian.org>, Sawyer X via RT <perl5-security-report [...] perl.org>, Salvatore Bonaccorso <carnil [...] debian.org>, Florian Weimer <fw [...] deneb.enyo.de>, John Lightsey <lightsey [...] debian.org>, Todd Rinaldo <toddr [...] cpan.org>, Dominic Hargreaves <dom [...] earth.li>
To: Zefram <zefram [...] fysh.org>
Date: Wed, 14 Sep 2016 22:29:16 +0200
Download (untitled) / with headers
text/plain 4.1k
This has been waiting for a long while. Far too long. First, Zefram, I appreciate your comments here. Secondly, it took a long time because I had many off-list conversations with various people to understand the objection to this change on one hand and the objection to avoiding this change on the other. I would like to provide Aristotle's comments below on this matter, with his approval, in case anyone would like to address them. In such a case, I suggest adding Aristotle to this conversation directly, as passing everything through me with notes is highly ineffective. If there are no further comments to be made, I am content with moving forward using Aristotle's published patch within a few days at the most. Aristotle's comments on the matter: The problem is that base.pm is broken by design. It is about setting @ISA, but as a convenience it will try to load a module of the same name for you on the off chance you needed it, which means that any use base 'Some::Internal::Package::BaseClass' that wasn’t intended to load anything can be weaponised by someone creating a file with the right name in @ISA. That’s the issue that base.pm has above and beyond the issues that apply to any use of `require` or any other module loader. [The] problem is that the base.pm interface has no way of distinguishing “I’m just using this as sugar for setting @ISA and am not looking to load any module”, “I am using this for an optional dependency” and “this is a module which I expect to be installed and which I definitely need loaded”, so you can’t target any fixes very well. I expect massive fallout from removing . from @INC but there’s no alternative to that, only managing it well or managing it badly, but patching base.pm is likely to not be pretty either, just on a smaller scaler, but seems to me like it makes the behaviour of the system far less easy to reason about in edge cases, unlike removing . from @INC which at least is a simple straightforward change. Thing is, if . is not in @INC in the first place, then base.pm is no more or less susceptible than anything else. and . removal is inevitable. so base.pm being what it is will resolve itself in due time. (Nevertheless – it should be discouraged. or at least large caveats painted on its POD. a few people who really do want optional dependencies have legitimate use for base.pm as it is, everyone else should steer clear). No one is arguing to ship . removal in a point release. so why is base.pm OK? fine… it’s less breakage. but it’s also less fixage. It’s obvious that removing . from @INC is necessary but will break so much stuff that we can’t do it in a point release even though it’s the basis for a security hole affecting everyone who uses a certain kind of perl program. Patching base.pm is problematic in the exact same way, just on a smaller scale, but also with correspondingly less payoff. Please don’t forget I have two concerns: not just the risk from breaking stuff, but taking on the debt of complexity of introducing conditional cases to the system’s behaviour. Will we revert the base.pm changes once . is gone from @INC? That’s what I worried I was going to hear. So in the future when . is gone from @INC if the user pushes it there explicitly then base.pm will override their decision… but on old perls it will do something else. ([That's] what I meant by debt of complexity.) We could version-guard it or something but that just increases the number of conditional cases in a different way, yet again. The only real answer [to dealing with this] is “compile perl with sitecustomize and use that to kick . out of @INC”. The answer for a vendor turns into an answer for a user by way of “get package upgrade from your vendor”. It’s also an answer for perlbrew people etc. Ribasushi’s patch with my modification is the least intrusive change I can think of. [Zefram's comments] seem to miss the use case of a module loaded (maybe indirectly) through base.pm pushing a hook to the end of @INC. The scope guard shouldn’t drop a . *behind* such a hook. Any comments or should we move forward with the "least intrusive change"?
CC: Niko Tyni <ntyni [...] debian.org>, Salvatore Bonaccorso <carnil [...] debian.org>, Florian Weimer <fw [...] deneb.enyo.de>, John Lightsey <lightsey [...] debian.org>, Todd Rinaldo <toddr [...] cpan.org>, Dominic Hargreaves <dom [...] earth.li>
From: Zefram <zefram [...] fysh.org>
Subject: Re: [perl #127834] Flaws in Perl code due to unsafe module load path
To: perl5-security-report [...] perl.org
Date: Thu, 15 Sep 2016 10:31:23 +0100
Download (untitled) / with headers
text/plain 5.3k
Show quoted text
>Aristotle's comments on the matter:
... Show quoted text
> [The] problem is that the base.pm interface has no way of >distinguishing "I'm just using this as sugar for setting @ISA and am >not looking to load any module", "I am using this for an optional >dependency" and "this is a module which I expect to be installed and >which I definitely need loaded",
As I suggested much earlier, we can fix this in the long run by adding "-require" and "-norequire" flags to base.pm's import interface, and deprecating using it without a flag. We should do this. But of course it doesn't make our immediate situation any easier. Show quoted text
> Will we revert the base.pm changes once . is gone from @INC?
I would not expect us to revert any of the changes that implement temporary . removal for optional module loading. They'll still be in use on older perls. But they would do nothing in the cases where "." is not on the end of @INC. Show quoted text
> if the user pushes it there explicitly then base.pm >will override their decision
If the user deliberately puts "." into @INC, it would normally go at the beginning of @INC, where the temporary removal won't touch it. In the rare case that the user wants to put "." at the end of @INC, then indeed there is a clash with the temporary removal changes. Not specifically with base.pm, but with all of them. Given that this problem inevitably arises on perl versions that do put an implicit "." in @INC, we would gain very little by trying to avoid it on other versions. Any perl-version-dependent logic here would just be greater complexity and so greater scope to make a security-damaging mistake. I think we must accept that any user-supplied "." to go on the end of @INC will have to be spelled "./." or some such. Show quoted text
> [Zefram's comments] seem to miss the use case of a module loaded >(maybe indirectly) through base.pm pushing a hook to the end of @INC. >The scope guard shouldn't drop a . *behind* such a hook.
This seems so speculative that it's not clear what the intent would be. It would be not just a module that adds onto the end of @INC, but one that's liable to be invoked from somewhere other than the program's top level. Do you have a concrete example of this kind of interaction, from which we could discern some actual intent? We essentially want the "."-restoring logic to guess what the @INC-modifying module would have done had the "." been there when it made its modification. If it would add its hook to the end of @INC unconditionally, which at first glance seems most likely because it is the simplest behaviour, then to honour that intent the "." restoration ought to insert the "." before the hook. But that would mean that the "." is now not recognisable as the implicit one, so it won't be temporarily removed for later optional module loads, opening a security hole. But not only would restoring "." there cause this problem, so would the notional module unconditionally adding its hook at the end of @INC when there's a "." there. So a more sensible behaviour for the hook-adding module would actually be to detect the implicit "." at the end of @INC and insert its hook before the ".". Given this security-conscious behaviour of the hook-adding module, where the module has operated with the "." temporarily removed it is after all correct for the "." restorer to re-add the "." right on the end. For the Ribasushi/Aristotle behaviour, of not restoring the "." if $INC[-1] has changed, to be correct, it implies that the hook-adding module would have *replaced* the implicit "." if it found one there. This seems most unlikely. What the hook-adding module would really do depends on the purpose of the hook. Does its ordering relative to the "." matter for its purposes? Discerning the intent is not just a difficulty for us thinking about it now, it's a problem that in some form we delegate to the "."-restoring code. To always discern correctly is not possible; some amount of bad interaction is inevitable. I still prefer my proposed semantics, of unconditionally restoring the "." onto the end of @INC. It is especially inevitable to have a bad interaction with any module that would put a hook after the implicit ".". If such a module is invoked outside an optional-load context, so that it sees the @INC complete with ".", then by adding its hook after the "." it would break the recognition of the implicit "." in order to temporarily remove it for later optional module loads. If there is such a module, that's a security problem in itself that we ought to fix as part of this. Hypothetically, if the module actually needs its hook to come after the implicit "." for its own purposes, then that's a really difficult problem that confounds our simple fix. Show quoted text
>Any comments or should we move forward with the "least intrusive change"?
In addition to the above, Aristotle's comments don't make the case for base.pm to have different "."-handling behaviour from other modules that perform optional module loading. His comments are almost exclusively concerned with base.pm, and never address the question of what other optional-loading modules should do. He did make the point, supporting my position, that base.pm is doing basically the same thing as other optional module loads. Also the point that base.pm is especially often vulnerable, which echoes my argument against removing its @INC munging entirely. I still reckon that the same fix should be applied to all optional-loading modules. -zefram
RT-Send-CC: rt-deliver-to-perl5-security-report [...] rt.perl.org
Download (untitled) / with headers
text/plain 904b
On Fri Aug 12 14:00:49 2016, xsawyerx@cpan.org wrote: Show quoted text
> Hi, everyone. > > Peter Rabbitson provided a different workaround for base.pm: > https://github.com/Perl/perl5/pull/10.
There's one obvious error in the patch: + push @INC, '.' + if $localized_tail eq $INC[-1]||''; presumably the: $INC[-1]||'' is intended to prevent the code from warning when @INC is empty, but this groups like: if ( ( $localized_tail eq $INC[-1] ) || '' ); making the C< || '' > useless. I'm not sure the condition itself (assuming correct grouping) makes sense, Zefram's suggestion is probably better, always put the dot back unless we found new dot at the end. Even this is just guessing the user's intent, and we're unlikely to succeed in every case (and break things in new, more complex ways) I don't have an opinion either way on applying this change. Tony
Subject: Re: [perl #127834] Flaws in Perl code due to unsafe module load path
From: Sawyer X <xsawyerx [...] gmail.com>
CC: rt-deliver-to-perl5-security-report [...] rt.perl.org
To: Perl 5 Security Report <perl5-security-report [...] perl.org>
Date: Thu, 15 Sep 2016 13:57:24 +0200
Download (untitled) / with headers
text/plain 285b
[top-posted] Zefram, Tony, thank you for your prompt responses! I know it's really exhausting at this point. If there are no objections, I would like to add Aristotle to this thread so we can reach a conclusion by end of week. If you object, you can let me know privately. Thanks.
Subject: Re: [perl #127834] Flaws in Perl code due to unsafe module load path
CC: Niko Tyni <ntyni [...] debian.org>, Salvatore Bonaccorso <carnil [...] debian.org>, Florian Weimer <fw [...] deneb.enyo.de>, John Lightsey <lightsey [...] debian.org>, Todd Rinaldo <toddr [...] cpan.org>, Dominic Hargreaves <dom [...] earth.li>
From: Zefram <zefram [...] fysh.org>
Date: Thu, 15 Sep 2016 18:12:31 +0100
To: perl5-security-report [...] perl.org
Download (untitled) / with headers
text/plain 464b
I wrote: Show quoted text
>I still prefer my proposed semantics, of unconditionally restoring the >"." onto the end of @INC.
Sorry, this is a bit unclear. My proposal wasn't of entirely unconditional appending of "."; it was that the "." should be re-appended unless there is now a "." at the end. So what it always restores is the fact that there is a "." at the end. I am endorsing that proposal that I made; I do not advocate entirely unconditional "." appending. -zefram
Subject: Re: [perl #127834] Flaws in Perl code due to unsafe module load path
From: Sawyer X <xsawyerx [...] gmail.com>
CC: Perl 5 Security Report <perl5-security-report [...] perl.org>, Niko Tyni <ntyni [...] debian.org>, Salvatore Bonaccorso <carnil [...] debian.org>, Florian Weimer <fw [...] deneb.enyo.de>, John Lightsey <lightsey [...] debian.org>, Todd Rinaldo <toddr [...] cpan.org>, Dominic Hargreaves <dom [...] earth.li>, Aristotle Pagaltzis <pagaltzis [...] gmx.de>
Date: Fri, 16 Sep 2016 15:30:26 +0200
To: Zefram <zefram [...] fysh.org>
Download (untitled) / with headers
text/plain 675b
I've added Aristotle to this ticket, both on RT and as CC, just to double check. Aristotle, Zefram and Tony provided updates. There are several responses to your recent feedback. If you could review those and respond, it will be greatly appreciated. I want to note that I do not want this to start a bike-shedding thread. We're all pretty much exhausted by this (security personnel reporting and testing, Tony working on applying the patches, Zefram in reviewing, etc.). To make it clear, my position is that we should patch base.pm as well. However, we would like to make this the least problematic one, and that's what's discussed here. Let's focus on that. Thank you.
Subject: Re: [perl #127834] Flaws in Perl code due to unsafe module load path
From: Leon Timmermans <fawaka [...] gmail.com>
CC: Sawyer X <xsawyerx [...] gmail.com>, Niko Tyni <ntyni [...] debian.org>, Sawyer X via RT <perl5-security-report [...] perl.org>, Salvatore Bonaccorso <carnil [...] debian.org>, Florian Weimer <fw [...] deneb.enyo.de>, John Lightsey <lightsey [...] debian.org>, Todd Rinaldo <toddr [...] cpan.org>, Dominic Hargreaves <dom [...] earth.li>
To: Zefram <zefram [...] fysh.org>
Date: Fri, 16 Sep 2016 15:50:57 +0200
On Fri, Aug 26, 2016 at 7:11 PM, Zefram <zefram@fysh.org> wrote:
Show quoted text
As for base.pm versus other optional-loading modules, it is crazy
to treat base.pm as an exception, particularly in this direction.
base.pm causes especially many vulnerabilities, for a wider range of
module names, and with less opportunity to mitigate the risk by installing
optional modules.  base.pm should certainly not be made less cautious
than other optional-loading modules; if there is to be any distinction
between optional-loading modules then base.pm should be *more* cautious
than most.  It would be most sensible for us to treat them all the same,
putting the same @INC munging (or none) into all modules that perform
optional module loading.

base.pm is unique in meaning "maybe the loading is meant optional, maybe it wasn't". If it can't know if there's optional loading involved or not, it's by definition not the right position to make such a decision, so the thing that's calling it should.

Not saying it's the easy way to deal with the issue, but anything else is simply incorrect.

Leon


Subject: Re: [perl #127834] Flaws in Perl code due to unsafe module load path
CC: "perl5-security-report [...] perl.org" <perl5-security-report [...] perl.org>, Niko Tyni <ntyni [...] debian.org>, Salvatore Bonaccorso <carnil [...] debian.org>, Florian Weimer <fw [...] deneb.enyo.de>, John Lightsey <lightsey [...] debian.org>, Todd Rinaldo <toddr [...] cpan.org>, Dominic Hargreaves <dom [...] earth.li>
From: Leon Timmermans <fawaka [...] gmail.com>
To: Zefram <zefram [...] fysh.org>
Date: Fri, 16 Sep 2016 16:03:24 +0200
Download (untitled) / with headers
text/plain 1.1k
On Thu, Sep 15, 2016 at 11:31 AM, Zefram <zefram@fysh.org> wrote:
Show quoted text
>    [The] problem is that the base.pm interface has no way of
>distinguishing "I'm just using this as sugar for setting @ISA and am
>not looking to load any module", "I am using this for an optional
>dependency" and "this is a module which I expect to be installed and
>which I definitely need loaded",

As I suggested much earlier, we can fix this in the long run by adding
"-require" and "-norequire" flags to base.pm's import interface, and
deprecating using it without a flag.  We should do this.  But of course
it doesn't make our immediate situation any easier.

How the hell is this a realistic option?

base.pm is terrible in a lot of ways, but it's one attractive feature is its backwards compatibility. The thing is worth absolutely nothing if you break the compatibility with every use of it anywhere, and given how frequently base is used that anywhere really means everywhere.

This is not an option. It simply isn't. Pretending it is means deluding ourselves. This thing you're describing is not base.pm by any stretch of the imagination.

Leon

To: Leon Timmermans <fawaka [...] gmail.com>
Date: Fri, 16 Sep 2016 15:10:49 +0100
From: Zefram <zefram [...] fysh.org>
CC: "perl5-security-report [...] perl.org" <perl5-security-report [...] perl.org>, Niko Tyni <ntyni [...] debian.org>, Salvatore Bonaccorso <carnil [...] debian.org>, Florian Weimer <fw [...] deneb.enyo.de>, John Lightsey <lightsey [...] debian.org>, Todd Rinaldo <toddr [...] cpan.org>, Dominic Hargreaves <dom [...] earth.li>
Subject: Re: [perl #127834] Flaws in Perl code due to unsafe module load path
Download (untitled) / with headers
text/plain 212b
Leon Timmermans wrote: Show quoted text
> The thing is worth absolutely nothing if you >break the compatibility with every use of it anywhere,
I did say "deprecate", not "remove instantly". -zefram
From: Todd Rinaldo <toddr [...] cpanel.net>
CC: Salvatore Bonaccorso <carnil [...] debian.org>, Florian Weimer <fw [...] deneb.enyo.de>, John Lightsey <lightsey [...] debian.org>, Todd Rinaldo <toddr [...] cpan.org>, Dominic Hargreaves <dom [...] earth.li>, Niko Tyni <ntyni [...] debian.org>, Aristotle Pagaltzis <pagaltzis [...] gmx.de>
Subject: Re: [perl #127834] Flaws in Perl code due to unsafe module load path
To: Steve Hay via RT <perl5-security-report [...] perl.org>
Date: Fri, 16 Sep 2016 12:30:32 -0500
Download (untitled) / with headers
text/plain 1.6k
Show quoted text
> On Sep 16, 2016, at 9:04 AM, Leon Timmermans via RT <perl5-security-report@perl.org> wrote: > > On Thu, Sep 15, 2016 at 11:31 AM, Zefram <zefram@fysh.org> wrote: >
>>> [The] problem is that the base.pm interface has no way of >>> distinguishing "I'm just using this as sugar for setting @ISA and am >>> not looking to load any module", "I am using this for an optional >>> dependency" and "this is a module which I expect to be installed and >>> which I definitely need loaded",
>> >> As I suggested much earlier, we can fix this in the long run by adding >> "-require" and "-norequire" flags to base.pm's import interface, and >> deprecating using it without a flag. We should do this. But of course >> it doesn't make our immediate situation any easier. >>
> > How the hell is this a realistic option? > > base.pm is terrible in a lot of ways, but it's one attractive feature is > its backwards compatibility. The thing is worth absolutely nothing if you > break the compatibility with every use of it anywhere, and given how > frequently base is used that anywhere really means everywhere. > > This is not an option. It simply isn't. Pretending it is means deluding > ourselves. This thing you're describing is not base.pm by any stretch of > the imagination. > > Leon >
For starters, isn't base deprecated already in favor of parent? Second, if anyone has a proposed solution could you please provide it to this email list? Ideally I'd like to see your proposal on top of maint-5.24 along with the output from: `git diff v5.24.0..maint-5.24-with-my-patch dist/base/lib/base.pm` I think this might make it easier for others to participate. Thanks, Todd
To: Zefram <zefram [...] fysh.org>
Date: Fri, 16 Sep 2016 23:03:01 +0200
From: Leon Timmermans <fawaka [...] gmail.com>
CC: "perl5-security-report [...] perl.org" <perl5-security-report [...] perl.org>, Niko Tyni <ntyni [...] debian.org>, Salvatore Bonaccorso <carnil [...] debian.org>, Florian Weimer <fw [...] deneb.enyo.de>, John Lightsey <lightsey [...] debian.org>, Todd Rinaldo <toddr [...] cpan.org>, Dominic Hargreaves <dom [...] earth.li>
Subject: Re: [perl #127834] Flaws in Perl code due to unsafe module load path
Download (untitled) / with headers
text/plain 720b
On Fri, Sep 16, 2016 at 4:10 PM, Zefram <zefram@fysh.org> wrote:
Show quoted text
Leon Timmermans wrote:
>                             The thing is worth absolutely nothing if you
>break the compatibility with every use of it anywhere,

I did say "deprecate", not "remove instantly".

Even "remove ever" is not a realistic option, given it would break almost two decades of common use. Even making it warn when doing things the "old" way sounds incredibly end-user hostile to me.

The thing you described is pretty much identical to parent.pm anyway. Not that either solves any problem, because the security issue is in the use-cases that can't be converted to parent: the use-cases where optional loading is intended.

Leon

To: Leon Timmermans <fawaka [...] gmail.com>
Date: Fri, 16 Sep 2016 21:22:24 -0500
Subject: Re: [perl #127834] Flaws in Perl code due to unsafe module load path
CC: Zefram <zefram [...] fysh.org>, "perl5-security-report [...] perl.org" <perl5-security-report [...] perl.org>, Niko Tyni <ntyni [...] debian.org>, Salvatore Bonaccorso <carnil [...] debian.org>, Florian Weimer <fw [...] deneb.enyo.de>, John Lightsey <lightsey [...] debian.org>, Todd Rinaldo <toddr [...] cpan.org>, Dominic Hargreaves <dom [...] earth.li>
From: "Craig A. Berry" <craig.a.berry [...] gmail.com>
Download (untitled) / with headers
text/plain 1.1k
On Fri, Sep 16, 2016 at 4:03 PM, Leon Timmermans <fawaka@gmail.com> wrote: Show quoted text
> On Fri, Sep 16, 2016 at 4:10 PM, Zefram <zefram@fysh.org> wrote:
Show quoted text
>> I did say "deprecate", not "remove instantly".
> > > Even "remove ever" is not a realistic option,
Why is there a discussion of "remove ever" *now* after Sawyer specifically requested people to focus on the best (or least worst?) patch that can let us ship a maint release. We've been sitting on 5.24.1-RC3 for five weeks. Per Todd's question, from the discussion at: <http://www.nntp.perl.org/group/perl.perl5.porters/2016/08/msg238991.html> I don't even see a latest, greatest patch. That thread trails off with suggested revisions to Rabbitson's patch that as far as I can see have not resulted in a revised patch. Sorry to be grumpy, but it's the only thing I'm qualified to do. I've never looked at the base.pm code and have only the vaguest notion what it does. As far as I can tell, the executive summary of all the discussions to date is that any changes to it are likely to break something, but not providing any mitigations to its security flaws when there is a dot in @INC is irresponsible. Given that, what is an acceptable compromise?
To: "Craig A. Berry" <craig.a.berry [...] gmail.com>
Date: Tue, 20 Sep 2016 00:03:02 -0500
CC: Leon Timmermans <fawaka [...] gmail.com>, Zefram <zefram [...] fysh.org>, "perl5-security-report [...] perl.org" <perl5-security-report [...] perl.org>, Niko Tyni <ntyni [...] debian.org>, Salvatore Bonaccorso <carnil [...] debian.org>, Florian Weimer <fw [...] deneb.enyo.de>, Todd Rinaldo <toddr [...] cpan.org>, Dominic Hargreaves <dom [...] earth.li>
From: John Lightsey <lightsey [...] debian.org>
Subject: Re: [perl #127834] Flaws in Perl code due to unsafe module load path
Download (untitled) / with headers
text/plain 1.7k
On Fri, 2016-09-16 at 21:22 -0500, Craig A. Berry wrote: Show quoted text
> Per Todd's question, from the discussion at: > > <http://www.nntp.perl.org/group/perl.perl5.porters/2016/08/msg238991.html> > > I don't even see a latest, greatest patch. That thread trails off > with suggested revisions to Rabbitson's patch that as far as I can see > have not resulted in a revised patch. > > Sorry to be grumpy, but it's the only thing I'm qualified to do. I've > never looked at the base.pm code and have only the vaguest notion what > it does. As far as I can tell, the executive summary of all the > discussions to date is that any changes to it are likely to break > something, but not providing any mitigations to its security flaws > when there is a dot in @INC is irresponsible. Given that, what is an > acceptable compromise?
I'm also in favor of removing the patch from base.pm and just moving on with this. The main point of these RT127834 is that scripts are responsible for sanitizing @INC and that P5P updated all of the scripts it ships for that purpose. All of the module changes are secondary to this and just limit the scope of the problem for scripts outside of P5P's control. It makes little sense to patch base.pm if it's so contentious and causes regressions. The last time I tested this, I got these numbers... Total scripts: 1381 Initially vulnerable: 501 Fixed by initial CVE-2016-1238 updates: 398 Still problematic after initial CVE-2016-1238 updates: 103 Problematic after reverting base.pm changes: 113 So, 10 scripts become vulnerable again on this test system if you switch base.pm back. In the grand scheme of things that seems like a very small number. If you factor in the regressions that switching base.pm causes, the tradeoff just doesn't seem worth it to me.
Download signature.asc
application/pgp-signature 819b

Message body not shown because it is not plain text.

CC: "Craig A. Berry" <craig.a.berry [...] gmail.com>, Leon Timmermans <fawaka [...] gmail.com>, Zefram <zefram [...] fysh.org>, "perl5-security-report [...] perl.org" <perl5-security-report [...] perl.org>, Niko Tyni <ntyni [...] debian.org>, Salvatore Bonaccorso <carnil [...] debian.org>, Florian Weimer <fw [...] deneb.enyo.de>, Todd Rinaldo <toddr [...] cpan.org>, Dominic Hargreaves <dom [...] earth.li>
From: Sawyer X <xsawyerx [...] gmail.com>
Subject: Re: [perl #127834] Flaws in Perl code due to unsafe module load path
To: John Lightsey <lightsey [...] debian.org>
Date: Mon, 26 Sep 2016 19:41:47 +0200
Download (untitled) / with headers
text/plain 3.3k
This is our weekly ping on this topic. :) On Tue, Sep 20, 2016 at 7:03 AM, John Lightsey <lightsey@debian.org> wrote: Show quoted text
> > On Fri, 2016-09-16 at 21:22 -0500, Craig A. Berry wrote: >
> > Per Todd's question, from the discussion at: > > > > <http://www.nntp.perl.org/group/perl.perl5.porters/2016/08/msg238991.html> > > > > I don't even see a latest, greatest patch. That thread trails off > > with suggested revisions to Rabbitson's patch that as far as I can see > > have not resulted in a revised patch. > > > > Sorry to be grumpy, but it's the only thing I'm qualified to do. I've > > never looked at the base.pm code and have only the vaguest notion what > > it does. As far as I can tell, the executive summary of all the > > discussions to date is that any changes to it are likely to break > > something, but not providing any mitigations to its security flaws > > when there is a dot in @INC is irresponsible. Given that, what is an > > acceptable compromise?
> > I'm also in favor of removing the patch from base.pm and just moving on > with this. > > > The main point of these RT127834 is that scripts are responsible for > sanitizing @INC and that P5P updated all of the scripts it ships for > that purpose. > > All of the module changes are secondary to this and just limit the scope > of the problem for scripts outside of P5P's control. It makes little > sense to patch base.pm if it's so contentious and causes regressions. > > The last time I tested this, I got these numbers... > > Total scripts: 1381 > Initially vulnerable: 501 > Fixed by initial CVE-2016-1238 updates: 398 > Still problematic after initial CVE-2016-1238 updates: 103 > Problematic after reverting base.pm changes: 113 > > So, 10 scripts become vulnerable again on this test system if you switch > base.pm back. In the grand scheme of things that seems like a very small > number. If you factor in the regressions that switching base.pm causes, > the tradeoff just doesn't seem worth it to me.
I think we have multiple considerations here and I don't think that in the long run reverting any patch to base.pm will be beneficial. At the end of the day we have a module here that provides a way for others to exploit a problem the user is not aware of. We already patched our code but also consider it crucial enough to patch modules that are provided in core. If we consider the issue this important, we should be consider base.pm *at least* as important. From a conversation I've had with John off the list I would like to highlight parts he has written (with this permission): * "I view these changes as just step number 12 of 97 to get things fully cleaned up. * "The discussion about base.pm seems to be holding up progress where it really should be happening." I have to agree. The conclusion I reached, then, isn't "Let's just revert it and deal with this later", but instead "Let's move forward on this". Someone had mentioned to me off the list that there is a less intrusive solution to this than the Ribasushi-Aristotle patch. If that exists, I would like to see it. Otherwise, as far as I can tell, we're entering the area of "some people might experience breakage due to providing security to people who are likely unaware that their programs are compromisable". This is breakage I'm willing to defend and I think it is reasonable. It was reasonable enough for us to agree on patching modules in core and not just the applications provided with core.
Date: Mon, 26 Sep 2016 14:06:24 -0500
To: Sawyer X <xsawyerx [...] gmail.com>
Subject: Re: [perl #127834] Flaws in Perl code due to unsafe module load path
CC: John Lightsey <lightsey [...] debian.org>, "Craig A. Berry" <craig.a.berry [...] gmail.com>, Leon Timmermans <fawaka [...] gmail.com>, Zefram <zefram [...] fysh.org>, "perl5-security-report [...] perl.org" <perl5-security-report [...] perl.org>, Niko Tyni <ntyni [...] debian.org>, Salvatore Bonaccorso <carnil [...] debian.org>, Florian Weimer <fw [...] deneb.enyo.de>, Todd Rinaldo <toddr [...] cpan.org>, Dominic Hargreaves <dom [...] earth.li>
From: Todd Rinaldo <toddr [...] cpanel.net>
Download (untitled) / with headers
text/plain 4.2k
Show quoted text
> On Sep 26, 2016, at 12:41 PM, Sawyer X <xsawyerx@gmail.com> wrote: > > This is our weekly ping on this topic. :) > > On Tue, Sep 20, 2016 at 7:03 AM, John Lightsey <lightsey@debian.org> wrote:
>> >> On Fri, 2016-09-16 at 21:22 -0500, Craig A. Berry wrote: >>
>>> Per Todd's question, from the discussion at: >>> >>> <http://www.nntp.perl.org/group/perl.perl5.porters/2016/08/msg238991.html> >>> >>> I don't even see a latest, greatest patch. That thread trails off >>> with suggested revisions to Rabbitson's patch that as far as I can see >>> have not resulted in a revised patch. >>> >>> Sorry to be grumpy, but it's the only thing I'm qualified to do. I've >>> never looked at the base.pm code and have only the vaguest notion what >>> it does. As far as I can tell, the executive summary of all the >>> discussions to date is that any changes to it are likely to break >>> something, but not providing any mitigations to its security flaws >>> when there is a dot in @INC is irresponsible. Given that, what is an >>> acceptable compromise?
>> >> I'm also in favor of removing the patch from base.pm and just moving on >> with this. >> >> >> The main point of these RT127834 is that scripts are responsible for >> sanitizing @INC and that P5P updated all of the scripts it ships for >> that purpose. >> >> All of the module changes are secondary to this and just limit the scope >> of the problem for scripts outside of P5P's control. It makes little >> sense to patch base.pm if it's so contentious and causes regressions. >> >> The last time I tested this, I got these numbers... >> >> Total scripts: 1381 >> Initially vulnerable: 501 >> Fixed by initial CVE-2016-1238 updates: 398 >> Still problematic after initial CVE-2016-1238 updates: 103 >> Problematic after reverting base.pm changes: 113 >> >> So, 10 scripts become vulnerable again on this test system if you switch >> base.pm back. In the grand scheme of things that seems like a very small >> number. If you factor in the regressions that switching base.pm causes, >> the tradeoff just doesn't seem worth it to me.
> > > I think we have multiple considerations here and I don't think that in > the long run reverting any patch to base.pm will be beneficial. > > At the end of the day we have a module here that provides a way for > others to exploit a problem the user is not aware of. We already > patched our code but also consider it crucial enough to patch modules > that are provided in core. If we consider the issue this important, we > should be consider base.pm *at least* as important.
I disagree on the base.pm front. The other patches to the modules were to mitigate as much as we could without causing side effects. In the statement you sent out, you stated that ultimately the responsibility was to the script writer. base.pm is the only module change that makes changes not termed as appropriate for a maintenance release. I am very pretty concerned that we're changing the API in this way. Would you be open to a vote on patching or not patching base? This might move things along. A speak now or forever hold your peace sorta thing. If the vote is to patch to base.pm, I can live with it too if it progresses things. We will just patch it back off in our distro and I bet others will do the same. I would also suggest you be prepared for the discussion if/when blead removes . from INC about us taking the patch to base.pm back out (Yes I'm aware base is dual life). Show quoted text
> Someone had mentioned to me off the list that there is a less > intrusive solution to this than the Ribasushi-Aristotle patch. If that > exists, I would like to see it. Otherwise, as far as I can tell, we're > entering the area of "some people might experience breakage due to > providing security to people who are likely unaware that their > programs are compromisable". This is breakage I'm willing to defend > and I think it is reasonable. It was reasonable enough for us to agree > on patching modules in core and not just the applications provided > with core.
I'll re-state: I don't know how we can even discuss patches until they're provided to the list. To date the only patch I'm aware of is the one applied to maint-5.24. I think this is the root cause of this conversation stalling. Is anyone aware of another proposal they can provide to the list? Todd
Date: Mon, 26 Sep 2016 20:20:31 +0100
To: Todd Rinaldo <toddr [...] cpanel.net>
CC: Sawyer X <xsawyerx [...] gmail.com>, John Lightsey <lightsey [...] debian.org>, "Craig A. Berry" <craig.a.berry [...] gmail.com>, Leon Timmermans <fawaka [...] gmail.com>, Zefram <zefram [...] fysh.org>, "perl5-security-report [...] perl.org" <perl5-security-report [...] perl.org>, Niko Tyni <ntyni [...] debian.org>, Salvatore Bonaccorso <carnil [...] debian.org>, Florian Weimer <fw [...] deneb.enyo.de>, Todd Rinaldo <toddr [...] cpan.org>, Dominic Hargreaves <dom [...] earth.li>
From: Zefram <zefram [...] fysh.org>
Subject: Re: [perl #127834] Flaws in Perl code due to unsafe module load path
Download (untitled) / with headers
text/plain 649b
Todd Rinaldo wrote: Show quoted text
>The other patches to the modules were to mitigate as much as we could >without causing side effects.
That's not correct. We made other patches to optional-loading modules that cause side effects. Specifically, they localise @INC, the same side effect seen in base.pm. A bunch of modules get the same treatment in commit c2eec5217. Show quoted text
>base.pm is the only module change that makes changes not termed as >appropriate for a maintenance release.
Where does this idea come from? We already made the decision that localising and modifying @INC in modules, nasty as it is, was appropriate for these maintenance releases. -zefram
To: perl5-security-report [...] perl.org
Date: Mon, 26 Sep 2016 15:03:16 -0500
CC: Salvatore Bonaccorso <carnil [...] debian.org>, Florian Weimer <fw [...] deneb.enyo.de>, John Lightsey <lightsey [...] debian.org>, Todd Rinaldo <toddr [...] cpan.org>, Dominic Hargreaves <dom [...] earth.li>, Niko Tyni <ntyni [...] debian.org>, pagaltzis [...] gmx.de
From: Todd Rinaldo <toddr [...] cpanel.net>
Subject: Re: [perl #127834] Flaws in Perl code due to unsafe module load path
Download (untitled) / with headers
text/plain 1.7k

Show quoted text
On Sep 26, 2016, at 2:20 PM, Zefram via RT <perl5-security-report@perl.org> wrote:

Todd Rinaldo wrote:
The other patches to the modules were to mitigate as much as we could
without causing side effects.

That's not correct.  We made other patches to optional-loading modules
that cause side effects.  Specifically, they localise @INC, the same
side effect seen in base.pm.  A bunch of modules get the same treatment
in commit c2eec5217.

The modules loaded by the modules we have patched to my knowledge do not manipulate @INC. 

Example: Storable optionally loads Log::Agent. Our change ONLY modifies Storable during its optional load of Log::Agent. We also can determine that nothing about the load of Log::Agent manipulates @INC so it's safe to localize @INC for that load. The same goes with the rest of the changes we made to core modules.

base.pm is different in that we are not modifying an optional loader of a single module we understand. We're modifying how the interface itself behaves.

Show quoted text

base.pm is the only module change that makes changes not termed as
appropriate for a maintenance release.

Where does this idea come from?  We already made the decision that
localising and modifying @INC in modules, nasty as it is, was appropriate
for these maintenance releases.


I'm referring to:
and

Todd

To: Todd Rinaldo <toddr [...] cpanel.net>
Date: Mon, 26 Sep 2016 21:48:43 +0100
Subject: Re: [perl #127834] Flaws in Perl code due to unsafe module load path
CC: perl5-security-report [...] perl.org, Salvatore Bonaccorso <carnil [...] debian.org>, Florian Weimer <fw [...] deneb.enyo.de>, John Lightsey <lightsey [...] debian.org>, Todd Rinaldo <toddr [...] cpan.org>, Dominic Hargreaves <dom [...] earth.li>, Niko Tyni <ntyni [...] debian.org>, pagaltzis [...] gmx.de
From: Zefram <zefram [...] fysh.org>
Download (untitled) / with headers
text/plain 1.1k
Todd Rinaldo wrote: Show quoted text
>base.pm is different in that we are not modifying an optional loader >of a single module we understand.
That's an interesting distinction. I wouldn't be confident that the tree of dependencies of the specific optionally-loaded modules will always be free of @INC diddling; our understanding of specific modules generally doesn't extend to placing much of a constraint on their recursive dependencies. Still, as a practical matter, you're right that base.pm has a greater scope for such surprises. Are we aware of a specific @INC-diddling module that could reasonably be used as such a recursive dependency? It seems rude for anything to modify @INC without a direct request from the top-level script. If we don't have such an example, we can't attach much weight to base.pm's ability to optional-load a greater variety of modules. Show quoted text
>I'm referring to:
Not what I was asking about. I understand our criteria for what's suitable for a maint release. The idea whose origin is a mystery to me is that the change in base.pm (taking into account the security motivation) offends those criteria. -zefram
Date: Mon, 26 Sep 2016 17:53:45 -0500
To: Zefram <zefram [...] fysh.org>
CC: Todd Rinaldo <toddr [...] cpanel.net>, Steve Hay via RT <perl5-security-report [...] perl.org>, Salvatore Bonaccorso <carnil [...] debian.org>, Florian Weimer <fw [...] deneb.enyo.de>, John Lightsey <lightsey [...] debian.org>, Todd Rinaldo <toddr [...] cpan.org>, Dominic Hargreaves <dom [...] earth.li>, Niko Tyni <ntyni [...] debian.org>, Aristotle Pagaltzis <pagaltzis [...] gmx.de>
From: "Craig A. Berry" <craig.a.berry [...] gmail.com>
Subject: Re: [perl #127834] Flaws in Perl code due to unsafe module load path
Download (untitled) / with headers
text/plain 1.2k
On Mon, Sep 26, 2016 at 3:48 PM, Zefram <zefram@fysh.org> wrote: Show quoted text
> I understand our criteria for what's > suitable for a maint release. The idea whose origin is a mystery to me is > that the change in base.pm (taking into account the security motivation) > offends those criteria.
Perhaps the new error message added at: <http://perl5.git.perl.org/perl.git/commitdiff/bca552795994a553e07b38a6f82a233533919926> and subsequently expanded could be legalistically construed as violating the "no new errors or warnings" language in the maint policy, but it would be wrong to prefer an older more generic message that doesn't really tell people what's going on and what to do about it simply to comply with this construction of the policy. And it would be equally wrong to say we can't plug a hole because throwing an error to prevent people falling into that hole violates the "no new errors" clause of the maint policy. The policy should probably state a little more strongly that security can trump all the other rules when genuinely necessary, even binary compatibility. The NodeJS folks just broke APIs in a minor release for security reasons: <https://nodejs.org/en/blog/vulnerability/september-2016-security-releases/> Can we afford to be more lax about security than they can?
Date: Mon, 26 Sep 2016 19:07:27 -0400
Subject: Re: [perl #127834] Flaws in Perl code due to unsafe module load path
From: Jarkko Hietaniemi <jhi [...] iki.fi>
To: perl5-security-report [...] perl.org
Download (untitled) / with headers
text/plain 446b
First off, I have to admit that I haven't followed all the details, scenarios, alternatives, and suggestions. But the overall sense I am getting is that there will be breakage, whichever way we try to go with this. If this is indeed the case, how about instead of trying to minimize the breakage, how about maximizing it, now that we have to? Fix things as much as possible, now that we can? This in turn of course assumes clairvoyance.
Date: Mon, 26 Sep 2016 22:57:31 -0500
To: Aristotle Pagaltzis <pagaltzis [...] gmx.de>
From: "Craig A. Berry" <craig.a.berry [...] gmail.com>
CC: Zefram <zefram [...] fysh.org>, Todd Rinaldo <toddr [...] cpanel.net>, Steve Hay via RT <perl5-security-report [...] perl.org>, Salvatore Bonaccorso <carnil [...] debian.org>, Florian Weimer <fw [...] deneb.enyo.de>, John Lightsey <lightsey [...] debian.org>, Todd Rinaldo <toddr [...] cpan.org>, Dominic Hargreaves <dom [...] earth.li>, Niko Tyni <ntyni [...] debian.org>
Subject: Re: [perl #127834] Flaws in Perl code due to unsafe module load path
Download (untitled) / with headers
text/plain 2.6k
On Mon, Sep 26, 2016 at 7:23 PM, Aristotle Pagaltzis <pagaltzis@gmx.de> wrote: Show quoted text
> * Aristotle Pagaltzis <pagaltzis@gmx.de> [2016-09-27 02:02]:
>> If you want to advocate breaking bincompat in a point release,
I do not want to and did not advocate that. I recommended that the policy allow for such a possibility in case it ever became necessary. I don't see that it's necessary now. Show quoted text
>> why are >> not just removing the dot from @INC instead of all this faffing around >> with base.pm and all the other spot fixes?
Show quoted text
> I am not unserious here, btw. That breakage is not going to be fun, but > at least it serves a purpose. Patching base.pm is just entropy, and now > base.pm has a weird edge case that someday in the future will only > trigger under very then-unusual circumstances.
It's two months since 5.24.1-RC2. That was the culmination of many lengthy discussions including coordination with some vendors. Eventually, as I remember it, the consensus was that removing '.' from @INC in core modules was the best and most achievable initial step that would greatly reduce risk though not eliminate it. Hard removal of the default '.' in @INC for all users of require will obviously cause a lot more heartache for a lot more modules and I don't think anyone even considered doing that for a maint release. Then there was lots of work to get the patches done and the release candidates out. Other than trying to come up with the best, safest mitigation for base.pm, it's all been a done deal for some time. I don't think throwing that all away and starting from scratch with something we know will break lots of downstream is worth considering now. I also don't expect the vendors who have already made releases similar to the patches that are in the maint branches would appreciate such a course reversal. There is really only one question before us now, which is what is the best we can do for base.pm. Until recently it was possible that we might do nothing with it, but as of 10 hours ago, we have a pumpking ruling that we will not revert what we have but we might still improve on it if somebody actually produces such an improvement. That's the only thing still under consideration. Show quoted text
> Question: > > Does anyone present here propose that we tell users of older perls (with > dot still in @INC) that if they just upgrade their base.pm from CPAN, > they’ll be safe?
I don't propose telling anyone who benefits from the mitigations provided by the current scheme that they are "safe." The mitigations are just that. They reduce risk. They do not eliminate it. Of course any work anyone wants to do to test new base.pm with older Perls would be a good thing.
Subject: Re: [perl #127834] Flaws in Perl code due to unsafe module load path
From: Todd Rinaldo <toddr [...] cpanel.net>
CC: Salvatore Bonaccorso <carnil [...] debian.org>, Florian Weimer <fw [...] deneb.enyo.de>, John Lightsey <lightsey [...] debian.org>, Todd Rinaldo <toddr [...] cpan.org>, Dominic Hargreaves <dom [...] earth.li>, Niko Tyni <ntyni [...] debian.org>, pagaltzis [...] gmx.de
To: Steve Hay via RT <perl5-security-report [...] perl.org>
Date: Tue, 27 Sep 2016 00:26:03 -0500
Download (untitled) / with headers
text/plain 2.6k
Show quoted text
> On Sep 26, 2016, at 3:49 PM, Zefram via RT <perl5-security-report@perl.org> wrote: > > Todd Rinaldo wrote:
>> base.pm is different in that we are not modifying an optional loader >> of a single module we understand.
> > That's an interesting distinction. I wouldn't be confident that the tree > of dependencies of the specific optionally-loaded modules will always be > free of @INC diddling; our understanding of specific modules generally > doesn't extend to placing much of a constraint on their recursive > dependencies. Still, as a practical matter, you're right that base.pm > has a greater scope for such surprises. > > Are we aware of a specific @INC-diddling module that could reasonably > be used as such a recursive dependency? It seems rude for anything to > modify @INC without a direct request from the top-level script. If we > don't have such an example, we can't attach much weight to base.pm's > ability to optional-load a greater variety of modules.
Actually we ran into 2 instances where this was a problem in our code, but we have some pretty creative developers. I think we worked around it by doing: use Foo; use base 'Foo'; I believe I then went in and converted them all to use parent :) I had assumed Ribasushi had a known issue when he used the phrase "pretty serious regression" but now that I'm searching, I can't find that he had an example of a break he had as a result of the change. Maybe someone else can point us to it. Maybe his concerns are simply the ones I've already raised. Show quoted text
>
>> I'm referring to:
> > Not what I was asking about. I understand our criteria for what's > suitable for a maint release. The idea whose origin is a mystery to me is > that the change in base.pm (taking into account the security motivation) > offends those criteria. >
My criteria for excluding base is because of the localization of @INC during module load. My opinion is that it is an API change. I understand your security concern. Other than base, every other @INC manipulation in modules was for a very specific module load so low risk and high benefit (given the numbers John provided). I think base is a higher risk and based on John's number provided little value. To my knowledge, you are the one who stated that the responsibility of protecting @INC was ultimately the script writer. I admit being surprised at your current stance. I'm happy we got more to the bottom of our disagreement. Ultimately, I don't think we're going to agree on this. I'm ok with that. I'm for a vote and a release of 5.24.1, regardless of which way we go. It's been pointed out to me that right now anyone using Brew Perl still does not have these fixes 2 months later because we're sitting on the RC over this. Todd
From: Leon Timmermans <fawaka [...] gmail.com>
CC: Todd Rinaldo <toddr [...] cpanel.net>, "perl5-security-report [...] perl.org" <perl5-security-report [...] perl.org>, Salvatore Bonaccorso <carnil [...] debian.org>, Florian Weimer <fw [...] deneb.enyo.de>, John Lightsey <lightsey [...] debian.org>, Todd Rinaldo <toddr [...] cpan.org>, Dominic Hargreaves <dom [...] earth.li>, Niko Tyni <ntyni [...] debian.org>, Aristotle Pagaltzis <pagaltzis [...] gmx.de>
Subject: Re: [perl #127834] Flaws in Perl code due to unsafe module load path
To: Zefram <zefram [...] fysh.org>
Date: Tue, 27 Sep 2016 10:18:04 +0200
Download (untitled) / with headers
text/plain 754b
On Mon, Sep 26, 2016 at 10:48 PM, Zefram <zefram@fysh.org> wrote:
Show quoted text
>I'm referring to:

Not what I was asking about.  I understand our criteria for what's
suitable for a maint release.  The idea whose origin is a mystery to me is
that the change in base.pm (taking into account the security motivation)
offends those criteria.

Most obviously any program that lays out its modules in its root dir and happens to be using base.pm will be broken by this. This is not something a CPAN module would do, but I've seen this sort of layout before in bioinformatics and I would not be surprised if many CGI-type applications also used it; it's a perfectly sensible one for a newbie Perl programmer even if such a setup scales badly in practice.

Leon
Subject: Re: [perl #127834] Flaws in Perl code due to unsafe module load path
CC: Zefram <zefram [...] fysh.org>, Todd Rinaldo <toddr [...] cpanel.net>, Steve Hay via RT <perl5-security-report [...] perl.org>, Salvatore Bonaccorso <carnil [...] debian.org>, Florian Weimer <fw [...] deneb.enyo.de>, John Lightsey <lightsey [...] debian.org>, Todd Rinaldo <toddr [...] cpan.org>, Dominic Hargreaves <dom [...] earth.li>, Niko Tyni <ntyni [...] debian.org>
From: Aristotle Pagaltzis <pagaltzis [...] gmx.de>
To: "Craig A. Berry" <craig.a.berry [...] gmail.com>
Date: Tue, 27 Sep 2016 02:02:13 +0200
Download (untitled) / with headers
text/plain 758b
* Craig A. Berry <craig.a.berry@gmail.com> [2016-09-27 01:00]: Show quoted text
> The policy should probably state a little more strongly that security > can trump all the other rules when genuinely necessary, even binary > compatibility. The NodeJS folks just broke APIs in a minor release for > security reasons: > > <https://nodejs.org/en/blog/vulnerability/september-2016-security-releases/> > > Can we afford to be more lax about security than they can?
If you want to advocate breaking bincompat in a point release, why are not just removing the dot from @INC instead of all this faffing around with base.pm and all the other spot fixes? Personally I think NodeJS is an example of what to get away from. They should be looking to us as a role model, not we to them.
Subject: Re: [perl #127834] Flaws in Perl code due to unsafe module load path
From: Aristotle Pagaltzis <pagaltzis [...] gmx.de>
To: "Craig A. Berry" <craig.a.berry [...] gmail.com>, Zefram <zefram [...] fysh.org>, Todd Rinaldo <toddr [...] cpanel.net>, Steve Hay via RT <perl5-security-report [...] perl.org>, Salvatore Bonaccorso <carnil [...] debian.org>, Florian Weimer <fw [...] deneb.enyo.de>, John Lightsey <lightsey [...] debian.org>, Todd Rinaldo <toddr [...] cpan.org>, Dominic Hargreaves <dom [...] earth.li>, Niko Tyni <ntyni [...] debian.org>
Date: Tue, 27 Sep 2016 02:23:25 +0200
Download (untitled) / with headers
text/plain 686b
* Aristotle Pagaltzis <pagaltzis@gmx.de> [2016-09-27 02:02]: Show quoted text
> If you want to advocate breaking bincompat in a point release, why are > not just removing the dot from @INC instead of all this faffing around > with base.pm and all the other spot fixes?
I am not unserious here, btw. That breakage is not going to be fun, but at least it serves a purpose. Patching base.pm is just entropy, and now base.pm has a weird edge case that someday in the future will only trigger under very then-unusual circumstances. Question: Does anyone present here propose that we tell users of older perls (with dot still in @INC) that if they just upgrade their base.pm from CPAN, they’ll be safe?
To: perl5-security-report [...] perl.org
Date: Tue, 27 Sep 2016 16:40:02 +0200
Subject: Re: [perl #127834] Flaws in Perl code due to unsafe module load path
From: Aristotle Pagaltzis <pagaltzis [...] gmx.de>
Download (untitled) / with headers
text/plain 3.5k
To be clear up front: I am still against patching base.pm. I only want to address some of Zefram’s claims/points about the patch I proposed as the least intrusive, because I do not want to let them stand. Please do not take this as an indication that I wish to pursue this course, however. And with that out of the way: Show quoted text
> > [Zefram's comments] seem to miss the use case of a module loaded > > (maybe indirectly) through base.pm pushing a hook to the end of @INC. > > The scope guard shouldn't drop a . *behind* such a hook.
> > This seems so speculative that it's not clear what the intent would > be.
If the prose is too speculative, you can refer to the test that was in ribasushi’s patch. As for intent, you put a hook at the end of @INC when you want to intercept module loads that failed in order to log them, or make a catch-all attempt to load them from some other storage (treating locally installed modules as a cache), or the like. That simply follows immediately from where the hook is placed and what that implies for when it would be invoked. Show quoted text
> If it would add its hook to the end of @INC unconditionally, which at > first glance seems most likely because it is the simplest behaviour, > then to honour that intent the "." restoration ought to insert the "." > before the hook.
Which is what ends up happening under my proposal. Show quoted text
> But that would mean that the "." is now not recognisable as the > implicit one, so it won't be temporarily removed for later optional > module loads, opening a security hole.
You yourself found the whole concern too speculative to even understand. And I am not proposing it because it is a common or extremely important use case to cover. So I don’t think the security exposure is a practical concern. I am proposing it because my concern is to make the behaviour as predictable as possible, because the rules for platforms (like perl) are different than for products. There is a vast base of perl code we are affecting that we’ll never hear about. Therefore, first do no harm. Show quoted text
> For the Ribasushi/Aristotle behaviour, of not restoring the "." if > $INC[-1] has changed, to be correct, it implies that the hook-adding > module would have *replaced* the implicit "." if it found one there. > This seems most unlikely.
That is not “the Ribasushi/Aristotle behaviour”. It is specifically the difference between the proposals. Riba wrote logic that removes the dot and makes restoration conditional upon $INC[-1] staying the same. My change was to replace the dot with a no-op placeholder rather than remove it, hanging onto a placeholder reference, then *unconditionally* converting it back to a dot upon restoration – without even looking at @INC. This means the dot will be restored at whatever location the dot would have occupied in @INC if it had been left there. It will even DTRT if the entire contents of @INC had been replaced in the meantime. The *only* possible difference is if @INC was modified by code that cares about the dot specifically, and would have done something different if it had found it. That seems about as invariant as hiding the dot can get – short of not hiding the dot at all. Again, my concern is to make the behaviour as predictable as possible, even under scenarios that we canNOT necessarily foresee. Because there ARE more of these than we will ever get to hear about. Show quoted text
> I still prefer my proposed semantics, of unconditionally restoring the > "." onto the end of @INC.
I still don’t, because then the overall effect of the logic is ordering- sensitive in edge cases, which is where it’s most important to first do no harm.
CC: Zefram <zefram [...] fysh.org>, Todd Rinaldo <toddr [...] cpanel.net>, "perl5-security-report [...] perl.org" <perl5-security-report [...] perl.org>, Salvatore Bonaccorso <carnil [...] debian.org>, Florian Weimer <fw [...] deneb.enyo.de>, John Lightsey <lightsey [...] debian.org>, Todd Rinaldo <toddr [...] cpan.org>, Dominic Hargreaves <dom [...] earth.li>, Niko Tyni <ntyni [...] debian.org>, Aristotle Pagaltzis <pagaltzis [...] gmx.de>
From: Zefram <zefram [...] fysh.org>
Subject: Re: [perl #127834] Flaws in Perl code due to unsafe module load path
Date: Tue, 27 Sep 2016 15:48:34 +0100
To: Leon Timmermans <fawaka [...] gmail.com>
Download (untitled) / with headers
text/plain 265b
Leon Timmermans wrote: Show quoted text
>Most obviously any program that lays out its modules in its root dir and >happens to be using base.pm will be broken by this.
That's broken by the removal of ".", not by the localisation of @INC, which is what we were discussing. -zefram
Date: Tue, 27 Sep 2016 19:16:40 +0200
To: Zefram <zefram [...] fysh.org>
From: Sawyer X <xsawyerx [...] gmail.com>
CC: Leon Timmermans <fawaka [...] gmail.com>, Todd Rinaldo <toddr [...] cpanel.net>, "perl5-security-report [...] perl.org" <perl5-security-report [...] perl.org>, Salvatore Bonaccorso <carnil [...] debian.org>, Florian Weimer <fw [...] deneb.enyo.de>, John Lightsey <lightsey [...] debian.org>, Todd Rinaldo <toddr [...] cpan.org>, Dominic Hargreaves <dom [...] earth.li>, Niko Tyni <ntyni [...] debian.org>, Aristotle Pagaltzis <pagaltzis [...] gmx.de>
Subject: Re: [perl #127834] Flaws in Perl code due to unsafe module load path
Download (untitled) / with headers
text/plain 1.1k
To add one perspective: Take into account that several vendors are already working (and possibly have released) versions that include the original base.pm patch. Bike-shedding this, in practice, moves us further away from having less impact and into "whatever impact will effectively take place because we were bike-shedding this meanwhile". I'm aware that's not the most fair comment to make, but it's true nonetheless. I want to add that I have a strong objection to the muddy-the-water form of argument. "If we agree with this, we might as well <enter more swooping change>". It's pushing us further from practical changes in the present. Lastly, I would like to focus back to the kind of change we want, as Craig stressed several times now. If no one is able to offer a way to reduce breakage further (other than "let's just not apply a security fix patch"), I don't see a reason for this thread to continue and Aristotle's patch should be applied, pending any changes Zefram (or others knowledgeable in base.pm) might want to make to it. (Any attempt to move forward by excluding base.pm from this patchset is now turned into making this a much greater issue and a reason to bike-shed further. Ironic.)
CC: Zefram <zefram [...] fysh.org>, Leon Timmermans <fawaka [...] gmail.com>, Todd Rinaldo <toddr [...] cpanel.net>, "perl5-security-report [...] perl.org" <perl5-security-report [...] perl.org>, Salvatore Bonaccorso <carnil [...] debian.org>, Florian Weimer <fw [...] deneb.enyo.de>, John Lightsey <lightsey [...] debian.org>, Todd Rinaldo <toddr [...] cpan.org>, Dominic Hargreaves <dom [...] earth.li>, Niko Tyni <ntyni [...] debian.org>
From: Aristotle Pagaltzis <pagaltzis [...] gmx.de>
Subject: Re: [perl #127834] Flaws in Perl code due to unsafe module load path
Date: Tue, 27 Sep 2016 21:04:40 +0200
To: Sawyer X <xsawyerx [...] gmail.com>
Download (untitled) / with headers
text/plain 1.7k
* Sawyer X <xsawyerx@gmail.com> [2016-09-27 19:24]: Show quoted text
> To add one perspective: Take into account that several vendors are > already working (and possibly have released) versions that include the > original base.pm patch.
Several others have said they will revert any patch to base.pm in their own perl packages. And there are vendors who already ship a perl without the dot in @INC. AFAIK there are specimen for all combinations of these positions (either, neither or both). Show quoted text
> Bike-shedding this, in practice, moves us further away from having > less impact and into "whatever impact will effectively take place > because we were bike-shedding this meanwhile". I'm aware that's not > the most fair comment to make, but it's true nonetheless.
Shooting from the hip doesn’t increase impact. Making good choices that downstream can live well with does. Show quoted text
> I want to add that I have a strong objection to the muddy-the-water > form of argument. "If we agree with this, we might as well <enter more > swooping change>". It's pushing us further from practical changes in > the present.
I object strongly to characterising it as muddying the waters. :-) I consider it to be clearing the waters by cutting to the core of the “achieve”. If looking at the bigger picture points toward the course of action you have stated a preference against, and you wish it not to be considered in spite of merit, then besmirching the argument as “muddying the waters” is… well… muddying the waters. :-) If you have some actual argument why it’s the wrong way to look at things, I’m all ears. (Note that I am objecting to the characterisation as such only. It is your prerogative as the pumpking to say the choice is made and off the table.)
Subject: Re: [perl #127834] Flaws in Perl code due to unsafe module load path
CC: Sawyer X <xsawyerx [...] gmail.com>, Zefram <zefram [...] fysh.org>, Leon Timmermans <fawaka [...] gmail.com>, Todd Rinaldo <toddr [...] cpanel.net>, "perl5-security-report [...] perl.org" <perl5-security-report [...] perl.org>, Salvatore Bonaccorso <carnil [...] debian.org>, Florian Weimer <fw [...] deneb.enyo.de>, John Lightsey <lightsey [...] debian.org>, Todd Rinaldo <toddr [...] cpan.org>, Dominic Hargreaves <dom [...] earth.li>, Niko Tyni <ntyni [...] debian.org>
From: "Craig A. Berry" <craig.a.berry [...] gmail.com>
To: Aristotle Pagaltzis <pagaltzis [...] gmx.de>
Date: Tue, 27 Sep 2016 15:55:15 -0500
Download (untitled) / with headers
text/plain 876b
On Tue, Sep 27, 2016 at 2:04 PM, Aristotle Pagaltzis <pagaltzis@gmx.de> wrote: Show quoted text
> Shooting from the hip doesn’t increase impact. Making good choices that > downstream can live well with does.
I'm glad you're here, but did you possibly show up at the party without reading the invitation? :-). Take a day off work and read through the ticket (it will take that long): <https://rt.perl.org/Ticket/Display.html?id=127834> Then tell us how months of discussion including serious consideration of the possibility that base.pm might be left alone (but reconsideration of that possibility at the request of downstream) constitutes shooting from the hip. I just reread some of it myself and was reminded that over a month ago Debian chimed in with a real-world vulnerability in a /usr/bin package that was corrected by patching base.pm as has been done in the maint branches.
From: Sawyer X <xsawyerx [...] gmail.com>
CC: Aristotle Pagaltzis <pagaltzis [...] gmx.de>, Zefram <zefram [...] fysh.org>, Leon Timmermans <fawaka [...] gmail.com>, Todd Rinaldo <toddr [...] cpanel.net>, "perl5-security-report [...] perl.org" <perl5-security-report [...] perl.org>, Salvatore Bonaccorso <carnil [...] debian.org>, Florian Weimer <fw [...] deneb.enyo.de>, John Lightsey <lightsey [...] debian.org>, Todd Rinaldo <toddr [...] cpan.org>, Dominic Hargreaves <dom [...] earth.li>, Niko Tyni <ntyni [...] debian.org>
Subject: Re: [perl #127834] Flaws in Perl code due to unsafe module load path
To: "Craig A. Berry" <craig.a.berry [...] gmail.com>
Date: Tue, 27 Sep 2016 23:06:09 +0200
Download (untitled) / with headers
text/plain 2.6k
On Tue, Sep 27, 2016 at 10:55 PM, Craig A. Berry <craig.a.berry@gmail.com> wrote: Show quoted text
> On Tue, Sep 27, 2016 at 2:04 PM, Aristotle Pagaltzis <pagaltzis@gmx.de> wrote: >
>> Shooting from the hip doesn’t increase impact. Making good choices that >> downstream can live well with does.
> > I'm glad you're here, but did you possibly show up at the party > without reading the invitation? :-).
I'm not sure how to read this, but just in case, I want to make it clear I've asked Aristotle to provide his comments back to Zefram on this topic through the ticket, since it would allow removing me as a middleman. It was slow and unproductive. Show quoted text
> > Take a day off work and read through the ticket (it will take that long): > > <https://rt.perl.org/Ticket/Display.html?id=127834>
I couldn't provide Aristotle with the rights to read the ticket. I don't know how to do that or if it's possible. However, I've provided Aristotle (on his request) the entire ticket history. I suggested against it, but he stressed he would like to have as much context available on this. Show quoted text
> > Then tell us how months of discussion including serious consideration > of the possibility that base.pm might be left alone (but > reconsideration of that possibility at the request of downstream) > constitutes shooting from the hip. [...]
I think Craig's comment here exemplifies how tired we all are of this topic and how involved we've been in it. It's been exhausting and highly volatile. It really is not fair to call it "shooting from the hip". If we were shooting from the hip, we would be done with this as soon as Tony provided the patches (which were quite a lot of work for him as well). :) As for your comments on my comments on your comments, Aristotle, I think that there is a clear difference between changing the core language (dropping '.' in @INC) and changing a module. If this seems the same to you, we have a much bigger problem. If you really do not see these as differing, we will simply have to pause here. I'm including here comments I've made on another off-list conversation about this: * I think this change is in line with a security fix. Later we will apply a more wide-range fix in core instead of in specific modules. * For stable release we're only doing this in modules and core applications, not the interpreter itself. One of those modules is a gateway to these problems, so it was fixed as well, in the least damaging way we could. * That's it. I've clarified multiple times in this thread that I do *NOT* want to engage in more bike-shedding. We have a decision in place taking the considerations that were raised. If there is any intention in updating the patch to make it even less intrusive, it is more than welcomed.
CC: Sawyer X <xsawyerx [...] gmail.com>, Zefram <zefram [...] fysh.org>, Leon Timmermans <fawaka [...] gmail.com>, Todd Rinaldo <toddr [...] cpanel.net>, "perl5-security-report [...] perl.org" <perl5-security-report [...] perl.org>, Salvatore Bonaccorso <carnil [...] debian.org>, Florian Weimer <fw [...] deneb.enyo.de>, John Lightsey <lightsey [...] debian.org>, Todd Rinaldo <toddr [...] cpan.org>, Dominic Hargreaves <dom [...] earth.li>, Niko Tyni <ntyni [...] debian.org>
From: Aristotle Pagaltzis <pagaltzis [...] gmx.de>
Subject: Re: [perl #127834] Flaws in Perl code due to unsafe module load path
To: "Craig A. Berry" <craig.a.berry [...] gmail.com>
Date: Wed, 28 Sep 2016 00:16:32 +0200
Download (untitled) / with headers
text/plain 1.9k
* Craig A. Berry <craig.a.berry@gmail.com> [2016-09-27 23:00]: Show quoted text
> Take a day off work and read through the ticket (it will take that > long):
I have. Show quoted text
> Then tell us how months of discussion including serious consideration > of the possibility that base.pm might be left alone (but > reconsideration of that possibility at the request of downstream) > constitutes shooting from the hip.
[Echoed by Sawyer:] * Sawyer X <xsawyerx@gmail.com> [2016-09-27 23:12]: Show quoted text
> It really is not fair to call it "shooting from the hip".
I didn’t. Apologies that my statement was ambiguous. I meant shooting from the hip as the opposite of what happened. I was disagreeing that the delay is reducing impact – just as the opposite extreme wouldn’t lead to a maximum of impact. My point was that it’s not the speed at which decisions are made that makes impact but the quality of the choice. If you take a long time, vendors will patch at their discretion. Then again if you make a bad choice quickly, vendors will patch at their discretion, and if the decision ends up bad after taking a long time, vendors will patch at their discretion. But make a good choice quickly and vendors will go along, and make it slowly and they’ll still discard their patches once it’s there. Basically I don’t think of it as “we have taken so long, it’s not even going to matter any more” or “we’re losing our chance to have influence” or such. (It wasn’t a point that merited this volume of prose, which is why I was so brief… that I ended up achieving the opposite of keeping it short. Oh well. :-) ) Show quoted text
> I've clarified multiple times in this thread that I do *NOT* want to > engage in more bike-shedding. We have a decision in place taking the > considerations that were raised. If there is any intention in updating > the patch to make it even less intrusive, it is more than welcomed.
OK. Have followed through on my part of that and will be resting my case until further comment.
From: Sawyer X <xsawyerx [...] gmail.com>
To: Aristotle Pagaltzis <pagaltzis [...] gmx.de>
Subject: Re: [perl #127834] Flaws in Perl code due to unsafe module load path
CC: "Craig A. Berry" <craig.a.berry [...] gmail.com>, Zefram <zefram [...] fysh.org>, Leon Timmermans <fawaka [...] gmail.com>, Todd Rinaldo <toddr [...] cpanel.net>, "perl5-security-report [...] perl.org" <perl5-security-report [...] perl.org>, Salvatore Bonaccorso <carnil [...] debian.org>, Florian Weimer <fw [...] deneb.enyo.de>, John Lightsey <lightsey [...] debian.org>, Todd Rinaldo <toddr [...] cpan.org>, Dominic Hargreaves <dom [...] earth.li>, Niko Tyni <ntyni [...] debian.org>
Date: Mon, 3 Oct 2016 12:52:00 -0700
Download (untitled) / with headers
text/plain 354b
Having no additional discussion points, or suggestions for improvement by anyone, I think we're ready to merge. Aristotle, can you please provide the patch including any changes that came from this discussion? (Were there any?) Steve, could you please apply the patch Aristotle provides instead of the original change to base.pm and release a new RC?
Date: Tue, 11 Oct 2016 19:18:12 +0200
CC: "Craig A. Berry" <craig.a.berry [...] gmail.com>, Zefram <zefram [...] fysh.org>, Leon Timmermans <fawaka [...] gmail.com>, Todd Rinaldo <toddr [...] cpanel.net>, "perl5-security-report [...] perl.org" <perl5-security-report [...] perl.org>, Salvatore Bonaccorso <carnil [...] debian.org>, Florian Weimer <fw [...] deneb.enyo.de>, John Lightsey <lightsey [...] debian.org>, Todd Rinaldo <toddr [...] cpan.org>, Dominic Hargreaves <dom [...] earth.li>, Niko Tyni <ntyni [...] debian.org>
Subject: Re: [perl #127834] Flaws in Perl code due to unsafe module load path
To: Aristotle Pagaltzis <pagaltzis [...] gmx.de>
From: Sawyer X <xsawyerx [...] gmail.com>
Download (untitled) / with headers
text/plain 102b
From: Steve Hay via perl5-security-report <perl5-security-report [...] perl.org>
CC: Aristotle Pagaltzis <pagaltzis [...] gmx.de>, "Craig A. Berry" <craig.a.berry [...] gmail.com>, Zefram <zefram [...] fysh.org>, Leon Timmermans <fawaka [...] gmail.com>, Todd Rinaldo <toddr [...] cpanel.net>, "perl5-security-report [...] perl.org" <perl5-security-report [...] perl.org>, Salvatore Bonaccorso <carnil [...] debian.org>, Florian Weimer <fw [...] deneb.enyo.de>, John Lightsey <lightsey [...] debian.org>, Todd Rinaldo <toddr [...] cpan.org>, Dominic Hargreaves <dom [...] earth.li>, Niko Tyni <ntyni [...] debian.org>
Date: Wed, 12 Oct 2016 09:16:26 +0100
Subject: Re: [perl #127834] Flaws in Perl code due to unsafe module load path
To: Sawyer X <xsawyerx [...] gmail.com>
Download (untitled) / with headers
text/plain 371b
On 11 October 2016 at 18:18, Sawyer X <xsawyerx@gmail.com> wrote: Show quoted text
Now applied to both maint-5.22 and maint-5.24. I will release RC4s tonight, and am hoping for the final release (finally!) in a week's time (19th). Do we need to apply this patch to blead as well?
Date: Wed, 12 Oct 2016 12:04:18 +0200
Subject: Re: [perl #127834] Flaws in Perl code due to unsafe module load path
To: Steve Hay <steve.m.hay [...] googlemail.com>
CC: Sawyer X <xsawyerx [...] gmail.com>, "Craig A. Berry" <craig.a.berry [...] gmail.com>, Zefram <zefram [...] fysh.org>, Leon Timmermans <fawaka [...] gmail.com>, Todd Rinaldo <toddr [...] cpanel.net>, "perl5-security-report [...] perl.org" <perl5-security-report [...] perl.org>, Salvatore Bonaccorso <carnil [...] debian.org>, Florian Weimer <fw [...] deneb.enyo.de>, John Lightsey <lightsey [...] debian.org>, Todd Rinaldo <toddr [...] cpan.org>, Dominic Hargreaves <dom [...] earth.li>, Niko Tyni <ntyni [...] debian.org>
From: Aristotle Pagaltzis <pagaltzis [...] gmx.de>
Download (untitled) / with headers
text/plain 722b
* Steve Hay <steve.m.hay@googlemail.com> [2016-10-12 10:24]: Show quoted text
> On 11 October 2016 at 18:18, Sawyer X <xsawyerx@gmail.com> wrote: > > Now applied to both maint-5.22 and maint-5.24. I will release RC4s > tonight, and am hoping for the final release (finally!) in a week's > time (19th).
Argh. Hold the presses, I mispatched the existing test that started failing. I misunderstood what it was testing and fixed the failure in the wrong way, by changing the test. It’s not fatal, in that the correctness of the code is not in question – but the diagnostic is now misleading. Working on a followup to fix that.
From: Aristotle Pagaltzis <pagaltzis [...] gmx.de>
Subject: Re: [perl #127834] Flaws in Perl code due to unsafe module load path
To: Steve Hay <steve.m.hay [...] googlemail.com>, Sawyer X <xsawyerx [...] gmail.com>, "Craig A. Berry" <craig.a.berry [...] gmail.com>, Zefram <zefram [...] fysh.org>, Leon Timmermans <fawaka [...] gmail.com>, Todd Rinaldo <toddr [...] cpanel.net>, "perl5-security-report [...] perl.org" <perl5-security-report [...] perl.org>, Salvatore Bonaccorso <carnil [...] debian.org>, Florian Weimer <fw [...] deneb.enyo.de>, John Lightsey <lightsey [...] debian.org>, Todd Rinaldo <toddr [...] cpan.org>, Dominic Hargreaves <dom [...] earth.li>, Niko Tyni <ntyni [...] debian.org>
Date: Wed, 12 Oct 2016 12:18:13 +0200
Download (untitled) / with headers
text/plain 476b
* Aristotle Pagaltzis <pagaltzis@gmx.de> [2016-10-12 12:04]: Show quoted text
> Working on a followup to fix that.
Now pushed to the same branch. Normally I’d amend the previous one for this but I assume since you’ve pushed the other changes already, you’ll want it separated out. If not, feel free to squash this second commit into the first. http://perl5.git.perl.org/perl.git/commitdiff/refs/heads/ap/baseincguard (I’ll also attach the patch to RT for archival purposes later.)
To: Aristotle Pagaltzis <pagaltzis [...] gmx.de>
Subject: Re: [perl #127834] Flaws in Perl code due to unsafe module load path
From: Steve Hay via perl5-security-report <perl5-security-report [...] perl.org>
CC: Sawyer X <xsawyerx [...] gmail.com>, "Craig A. Berry" <craig.a.berry [...] gmail.com>, Zefram <zefram [...] fysh.org>, Leon Timmermans <fawaka [...] gmail.com>, Todd Rinaldo <toddr [...] cpanel.net>, "perl5-security-report [...] perl.org" <perl5-security-report [...] perl.org>, Salvatore Bonaccorso <carnil [...] debian.org>, Florian Weimer <fw [...] deneb.enyo.de>, John Lightsey <lightsey [...] debian.org>, Todd Rinaldo <toddr [...] cpan.org>, Dominic Hargreaves <dom [...] earth.li>, Niko Tyni <ntyni [...] debian.org>
Date: Wed, 12 Oct 2016 13:55:35 +0100
Download (untitled) / with headers
text/plain 614b
On 12 October 2016 at 11:18, Aristotle Pagaltzis <pagaltzis@gmx.de> wrote: Show quoted text
> * Aristotle Pagaltzis <pagaltzis@gmx.de> [2016-10-12 12:04]:
>> Working on a followup to fix that.
> > Now pushed to the same branch. Normally I’d amend the previous one for > this but I assume since you’ve pushed the other changes already, you’ll > want it separated out. If not, feel free to squash this second commit > into the first. > > http://perl5.git.perl.org/perl.git/commitdiff/refs/heads/ap/baseincguard > > (I’ll also attach the patch to RT for archival purposes later.)
Thanks, now applied to both maint branches.
From: Sawyer X <xsawyerx [...] gmail.com>
To: Steve Hay <steve.m.hay [...] googlemail.com>
Date: Thu, 22 Dec 2016 21:36:55 +0100
Subject: Re: [perl #127834] Flaws in Perl code due to unsafe module load path
CC: Aristotle Pagaltzis <pagaltzis [...] gmx.de>, "Craig A. Berry" <craig.a.berry [...] gmail.com>, Zefram <zefram [...] fysh.org>, Leon Timmermans <fawaka [...] gmail.com>, Todd Rinaldo <toddr [...] cpanel.net>, "perl5-security-report [...] perl.org" <perl5-security-report [...] perl.org>, Salvatore Bonaccorso <carnil [...] debian.org>, Florian Weimer <fw [...] deneb.enyo.de>, John Lightsey <lightsey [...] debian.org>, Todd Rinaldo <toddr [...] cpan.org>, Dominic Hargreaves <dom [...] earth.li>, Niko Tyni <ntyni [...] debian.org>
Download (untitled) / with headers
text/plain 816b
Update on 5.24.1: Despite considerable efforts by Aristotle, it seems to be taking longer to produce the base.pm patch. At this point, I think it's time to call it a day on 5.24.1 and release it without the base.pm changes. The benefit is two-fold: * Firstly, we move back into a proper release cycle. The changes provided, even without the base.pm patch, are valuable by themselves. This offset in the release cycle had added stress and disarray * Secondly, returning to a proper cycle allows us to release some pressure and gives an opportunity for vendors to catch up. This break also provides Aristotle with a short period of about a month to resolve the issue, in which case we could release 5.24.2 with the base.pm changes. In hindsight, this is what we should have done, but we didn't. Any objections?
CC: Aristotle Pagaltzis <pagaltzis [...] gmx.de>, "Craig A. Berry" <craig.a.berry [...] gmail.com>, Zefram <zefram [...] fysh.org>, Leon Timmermans <fawaka [...] gmail.com>, Todd Rinaldo <toddr [...] cpanel.net>, "perl5-security-report [...] perl.org" <perl5-security-report [...] perl.org>, Salvatore Bonaccorso <carnil [...] debian.org>, Florian Weimer <fw [...] deneb.enyo.de>, John Lightsey <lightsey [...] debian.org>, Todd Rinaldo <toddr [...] cpan.org>, Dominic Hargreaves <dom [...] earth.li>, Niko Tyni <ntyni [...] debian.org>
To: Sawyer X <xsawyerx [...] gmail.com>
Date: Fri, 23 Dec 2016 08:32:26 +0000
From: Steve Hay via perl5-security-report <perl5-security-report [...] perl.org>
Subject: Re: [perl #127834] Flaws in Perl code due to unsafe module load path
Download (untitled) / with headers
text/plain 1.4k
On 22 December 2016 at 20:36, Sawyer X <xsawyerx@gmail.com> wrote: Show quoted text
> Update on 5.24.1: > > Despite considerable efforts by Aristotle, it seems to be taking > longer to produce the base.pm patch. > > At this point, I think it's time to call it a day on 5.24.1 and > release it without the base.pm changes. The benefit is two-fold: > > * Firstly, we move back into a proper release cycle. The changes > provided, even without the base.pm patch, are valuable by themselves. > This offset in the release cycle had added stress and disarray > > * Secondly, returning to a proper cycle allows us to release some > pressure and gives an opportunity for vendors to catch up. This break > also provides Aristotle with a short period of about a month to > resolve the issue, in which case we could release 5.24.2 with the > base.pm changes. > > In hindsight, this is what we should have done, but we didn't. >
I worry that releasing 5.24.1 after such a long delay since the last RC (two and a half months now) but with no proper fix in it for the issue that was holding things up will look bad. However, continuing delay also looks bad, so if there is no chance of finding a fix any time soon then I agree that we should cut our losses and release now without the base.pm changes. I would still want to make an RC5, though, rather than jumping straight to the final release. We should always give people a chance to see what we propose the final release to be before going ahead with it.
Subject: Re: [perl #127834] Flaws in Perl code due to unsafe module load path
CC: Aristotle Pagaltzis <pagaltzis [...] gmx.de>, "Craig A. Berry" <craig.a.berry [...] gmail.com>, Zefram <zefram [...] fysh.org>, Leon Timmermans <fawaka [...] gmail.com>, Todd Rinaldo <toddr [...] cpanel.net>, "perl5-security-report [...] perl.org" <perl5-security-report [...] perl.org>, Salvatore Bonaccorso <carnil [...] debian.org>, Florian Weimer <fw [...] deneb.enyo.de>, John Lightsey <lightsey [...] debian.org>, Todd Rinaldo <toddr [...] cpan.org>, Dominic Hargreaves <dom [...] earth.li>, Niko Tyni <ntyni [...] debian.org>
From: Sawyer X <xsawyerx [...] gmail.com>
To: Steve Hay <steve.m.hay [...] googlemail.com>
Date: Fri, 23 Dec 2016 09:56:39 +0100
Download (untitled) / with headers
text/plain 1.7k
On Fri, Dec 23, 2016 at 9:32 AM, Steve Hay <steve.m.hay@googlemail.com> wrote: Show quoted text
> On 22 December 2016 at 20:36, Sawyer X <xsawyerx@gmail.com> wrote:
>> Update on 5.24.1: >> >> Despite considerable efforts by Aristotle, it seems to be taking >> longer to produce the base.pm patch. >> >> At this point, I think it's time to call it a day on 5.24.1 and >> release it without the base.pm changes. The benefit is two-fold: >> >> * Firstly, we move back into a proper release cycle. The changes >> provided, even without the base.pm patch, are valuable by themselves. >> This offset in the release cycle had added stress and disarray >> >> * Secondly, returning to a proper cycle allows us to release some >> pressure and gives an opportunity for vendors to catch up. This break >> also provides Aristotle with a short period of about a month to >> resolve the issue, in which case we could release 5.24.2 with the >> base.pm changes. >> >> In hindsight, this is what we should have done, but we didn't. >>
> > I worry that releasing 5.24.1 after such a long delay since the last > RC (two and a half months now) but with no proper fix in it for the > issue that was holding things up will look bad. > > However, continuing delay also looks bad, so if there is no chance of > finding a fix any time soon then I agree that we should cut our losses > and release now without the base.pm changes.
The balance I have for this is on one hand not giving up on base.pm, and on the other not holding back the other fixes, which are valuable to have. Show quoted text
> > I would still want to make an RC5, though, rather than jumping > straight to the final release. We should always give people a chance > to see what we propose the final release to be before going ahead with > it.
Would it be any different than RC4?