Flaws in Perl code due to unsafe module load path

[p5pRT]

Migrated from rt.perl.org#127834 (status was 'resolved')

Searchable as RT127834$

[p5pRT]

From @lightsey

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.

[p5pRT]

From @fweimer

* 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?

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.

[p5pRT]

From @demerphq

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​:

# 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-archive.perl.org/perl5/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/"

[p5pRT]

The RT System itself - Status changed from 'new' to 'open'

[p5pRT]

From carnil@debian.org

Hi,

On Tue, Apr 05, 2016 at 08​:59​:46AM +0200, Florian Weimer wrote​:

* 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

[p5pRT]

From @iabyn

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.

--
"You're so sadly neglected, and often ignored.
A poor second to Belgium, When going abroad."
  -- Monty Python, "Finland"

[p5pRT]

From @rgarcia

On 5 April 2016 at 10​:07, Dave Mitchell <davem@​iabyn.com> wrote​:

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)

[p5pRT]

From @timbunce

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.

[p5pRT]

From @jhi

On Tuesday-201604-05 4​:48, Tim Bunce wrote​:

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

[p5pRT]

From @lightsey

On Tue, 2016-04-05 at 09​:37 +0200, Salvatore Bonaccorso wrote​:

Hi,

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?

[p5pRT]

From zefram@fysh.org

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.)

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

[p5pRT]

From @lightsey

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.

[p5pRT]

From @tonycoz

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

[p5pRT]

From @tonycoz

On Tue Apr 05 01​:07​:50 2016, davem wrote​:

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

[p5pRT]

From @Leont

On Tue, Apr 5, 2016 at 5​:23 AM, John Lightsey <
perl5-security-report@​perl.org> wrote​:

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

[p5pRT]

From @toddr

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;
  }

[p5pRT]

From zefram@fysh.org

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.

-zefram

[p5pRT]

From @craigberry

On Sat, Apr 9, 2016 at 11​:12 AM, Zefram <zefram@​fysh.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 ".".

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?

[p5pRT]

From @jhi

On Saturday-201604-09 12​:53, Craig A. Berry wrote​:

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.

[p5pRT]

From zefram@fysh.org

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.

-zefram

[p5pRT]

From @jhi

On Saturday-201604-09 20​:38, Zefram wrote​:

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.

-zefram

[p5pRT]

From @toddr

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

[p5pRT]

From @tonycoz

On Mon Apr 11 15​:56​:51 2016, toddr@​cpanel.net wrote​:

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

[p5pRT]

From @Leont

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.

Leon

[p5pRT]

From @lightsey

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.

[p5pRT]

From @toddr

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

[p5pRT]

From @lightsey

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.

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?

[p5pRT]

From @demerphq

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?

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.

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/"

[p5pRT]

From @lightsey

On Sat, 2016-04-16 at 15​:57 +0200, demerphq wrote​:

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.

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.

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

[p5pRT]

From @fweimer

* 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.

[p5pRT]

From @xsawyerx

On Fri, Dec 23, 2016 at 8​:25 PM, Karl Williamson
<public@​khwilliamson.com> wrote​:

On 12/23/2016 02​:25 AM, Sawyer X wrote​:

On Fri, Dec 23, 2016 at 10​:09 AM, Steve Hay <steve.m.hay@​googlemail.com> wrote​:

On 23 December 2016 at 08​:56, Sawyer X <xsawyerx@​gmail.com> wrote​:

On Fri, Dec 23, 2016 at 9​:32 AM, Steve Hay <steve.m.hay@​googlemail.com> wrote​:

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.

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?

Yes - If I understood you correctly, you're proposing that we remove
the base.pm changes that we've made so far?

That's what I meant. Sorry, should've been clearer. If it's different,
it definitely needs another RC.

And when do the things we normally would put in a dot release go in? 5.24.2?

I would prefer having them in 5.24.3, making both 5.24.1 and 5.24.2
the INC issues separately. We can add additional security related
issues into 5.24.2 as well as INC, if we really wish, sealing them as
"security releases".

[p5pRT]

From @craigberry

On Fri, Dec 23, 2016 at 2​:56 AM, Sawyer X <xsawyerx@​gmail.com> wrote​:

On Fri, Dec 23, 2016 at 9​:32 AM, Steve Hay <steve.m.hay@​googlemail.com> wrote​:

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​:

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.

Thanks to those who have continued to work on this zombie ticket that
refuses to be put down.

How do we communicate the current state of affairs in a way that lets
people decide what to do when 5.24.1 is released? I don't even know
what "the base.pm patch" is anymore. There have already been three or
more sets of base.pm patches discussed or committed in public.
Downstream folks have already applied one or more of them or produced
their own.

