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

Re: Security Issues in perl-5.16.x

Thread Previous | Thread Next
October 1, 2012 16:10
Re: Security Issues in perl-5.16.x
Message ID:
On 1 October 2012 21:43, Reini Urban <> wrote:
> On Sat, Sep 29, 2012 at 9:26 AM, demerphq <> wrote:
>> On 29 September 2012 09:26, Shlomi Fish <> wrote:
>>> Hi Reini,
>>> On Fri, 28 Sep 2012 15:17:54 +0000
>>> wrote:
>>>> Updates:
>>>>       Status: WontFix
>>>> Comment #1 on issue 107 by reini.urban: Build fails with
>>>> perl-5.16.1-7.mga3
>>>> 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:
>>> *
>>> 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.

Sorry, but the p5p security folks did not fail to understand the
issue. We disagreed with your assessment of it and you failed to
provide anything to make us reconsider our view.

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

Which module is that? Please start substantiating your accusations or
stop spreading FUD.

Seriously Reini, a lot of people have spent a lot of time looking into
and discussing the issues you raise and we have in the past asked
questions to substantiate your claims and gotten very little back to
work with.

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

If we have any such bugs remaining post them to the list, either
security or this list.

Otherwise this is just FUD.

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

Or alternatively in 2 years we will *still* be wondering what the heck
you were talking about.

You never seem to admit the possibility you are wrong, and you repeat
demonstrably bullshit points over and over.

Thus from our point of view you are spreading FUD.

> 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 "\0anyshellcode"; print map {"$_ =>
> $INC{$_}"} keys %INC'
> strict.pmanyshellcode => /usr/local/lib/perl5/5.14.2/
> (-e:1) const(PV("\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.

If you pass arbitrary user data to the shell without validating it
properly you have a real problem, nulls are completely irrelevant.

Perl provides tools to prevent this from happening, such as taint
mode. Anyone using taint mode is "safe" from this kind of problem. Are
you suggesting that taint mode does not work?

> So the new binary-safe parser and the vm is now highly vulnerable to all kind
> of abusing pointer exploits with hidden payloads in variable names or
> package names.
> Before we allowed ending \0 such as in %main::\0 which led to the effect that
> such a package could never be loaded or updated via require.
> Now we allow \0 in the middle and still do not check our system calls.

So please give us an example. As far as I have seen you haven't
provided any examples for us to look into.

> So in summary p5p is now proud to be binary-safe.
> And I told them that this is a highly false sense of security. It's worse.
> Clearly a different point of view and not a failing burden of proof.
> Problem is that I'm not comfortable in releasing perl versions and modules
> with those unfixed problems.

I hope that anyone reading this thread understands that you have not
substantiated your claims and that until you do anything you say
should be taken to be FUD.

ps: Reini, I just wanted to say something else. I tend to support the
underdog and for a long time I thought your were just misunderstood,
and I tended to give you the benefit of the doubt. But this whole
security discussion has really made me wonder as to the sincerity of
your motives. Your reaction in these threads has been childish and
unproductive and I really wish you would either work with us to fix
whatever the problem is (assuming there actually is a problem) or shut
up and go away.
perl -Mre=debug -e "/just|another|perl|hacker/"

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