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

[perl #128800] broken in Perl 5.24.1 rc2

Thread Previous | Thread Next
Chris Travers via RT
August 2, 2016 03:13
[perl #128800] broken in Perl 5.24.1 rc2
Message ID:
Removing . from @INC would frankly cause fewer problems than this modification to  There are several very significant problems here:

1.  @INC no longer has a distinct meaning which makes debugging far harder
2.  The errors which come from this patch are very opaque, order dependent, and difficult to troubleshoot.  Adding Heisenbugs is bad practice.
3.  The behavior change and its implications are currently undocumented and probably unknowable in advance.
4.  Perhaps most importantly, this patch eliminates the problem from the first places system administrators are likely to look to determine if they are secure while also giving attackers free range of every other module.

In my view, support . in @INC or not but don't do this funny half-way way which makes undocumented (and probably undocumentable) changes to behavior.

I wear a lot of hats.  I do system administration, software development, some pen testing.  Debian's rollout of this change broke things that took me a day to debug (because nobody ever expects that problems will come from undocumented behavior changes in standard libraries), and I don't think I will be alone there.  When I found out the patch was here too, I filed this bug report.

But then I asked myself, "what is the scope of this vulnerability?"  and "Are my systems at risk?"  After careful review I determined the business systems I had built were not, but that this was a real problem with a far reach, and that these patches don't actually help that much in securing a system from a sysadmin perspective.

I recognize that this is a difficult situation, and security is important to me too.  And I recognize there is probably intense pressure to release a fix yesterday.  But this is a bad idea and if you go this route, you will be answering variations of this bug report every day for years to come.

One of the things Debian did right was to introduce a system setting to disable implicit current working directories in @INC.  I recognize that with a portable language like Perl, that may not be practical.  But you have a lot of options that would be real solutions to this problem which would be a lot better than what you have now.  They include:

1.  A simple compile time option to fix the behavior (woohoo!  Perl fixed! now the downstream distributors have to decide whether to release two versions or just the fixed one)

2.  Make a fallback if an environment variable is set.

There are probably half a dozen other approaches that would allow for people who still need the old behavior to get it without introducing strange, order-dependent, opaque bugs into large numbers of Perl codebases out there.

A second point is that there are security implications for perl scripts out there and that fixing this on the module level fails to account for the fact that the module is not in a position to understand the implications of the change.

As it stands right now, my view is that system administrators are the only ones who can secure their systems, and that it is critical that they understand the problems in this area. So for that reason, I have started a full disclosure series on this problem discussing different attack scenarios and how system administrators can prevent them (from what to look for in scripts that run on their systems, how to secure scripts, including ones they write themselves, and how to avoid problems from running programs like prove).  Every exploit I plan to discuss will work with these patches in place so that system administrators are in a better position to assess vulnerability of their systems.

It is humanly possible to secure a system with this issue.  But I am not convinced it is humanly possible to understand the implications of making this the module's responsibility.

via perlbug:  queue: perl5 status: open

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