4 ms·
>People will hate me for saying this... Here comes the first pitchfork-bearer! Are there ready examples of what makes the usage of Perl a security liability?
by bgilroy26 14y ago
>People will hate me for saying this...
Here comes the first pitchfork-bearer! Are there ready examples of what makes the usage of Perl a security liability?
By grouping PHP and Perl together, it seems like the security issue you're highlighting is websites made by inexperienced programmers. Perl is much worse than PHP in this regard owing to the fact that Perl's history of being used by people building their first website goes back further than PHP's does.
The last time that I recall Perl being in the news for security was in the first quarter of this year when they were patching up the DDoS vulnerability in Ruby and Python [1] whereas Perl and CRuby had addressed the vulnerability in question in 2004.
I would argue that at least since 2007 or 2008, that the Perl programming demographics have shifted significantly and that most restauranteurs and florists who are trying their hand at making a page for their SMB are using PHP. At this point I would venture that the fat part of the bell curve of the Perl web programming population would be systems administrators who venture outside the bounds of their automation scripting domain.
Given the stereotypical sysadmin, I would posit that they might tend to spend extra time and energy on security (in building some script-y spaghetti monstrosity).
1. http://arstechnica.com/business/news/2011/12/huge-portions-of-web-vulnerable-to-hashing-denial-of-service-attack.ars http://arstechnica.com/business/news/2011/12/huge-portions-o...
- daeken 14y ago> Are there ready examples of what makes the usage of Perl a security liability? The `open` function used on untrusted input allows arbitrary code execution (I've gotten privilege execution via setuid perl scripts many times this way, as well as getting a shell on the box via web apps allowing this). While there are many other common things I saw in real world apps, e.g. perl scripts using backticks for command execution and allowing me to run anything I wanted, the `open` one is by far the worst. It's insanely pervasive and incredibly easy to do.
- bgilroy26 14y agoThose sound like two good leads, thank you!
- peteretep 14y agoIf your web application is opening and closing files based on user input, without checking them first, you have bigger issues. Blaming this on the language seems bizarre.
- jkn 14y agoTrue but perl makes it amazingly easy to exploit. Suppose that you know the source contains this line: open(file_handler, "$userinput"); How much work and what assumptions do you need to exploit this? In perl it's that easy: $userinput = "cat /etc/passwd |zenity --text-info |"; open(file_handler, "$userinput");
- bgilroy26 14y agoDo you usually try $UserInput $Userinput $userInput $user_input etc. when you do that? It couldn't run your code if it had an uninitialized variable in it, right?
- jkn 14y agoIt's vulnerable because the user controls the content of $userinput, the variable name doesn't matter. Real code would look like this: #!/usr/bin/perl print "Enter filename: "; $filename = <STDIN>; open(file_handler, "$filename"); If you see this code, you know that you can execute any command by giving it at the filename prompt and appending a '|' character. For example giving cat /etc/passwd |zenity --text-info | will popup a dialog with the content of /etc/passwd.
- bgilroy26 14y agoOh I see, I thought you were talking about something that would be caught by the interpreter if you put use strict; and use warnings; in there. Thank you for taking the time to put in an example, I understand you better now.
- peteretep 14y ago> Suppose that you know the source contains this line Then you have a massive damn problem, and you could set up the same strawman about almost any language - if you're starting from the premise that you are piping arbitrary user input to a system call unimpeded, all bets are off. Shall we try some other examples? Let's say you accept input from a user, and dump it unchecked in to output shown to the user via Ruby. OH NOES! Ruby is insecure because it supports CSRF! Or, let's say you use Python and pass in input from a user unimpeded straight to the database without using the quoting mechanisms! OH NOES! Python is insecure because it enables SQL injections! etc etc etc But wait! you say... Sensible programming languages have specific features to stop these kinds of attacks! And you're right. That's why Perl has taint mode... for when you're dumb enough to pass user input straight to open: http://perldoc.perl.org/perlsec.html#Taint-mode http://perldoc.perl.org/perlsec.html#Taint-mode
- chromatic 14y agoThe `open` function used on untrusted input allows arbitrary code execution... ... only if you use the insecure open form. The secure open form has been available and recommended since the release of Perl 5.6.0 in March 2000--twelve years ago. People who write insecure code, when the language makes it just as easy to write secure code, are to blame for insecure code.
- ArbitraryLimits 14y ago> People who write insecure code, when the language makes it just as easy to write secure code, are to blame for insecure code We're not discussing who's to blame, we're discussing whether there's anything to assign blame for.
- chromatic 14y agoCan you name a practical language in which it's not possible, by default, to perform an unsafe operation with untrusted user input? I can easily use Haskell's type system to disallow the use of UnsafeUserInput in my database abstraction layer, but that requires me to use my types pervasively and correctly.
- SamReidHughes 14y agoThe question is not whether it is POSSIBLE.