Live data from Hacker News

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

events.ccc.de

1–10 of 44 posts

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

#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 really wanted to send the whole list as single argument to the function, you should have sent an array reference, like this:

    test('a', \@list, 'd');
Perl programmers say that if you took a minute to understand the language, you should have known this. However, what they don't realize is that Perl gives you ambiguous hints about this all the time. For example, the built in push function doesn't seem to follow this logic:

    push(@list, "item2", "item2");
This function knows perfectly that the list is a single argument and the other ones are the items to push into the list. You don't have to pass a reference to the array to make it work.

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

When a Perl newbie sees the push function, it's more than reasonable to think that passing arrays as function arguments will work as in any other language. When they find what really happens, it can be very frustrating, specially because Perl won't give you any error whatsoever. This is one of the reasons why Perl is so difficult to learn.

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

#5
post #3
post #2

You can watch the talk here: https://www.youtube.com/watch?v=gweDBQ-9LuQ

is it just me, or does he think that swearing makes him look cool?

I'd be fine with the swearing if it'd be backed up by some knowledge and experience, but that smug attitude is just incredibly irritating when coupled with such level of ignorance. First decide what are you going to bash. Some libraries, some applications, the entire programming environment ? Using induction from DBI->quote/CGI and a few old apps to bash the entire Perl ecosystem is just boringly stupid. It is fine and useful to patch those old apps, but to give an arrogant lecture as if all programmers use the same broken approaches in 2014 is just ignorant.

It is extensively documented to prefer placeholders when working with DBI, that is, if you even use DBI directly and not via an OO mapper. CGI as an approach is entirely deprecated on all languages/platforms not just Perl. List expansion ? It is a feature, use it or leave it. You have the option to use references. If you prefer Python, just use Python. It's like bashing C for having pointers. So, what else ? Try PHP with those examples. Find some Ruby apps prone to sql injection. Bash some NodeJS libraries. If Perl is dead already, be a rockstar bashing the new stuff, why even bother with the ghosts ? I think it is because deep down all Pythonistas know that Perl is a far superior platform and they all carry a deep ancestral envy. Otherwise they'd just be happy with their choice already. :)

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

#6
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…

Granted, and most people think prototypes are evil for similar reasons. Perl doesn't have the same design goals as something like Python, it will accept inconsistencies and complexity if they're deemed useful

I personally like this, assuming the complexities aren't too great and the documentation is good but to each their own

Edit: In Perl land it is a bad idea to treat built ins as being identical to subs, and this was taught to me by the books I learnt from. The rub of this is that it is bad to generalise from stuff like print, push etc

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

#7
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…

That's a fair point and it was certainly true that this tripped me up when I was learning Perl too. But now I've wrapped my head around the concept, I love it.

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

#9
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…

As an ex Perl guy (well I still use it sometimes), I find append and extend an endless source of confusion in Python. Especially as strings do the opposite of what I expect, and get treated as character arrays with extend (or was it append).

I like the way that in Perl you have to explicitly reference the array, as this leaves no ambiguity about what is happening. I guess its just what I am used to.

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

#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 (in fact most Perl DBI guides will walk you through using them!).

This is pretty much "working with databases 101" and if he can't get even that much right then he should not be stood in front of people lecturing about the evils of any language nor it's framework.

Sadly though, these days proper security research is less important than looking cool in front of a small crowd. After all, who needs to have any knowledge about your subject if you can curse a little and display a few slides of some tired old internet memes. :/

Post reply on HN