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

Re: Security Issues in perl-5.16.x

Thread Previous | Thread Next
Reini Urban
October 1, 2012 17:02
Re: Security Issues in perl-5.16.x
Message ID:
On Mon, Oct 1, 2012 at 6:10 PM, demerphq <> wrote:
> 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.

Your problem then.

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

This is too serious to be talked about publicly.

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

Sorry, I don't see any effort of understanding simple pointer problems and
simple \0 problems.

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

I would be very happy if you prove me wrong.

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

Sorry, perl has the real problem. \0 are not allowed as filename. And
not for dirs, and whatever.
Nulls are a new thing in packages and variable names. This is far from
Before without gv len the overlong names were cut off by any libc
string function.
Not anymore.
And the user has not a big chance to detect it. As shown above.

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

taint has nothing to do with that. Nobody uses it, since taint checks can
easily be bypassed, if you know to read perlsecurity.pod. And I'm not
talking about regex captures. (hint: heks missing the taint flag).

\0 needs be checked in user-land, but there's no need to do that.
perl needs to do those checks. On every system op, not just require.
unlink, mkdir, ...

require checks for \0 in filenames already. But not with my example.
And there's no eval and no strict refs involved.

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

I gave you one, which you obviously do not understand.

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

This is a worthless discussion. Most of my security fixes were applied by
the respective authors sooner or later already. Not FUD.
Most of them just too late for the 5.16.0 release.

It just needed about 6 months to acknowledge most issues.
Problem is that most authors do understand the issues, just p5p and
the security
list not. Which makes me wonder.

And as I said, it will need about 2 years to acknowledge the \0 issue,
the new shiny binary-safe parser and vm.
And the author understood this very issue. I talked to him at YAPC Madison.

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

If my motives were bad I would have announced the open problems publicly.
I refused to do so, until I was forced to.
The fixes were so trivial and most of the problems I did fix already.
p5p just didn't did not care to apply them.

And I fail to see my childish behavior, sorry. It's rather the opposite.
Reini Urban

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