The base.pm changes committed to maint-5.24 two months ago, four
months ago, and five months ago will all need to be reverted, which
might surprise some people who have been banking on having one or more
of those changes in 5.24.1. At the very least they will expect some
rationale for why they are better off without them, and/or some basis
for deciding whether to re-apply what they've been using.

I assume there is a category of CPAN modules that will break with all
the mitigations attempted so far, including whatever has been in
progress for the last two months but hasn't been committed. Can that
category be described or at least examples given? If the description
discloses too much to be made public now, can it at least be specified
here on the security list? Without actual demonstrations of the dire
consequences of all the base.pm patches attempted so far, it sure
looks as though we are intentionally re-introducing a vulnerability
with demonstrated exploits in order to avoid some hypothetical
breakage. Please tell me we aren't doing that.

[p5pRT]

From @xsawyerx

On Fri, Dec 30, 2016 at 4​:33 AM, Craig A. Berry <craig.a.berry@​gmail.com> wrote​:

On Fri, Dec 23, 2016 at 2​:56 AM, Sawyer X <xsawyerx@​gmail.com> wrote​:

On Fri, Dec 23, 2016 at 9​:32 AM, Steve Hay <steve.m.hay@​googlemail.com> wrote​:

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​:

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.

Thanks to those who have continued to work on this zombie ticket that
refuses to be put down.

How do we communicate the current state of affairs in a way that lets
people decide what to do when 5.24.1 is released? I don't even know
what "the base.pm patch" is anymore. There have already been three or
more sets of base.pm patches discussed or committed in public.
Downstream folks have already applied one or more of them or produced
their own.

The base.pm changes committed to maint-5.24 two months ago, four
months ago, and five months ago will all need to be reverted, which
might surprise some people who have been banking on having one or more
of those changes in 5.24.1. At the very least they will expect some
rationale for why they are better off without them, and/or some basis
for deciding whether to re-apply what they've been using.

I think this recent decision on 5.24.1 maintains a simple-to-follow
direction​: 5.24.1 patches all modules and included applications
*except base.pm*. base.pm receives no patch in this version. That's
it.

The reason is simple​: We kept improving this patch but we realize this
is taking longer and we want to 1. Users to have 5.24.1 with its other
patches included, 2. Get back to a release cycle, 3. Have a bit more
time to decide fully on which patch goes to base.pm.

The base.pm patch itself is also simpler to explain now​: We originally
had an aggressive patch which became less aggressive with time.
However, our recent attempts were to reduce the contentious points
from it. This is proving difficult but we hope to accomplish this by
5.24.2. If we cannot, the more aggressive patch will be used instead.
By the time 5.24.2 comes close, we will communicate clearly which
patch was decided upon. Hopefully it will be the non-contentious one.

Is that better?

What I am very sorry about is the limbo situation of both 5.24.1 and
base.pm, and I hope this allows us to realize what state they are in,
and to move forward, one way or the other.

I assume there is a category of CPAN modules that will break with all
the mitigations attempted so far, including whatever has been in
progress for the last two months but hasn't been committed. Can that
category be described or at least examples given? If the description
discloses too much to be made public now, can it at least be specified
here on the security list?

I think we should. However, this depends greatly on which patch is
picked. If Aristotle is able to complete the work on the
non-contentious patch, this category is limited to a level of
negligible, in my opinion. If it's not possible a more aggressive
patch is provided and we can provide a description of the situation
which will break since we cannot differ distinctively between a
legitimate situation and a security risk.

Without actual demonstrations of the dire
consequences of all the base.pm patches attempted so far, it sure
looks as though we are intentionally re-introducing a vulnerability
with demonstrated exploits in order to avoid some hypothetical
breakage. Please tell me we aren't doing that.

I think we are still moving forward protecting against this risk, but
we're realizing that doing so in incremental steps allows us to move
forward faster than get stuck on a single front. This is, in my
opinion, more responsible and I'm sorry we had done this beforehand.
That's pretty much on me there. (This, by the way, is what Todd R. and
John L. tried pushing earlier, with no success - also because of me,
since I had hoped we will be able to resolve this quickly enough.)

Steve is working on RC5 any day now, which will simply not include the
base.pm. 5.24.2 will contain a patch for base.pm, one way or the
other, and we will clarify which patch came in, what it addresses and
if there are any possible legitimate usages that will break, we will
clarify this best we can with an appropriate apology to those who
might suffer it.

I wanted to write about this to p5p at large. If you believe this
covers it in a satisfying way, let me know, and I'll prepare an email
with the general spirit of this response.

[p5pRT]

From @steve-m-hay

On 30 December 2016 at 10​:51, Sawyer X <xsawyerx@​gmail.com> wrote​:

Steve is working on RC5 any day now, which will simply not include the
base.pm. 5.24.2 will contain a patch for base.pm, one way or the
other, and we will clarify which patch came in, what it addresses and
if there are any possible legitimate usages that will break, we will
clarify this best we can with an appropriate apology to those who
might suffer it.

