Netanel Rubin's Perl Jam circus

I’ve just watched Netanel Rubin’s Perl Jam 2 talk from this year’s Chaos Communication Congress. As he’s due to give the same talk at Black Hat Asia, I thought it would be good to set the record straight concerning his claims about Perl (others have already done so). He makes 3 major claims:

The Perl language is insecure

Bugzilla & CGI.pm are representative of idiomatic Perl

Perl doesn’t improve

I’m going to address each claim in turn and show why it is false. In my view, Perl remains a powerful, general-purpose language well-suited to tasks like building dynamic web applications, processing big data, and managing systems.

Developers treat hashes and arrays as “secure” data types … this is the Perl standard. You’re not expected to use it, you have to, as you don’t have any other choice. This security mess is a fundamental part of the language.

– Netanel Rubin, The Perl Jam 2

Netanel starts by describing taint mode and claims that hashes are so secure, hash keys bypass Perl’s taint check. It’s true that hash keys are never considered tainted. This is documented in perlsec and discussed in depth in Chapter 2 of Mastering Perl. But it’s not because hashes are assumed to be secure, it’s because tainting hash keys involves a huge performance penalty. He never explains his claim as to why arrays are considered secure.

Perl’s ref function is a reliable and secure way to determine the data type of a reference. Arguments passed to functions are always passed as an array of scalars via @_. There is no doubt, no ambiguity. It’s not required security-wise, but if you want to use them you can use function signatures, types and meta-object programming in Perl. They’ve been available for years.

But I felt all of these points will go unnoticed without an extreme example of Perl’s absurdity. So I found an extreme example. One that will clearly show the ridiculousness nature of the language.

The issue with this code is that if $file has the value of ARGV, the diamond operator <$file> will call open on every value in @ARGV. CGI populates @ARGV with the HTTP query parameters which creates the vulnerability. So if the HTTP query parameter is ls|, Perl will execute ls. If the CGI program was running in taint mode, this attack vector would fail. Regardless, it’s a well-understood risk, the PLEAC project’s Perl recommendations from 1999 shows how to properly parse file descriptors in CGI parameters (ex 19.4). O’Reilly’s CGI Programming on the Web by Shishir Gundavaram recommended parsing metacharacters like | from user input, which also prevents this attack. That book was published in 1996.

The piping open behavior is well documented in open, perlipc and perlsec. Chapter 2 of Mastering Perl also covers it. It’s a useful feature when you want to efficiently process a lot of data from an external command: just like a shell pipe, it creates a socket between the Perl program and the external binary, avoiding the need to read the entire output into memory at once.

Netanel also identified a SQL injection vulnerability in Bugzilla. The weakness was caused by a poorly coded function which failed to properly validate input used in a dynamic SQL query. The developers should have used the safer pass-by-parameter DBIprepare and execute functions.

In both cases Perl provided methods for securely parsing untrusted input, but the developers didn’t use them.

Claim 2: Bugzilla & CGI.pm are representative of idiomatic Perl

Like every other Perl project, Bugzilla is heavily using functions that treat scalar and non-scalar argument types very differently.

– Netanel Rubin, The Perl Jam 2

Netanel is referring to this code from his talk, which uses the argument type to decide what to do:

Aside from the fact that Netanel’s code contains a big error which means it would never work, the claim that every other Perl project is coded in this way is preposterous. Dist::Zilla is a popular Perl project with over 20,000 lines of code. Can you guess how frequently Dist::Zilla uses the construct Netanel describes? A quick grep of the code shows zero instances. Bugzilla was developed in 1998, it is not an example of Modern Perl.

Regarding CGI.pm, I can’t say it better than the official documentation:

CGI.pm HAS BEEN REMOVED FROM THE PERL CORE

The rationale for this decision is that CGI.pm is no longer considered good practice for developing web applications, including quick prototyping and small web scripts. There are far better, cleaner, quicker, easier, safer, more scalable, more extensible, more modern alternatives available at this point in time.

– CGI.pm documentation

Claim 3: Perl doesn’t improve

Things get interesting during the Q&A section of the talk when an audience member says:

We use Perl for almost every module that we have at work, and it works really fine. I don’t know why you are picking Perl as a language to attack. It’s a really old language, and every language you can pick has problems, it doesn’t mean that … you have to stop using it.

The funny thing is Perl is improving all the time. Every year there is a major release of Perl which brings new features and enhancements to the language (history). Last year’s release included a new operator, the double diamond<< >> which disables the piping open behavior shown earlier. CGI.pm was removed from Perl’s core modules list in May 2014. Both of those occurrences predate Netanel’s talk.

Instead of waiting for a major release milestone, the Perl development team can fix critical security issues in a minor release if needed (for example see 5.16.3).

Perl also has a strong toolchain for evaluating Perl code. Perl::Critic is a linter that reviews Perl code against recommended coding practices. There is even a policy to check for potential SQL injection vulnerabilities.

Conclusion

You can’t always live in the fear of not knowing what data type you are trying to handle … not trusting your hashes, not trusting your arrays, what’s next, not trusting your own code?

– Netanel Rubin, The Perl Jam 2

As someone who has years of experience writing professional Perl code, and working with Perl programmers, I do not recognize this experience at all. All Netanel has shown is an attack on some example code from a neglected module and a SQL injection bug in a legacy application.

Site Map

Contact Us

License

Legal

Perl.com and the authors make no representations with respect to the accuracy or completeness of the contents of all work on this website and specifically disclaim all warranties, including without limitation warranties of fitness for a particular purpose. The information published on this website may not be suitable for every situation. All work on this website is provided with the understanding that Perl.com and the authors are not engaged in rendering professional services. Neither Perl.com nor the authors shall be liable for damages arising herefrom.