Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Perl Jam: Exploiting a 20 Year-old Vulnerability [pdf]

events.ccc.de

Post reply on HN
Print view View original

31–40 of 44 posts

Re: The Perl Jam: Exploiting a 20 Year-old Vulnerability [pdf]

#31

Post by kbenson »

D3ve1inE wrote: post #25

Hi guys, Netanel Rubin here. First of, I'm not a Pythonist. Python has nothing to do with the faults of Perl - Perl does. Perl was a great language back at the 90's and early 2000 - it doesn't now. That is mainly because of the 'write-only' code style and many not-that-intuitive behaviors other languages practice better. It is true that my talk was based on bad programming practices, but that's the practices actually…

From the changelog of the latest release of Perl: "CGI has been upgraded from version 3.63 to 3.65. NOTE: CGI is deprecated and may be removed from a future version of Perl."

You can still make arguments about list handling in Perl, but using a deprecated module, which has been understood by the community for years to be problematic and exists mostly for backwards compatibility, does not bolster your argument, it does the opposite.

Using large monolithic projects that were started 10+ years (Twiki: 1998, Movable Type: 2001, Bugzilla: open sourced by Mozilla in 1998) ago also doesn't lend itself well towards pointing out modern usage of Perl.

Feel free to make any argument you want, but you should use relevant examples if you hope to be taken seriously.

Edit: Typo fix: s/not be problematic/be problematic/

Re: The Perl Jam: Exploiting a 20 Year-old Vulnerability [pdf]

#32

Post by kbenson »

eCa wrote: post #30
D3ve1inE wrote: post #25

Hi guys, Netanel Rubin here. First of, I'm not a Pythonist. Python has nothing to do with the faults of Perl - Perl does. Perl was a great language back at the 90's and early 2000 - it doesn't now. That is mainly because of the 'write-only' code style and many not-that-intuitive behaviors other languages practice better. It is true that my talk was based on bad programming practices, but that's the practices actually…

My main problem with the talk is not that you make fun of Perl (every langauge is easy to make fun of), but that you don't seem to have more than a superficial grasp of Perl. No one that doesn't understand a language should make recommendations as to its use. A couple of examples: * "You need to backslash the variable" (near-quote) - no, you need to pass the array as a reference (which can be done in several ways). *…

No to mention, CGI is deprecated in the latest Perl release.

Re: The Perl Jam: Exploiting a 20 Year-old Vulnerability [pdf]

#33

Post by Pxtl »

sarciszewski wrote: post #16
Pxtl wrote: post #12

Earlier quoted context omitted.

I'd say that the problem has more to do with SQL and respective APIs than anything else. The fact that SQL injection happens so freaking often despite the fact that it's pretty simple to avoid should speak volumes.

How would you solve this problem? Parameterized queries are already a thing and ORMs are all the rage ;)

I prefer ORMs, but they're a lot of overhead to get set-up so I don't blame others for using strings where appropriate... and every parametrized query API I've ever used has been a tremendous PITA which is why people throw up their hands and say "screw it, I'll just escape the quotes!". And of course, the database API could provide a good method to do that but nobody ever does because it's impossible to do it securely (and that's definitely a fault in SQL).

Re: The Perl Jam: Exploiting a 20 Year-old Vulnerability [pdf]

#34

Post by laumars »

Pxtl wrote: post #33
sarciszewski wrote: post #16

Earlier quoted context omitted.

How would you solve this problem? Parameterized queries are already a thing and ORMs are all the rage ;)

I prefer ORMs, but they're a lot of overhead to get set-up so I don't blame others for using strings where appropriate... and every parametrized query API I've ever used has been a tremendous PITA which is why people throw up their hands and say "screw it, I'll just escape the quotes!". And of course, the database API could provide a good method to do that but nobody ever does because it's impossible to do it securel…

Have you used parameterized queries in Perl? It's the same DBI API and only about 3 or 4 additional lines. Plus you can easily abstract that away into a little helper function if you desired.

I'm on my phone at the moment but I'd be happy to post some example code later if you want it?

Re: The Perl Jam: Exploiting a 20 Year-old Vulnerability [pdf]

#35

Post by danielki »

OMGWTF wrote: post #11
laumars wrote: post #10

I love how he is building his own SQL string and then blaming Perl's DBI->quote for any vulnerabilities that arise. Anyone who writes SQL like that is writing bad code from the offset (regardless of the programming language nor it's DB/web frameworks). Parametrised queries and ORMs exist to prevent the kind of SQL injection attacks he's demonstrating and Perl's various DBD modules already support parametrised queries…

I think $sth = $dbh->prepare("SELECT document FROM table WHERE tag=? AND security_level=?"); $sth->execute(foo(), $user_level); breaks as well, if foo() unexpectedly returns a list.

The following won't break (at least not in the bad way), I don't think:

    $sth = $dbh->prepare("SELECT document FROM table WHERE tag=? AND security_level=?");

    $sth->bind_param(1,foo());

    $sth->bind_param(2, $user_level);

    $sth->execute();