The changes to revert all the various base.pm changes that had been
made have now been pushed to maint-5.22 and maint-5.24.

Those branches are now more or less what I will roll RC5 from in the
next day or two if we're still agreed that this is the best way to
proceed.

Please look in particular at the changes I've made to perldelta.pod,
from which discussion of base.pm has largely been removed, other than
to say that we've encountered difficulties which we hope to resolve in
5.22.4 (which I hadn't been intending to make, but really ought to
now) and 5.24.2.

[p5pRT]

From @craigberry

On Fri, Dec 30, 2016 at 4​:51 AM, Sawyer X <xsawyerx@​gmail.com> wrote​:

On Fri, Dec 30, 2016 at 4​:33 AM, Craig A. Berry <craig.a.berry@​gmail.com> wrote​:

I assume there is a category of CPAN modules that will break with all
the mitigations attempted so far, including whatever has been in
progress for the last two months but hasn't been committed. Can that
category be described or at least examples given? If the description
discloses too much to be made public now, can it at least be specified
here on the security list?

I think we should. However, this depends greatly on which patch is
picked.

But for now we're planning to ship with no patch at all to base.pm
(right?), which for some people will represent a roll-back of a patch
they are already using. If there is a rationale for doing so, I think
it needs to be as explicit as it can be without revealing details that
would be useful to an attacker.

Without actual demonstrations of the dire
consequences of all the base.pm patches attempted so far, it sure
looks as though we are intentionally re-introducing a vulnerability
with demonstrated exploits in order to avoid some hypothetical
breakage. Please tell me we aren't doing that.

I think we are still moving forward protecting against this risk, but
we're realizing that doing so in incremental steps allows us to move
forward faster than get stuck on a single front.

Steve is working on RC5 any day now, which will simply not include the
base.pm.

I think it's important to say explicitly that it's reverting base.pm
to its state as of 5.24.0 and to explain that the patch to base.pm
issued at the time of the disclosure has proved controversial and
attempts to improve on it have not yet produced an acceptable
alternative. I think people will want to know why the alternatives
are not acceptable and what the specific risk is to the CPAN
ecosystem.

5.24.2 will contain a patch for base.pm, one way or the
other, and we will clarify which patch came in, what it addresses and
if there are any possible legitimate usages that will break, we will
clarify this best we can with an appropriate apology to those who
might suffer it.

That all sounds excellent, though I don't think any apology is
necessary as long as the rationale for the decision is fully
explained.

I wanted to write about this to p5p at large. If you believe this
covers it in a satisfying way, let me know, and I'll prepare an email
with the general spirit of this response.

The general spirit is great. As I've indicated, a bit more detail in
some areas might head off some questions that will inevitably arise.

[p5pRT]

From @toddr

On Dec 30, 2016, at 12​:09 PM, Craig A. Berry <craig.a.berry@​gmail.com> wrote​:

On Fri, Dec 30, 2016 at 4​:51 AM, Sawyer X <xsawyerx@​gmail.com> wrote​:

On Fri, Dec 30, 2016 at 4​:33 AM, Craig A. Berry <craig.a.berry@​gmail.com> wrote​:

I assume there is a category of CPAN modules that will break with all
the mitigations attempted so far, including whatever has been in
progress for the last two months but hasn't been committed. Can that
category be described or at least examples given? If the description
discloses too much to be made public now, can it at least be specified
here on the security list?

I think we should. However, this depends greatly on which patch is
picked.

But for now we're planning to ship with no patch at all to base.pm
(right?), which for some people will represent a roll-back of a patch
they are already using. If there is a rationale for doing so, I think
it needs to be as explicit as it can be without revealing details that
would be useful to an attacker.

Honestly once 5.24.1 is out (without base.pm altered) I would argue that
the security case be opened up. At this time, there are no known exploits
that leverage base.pm. This is why I was against modifying the module
once we realized it was making breaking API changes.

Without actual demonstrations of the dire
consequences of all the base.pm patches attempted so far, it sure
looks as though we are intentionally re-introducing a vulnerability
with demonstrated exploits in order to avoid some hypothetical
breakage. Please tell me we aren't doing that.

I think we are still moving forward protecting against this risk, but
we're realizing that doing so in incremental steps allows us to move
forward faster than get stuck on a single front.

Steve is working on RC5 any day now, which will simply not include the
base.pm.

I think it's important to say explicitly that it's reverting base.pm
to its state as of 5.24.0 and to explain that the patch to base.pm
issued at the time of the disclosure has proved controversial and
attempts to improve on it have not yet produced an acceptable
alternative. I think people will want to know why the alternatives
are not acceptable and what the specific risk is to the CPAN
ecosystem.

+1. IMO we should make it clear that unlike the other changes, base.pm
is clearly a major API change. You're effectively putting a @​INC guard
around use since base is how some modules are loaded.

