develooper Front page | perl.perl5.porters | Postings from August 2016

Re: [perl #128800] broken in Perl 5.24.1 rc2

Thread Previous | Thread Next
Chris Travers
August 2, 2016 18:59
Re: [perl #128800] broken in Perl 5.24.1 rc2
Message ID:
BTW, the other real concern this brings up for someone like myself who has
built a business hosting Perl-based software is this:

How long before someone panics and breaks something again?

I spent a fair bit of time looking into the issue.  I wear many hats --
sysadmin, developer, pen tester, etc and the initial questions were how big
is the problem? Was my business vulnerable?  What I did to determine this
was to review the github issues filed over the RFC.  I determined that my
business was not vulnerable, but that the problem in other environments
could be very big and frankly very scary.  So I am willing to forgive the

But I also concluded that in terms of exploitability, this approach didn't
really answer a lot of serious problems.  For example, because of the way
prove works, it is simply never safe to run while in a world-writable
directory, and that no patches to prove can fix that (that's why it is the
favorite topic of my blog right now, because other sysadmins need to know
what I have found).  If you won't tell users that I have to.  Will it lower
the bar on writing expoits?  Probably.  But it also lowers the bar both in
knowledge and effort to securing systems and I think that's more important.

The second thing I determined was that this was trivially preventable on
the script level (no lib '.' for any script intended to run in a directory
of untrusted files unless it is also calling exec on Perl from that same
directory, in which case one just has to note the danger).  Perl developers
and sysadmins are in a position to audit their systems, make sure that line
is in place where appropriate, fix he problem locally and report bugs
upstream if not.

In other words, with a day's work or so (what I spent debugging this the
first time around) it is reasonably possible to secure any system including
the effort to report at least some issues upstream.

I have to tell you, I have been primarily writing in Perl 5 since 2007 and
this has really shaken my faith in the Perl community's ability to sit down
and think through security fixes.  I don't know if I expect too much.  I
understand it is a difficult situation, that maintenance of open source
software is often thankless work, and that there is probably serious
pressure to release a fix yesterday.  But this is the first time I have
come to doubt that people would come together when a problem is reported
and actually think through implications of fixes.

You just need a way to choose for now to strip . from the default @INC.
The sysadmin is the right person to make the call, not the module
maintainer.   Keep the system understandable and hence something one can
reasonably secure without special knowledge.  Really, that's all I ask.

On Mon, Aug 1, 2016 at 7:21 PM, Zefram via RT <>

> I wrote:
> >To avoid these problems, you should use instead of
> And I forgot to say: if for a particular application you really want a
> fully-honoured . in @INC, you can either put it in at the beginning of
> @INC (by PERL5LIB=., -I., or "use lib '.'"), or put it on the end as
> "./.".  Eventually you'll need this to load anything from ., when the
> core stops putting the . in implicitly.
> -zefram

Best Wishes,
Chris Travers

Efficito:  Hosted Accounting and ERP.  Robust and Flexible.  No vendor

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About