Re: The Perl Jam: Exploiting a 20 Year-old Vulnerability [pdf]

#36

Post by xorcist »

D3ve1inE wrote: post #25

Hi guys, Netanel Rubin here. First of, I'm not a Pythonist. Python has nothing to do with the faults of Perl - Perl does. Perl was a great language back at the 90's and early 2000 - it doesn't now. That is mainly because of the 'write-only' code style and many not-that-intuitive behaviors other languages practice better. It is true that my talk was based on bad programming practices, but that's the practices actually…

I love it how you picture anyone disagreeing with your conclusions,that Perl is somehow a "bad" language and everyone should just stop using it, as being (a) old and (b) think of Perl as "their" language.

You did find a real vulnerability in a common misuse of the 20 year old CGI module. What you did was good. Those were real bugs and should be fixed, and CGI.pm shouldn't have been designed that way in the first place.

But those bugs lingered for a reason. Nobody uses CGI anymore, expect for a handful of packages (of which you found three). There is no reason to stop using Perl because CGI is badly designed. There are plenty of reasons to criticise it, but at least take five minutes to get a basic grasp of the language syntax before doing so. The existance of variable contexts (which is the language feature where you can ask to flatten a list or count the elements by the calling convention alone) is simply not it.

Perl is a stable systems integration language with rock solid bindings to big database systems. The only language that even comes close is Python. The declarative object model of Moose can give you many features of a strongly typed language, and with the heavy focus on testing being ingrained in the community, it can be quite useful. That you should stay away from CGI in 2014 goes without saying.

Re: The Perl Jam: Exploiting a 20 Year-old Vulnerability [pdf]

#37

Post by chromatic »

D3ve1inE wrote: post #25

Hi guys, Netanel Rubin here. First of, I'm not a Pythonist. Python has nothing to do with the faults of Perl - Perl does. Perl was a great language back at the 90's and early 2000 - it doesn't now. That is mainly because of the 'write-only' code style and many not-that-intuitive behaviors other languages practice better. It is true that my talk was based on bad programming practices, but that's the practices actually…

Perl was a great language back at the 90's and early 2000 - it doesn't now.

Professional Perl programmers understood this coding error as a coding error at least in 2000, in my personal experience. If you squint, you can see it as a poorly designed interface in the CGI module (though I'm not sure how you would fix it), but your examples are passing untrusted, unvetted user input to sensitive code.

Professional programmers have understood that as bad practice for multiple decades.

Did all of those programmers and maintainers never read the tutorial for the language?

I'm certain if you went back in time and asked "What happens if a query string contains multiple parameters of the same name?" many people would look very confused, as if they'd never considered such a thing were possible. In other words, the answer to your question is "No, most web programmers neither read nor understood the documentation, because the state of web programming in those days was terrible."

Re: The Perl Jam: Exploiting a 20 Year-old Vulnerability [pdf]

#38

Post by CoconutPilot »

ceronman wrote: post #4

When he explains how Perl handles an array passed as an argument to a function: my @list = ('b', 'c'); test('a', @list, 'd'); Which ends up flatting the @list array into the argument list and printing 'a', 'b', 'c' , most Perl programmers defend the language saying that the author just doesn't understand Perl, and that's how things are done in the language since forever. The response is basically a RTFM. If you reall…

I think push is better understood if you realize its an operator. At a higher level what is happening is you are adding "item2" (and another "item2") to the array @list. ie @list += ("item2", "item2")

Re: The Perl Jam: Exploiting a 20 Year-old Vulnerability [pdf]

#39

Post by pwr22 »

OMGWTF wrote: post #11
laumars wrote: post #10

I love how he is building his own SQL string and then blaming Perl's DBI->quote for any vulnerabilities that arise. Anyone who writes SQL like that is writing bad code from the offset (regardless of the programming language nor it's DB/web frameworks). Parametrised queries and ORMs exist to prevent the kind of SQL injection attacks he's demonstrating and Perl's various DBD modules already support parametrised queries…

I think $sth = $dbh->prepare("SELECT document FROM table WHERE tag=? AND security_level=?"); $sth->execute(foo(), $user_level); breaks as well, if foo() unexpectedly returns a list.

Indeed it looks like it can, but this is still a non-issue if you understand context (a key feature of Perl) and know what foo does

Re: The Perl Jam: Exploiting a 20 Year-old Vulnerability [pdf]

#40

Post by pwr22 »

zzzcpan wrote: post #28
D3ve1inE wrote: post #25

Hi guys, Netanel Rubin here. First of, I'm not a Pythonist. Python has nothing to do with the faults of Perl - Perl does. Perl was a great language back at the 90's and early 2000 - it doesn't now. That is mainly because of the 'write-only' code style and many not-that-intuitive behaviors other languages practice better. It is true that my talk was based on bad programming practices, but that's the practices actually…

> list expansion behavior in function calls is a problem most programmers weren't aware of. Actually, what lists do in list context is one thing every Perl programmer knows. You cannot go too far without it in Perl.

Most Python programmers switching to Perl an assuming it works the same way is probably true though :P
Post reply on HN