5.24.2 will contain a patch for base.pm, one way or the
other, and we will clarify which patch came in, what it addresses and
if there are any possible legitimate usages that will break, we will
clarify this best we can with an appropriate apology to those who
might suffer it.

That all sounds excellent, though I don't think any apology is
necessary as long as the rationale for the decision is fully
explained.

I would suggest that once 5.24.1 is released and the security case is
made public, it will be much easier to have a public discussion about
how to fix base.pm.

We should not make the same mistake of promising base.pm
changes until it is ready.

Todd

[p5pRT]

From @craigberry

On Fri, Dec 30, 2016 at 12​:53 PM, Todd Rinaldo <toddr@​cpanel.net> wrote​:

At this time, there are no known exploits that leverage base.pm.

Do you mean no *active* exploits? I would have thought a demonstrator
such as Niko Tyni provided on 14 August where he showed how to make
Perl load a file that shouldn't even exist would count as a known
exploit​:

<https://rt-archive.perl.org/perl5/Ticket/Display.html?id=127834#txn-1416452>

Or does it have to be in use in the wild to be considered "known"?

[p5pRT]

From @toddr

On Dec 30, 2016, at 2​:11 PM, Craig A. Berry <craig.a.berry@​gmail.com> wrote​:

On Fri, Dec 30, 2016 at 12​:53 PM, Todd Rinaldo <toddr@​cpanel.net> wrote​:

At this time, there are no known exploits that leverage base.pm.

Do you mean no *active* exploits? I would have thought a demonstrator
such as Niko Tyni provided on 14 August where he showed how to make
Perl load a file that shouldn't even exist would count as a known
exploit​:

<https://rt-archive.perl.org/perl5/Ticket/Display.html?id=127834#txn-1416452>

Or does it have to be in use in the wild to be considered "known"?

Yeah we may be hitting a terminology mis-match here.

https://youtu.be/dlIg4kQ4nRY?t=2m12s

While base.pm arguably has is a vulnerability (though technically it's a problem with require) There aren't really any known exploits what haven't been patched already in what we agreed was the correct place (the script).

From what I can tell, the patch we're discussing (although I am also in the dark as to WHICH patch we're even discussing) for base.pm tries to address fixing the unknown unknowns. No matter how we patch base.pm, it will almost certainly cause breakage. To me, this goes down the road of​: "well if we're going to fix base.pm, why not require and use?"

Todd

[p5pRT]

From @ntyni

On Fri, Dec 30, 2016 at 12​:31​:47PM -0800, Todd Rinaldo via RT wrote​:

On Dec 30, 2016, at 2​:11 PM, Craig A. Berry <craig.a.berry@​gmail.com> wrote​:

On Fri, Dec 30, 2016 at 12​:53 PM, Todd Rinaldo <toddr@​cpanel.net> wrote​:

At this time, there are no known exploits that leverage base.pm.

Do you mean no *active* exploits? I would have thought a demonstrator
such as Niko Tyni provided on 14 August where he showed how to make
Perl load a file that shouldn't even exist would count as a known
exploit​:

<https://rt-archive.perl.org/perl5/Ticket/Display.html?id=127834#txn-1416452>

Or does it have to be in use in the wild to be considered "known"?

