Re: Security Issues in perl-5.16.x

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.
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 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.
--
Reini Urban
http://cpanel.net/ http://www.perl-compiler.org/