Slash Boxes
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

Ovid (2709)

  (email not shown publicly)
AOL IM: ovidperl (Add Buddy, Send Message)

Stuff with the Perl Foundation. A couple of patches in the Perl core. A few CPAN modules. That about sums it up.

Journal of Ovid (2709)

Wednesday February 02, 2005
11:54 AM

Is Perl unsafe?

[ #22986 ]

I recently received an email whose question was quite reasonable but surprised me nonetheless. In my CGI course, I harp on security quite a bit. Don't do this. Don't do that. Really don't do that one!

The author of the email, however, started to wonder if Perl was more dangerous than other languages due to all of these warnings. He has experience with JSP, ColdFusion, PHP, etc. He wrote "I don't remember that the issue of code security in any of these environments was as serious as it appears to be for CGI/Perl." He wondered if perhaps Perl is more vulnerable than those other tools and should he therefore not use it?

On the surface, this question seems silly. However, it's not. Programmers are so rarely exposed to security issues that when they arise, they're frequently a surprise. Personally, I've never taken a programming class where I can remember the issue being raised. In fact, glancing through my texts on various languages I see that security is rarely if ever mentioned. As a result, my course seems out of step with current pedagogy, though I'm unlikely to change it. If anything, I'll add more security information.

In any event, what follows is my (edited) reply to his question.


Actually, the short and easy answer is: those other languages are just as dangerous.

The long answer is a bit more complicated, but I'll try to keep it brief.

Security takes many forms. "Promiscuous" code is a serious problem with any language, for example. Storing a username and password in a cookie or giving an attacker too much information by telling her "what failed and why" is a systemic problem. Leaving default or easily guessable passwords or letting someone try to log in as many times as they like without locking them out is nother common problem. Perl has nothing to do with this.

Other issues tend to be less visible but are also global. For example, SQL injection attacks are extremely common (you can google for them). If you can type a single quote mark into a form field and the script throws an error, that's a strong indication of the problem. (For some reason, I've seen this quite a bit in ASP code.) Another common problem would be storing user-supplied data in a database and later showing this on a Web page without escaping HTML entities. This is one of the ways cross-site scripting attacks are born. Perl also has nothing to do with this, though it can be handled wrong in Perl just as easily as other languages.

All tools have their specific weaknesses. The only Perl-specific hacks that I can think of right off the top of my head are null-byte hacks and algorithmic complexity attacks. The latter has been fixed in the latest versions of Perl and the former tends to be very uncommon (I've never heard of it actually being exploited.)

And the single most common security exploit -- buffer overflows -- is something Perl is not vulnerable to. (And Perl also tends not to suffer from "off by one" errors which are one of the most common sources of bugs, but that's another story.)

Perl, however, offers "taint mode." Very few languages do this. With taint mode, when Perl detects you're trying to do something unsafe with insecure data, it simply kills the program rather than allow things to proceed. This is one of the strongest protections against attack that any language can provide. I'm at a loss to know why this useful technique is not more widespread.

The reason you probably are not as aware of this is simple: not many people know much about security. Good Web programming courses in other languages would cover this stuff in depth, but they don't. This is one of the many reasons why you read about computers getting hacked all over the world. People's awareness of this issue simply has not been raised. Admittedly, some might think I'm being alarmist, but few fault my security advice.

And in a related anecdote which illustrates the problem well, a few years ago I was applying for a job working with Perl and C. The owner of the company was showing me one of their flagship products: a custom Web templating language. This was a proprietary language I had never seen before, but only a few seconds after he started showing me I mentioned that their code appeared to make them vulnerable to an SQL injection attack. The owner looked at me strangely and said "we've been selling this for years and only discovered that a couple of weeks ago."

A few minutes later, I noticed that they appeared to be creating cookies with sequential session ids. This allows for easy session hijacking and is a huge vulnerability.

This was a product that professionals had been developing for years and I, out of blind luck, looking at a language I had never seen before, spotted common serious security issues. I knew there were going to be many of them and I elected not to take the job they offered.

Trust me. This is not a Perl issue. Any time you expose your computer to other computers via a network you tremendously raise the chances that it will be attacked and compromised. I'm just doing my part to ensure that Perl programmers are not responsible for creating more victims :)

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
More | Login | Reply
Loading... please wait.
  • I think that's a typical attitude though. I often encounter Java programmers who assume there is nothing they would need to think about with regard to security because Java will magically do it all for them.

    On the other hand, people like Chris Shiflett can make good money fixing security problems in other people's PHP code, and I wouldn't want to deny him his rent. Bring on the bad code!
  • You should add that reply, or something like it, to the course.
  • I now understand enough about security, to know that I don't actually know all that much. I'm now more careful than I use to be, and I think the code I write is safe enough.

    This week I've started to learn about a SAP system. For security reasons the root password on the AIX and Linux boxen it runs on are changed every 90 days - an unpopular feature that an auditor insisted on, yet nobody bats an eye lid that they are all running telnet, rsh and NFS unprotected on the company intranet. Contrasting this we

    -- "It's not magic, it's work..."
  • In most of the Stonehenge courses we talk about security, and we definitely hit it hard in the CGI course. We even have a separate course for web security where we try to cover everything. It's not that Perl is the problem, but that task, since you can make the same design and configuration problems in almost any language.

    I think the difference with open source stuff is that we are willing to talk about it and fix it. Most people don't see it that way though: they don't want to hear about it.
  • When you compare perl to other languages, it has a much more security-aware in its main user-base and is designed to be secure as much as possible.

    Things like a wide variety of ready-rolled strong encryption libraries and integration with standard SSL and SSH libraries, as well as the taint mode put it well ahead of languages like PHP, ASP and Cold Fusions.

    The culture of testing and defensive programming is also stronger than in some other cultures - Java programmers are certainly hot on testing (at lea


    @JAPH = qw(Hacker Perl Another Just);
    print reverse @JAPH;
  • ... of how an attack might happen, might open their eyes. I find SQL Injection Attacks by Example [] a very readable intro... and it's language neutral.