Beefy Boxes and Bandwidth Generously Provided by pair Networks
No such thing as a small change
 
PerlMonks  

Secrets & Lies & Perl

by ichimunki (Priest)
on Sep 04, 2001 at 16:49 UTC ( [id://110026]=perlmeditation: print w/replies, xml ) Need Help??

I've been reading Bruce Schneier's Secrets & Lies and frankly I'm scared out of my wits! There are so many ways to foil computer security that I'm almost afraid to touch my computer. Luckily for the machines, I've been addicted since the 4th grade and probably couldn't stop even if I wanted to.

My question is this, and I ask because some of these problems seem to plague applications written in C (and Perl is written in C as far as I know), but how vulnerable is Perl? I don't mean run of the mill CGI stuff-- we've discussed all of that to death on PM. What I'm curious about is whether Perl is susceptible to things like stack smashing or bugs related to null terminators in strings? Is printf vulnerable?

Does Perl have a history of security incidents? If I wrote a daemon that sat on my firewall to do X, Y, or Z, are there particular areas that I would want to be careful about? In my experience, most of the holes we've discussed related to Perl are not faults of the perl interpreter, but logical flaws in the scripts themselves.

What else should I be watching out for? And as a general practice, how much bullet-proofing do programmers put into code before they say that enough is enough. I mean, theoretically I could check every variable all the time to make sure it is about what I expect it to be like, I could wrap almost everything in evals to trap errors, I could go on. But how do you draw the line?

Replies are listed 'Best First'.
Perl is a secure language (as far as it can be)
by arhuman (Vicar) on Sep 04, 2001 at 17:21 UTC
    Yes Perl is vulnerable as almost every computer language.
    (Race condition,NULL poison...)
    But Perl has some feature that you could use to greatly reduce the risks :
    • Suidperl
    • The Taint mode
    • The automatic memory allocation
    • Modified (s)printf (no format string attack..)
    • Tons of open sourced robust security tools/modules : For encrypting, signing, communicating...

    Perl provides you many tools to produce safe code, but also enough freedom to screw your security...

    Anyway, to my mind, the security shouldn't be enforced by the language but by the programmer.
    You should better watch carefully your code logic to ensure security
    (this combined with a decent OS (which excludes windows ;-) should provide enough security)

    UPDATE :
    Don't hesitate to use Super Search with 'security' as keyword to find tons of interesting threads...
    Perlsec and the Camel's chapter about security should be mandatory too...

    "Only Bad Coders Code Badly In Perl" (OBC2BIP)
Re (tilly) 1: Secrets & Lies & Perl
by tilly (Archbishop) on Sep 04, 2001 at 19:44 UTC
    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': $!";
    *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...

Re: Secrets & Lies & Perl
by clemburg (Curate) on Sep 04, 2001 at 18:47 UTC

    What else should I be watching out for? And as a general practice, how much bullet-proofing do programmers put into code before they say that enough is enough. I mean, theoretically I could check every variable all the time to make sure it is about what I expect it to be like, I could wrap almost everything in evals to trap errors, I could go on. But how do you draw the line?

    A rational way to "draw the line" would be to do a risk assessment and cost/benefit analysis on your code. A good introductory discussion is provided in Chapter 2 "Policies and Guidelines" of Practical Unix and Internet Security by Simon Garfinkel and Gene Spafford.

    Also, if I recall correctly, Mr Schneier himself presents an approach to threat modeling and risk assessment in the book you mention.

    To actually "draw the line", you will have to think and decide for yourself. No magic bullets here. And it will probably not be a really "rational" decision, either.

    Christian Lemburg
    Brainbench MVP for Perl
    http://www.brainbench.com

      A rational way to "draw the line" would be to do a risk assessment and cost/benefit analysis on your code.

      This is really the only sane way to manage security. Even though there is no such thing as real, absolute security, there is such thing as more secure. This increase in security has a neccessary increase in time and manpower related to it. You just have to look at what kind of data you are handling, the sensitivity of the data, how much you care, how much time and money you have, and countless other factors, and then make a security model for yourself.

      The cost of superior security is eternal vigilance.

      redmist
      Purple Monkey Dishwasher
Re: Secrets & Lies & Perl
by hsmyers (Canon) on Sep 04, 2001 at 19:05 UTC
    I certainly agree with the advice given thus far, but—it's important to keep things in perspective when dealing with security. The mantra I usually chant is somthing like “There Is No Magic”1,which is to say that there should be a limit to the amount of paranoia in these things. After all, in order for a cracker to break security, it still comes down to executing foriegn code in your process space. And the only way for that to happen is for someone to let them (un-intentionly or not)! Sort of like vampires, they need the invitation before they can enter. I suppose that what I am saying is “Be careful, Be diligent, Be rational—but don't be more than that!”

    hsm
    1With apoligies to any elves out there...

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlmeditation [id://110026]
Approved by root
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others chanting in the Monastery: (4)
As of 2024-03-28 21:07 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found