Beefy Boxes and Bandwidth Generously Provided by pair Networks Joe
Do you know where your variables are?
 
PerlMonks  

How to answer "Perl is not secure" objections?

by radiantmatrix (Parson)
on Sep 06, 2007 at 17:55 UTC ( #637487=perlquestion: print w/ replies, xml ) Need Help??
radiantmatrix has asked for the wisdom of the Perl Monks concerning the following question:

I'm used to dealing with Perl-FUD of many shapes and sizes, from "it's unmaintainable" to "it's not enterprise-ready" to "it's too slow{1}". Today, though, I got a new one. My manager's manager's manager (manager^3, for short) is trying to put the brakes on a very nice project that happens to be mostly Perl code, on the grounds that "Perl is not secure."

As far as I can tell, manager^3 believes that this is the case because 'Perl has bindings into OS calls that bypass OS security'.

Fortunately, manager and manager^2 don't buy it. Manager^2 has asked me to disprove manager^3's misgivings. Now, I can certainly explain how Perl works, but that (a)will probably be beyond manager^3's ken, and (b)manager^3 will not be convinced by just my words alone.

I've Googled quite a bit, but can't really find what I'm looking for: a good article (not on someone's blog, unless they are a well-known technologist{2}) that explains how Perl compares to .NET and/or Java in terms of security. FWIW, the application in question is to be installed on a RedHat Linux sever and run under mod_perl, so any suggestions specifically germane to that environment would be useful as a supplement to more general resources. Ultimately, any help I can get from the Monastery would be useful.

I know there are Monks here who could probably write and publish such a piece, and whose work would be respected, but I'd be happy with any reference I can get hold of. Unfortunately, time is short, I only have a few days to make my case that we don't need to ditch an entire product just because it's written in Perl.

