The Perl Jam 2: The Camel Strikes Back



by Netanel Rubin

Presenting “The Perl Jam: Exploiting a 20 Year-old Vulnerability” at 31c3 opened a Pandora’s Box full of Perl debates and controversies. Many of these debates originated from the Perl community itself, with unforgiving arguments such as “vulnerabilities are the developer’s fault”, “RTFM” and “I really hate the Camel abuse in the presentation” that were mostly directed at me.

This is why I’m proud to say that this year I finally got the message – finding vulnerabilities in core modules is not enough. I need to prove there are problems in the most fundamental aspects of the Perl language, or the Perl community will keep ignoring the many language issues. So I did, and we are going to analyze it in a presentation filled with lolz, WATs, and 0-days, so maybe this time something will change.

Join me for a journey in which we will delve into more 0-days in Bugzilla, an RCE on everyone who follows CGI.pm documentation, and precious WTF moments with basically any other CGI module in the world, including (but not limited to) Mojolicious, Catalyst and PSGI, affecting almost every Perl based CGI application in existence.

I hope this talk will finally prove that developers are NOT the fault here, it’s the LANGUAGE, and its anti-intuitive, fail-prone ‘TMTOWTDI’ syntax. Btw, maybe it’s time to check your $$references 😉

7 thoughts on “The Perl Jam 2: The Camel Strikes Back

  1. Generalizing from the particular (bugzilla, an almost 20 year old code base) to the language as a whole is not really fair. Perl gives you plenty of rope to hang yourself with, but it's not like it's impossible to write well designed code. Furthermore more "considered safe" and "mandatory" and various other statements are not really objective statements of truth as the speaker makes them out to be.

    There are plenty of libraries that provide strong support for input validation, and that address some of Perl's syntactic quirks, which are being used extensively to write more robust code.

    If you have a JSON-RPC api and you shove the raw output of that into a legacy API that assumes calling conventions established in the 90s, that's a stupid thing to do in any language. It's especially stupid in Perl (though perhaps not as stupid as it would be in C?)

    The bottom line is that this feels like dated, irrelevant material and cheap shots with funny pictures to anyone who actually knows how to write good Perl code (which is certainly possible), which is why the response to this criticism is so negative (even though there is substance to the criticism)

    For example the belaboured point made around 15:00 – that's…. WTF? Everyone who's had any experience writing Perl web applications knows you do not trust user input even if it has been conveniently expanded into a hash by something that isn't CGI.pm.

    The assumption that hashes are somehow "safe" dates back to a different time, when CGI.pm was written, whose use has been discouraged from use for at least a decade. In other words, the Perl community by and large knows that CGI.pm is a pile of toxic shit, but it has failed to communicate that effectively, especially to the uninitiated.

    So 16 minutes into this talk basically the only content so far is "some prominent Perl projects carried over assumptions made in the 90s and this created security vulnerabilities when JSON RPC was added", and a whole lot of noise trying to misrepresent the consensus in the Perl community about whether such practices are a good idea (I assure you, anyone worth their salt will tell you that's a bad idea).

    As I typed this the video is paused at 17:50 and that code screams to me OH MY GOD THAT SERVER IS OWNED. But I learned that this is bad before I finished high school (read: no professional experience), 15 years ago. This is not news.

    So finally, we get to the end, where the actual point is made:

    1. Perl has some very surprising and dangerous features enabled by default
    2. There is a lot of legacy code, and a lot of people writing/maintaining that legacy code
    3. Large parts of the community are indeed resistant to change.
    4. This state of affairs is not being clearly communicated or addressed, so it's still too easy to fall down those traps which are all too common

    If these points were made a bit more carefully and diplomatically, this talk could have had a much better impact, and served to educate people, or even fix things. But reducto ad absurdum doesn't really work, especially when people are aware of the flaws in that argument.

    Unfortunately it also completely ignores all the efforts made to improve on these problems. For example, an appropriate solution for this category of bugs is to just use some form of form validation (really this isn't news to anyone with some experience in web development, certainly not in Perl). Secondly, using object oriented coding style to encapsulate data instead of haphazardly throwing it around the call stack.

    Instead of misrepresenting the Perl community as a bunch of incompetent fools burying their head in the sand, this could have contributed to a discussion about why the Perl community is not doing enough to address the mistakes of the past? That is a discussion worth having. It's a discussion that has been going on for a long time.

    In other words, the response has mostly to do with the attitude, not the content, which is a shame. And cherry picking, attacking straw men, and a sensationalist delivery is only diluting a fundamentally sound message (Perl will let you get things horribly wrong quite easily).

Leave a Reply

Your email address will not be published. Required fields are marked *