Perl is a far more secure language than C.

The single biggest historical security problem has been the buffer overflow. (Microsoft is making a valiant attempt to make poorly designed macro scripting surpass it, but they still have a ways to go. Even with SirCam spewing private files everywhere, it was a buffer overflow exploit, Code Red, that got the press...) The buffer overflow is very simple. The programmer allocates a data structure, assumes that they allocated enough and doesn't validate that assumption. Therefore someone can exploit it by just throwing out a lot of data to get past the buffer, and then put something in the section past the buffer.

OK, now that is the theory. You know from their ubiquity that they are hard to avoid in C. Now try to write one in Perl.

Give up?

Well some here know how to do it, but most do not. It certainly isn't something you tend to do by accident in Perl. This bug, the single biggest security problem year in, year out, is one you don't get if you use a language that does dynamic allocation of data structures and run-time bounds checking followed by reallocation if need be. A bug that is virtually impossible to avoid in assembly, C, C++, etc is very hard to write in Perl, Java, Lisp, Smalltalk, etc. (Incidentally the right way to avoid it in C is to write a library that does dynamic allocation of data structures and only use that library. You won't be hearing about buffer overflows in qmail any time soon...)

Now security holes in perl, do they exist? Undoubtably. The last big one was over a year ago, when it was discovered that suidperl would call sendmail as root, and you could get a root compromise by having the wrong thing in your environment variables. (A nice portable local root exploit. Lovely.) However perl's security record on the whole has been very good.

In fact good enough that you get things like Perl in Top 50 Security Tools ...

How about security holes in Perl code? Oh, yes. All of the time. The single biggest cause is letting something get near the shell without validating the input. It doesn't matter how good Perl is internally, if you let the shell get garbage in, you can get amusing garbage out. Things like:

my $file = param("input");
open (FILE, $file) or die "Cannot read '$file': $!";
[download]

*ahem* I just have to put a filename that starts with "| " and it will be executed as a program. I could mail your sysadmin your password file with a warning for a subject. Or I could get mean about it...

There are a lot of gotchas like that. But most of them are caught for you automatically by Perl if you just use taint checking and are restrictive about what you validate. (Hint: Validate by passing stuff according to rules that are guaranteed to be absolutely safe. If you try to just catch exploits you know about, you will fail.) So if you care about being secure, you can be fairly good about it in Perl with reasonably little work. Of course the last 5% of the way is not so easy...

---

---

• Are you posting in the right place? Check out Where do I post X? to know for sure.
• Posts may use any of the Perl Monks Approved HTML tags. Currently these include the following:

  <code> <a> <b> <big> <blockquote> <br /> <dd> <dl> <dt> <em> <font> <h1> <h2> <h3> <h4> <h5> <h6> <hr /> <i> <li> <nbsp> <ol> <p> <small> <strike> <strong> <sub> <sup> <table> <td> <th> <tr> <tt> <u> <ul>

• Snippets of code should be wrapped in <code> tags not <pre> tags. In fact, <pre> tags should generally be avoided. If they must be used, extreme care should be taken to ensure that their contents do not have long lines (<70 chars), in order to prevent horizontal scrolling (and possible janitor intervention).
• Want more info? How to link or How to display code and escape characters are good places to start.