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 18:03
Re: Security Issues in perl-5.16.x
Message ID:
On Mon, Oct 1, 2012 at 7:14 PM, David Golden <> wrote:
> On Mon, Oct 1, 2012 at 8:01 PM, Reini Urban <> wrote:
>> 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.
> What it should make you wonder is how well you have explained things.
> Consider these possibilities:
> (a) you explained things brilliantly, and the sizable and
> not-unskilled set of people on the security list* are too stupid to
> understand or have ulterior motives to ignore your advice

Nope, I was very short in my description.

> (b) you explained things tolerably, and the sizable and not-unskilled
> set of people on the security list* misunderstood what you said


> Without any additional information, I think an unbiased person might
> conclude that the likelihood of miscommunication is higher than the
> likelihood of the incompetence or malfeasance of the entire security
> list.
> Further, one of those is consistent with the actual response, which
> has been, to a large degree, "sorry, Reini, we still don't understand.
>  Could you please give us a working example of an exploit that
> demonstrates it?"
> And therein lies the impasse.
> I think we would all welcome less finger pointing and more
> constructive dialog to get past what is, in all probability, just a
> misunderstanding.
> David
> * The sec list members are mostly current/former pumpkings and select
> others deemed to have relevant expertise

To repeat myself:

I showed 6 actual ptr bugs which were already fixed in the meantime,
of the kinds: heap-overflow on read and write, and use-after-free.
No stack-overflow and no global-overflow interestingly.

These issues were not acknowledged, nor reproduced.
For most the issues even valgrind was able to detect them,
only some issues were reproducable with asan.
There was only shit talking about me and asan.
Not a single porter visited my asan talk at the yapc.

On the contrary other projects were happy to take my
security fixes immediately.

There's not much to argue about further.

5.16.1 still is a big risc for me, even if you call it untrusted userdata.
This is a completely new way to hide shellcode, in package name
HEKs and in GvNAMEs. With HEKs the data gets untainted.

There is no need at all to allow \0 in names at all, and \0 being
passed to system ops need to caught. There cannot be any
\0 in usernames, group names, filenames, dir names and such.
People know about strings but not about names.

It cannot be the users problem if perl passes such silently stripped
userdata along.
\0 in filenames is already checked in pp_require, but not in my simple case.

\0 was allowed before but not of much use, since the rest got stripped.
%main::\0 was the prime example. Since it was at the end already.
Reini Urban

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