Whatever material I find elsewhere, I will post here as well. Whatever I use, I will collect together and post, with a report on how it was received. When that happens, I will link to that post (probably a Meditation, I'd think) by updating this node as well.

Many thanks!

  1. Granted, Perl is sometimes too slow, but usually people think it's a lot slower than it really is.
  2. Doesn't have to be a household name, but someone who has done good work on something recognizable would be perfect.

Update:

Based on links provided below (thanks to those that read and understood that I needed external documentation, not just a technical explanation), and in collaboration with some savvy pro-Perl managers at my organization, I've come up with the following upper-management-friendly summary:

In general, Perl should be accepted as a secure development platform because:

  1. The Perl interpreter is a standard OS executable binary, and can be controlled like any other application
  2. Perl notices when an application is running under SetUID or SetGID, and forces "taint mode" -- a feature that requires the application validate data before passing it to potential injection targets.
  3. Perl is a virtualized environment (like Java or .Net Managed Code), and thus prevents buffer overflows and other classes of vulnerability, making it a more-secure choice than C/C++ or .Net Unmanaged Code.

Additionally:

  1. Perl is used extensively by many top enterprises:
    1. Morgan Stanley has widely been recognized has having one of the best IT departments in the financial industry: see http://conferences.oreillynet.com/cs/os2003/view/e_sess/4293, a presentation given on how Morgan Stanley uses Perl for command-line, GUI, and Web applications throughout their enterprise
    2. Citigroup, JPMorgan, UBS, Bank of America, Deutsche Bank and others all make use of Perl : http://perltraining.com.au/whyperl.html#who
    3. The Swedish government uses Perl to run its pension system: http://www.oreillynet.com/pub/a/oreilly/perl/news/swedishpension_0601.html
    4. The Canadian Customs and Revenue Agency uses a Perl-based system for document management and control (in a high-security setting): http://www.oreillynet.com/digitalmedia/blog/2002/06/perl_success_story_perl_provid.html
    5. The University Hospital of Lausanne, Switzerland manages its healthcare-billing system with Perl: http://www.oreillynet.com/windows/blog/2004/09/perl_success_story_easy_health.html
  2. Gartner's list of main app development technologies is: .Net, J2EE, and LAMP. LAMP is Linux (and OpenSolaris), Apache, MySQL (and PostGres), and Perl, PHP, or Python.

This is not entirely final, so if others have something to add, please feel free to do so.

Updates:

  • 20070907 : added marked 'Update' section

<radiant.matrix>
Ramblings and references
The Code that can be seen is not the true Code
I haven't found a problem yet that can't be solved by a well-placed trebuchet

Comment on How to answer "Perl is not secure" objections?
Re: How to answer "Perl is not secure" objections?
by starX (Chaplain) on Sep 06, 2007 at 18:19 UTC
    I know this probably isn't the sort of answer you're looking for, but maybe it would be best to ask Manager^3, in a way that makes him feel like you're complimenting his intelligence and tech savvy, that you've never heard of this and would greatly appreciate it if he could either point you to the resource he heard about Perl's "insecurity" from, or demonstrate with an example of his own.

    The first step in debunking most myths is figuring out who told them first.

      I agree about discovering the source of the myth but I disagree with your approach. It would be much better to have his managers ask the question -- they will be much more familiar with Manager^3 and doing it that way avoids going over anyone's head.

      See, I don't get to talk to Manager^3. I only get to hear the objections (filtered through others) and provide documentation to refute them.

      <radiant.matrix>
      Ramblings and references
      The Code that can be seen is not the true Code
      I haven't found a problem yet that can't be solved by a well-placed trebuchet
        Aye that's where the ugly bits and pieces of company and office politics rear their monstrous heads.

        CountZero

        A program should be light and agile, its subroutines connected like a string of pearls. The spirit and intent of the program should be retained throughout. There should be neither too little or too much, neither needless loops nor useless variables, neither lack of structure nor overwhelming rigidity." - The Tao of Programming, 4.1 - Geoffrey James

Re: How to answer "Perl is not secure" objections?
by Joost (Canon) on Sep 06, 2007 at 18:29 UTC
    'Perl has bindings into OS calls that bypass OS security'.

    The only way I can read that is as "our OS is insecure".

    Either there are legitimate bindings in the OS to bypass normal security for good reasons, and those hooks have the usual protection (i.e. you need to be root / of a specific group to call them), or there are hooks in the OS that just break security and it doesn't matter what language you're using - you could probably break them using a shell script.

      'Perl has bindings into OS calls that bypass OS security'.
      The only way I can read that is as "our OS is insecure".

      Quite. For instance, I wrote BSD::Sysctl, a module to allow you to manipulate FreeBSD sysctl kernel variables. If you're an ordinary user, you can only read the values. If you try to set a value... nothing happens (apart from an error condition returned by the kernel system call).

      You have to have superuser privileges in order to change a variable. So if you're already root, everything becomes insecure!.

      I'm sure if someone figured out how to set sysctl variables as an ordinary user in Perl, that the technique used would be completely language-independent (that is, the result of an exposed flaw in the OS).

      • another intruder with the mooring in the heart of the Perl

      You didn't understand the sentence you quoted, not at all, and your own first sentence has absolutely no logic.

      You assumed that OS is one thing, which is a bad assumption. Then you reasoned: if it is not secure to call A, then A is not secure.

      The fact is that OS is not one thing, it is many things - many layers. It is insecure to call layer B if you bypass layer A that was supposed to provide security.

      read my oppinion that I just provided as reply to one of tilly's post... really people should learn some philosophy and logic.

        You didn't understand the sentence you quoted, not at all, and your own first sentence has absolutely no logic.
        I disagree.
        You assumed that OS is one thing, which is a bad assumption. Then you reasoned: if it is not secure to call A, then A is not secure.
        I still do, and here's why: From the point of view of an application programming language, the OS is - more or less - a black box that provides services.

        The quote was 'Perl has bindings into OS calls that bypass OS security'.

        Now, there are calls in every OS that bypass 'normal' security protocols, but it's up to the OS to make sure that the application calling those hooks have the appropriate permissions to do so. For instance, a user on unix can create a file/tree that no other user can read or modify. The exception is, that processes running as root can. That is not 'bypassing security', that's providing exceptions to the normal protocol for system administration purposes.

        If there was a way for a normal user to modify another user's files (again, given restricted rwx permissions) that would be 'bypassing security'. It would also be bug in the OS and not any kind of problem with the programming language that exploits the bug.

        The fact is that OS is not one thing, it is many things - many layers. It is insecure to call layer B if you bypass layer A that was supposed to provide security.
        Again, if the OS is supposed to provide that security under certain conditions, it should make sure that that security is provided under those conditions. The OS should not blindly trust a program without elevated permissions to do the right thing, it should enforce its policies.

        read my oppinion that I just provided as reply to one of tilly's post...
        I would if I could find it.
        really people should learn some philosophy and logic.
        I have. If you want to convince me of your opinion, please explain your standpoint, because just asserting that I'm wrong and undereducated isn't going to convince me - and it's rude.

Re: How to answer "Perl is not secure" objections?
by kwaping (Priest) on Sep 06, 2007 at 18:51 UTC
    I have a feeling manager^3 was thinking about Perl's setuid functionality. I found this interesting (though out-dated, I believe) write-up about Perl's setuid features in context of security.

    http://www.cs.cmu.edu/People/rgs/pl-suid.html

    ---
    It's all fine and dandy until someone has to look at the code.
      Of course, large projects should never be run setuid anyway. Any setuid program in any language should be as small as possible, do as little as needs to be done setuid, then hand off to non-setuid executables.
        Regardless of the problems that running SUID programs (and SUID interpreted scripts in particular) can cause, note that you need to have root permissions in order to make anything SUID root.

        I might as well claim that all languages are insecure because I could code something destructive and run it using sudo.

        These kinds of issues should, for the most part, be solved by using sane system administrator (to make the policies) and a sane OS (to enforce the policies).

Re: How to answer "Perl is not secure" objections?
by perrin (Chancellor) on Sep 06, 2007 at 18:52 UTC

    Is he a Java guy? If so, he's probably thinking of how Java can prevent programs from accessing certain things (e.g. the filesystem). However, since any non-trivial Java program needs to access the filesystem, this type of permission will be granted immediately. It's more relevant for things like applets than it is for programs you would write in-house.

    In terms of things to read, here are three good ones:

    The most important point to make, IMO, is that security is a feature of programmers and their process, not of languages. There is no reason to think that a .NET or Java program that accessed a database and some files is more secure than a Perl program that does the same.

      Is he a Java guy?

      No, he's upper management. We're beyond the pale of tech-savvy at this point. The guy believes this because someone he trusts (probably a vendor) told him so. What I'm looking for is essentially literature that talks about how secure Perl is, or speaks to other big-name orgs using Perl for "high-risk" data like financial transactions. Something digestible for the upper-manglement set.

      <radiant.matrix>
      Ramblings and references
      The Code that can be seen is not the true Code
      I haven't found a problem yet that can't be solved by a well-placed trebuchet
        Well, Amazon.com and TicketMaster.com run millions of dollars of business through their websites, which are written in perl. That seems like a pretty solid case to me.
        As was told during the latest YAPC::EU job fair, VERISIGN uses Perl!

        If I remember well, they have about a million lines of Perl code in their applications and they are still actively seeking Perl programmers (see Perl Jobs).

        If Perl was inherently insecure, should a company like Verisign use it?

        CountZero

        A program should be light and agile, its subroutines connected like a string of pearls. The spirit and intent of the program should be retained throughout. There should be neither too little or too much, neither needless loops nor useless variables, neither lack of structure nor overwhelming rigidity." - The Tao of Programming, 4.1 - Geoffrey James

Re: How to answer "Perl is not secure" objections?
by mr_mischief (Prior) on Sep 06, 2007 at 19:50 UTC
    Perl, as a language, is much more secure than C or any other language that can have buffer overruns. http://www.computeruser.com/articles/2202,5,36,1,0201,03.html is a magazine article on buffer overruns and mentions Perl and Java as technologies to use to avoid the whole class of issues.

    CERT's advisories page lists 31 advisories that in some way mention Perl. It has 2 for C#, 13 for Visual Basic, 56 for IIS, and 65 for Apache. Guess what? Nearly all of the Perl mentions are example exploits written in Perl of security issues in other projects. So you're seeing far fewer security advisories for your language than for the platform you'll be using to serve it. That should give some perspective.

    .NET is not a convenient search term for CERT's database. Over at SecurityFocus, on the search by vendor page http://www.securityfocus.com/bid, Microsoft's .NET framework has 16 vulnerabilities listed as far back as 2002, with only two marked as 'retired'. To be fair, many of these only list past versions, but still have not been retired. Some of them are as new as July. Perl 5.8.0 from the perl5porters has 0.

    On the BugTraq archive, I currently see no reference to Perl in the most recent five pages. PHP is the only language I noticed, with 5 vulnerabilities listed on page 1. The Linux kernel, vim, emacs, tar, OpenBSD, VMWare, Kerberos, postfix, and Thunderbird make the five most recent pages. Again, your programming language of choice has better numbers than the platform you'd use to host the code.

Re: How to answer "Perl is not secure" objections?
by zentara (Archbishop) on Sep 06, 2007 at 20:17 UTC
    because 'Perl has bindings into OS calls that bypass OS security'.

    I would press him to prove that point. It sounds like he is on a weak OS (Windows :-) ), that uses "voluntary cooperation" to maintain security.

    Maybe he is thinking of a "limited cgi runtime environment plugin" like Java has. I wish Perl could get a Browser plugin like Java's. That is about the only disadvantage that Perl has. I'm seeing alot of pages with dynamic graphing apps, using the Java Browser Plugin. Then again, a combination of a perl cgi and flash animation is about as good as Java's plugin.


    I'm not really a human, but I play one on earth. Cogito ergo sum a bum
      Java on the server side usually doesn't have the same kind of sandboxing as Java on the browser, so you have a good point but the comparison for server-side work may not hold. I've often wished I could use Perl on the user's browser rather than JavaScript, ActionScript, or HaXe. One thing that might be nice is if we could have a Perl to Flash compiler similar to what HaXe has.

      As for securing Perl more on the server, a perl with a small default @INC can be done easily enough. There are taint mode and Safe.pm to help with boxing in data and code. The installed modules could be kept minimal. Perl supports chroot (although only root can do that).

      It should be possible (I'm not saying 'easy') to run both Apache and perl (or Apache with mod_perl) chrooted in the first place if security is at such a high priority. That's a pretty language-independent way to help with security. Things such as ulimit and a good IDS help no matter the language, too.

      One thing to keep in mind is that the ability of the programmer to do something doesn't mean it's possible for the site's end user. Any system written in any language which does stupid things with end-user data poses a security risk, no matter the sandbox restrictions. XSS proves the server itself doesn't even have to be vulnerable to cause a security issue -- it can create a security issue for the user even if it is entirely protected.

        While we are on the subject, of a "Perl browser plugin" , like the libjavaplugin_oji.so in our browser's plugin directory; what has stopped the Perl developers from doing this? From my limited understanding, the java plugin is just a java interpreter with the functions which pose a security risk removed, leaving only simple computational and display functions, and which limits display in the parent's (browser's) allocated window.

        When I build Perl, I see the mini and micro Perl interpreters, which are limited versions. Would it be that hard to modify those to be a secure browser plugin? Then maybe add a chopped-down Tk or Gtk2 display engine to it? Now I wish I studied c in more depth. :-)


        I'm not really a human, but I play one on earth. Cogito ergo sum a bum
Re: How to answer "Perl is not secure" objections?
by derby (Abbot) on Sep 06, 2007 at 21:30 UTC

    Hmmmm ... I think public ridicule and humiliation are your best bet. I would suggest setting up a fake blog that describes a similar situation (make sure you date it for about two or three years ago). Seed it with a bunch of comments that don't specifically answer the red-herring question of security but answers that ridicule the question. Once you have that up and running, submit it to digg or reddit and have your friends and coworkers upvote it. Once it's on the front page, just casually mention to manager and manager^2 what you've found during your *research*. Hopefully that will flow up (or down) and manager^3 will see the question as pretty irrelevant.

    Okay ... it's either that or just tell manager^3 you think his question is silly -- you want a new job anyways.

    -derby

    Update: Just humor people ... I think perrin's answer is probably the best so far.

Re: How to answer "Perl is not secure" objections?
by lyklev (Pilgrim) on Sep 06, 2007 at 21:47 UTC
    There is some truth in the manager^3's fear: if you are running Perl through mod_perl on apache without any security in mind, the application runs with the privileges of the web server. If that is root, you have a problem.

    As far as I remember though, Red Hat locked apache down by changing to some "nobody/nogroup" user after starting. If it is RH Enterprise 4 or later, SELinux might be used to further lock down the server. To such an extent that it might be a pain to get mod_perl running at all.

    The bottom line is that mod_perl can be a security hole if the system has bad administration. With good administration (chroot, changing user/group after startup), mod_perl can be perfectly secure. It can never bypass OS security, but it can use the permissions it was granted.

      the application runs with the privileges of the web server. If that is root, you have a problem.

      No, you have two problems - the first of which is solved by firing your system administrator.

      Red Hat locked apache down by changing to some "nobody/nogroup"

      No, apache has done that from (very nearly if not) the start. Various distributions will change the username and/or group, but the net effect is that apache needs to be launched as root to bind to a privileged port (< 1024) and then drops privileges to as unprivileged a user as possible.


      --chargrill
      s**lil*; $*=join'',sort split q**; s;.*;grr; &&s+(.(.)).+$2$1+; $; = qq-$_-;s,.*,ahc,;$,.=chop for split q,,,reverse;print for($,,$;,$*,$/)
Re: How to answer "Perl is not secure" objections?
by perlhaq (Scribe) on Sep 06, 2007 at 22:02 UTC
    Perl is installed by default on OpenBSD (i.e., in the base system, not as a port or package). Perhaps you can add this as a bullet item on your list...
      Granted, this is arguing from authority, but if something's secure enough for Theo de Raadt, just how insecure can it be? He is not known for a relaxed attitude about this.
Re: How to answer "Perl is not secure" objections?
by Anonymous Monk on Sep 06, 2007 at 23:36 UTC
    Hi radiantmatrix,

    manager^2 and manager^3 are squaring and cubing the 'r' respectively. I think you meant:

    (manager)^2 and (manager)^3
    The lone manager is understood to have an exponent of 1.

    ;-D

    ~DigitalKitty
    Too lazy to log in.
      DigitalKitty,

      Are you sure ^ binds stronger than the characters within a word?

      CountZero

      A program should be light and agile, its subroutines connected like a string of pearls. The spirit and intent of the program should be retained throughout. There should be neither too little or too much, neither needless loops nor useless variables, neither lack of structure nor overwhelming rigidity." - The Tao of Programming, 4.1 - Geoffrey James

      How does the xor operator result in exponentiation? Did you mean ** instead??

      :-P

Re: How to answer "Perl is not secure" objections?
by tirwhan (Abbot) on Sep 07, 2007 at 00:13 UTC
    'Perl has bindings into OS calls that bypass OS security'

    That sentence makes no sense at all. The 'bindings' Perl has to 'OS call's (read: system calls) are subject to all the normal security restrictions the OS imposes. Regardless of whether you program in Shell, Perl, Java, C or whatever (well, perhaps not Logo), you will be able to access these system calls, subject to the OS's restrictions. So it all comes down to the question of "is your OS secure" and has nothing at all to do with the programming language chosen.


    All dogma is stupid.

      Yes, I know it's silly. The question is how to tell manager^3, since he won't just take my word for it. Saying "nuh uh" isn't really sufficient.

      <radiant.matrix>
      Ramblings and references
      The Code that can be seen is not the true Code
      I haven't found a problem yet that can't be solved by a well-placed trebuchet
Re: How to answer "Perl is not secure" objections?
by runrig (Abbot) on Sep 07, 2007 at 00:18 UTC

    M^3: Perl has bindings into OS calls that bypass OS security
    radiantmatrix: Name one.
Re: How to answer "Perl is not secure" objections?
by dk (Chaplain) on Sep 07, 2007 at 08:04 UTC
    I'd say this is a matter of trust. If manager^3 trusts other peoples' opinions more than of his own perl guru, well, anything you dig up is doomed not to be weighed anyway. Also, seeking an article that specifically debunks an arbirtatry remark about anything (in your case, about Perl's insecurity), I think, is not really a sufficient strategy by itself, because "fools ask questions that wise men cannot answer".

    Following this, if I'd be confronted with "Perl is insecure" I'd answer "this is not true" without further explanations; if the other side would be then interested in a dialog, then definitely articles, examples, and documentations can be discussed. Or, simply put, now you are prepared to discuss articles with a reasonable person, and I'm saying that it might not necessarily be so.

Re: How to answer "Perl is not secure" objections?
by pajout (Curate) on Sep 07, 2007 at 11:30 UTC
    My experience is that the crucial point of security is quality of code. The programming language can only slightly help, but cannot guarantee some reasonable security.

    From my perspective, why m^3 does not specify the security requirements of particular applications? It would spare his time when he will not concentrate on technical specialities, for instance, programming language...

Re: How to answer "Perl is not secure" objections?
by moritz (Cardinal) on Sep 07, 2007 at 12:02 UTC
    You have to distinguish between perl (the compiler/interpreter) and Perl (the language).

    As for the program, I'd like to point you to the Common Vulnerabilities and Exposures List, search for Products -> Perl (don't enter 'perl' in the search box, it will find 'properly' as well).

    Now compare these results to other interpreters and virtual maschines.

    As for the language: you don't have to mess with your memory on your own (like C), you have tainting, no insecure register_globals (or whatever that stuff is called in PHP).

      13 vulnerabilties for product "Perl" since 1999 and the last one dates back from 2005!

      Compare this to PHP, which has 185 vulnerabiities since 2000, with the last one in April 2007.

      CountZero

      A program should be light and agile, its subroutines connected like a string of pearls. The spirit and intent of the program should be retained throughout. There should be neither too little or too much, neither needless loops nor useless variables, neither lack of structure nor overwhelming rigidity." - The Tao of Programming, 4.1 - Geoffrey James

Re: How to answer "Perl is not secure" objections?
by mr_mischief (Prior) on Sep 07, 2007 at 18:13 UTC
    Regarding your update, there are some very strong other references about who uses Perl:
    • The Linux Journal article in which Larry Wall says, "A couple of years ago, I ran into someone at a trade show who was representing the NSA (National Security Agency). He mentioned to someone else in passing that he'd written a filter program in Perl, so without telling him who I was, I asked him if I could tell people that the NSA uses Perl. His response was, ``Doesn't everyone?'' So now I don't tell people the NSA uses Perl. I merely tell people the NSA thinks everyone uses Perl. They should know, after all."
    • Larry's State of the Onion 9 speech in which he mentions that Perl was designed to deal with needs for programming projects within an NSA project.
    • Someone's info on what could be important for an internship with the NSA which mentions programming in Matlab, Mathematica, maple, C++, Java, C, Unix, Linux, Perl, Python, and MAGMA
    • Searching http://www.nsa.gov for 'Perl' using the built-in search returns no fewer than 80 results. Many of these are examples of how to test security on SELinux.
    • The NSA guide to securing IIS 5.0, which states that setting up Perl (and ASP) properly under IIS with handler configuration is an acceptable security move while setting up external executables under IIS is dangerous.
    If the NSA doesn't know information system security, your boss has no one left to trust.

    Update: fixed a couple of typos.

      Thanks for the NSA reference! I casually mentioned it in a meeting where Manager^3 was present, and I think that nugget may have sealed the deal and kept us from tanking a successful project. Thank you so much!

      Updates:

      • 20070912 : tanking, not "taking". Whoops. ;-)

      <radiant.matrix>
      Ramblings and references
      The Code that can be seen is not the true Code
      I haven't found a problem yet that can't be solved by a well-placed trebuchet

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: perlquestion [id://637487]
Approved by FunkyMonk
Front-paged by almut
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others studying the Monastery: (3)
As of 2014-04-21 00:50 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    April first is:







    Results (489 votes), past polls