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

11–20 of 44 posts

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

#11

Post by OMGWTF »

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.

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

#12

Post by Pxtl »

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'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.

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

#13

Post by maxlybbert »

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…

> The push function works like this because it uses an obscure feature called function prototypes. Which is rarely mentioned in any tutorial.

I think the push function behaves differently mainly because it's a builtin. It is possible to use function prototypes to make your functions act like builtins, but the reason that isn't mentioned in tutorials is that most Perl programmers are less than impressed with prototypes. Except when passing code blocks as subroutine references, since prototypes allow you to omit the comma after the code block.

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

#14

Post by sarciszewski »

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.

Breaks as in "SQL injection is possible" or breaks as in "invalid number of parameters"?

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

#15

Post by xorcist »

This guy just comes off as very smug about a language he apparently has no idea what he's doing in.

Bascially all the WAT?s are because Perl's lists are very different from Python's. If he had spent five minutes reading the very first chapters of Programming Perl he would make much less fool of himself. He explicitly asks to flatten the lists, so there shouldn't be much surprise that Perl obliges.

That said, the security issues he pointed out are real ones. Be very careful in you are programming CGI (in any language)!

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

#16

Post by sarciszewski »

Pxtl wrote: post #12
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'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 ;)

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

#17

Post by OMGWTF »

sarciszewski wrote: post #14
OMGWTF wrote: post #11

Earlier quoted context omitted.

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.

Breaks as in "SQL injection is possible" or breaks as in "invalid number of parameters"?

If the list contains 2 elements, it will overwrite the second parameter, so the total number of arguments is still the same.

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

#18

Post by tedunangst »

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…

? Where's the string building in this code?

    my $otheruser = Bugzilla::User->create({
        login_name => $login_name, 
        realname   => $cgi->param('realname'), 
        cryptpassword => $password});

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

#20

Post by sarciszewski »

I love how, at the very end of the talk, when someone asked the speaker if he knew of any other languages that had this problem, and the speaker didn't know, someone decided to shout out "PHP!"

There is something that PHP developers should be made aware of, but it isn't something as weird as Perl's list behavior.

Test script:
If you access /test.php?a=1&a=2 you will be greeted with:

    array(1) {
      ["a"]=>
      string(1) "2"
    }
You can reason amongst yourselves about whether 1 or 2 is more desirable, but it's only one parameter. So the Perl list trickery is not applicable. Now visit /test.php?a[]=1&a[]=2

    array(1) {
      ["a"]=>
      array(2) {
        [0]=>
        string(1) "1"
        [1]=>
        string(1) "2"
      }
    }
If you're expecting a string in a GET/POST parameter, make sure you're not receiving an array. This is a HTTP feature, not a bug, but it can sometimes break code if you're not expecting it. (Break as in error messages)

So, no, PHP is not an example of a language with a similar vulnerability.

Post reply on HN