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

Re: Security Issues in perl-5.16.x

Thread Previous | Thread Next
From:
Leon Timmermans
Date:
October 1, 2012 13:12
Subject:
Re: Security Issues in perl-5.16.x
Message ID:
CAHhgV8jwUYpcbA-r_mzwj1C_DOD6tBGB58PRVcNJnhW8MKZWfQ@mail.gmail.com
On Mon, Oct 1, 2012 at 9:43 PM, Reini Urban <rurban@x-ray.at> wrote:
> 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 don't think anyone fails to understand heap-overflows and
use-after-free. AFAIK all such known issues in core are fixed (and I'm
absolutely sure no one would oppose fixing a newly discovered one).

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

As far as I understand this requires the user to be in control of the
$path in «require $path». By that time, you don't need any trick to
achieve anything you want. Binary nulls are not really an issue
anymore at that stage of being compromised.

Leon

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