develooper Front page | perl.perl5.porters | Postings from October 2012

Re: Security Issues in perl-5.16.x

Thread Previous | Thread Next
From:
Jesse Luehrs
Date:
October 1, 2012 13:06
Subject:
Re: Security Issues in perl-5.16.x
Message ID:
20121001200622.GC10026@tozt.net
On Mon, Oct 01, 2012 at 02:43:31PM -0500, Reini Urban wrote:
> On Sat, Sep 29, 2012 at 9:26 AM, demerphq <demerphq@gmail.com> wrote:
> > On 29 September 2012 09:26, Shlomi Fish <shlomif@shlomifish.org> wrote:
> >> Hi Reini,
> >>
> >> On Fri, 28 Sep 2012 15:17:54 +0000
> >> perl-compiler@googlecode.com wrote:
> >>
> >>> Updates:
> >>>       Status: WontFix
> >>>
> >>> Comment #1 on issue 107 by reini.urban: Build fails with
> >>> perl-5.16.1-7.mga3
> >>> http://code.google.com/p/perl-compiler/issues/detail?id=107
> >>>
> >>> If you see the Changelog and the STATUS file, you'll see that 5.16
> >>> and 5.17 is not yet supported with v1.42.
> >>>
> >>> Use latest git please.
> >>>
> >>
> >> Well, that's not a good solution for downstream packagers, and beside
> >> that, the CPAN release should also work, because that's where people
> >> look in general. See:
> >>
> >> * http://www.linuxtoday.com/developer/2006052100726OPSWDV
> >>
> >> But that's not why I contacted you about. See below.
> >>
> >>> I would also strongy recommend not to use 5.16 at all, as it still
> >>> has security issues with "binary safe" names being passed to e.g.
> >>> require and stored now in names, which allow a lot of new security
> >>> attack vectors. And 5.16.0 has a lot of known security holes.
> >>>
> >>
> >> I've read about something like that in Perl Weekly as well, but can you be
> >> more specific about the issues with perl-5.16.x? Also, I'm not using
> >> perl-5.16.0 but rather perl-5.16.1.
> >
> > To date Reini has failed to substantiate this claim despite requests to do so.
> 
> Wrong, the security folks failed to understand the issues. And p5p ditto.
> There is no remaining burden of proof on me.
> I told the closed security list my concerns, and also raised parts of
> it publicly or on irc.
> One module author even took my private explanation to a public RT
> ticket, after several
> months of misunderstanding, so this very important module is not safe
> when not being
> updated.
> 
> The security list failed to understand the following problems:
>   heap-overflow in read and write, use-after-free and false binary safety,
> and told me to come up with actual exploits, which I refused to do.
> The first two are pretty non-negotiable, and the most common pointer
> problems on earth, esp. use-after-free.
> 
> I listed several tickets, some of them have been fixed in 5.16.1 and
> CPAN modules.
> But 5.16.0 is still horribly broken, and all releases post 5.16 are
> inherently insecure
> because of false binary safety. Maybe the porters will understand
> these issues within
> the next 2 years.
> 
> To make it public, since the "security list" does not deserve this
> name in my eyes,
> I came up with this simple code which could be used to actually
> exploit the known problems.
> 
> $ perl -le'require "strict.pm\0anyshellcode"; print map {"$_ =>
> $INC{$_}"} keys %INC'
> strict.pmanyshellcode => /usr/local/lib/perl5/5.14.2/strict.pm
> 
> (-e:1) const(PV("strict.pm\0anyshellcode"\0))
> 
> The filename \0 bit is NOT checked in pp_require.
> Only a minor require security problem with leading '::' was fixed for 5.16.1.
> 
> But the "binary-safety" problems are much worse, since we allow now \0
> everywhere,
> and every system call with such a name silently strips the parts after the \0.
> There's no "eval" and "no use 'strict'" required here.
> Every user input has to be checked against \0.

Why are you calling require on arbitrary user input to begin with? Code
that does that has far more serious security issues to worry about than
embedded nulls. And how is storing arbitrary user-supplied data in %INC
any more of a vulnerability than storing arbitrary user-supplied data
anywhere else in the program? Surely if you have an exploit that can
figure out the address of the string data in some key in %INC, it could
also find string data that you supplied elsewhere. These are the
questions that you aren't answering, and the lack of answers to these
questions is why, while the behavior may be buggy, calling it a security
bug doesn't seem appropriate, especially since this issue can't actually
cause a security problem on its own.

As for the use-after-free and heap overflow bugs, I believe those are
already fixed in 5.16.1, aren't they? And the majority of them had
existed at least in 5.14, because we were only able to identify them
recently with better tools, as far as I understand it. Are there any of
those remaining?

-doy

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About