While base.pm arguably has is a vulnerability (though technically it's a problem with require) There aren't really any known exploits what haven't been patched already in what we agreed was the correct place (the script).

FWIW Debian has /usr/bin/sbuild ("tool for building Debian binary
packages from Debian sources"), which uses Sbuild​::Exception which uses
Exception​::Class in a vulnerable manner. Neither /usr/bin/sbuild nor
Sbuild​::Exception have been patched to remove cwd from @​INC.

Debian stable has had the first version (well, one of them I guess)
of the base.pm patch backported to the 5.20 series since late July,
and that's what is mitigating the sbuild vulnerability.

Debian unstable/testing has 5.24.1-RC4 (therefore with the latest base.pm
patch) and cwd removed from @​INC by default, but it can be restored by
editing /etc/perl/sitecustomize.pl or setting PERL_USE_UNSAFE_INC=1 in
the environment.

I think Ubuntu is using the same patches/packages but I'm not 100%
certain.

Having 5.24.1 without any base.pm mitigations seems unfortunate to me,
but I certainly don't want to hold up this thing any longer. I'm not sure
yet what we want to do about Debian stable (both current and upcoming)
in that case.

Many thanks to everybody who has worked on this burdensome issue.
--
Niko Tyni ntyni@​debian.org

[p5pRT]

From @xsawyerx

I feel like we're drifting off into other smaller parts of the bigger
issue here. I would like to avoid branching off into sub-discussions
and bikeshedding. Let me try and summarize the issues raised here,
with hopes of moving forward​:

* There is already a strategy to resolve base.pm in a cleaner way.
Aristotle's work is public at branch "ap/baseincguard". I've noted
this on the list. The discussion on this can be done publicly at the
moment using that branch. I don't wish to open the ticket and I see
little value other than making some distributions uncomfortable with
existing tools and risks.
* 5.24.1 is not a move back. It is a move forward. That is, I believe,
the core resolution here. Instead of waiting with it for 5.24.1, we're
solidifying what we have so far and releasing it. This will allow us
to move forward instead of sitting on all the other fixes. We do see
this causing a minimal risk to breakage and so far, the most one
acceptable by contributors and commenters.
* Anyone who has patches that need to be reverted are those that
patched the release. I have communicated to all distributions
(including Debian) that we are not producing the original base.pm
patch at the moment a while ago.
* These changes apply to anything under 5.24.2 (and 5.22.4) since 5.26
will contain the fix for @​INC.

Craig has raised good points on what we need to make sure we
communicate (and communicate properly) when releasing this. I intended
to write a separate email about this. Vendors and distributions will
receive a separate email for their security contact.

Thank you for the comments. I hope we covered everything.

[p5pRT]

From @Leont

On Sat, Dec 31, 2016 at 12​:05 AM, Niko Tyni <ntyni@​debian.org> wrote​:

FWIW Debian has /usr/bin/sbuild ("tool for building Debian binary
packages from Debian sources"), which uses Sbuild​::Exception which uses
Exception​::Class in a vulnerable manner. Neither /usr/bin/sbuild nor
Sbuild​::Exception have been patched to remove cwd from @​INC.

This is Exception​::Class' sloppiness; if it would set $INC{$subclass_pm} to
a true value base.pm wouldn't try to load it that class. It not doing so is
a bug regardless of these security considerations.

I still haven't seen a case where base.pm was truly used to optionally load
a class, which is making this change all the more ironic.

Leon

[p5pRT]

From @demerphq

On 31 December 2016 at 17​:37, Leon Timmermans <fawaka@​gmail.com> wrote​:

On Sat, Dec 31, 2016 at 12​:05 AM, Niko Tyni <ntyni@​debian.org> wrote​:

FWIW Debian has /usr/bin/sbuild ("tool for building Debian binary
packages from Debian sources"), which uses Sbuild​::Exception which uses
Exception​::Class in a vulnerable manner. Neither /usr/bin/sbuild nor
Sbuild​::Exception have been patched to remove cwd from @​INC.

This is Exception​::Class' sloppiness; if it would set $INC{$subclass_pm} to
a true value base.pm wouldn't try to load it that class. It not doing so is
a bug regardless of these security considerations.

I still haven't seen a case where base.pm was truly used to optionally load
a class, which is making this change all the more ironic.

Agreed. And I don't think the unknown people who might be doing so
will upgrade to a maint release anyway.

I have watched this from afar and I feel like a big part of it is
much-ado-about-nothing.

I say that while fully respecting the effort and passions and that
have been invested in this thread.

But sometimes I think tunnel vision sets in and people lose track of
the bigger picture. (I know it happens to me from time to time.)

At $work when this came up we set up sitecustomize.pl to strip dot
from @​INC, and we have not seen any fallout from it as far as I know.
(Yeah yeah, i know this isnt going to be true for everyone.)

Yves

--
perl -Mre=debug -e "/just|another|perl|hacker/"

[p5pRT]

From @Leont

On Sat, Dec 31, 2016 at 5​:37 PM, Leon Timmermans <fawaka@​gmail.com> wrote​:

On Sat, Dec 31, 2016 at 12​:05 AM, Niko Tyni <ntyni@​debian.org> wrote​:

FWIW Debian has /usr/bin/sbuild ("tool for building Debian binary
packages from Debian sources"), which uses Sbuild​::Exception which uses
Exception​::Class in a vulnerable manner. Neither /usr/bin/sbuild nor
Sbuild​::Exception have been patched to remove cwd from @​INC.

This is Exception​::Class' sloppiness; if it would set $INC{$subclass_pm}
to a true value base.pm wouldn't try to load it that class. It not doing
so is a bug regardless of these security considerations.

I still haven't seen a case where base.pm was truly used to optionally
load a class, which is making this change all the more ironic.

Leon

The attached patch to Exception​::Class should secure sbuild and other users
of Exception​::Class even when . is in @​INC and base.pm is not patched.

Leon

[p5pRT]

From @Leont

0001-Set-INC-for-generated-classes.patch

From 64aaebbb46ae24ebf11754b98f05914769af5939 Mon Sep 17 00:00:00 2001
From: Leon Timmermans <fawaka@gmail.com>
Date: Sun, 1 Jan 2017 19:38:22 +0100
Subject: [PATCH] Set %INC for generated classes

---
 lib/Exception/Class.pm | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/lib/Exception/Class.pm b/lib/Exception/Class.pm
index 996ce65..c58a5f1 100644
--- a/lib/Exception/Class.pm
+++ b/lib/Exception/Class.pm
@@ -188,6 +188,9 @@ EOPERL
     eval $code;
     die $@ if $@;
 
+    (my $filename = "$subclass.pm") =~ s{::}{/}g;
+    $INC{$filename} = __FILE__;
+
     $CLASSES{$subclass} = 1;
 }
 
-- 
2.11.0

[p5pRT]

From @toddr

On Jan 1, 2017, at 12​:44 PM, Leon Timmermans via RT <perl5-security-report@​perl.org> wrote​:

On Sat, Dec 31, 2016 at 5​:37 PM, Leon Timmermans <fawaka@​gmail.com> wrote​:

On Sat, Dec 31, 2016 at 12​:05 AM, Niko Tyni <ntyni@​debian.org> wrote​:

FWIW Debian has /usr/bin/sbuild ("tool for building Debian binary
packages from Debian sources"), which uses Sbuild​::Exception which uses
Exception​::Class in a vulnerable manner. Neither /usr/bin/sbuild nor
Sbuild​::Exception have been patched to remove cwd from @​INC.

This is Exception​::Class' sloppiness; if it would set $INC{$subclass_pm}
to a true value base.pm wouldn't try to load it that class. It not doing
so is a bug regardless of these security considerations.

I still haven't seen a case where base.pm was truly used to optionally
load a class, which is making this change all the more ironic.

Leon

The attached patch to Exception​::Class should secure sbuild and other users
of Exception​::Class even when . is in @​INC and base.pm is not patched.

Leon

<0001-Set-INC-for-generated-classes.patch>

https​://github.com/houseabsolute/Exception-Class/pull/8 <https://github.com/houseabsolute/Exception-Class/pull/8>

[p5pRT]

From @Leont

On Sun, Jan 1, 2017 at 8​:55 PM, Todd Rinaldo <toddr@​cpanel.net> wrote​:

On Jan 1, 2017, at 12​:44 PM, Leon Timmermans via RT <
perl5-security-report@​perl.org> wrote​:

On Sat, Dec 31, 2016 at 5​:37 PM, Leon Timmermans <fawaka@​gmail.com> wrote​:

On Sat, Dec 31, 2016 at 12​:05 AM, Niko Tyni <ntyni@​debian.org> wrote​:

FWIW Debian has /usr/bin/sbuild ("tool for building Debian binary
packages from Debian sources"), which uses Sbuild​::Exception which uses
Exception​::Class in a vulnerable manner. Neither /usr/bin/sbuild nor
Sbuild​::Exception have been patched to remove cwd from @​INC.

This is Exception​::Class' sloppiness; if it would set $INC{$subclass_pm}
to a true value base.pm wouldn't try to load it that class. It not doing
so is a bug regardless of these security considerations.

I still haven't seen a case where base.pm was truly used to optionally
load a class, which is making this change all the more ironic.

Leon

The attached patch to Exception​::Class should secure sbuild and other users
of Exception​::Class even when . is in @​INC and base.pm is not patched.

Leon

<0001-Set-INC-for-generated-classes.patch>

houseabsolute/Exception-Class#8

Merged :-)

Leon

[p5pRT]

From @jmdh

On Wed, Jan 04, 2017 at 10​:08​:45PM +0100, Leon Timmermans wrote​:

On Sun, Jan 1, 2017 at 8​:55 PM, Todd Rinaldo <toddr@​cpanel.net> wrote​:

On Jan 1, 2017, at 12​:44 PM, Leon Timmermans via RT <
perl5-security-report@​perl.org> wrote​:

On Sat, Dec 31, 2016 at 5​:37 PM, Leon Timmermans <fawaka@​gmail.com> wrote​:

On Sat, Dec 31, 2016 at 12​:05 AM, Niko Tyni <ntyni@​debian.org> wrote​:

FWIW Debian has /usr/bin/sbuild ("tool for building Debian binary
packages from Debian sources"), which uses Sbuild​::Exception which uses
Exception​::Class in a vulnerable manner. Neither /usr/bin/sbuild nor
Sbuild​::Exception have been patched to remove cwd from @​INC.

This is Exception​::Class' sloppiness; if it would set $INC{$subclass_pm}
to a true value base.pm wouldn't try to load it that class. It not doing
so is a bug regardless of these security considerations.

I still haven't seen a case where base.pm was truly used to optionally
load a class, which is making this change all the more ironic.

Leon

The attached patch to Exception​::Class should secure sbuild and other users
of Exception​::Class even when . is in @​INC and base.pm is not patched.

Leon

<0001-Set-INC-for-generated-classes.patch>

houseabsolute/Exception-Class#8

Merged :-)

Thanks all, this fix is now on its way to Debian unstable, and
we'll make sure this is included on any Debian system running
5.24.1-RC5 or above (via a Breaks relation).

Cheers,
Dominic.

[p5pRT]

From @jmdh

On Sat, Dec 31, 2016 at 07​:10​:45AM -0800, Sawyer X via RT wrote​:

* These changes apply to anything under 5.24.2 (and 5.22.4) since 5.26
will contain the fix for @​INC.

Hi Sawyer et al,

Could you clarify what you mean here by 'the fix for @​INC'? I read it as
the removal by default of '.' (ie rt#130467) but that ticket is still
lingering in the gaining consensus stage. It looks to me like we have
enough information to make that decision, so if so, can we mark that
ticket as blocking 5.26, and make a statement to that effect on the ticket?

We can then move forward with enumerating the other tools that must be
fixed, and file bugs there.

I know that ideally we would have a full cpantesters run to check the
impact, but in the absence of that both Todd's report and Debian's
experience over the past 6 months provides a strong case that the fallout
is acceptable.

Cheers,
Dominic.

[p5pRT]

From @xsawyerx

On Fri, Jan 6, 2017 at 2​:17 PM, Dominic Hargreaves <dom@​earth.li> wrote​:

On Sat, Dec 31, 2016 at 07​:10​:45AM -0800, Sawyer X via RT wrote​:

* These changes apply to anything under 5.24.2 (and 5.22.4) since 5.26
will contain the fix for @​INC.

Hi Sawyer et al,

Hi Dominic, :)

Could you clarify what you mean here by 'the fix for @​INC'?

Localized cleanup of @​INC in core applications and modules. The set of
commits provided by Tony Cook. Everything except base.pm.

I read it as
the removal by default of '.' (ie rt#130467) but that ticket is still
lingering in the gaining consensus stage. It looks to me like we have
enough information to make that decision, so if so, can we mark that
ticket as blocking 5.26, and make a statement to that effect on the ticket?

That is a related issue, but not the same. RT#130467 is when to flip
the switch for a change to remove '.' from @​INC, for 5.26.0 and above.
That ticket is about core (and when to turn on a solution we already
agreed upon and implemented) while this is about core modules and
applications.

I agree it fits as a blocker for 5.26.0 and I have just added it as such.

[p5pRT]

From @iabyn

On Mon, Apr 04, 2016 at 08​:23​:27PM -0700, John Lightsey wrote​:
[stuff that triggered a huge thread about '.' in @​INC on the security list]

I'm just checking on the status of this (still open) security ticket.

Is there anything we still need to do for 5.26.0?
Is there anything we need to do for maint-*?
is there anything still confidential in this ticket which would prevent it
  being moved to the public queue?
Is there anything else stopping this ticket from being closed?

--
In England there is a special word which means the last sunshine
of the summer. That word is "spring".

[p5pRT]

From @xsawyerx

On Fri, Mar 17, 2017 at 12​:42 PM, Dave Mitchell <davem@​iabyn.com> wrote​:

On Mon, Apr 04, 2016 at 08​:23​:27PM -0700, John Lightsey wrote​:
[stuff that triggered a huge thread about '.' in @​INC on the security list]

I'm just checking on the status of this (still open) security ticket.

Is there anything we still need to do for 5.26.0?

Nope.

Is there anything we need to do for maint-*?

base.pm is still not patched. Waiting for Aristotle to fully resolve his patch.

is there anything still confidential in this ticket which would prevent it
being moved to the public queue?

I think we resolved to only open this after the full patched 5.24.2
and 5.22.4 are released (completing the related patched - this time in
base.pm.)

Is there anything else stopping this ticket from being closed?

* 5.24.2
* 5.22.4

[p5pRT]

From @xsawyerx

On Fri, 17 Mar 2017 06​:17​:41 -0700, xsawyerx@​gmail.com wrote​:

On Fri, Mar 17, 2017 at 12​:42 PM, Dave Mitchell <davem@​iabyn.com>
wrote​:

On Mon, Apr 04, 2016 at 08​:23​:27PM -0700, John Lightsey wrote​:
[stuff that triggered a huge thread about '.' in @​INC on the security
list]

[...]

is there anything still confidential in this ticket which would
prevent it
being moved to the public queue?

I think we resolved to only open this after the full patched 5.24.2
and 5.22.4 are released (completing the related patched - this time in
base.pm.)

Update to this​: I have asked the Debian team about opening this ticket before 5.24.2/5.22.4 are out and they agree to have it disclosed. Unless someone objects, I will open the ticket on Monday.

[p5pRT]

From @tonycoz

On Thu, 18 May 2017 04​:48​:31 -0700, xsawyerx@​cpan.org wrote​:

Update to this​: I have asked the Debian team about opening this ticket
before 5.24.2/5.22.4 are out and they agree to have it disclosed.
Unless someone objects, I will open the ticket on Monday.

Is this waiting on anything to be marked resolved?

Tony

[p5pRT]

From @jmdh

On Wed, Jun 14, 2017 at 05​:51​:13PM -0700, Tony Cook via RT wrote​:

On Thu, 18 May 2017 04​:48​:31 -0700, xsawyerx@​cpan.org wrote​:

Update to this​: I have asked the Debian team about opening this ticket
before 5.24.2/5.22.4 are out and they agree to have it disclosed.
Unless someone objects, I will open the ticket on Monday.

Is this waiting on anything to be marked resolved?

Presumably, releases of perl 5.24.x and 5.22.x including the base.pm
fixes.

Dominic.

[p5pRT]

From @xsawyerx

On 06/19/2017 06​:33 AM, Dominic Hargreaves wrote​:

On Wed, Jun 14, 2017 at 05​:51​:13PM -0700, Tony Cook via RT wrote​:

On Thu, 18 May 2017 04​:48​:31 -0700, xsawyerx@​cpan.org wrote​:

Update to this​: I have asked the Debian team about opening this ticket
before 5.24.2/5.22.4 are out and they agree to have it disclosed.
Unless someone objects, I will open the ticket on Monday.
Is this waiting on anything to be marked resolved?
Presumably, releases of perl 5.24.x and 5.22.x including the base.pm
fixes.

Agreed.

[p5pRT]

From @khwilliamson

On Tue, 20 Jun 2017 11​:12​:10 -0700, xsawyerx@​gmail.com wrote​:

On 06/19/2017 06​:33 AM, Dominic Hargreaves wrote​:

On Wed, Jun 14, 2017 at 05​:51​:13PM -0700, Tony Cook via RT wrote​:

On Thu, 18 May 2017 04​:48​:31 -0700, xsawyerx@​cpan.org wrote​:

Update to this​: I have asked the Debian team about opening this ticket
before 5.24.2/5.22.4 are out and they agree to have it disclosed.
Unless someone objects, I will open the ticket on Monday.
Is this waiting on anything to be marked resolved?
Presumably, releases of perl 5.24.x and 5.22.x including the base.pm
fixes.

Agreed.

Are these now done?

--
Karl Williamson

[p5pRT]

From @steve-m-hay

On Fri, 28 Jul 2017 09​:33​:51 -0700, khw wrote​:

On Tue, 20 Jun 2017 11​:12​:10 -0700, xsawyerx@​gmail.com wrote​:

On 06/19/2017 06​:33 AM, Dominic Hargreaves wrote​:

On Wed, Jun 14, 2017 at 05​:51​:13PM -0700, Tony Cook via RT wrote​:

On Thu, 18 May 2017 04​:48​:31 -0700, xsawyerx@​cpan.org wrote​:

Update to this​: I have asked the Debian team about opening this ticket
before 5.24.2/5.22.4 are out and they agree to have it disclosed.
Unless someone objects, I will open the ticket on Monday.
Is this waiting on anything to be marked resolved?
Presumably, releases of perl 5.24.x and 5.22.x including the base.pm
fixes.

Agreed.

Are these now done?

5.22.4 and 5.24.2 have now been released with the base.pm fix, but the changes have also been ported forward to 5.26.x and blead. I'm not sure whether that means the ticket should be kept open until 5.26.1 and even 5.28.0 have been released? Arguably not, since other changes in those streams mean perl is now safe by default; the base.pm fix is only in them for the sake of anybody who disables the default safe mode.

[p5pRT]

From @xsawyerx

On Fri, 28 Jul 2017 09​:49​:18 -0700, shay wrote​:

On Fri, 28 Jul 2017 09​:33​:51 -0700, khw wrote​:

On Tue, 20 Jun 2017 11​:12​:10 -0700, xsawyerx@​gmail.com wrote​:

On 06/19/2017 06​:33 AM, Dominic Hargreaves wrote​:

On Wed, Jun 14, 2017 at 05​:51​:13PM -0700, Tony Cook via RT wrote​:

On Thu, 18 May 2017 04​:48​:31 -0700, xsawyerx@​cpan.org wrote​:

Update to this​: I have asked the Debian team about opening this
ticket
before 5.24.2/5.22.4 are out and they agree to have it
disclosed.
Unless someone objects, I will open the ticket on Monday.
Is this waiting on anything to be marked resolved?
Presumably, releases of perl 5.24.x and 5.22.x including the
base.pm
fixes.

Agreed.

Are these now done?

5.22.4 and 5.24.2 have now been released with the base.pm fix, but the
changes have also been ported forward to 5.26.x and blead. I'm not
sure whether that means the ticket should be kept open until 5.26.1
and even 5.28.0 have been released? Arguably not, since other changes
in those streams mean perl is now safe by default; the base.pm fix is
only in them for the sake of anybody who disables the default safe
mode.

I think we can resolve it now. And I have.

[p5pRT]

@xsawyerx - Status changed from 'open' to 'resolved'