Front page | perl.perl5.porters |
Postings from August 2016
Re: [perl #128800] base.pm broken in Perl 5.24.1 rc2
From: Chris Travers
August 2, 2016 18:59
Re: [perl #128800] base.pm broken in Perl 5.24.1 rc2
Message ID: CAKt_ZfvGyS9KRw+=gj_2LjiJdidQMU60AMLKEd3u12o_2+v1Gg@mail.gmail.com
On Mon, Aug 1, 2016 at 7:16 PM, Zefram via RT <email@example.com>
> Chris Travers wrote:
> >Please fix it properly or not at all. This idea of mostly supporting
> >. in the INC but not really is going to cause a lot of people a LOT of
> We *are* going to fix it properly: we're heading in the direction of
> not having the implicit . in @INC at all.
Good. That would waste people's time a *whole lot less* than the current
fix (which I spent an *entire day* debugging following Debian's roll out).
This is not a proper fix in any universe for a few important reasons:
1. The bugs it introduces are very opaque and currently the behavior
change is entirely undocumented anywhere.
2. The breaking behavior change (at least in the case of Debian's rollout)
was pretty clearly not understood well enough to alert potential users to
the change in advance. I am not sure this can be understood once INC
sometimes means one thing and sometimes means something else.
3. No amount of this sort of fix can ever secure a system but it can make
admins mistakenly think they are secure by giving false signs in the first
places they might look.
4. Even removing . from @INC isn't sufficient. In my blog post I discuss
why. You also need to provide a pragma which bans all world writable
directories from @INC so that programs can at least opt into real security
But by making a code contract only sometimes binding you create extremely
difficult to troubleshoot bugs in peoples' production environments and I
would bet that the cost of that would be worse than the costs of any
The first thing to do when faced with a security problem is to make sure
you understand the problem and the solution and I don't think anyone can
understand the full ramifications of this patch. So if it gets in the way
it is, you will answer variations of this bug report every day for years to
come, I would be willing to bet.
> Expect 5.26 to have at least
> a big step in that direction. The problem is that that's quite a big
> break in compatibility, which we can't impose straight away.
So, remove it unless an environment variable is set or something, or make
it a build time option, or half a dozen other things you can do.
> Being a
> core change, it also won't help the many programs that run on older
> perl versions. So in the short term we need some fixes that address the
> really problematic cases without entirely dishonouring . in @INC, and even
> in the long term we need some fixes that don't require the core change.
> The changes that you're seeing now are those expedient fixes. Yes,
> they're not as good as the proper core change, but they're the best that's
> possible to deal with this difficult situation.
Well it cost me a day of debugging the fix when it came out in Debian, so
you can expect me to complain loudly about making modules responsible for
INC in this way everywhere this is proposed. It is a bad fix to the wrong
problem and if you stopped and carefully evaluated options I think you'd
But it also is nowhere near a complete fix, which is why it is critical
that system administrators understand the dangers and how to protect
themselves, so I have started a full disclosure series on this
vulnerability which discusses forms of attacks and how system
administrators can protect themselves against them. I intend to continue
that (my current favorite topic is prove, which cannot be made secure in a
world writeable directory without fundamentally breaking its core
guarantee, unless you remove . from @INC). Maybe 3-4 published discussions
a week on variations.
Major topics I have planned include prove, scripts that process data in
user-submitted directories, and a few programming antipatterns that make
this problem a lot worse. Like all responsible full disclosure, I intend
to try to ensure that the cost in lowering the barrier to writing exploits
is small in comparison to the benefit to sysadmins trying to secure their
Because right now system administrators can reasonably protect their
systems. The current approach given here does not help with that in any
real significant way.
> They're the result
> of a balancing act which the security list spent weeks thrashing out.
> One of the two classes of immediate change is that code implementing
> optional module loads won't honour . in @INC. This is quite intrusive
> to that code, and does cause problems, but really is the least bad thing
> we can do to address the serious security problem.
> base.pm is especially problematic, because it gets used a lot more than
> most optional module loading code, and especially because, due to its
> poor design, it mostly gets used for module loads that are not intended
> to be optional. We know that this cost arises from the security fix,
> and we chose to accept it. It is still less disruptive than an immediate
> total removal of . from @INC would be.
Then I hope *at least* you announce the breakage in a big way, properly
document it in the POD (right now that isn't there), and make sure that
everyone who faces the dreaded base class empty error knows that this is
because of this change. Nobody should have to spend a day debugging only
to find the problem is an undocumented change in behavior to a part of the
standard module. I won't get back the day that I would have spent doing
billable work. Neither will my business partner. But at least you can try
to minimize that from happening to everyone else.
If you would like to follow the full disclosure entries I will email you
directly. I don't see a point in putting them in the ticket.
> To avoid these problems, you should use parent.pm instead of base.pm.
Efficito: Hosted Accounting and ERP. Robust and Flexible. No vendor