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

Re: Security Issues in perl-5.16.x

Thread Previous | Thread Next
David Golden
October 1, 2012 18:24
Re: Security Issues in perl-5.16.x
Message ID:
On Mon, Oct 1, 2012 at 9:03 PM, Reini Urban <> wrote:
> There's not much to argue about further.

I'm not arguing.  I honestly want to understand the risk you're describing.

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

I apologize for not being a deep C wizard or black/white hat security
guy, but I still don't understand the threat.  Is there a way to hide
(execute?) shellcode that doesn't assume arbitrary user code execution
or a blind "require()" of a user-given string in the first place?

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

This sounds like a philosophical difference.  Maybe the crux of the
issue.  (One that I have no opinion on.)  It sounds like you want "\0"
stopped on general principles, and others maybe view it more laissez
faire unless there is an actual exploit?

Philosophical differences are OK -- but they aren't solved with
technical debate, either, so if that's really the issues, we can at
least try to facilitate *that* discussion more directly and avoid
getting caught up in "show me the exploit" arguments.

Or, if I've misunderstood, please correct me.


David Golden <>
Take back your inbox! →
Twitter/IRC: @xdg

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