Response to The Perl Jam 2
Given the embarrassing talk that Netanel Rubin gave last year, in which he chose not to learn a language and then laugh at it for the mistakes he made, I’m surprised I have to respond to yet another of his talks. Surprisingly, CCC gave him another slot to present strawman arguments for cheap laughs again this year, and no doubt that’s what he did.
This year Netanel found two things and ran with them past the point of absurdity. Starting with the second one, he found an example in the CGI.pm documentation had contains an exploit. Sure, that’s kinda bad, except it was clearly a demo and in documentation for a library that has been lambasted for being old and broken for ages. CGI.pm’s problems are so well known that Perl has removed it from the core just so that it doesn’t seem like we are promoting its use. Now for the one that really irks me.
His first “exploit” was that he found some crappy code in Bugzilla in which it assumes (wrongly) that a user cannot create a data structure in an HTTP request, which of course many perl modules can create given any number of circumstances. His accusation is that people reuse methods in application logic for trusted and untrusted inputs. The code is basically this
sub doit {
my ($input) = @_;
if (ref $input) {
# treat $input as trusted data
} else {
# treat input as untrusted
}
}
Well this is of course very silly and if you do that its your fault. The idea that because its a reference we all assume its trusted input is patently absurd and no one knows how he even got that idea. Fine; bugzilla did that, it doesn’t make it true generally. There are all kinds of better ways to do this, most appropriately (and very MVC), separate your business logic (which operates on validated data) from controllers (which accept and validate data).
This has nothing to do with Perl, it has everything to do with writing good code.
Now if that weren’t enough Netanel goes on to assume that since we all share this insane belief that data structures contain safe data (again, wat?) that any web frameworks that create data structures are broken and contain exploits. He accuses Mojolicious and Catalyst of this while providing no examples for only the reason that they can create data structures. I should note that at least in Mojolicious’ case, there are never ambiguities about which data structures are returned (as was his complaint last year).
It all got great laughs. Of course it did. Anyone can build a strawman and beat it to death for the amusement of a neophyte crowd. Where this is supposed to stop is with the organizers. CCC you should be embarrassed for giving this guy a stage again. Please don’t make the same mistake for a third year in a row.
As I delve into the deeper Perl magic I like to share what I can.
Did he ever bother reporting these “vulnerabilities” to bugzilla first, I wonder? If not, then he’s not practicing responsible disclosure, and no conference should be sanctioning that behaviour (even setting aside all other aspects of his talk).
This “bug” was reported and taken care of.
https://bugzilla.mozilla.org/show_bug.cgi?id=1230932
The sad, and very embarassing part for CCC is that it’s not even like he slipped in unnoticed or something like that. They introduce the perl jam 2 talk by describing the deserved criticism he got as “bashing”, i.e. undeserved.
https://streaming.media.ccc.de/32c3/relive/7130/ @ 15:00
The perl code he posts at 00:20:33 into the video isn’t correct:
sub rubin { $arg1, $arg2 = @_; print "$arg1 $arg2\n"; } rubin (1, 2);just prints out ” 2” because he left out the () around $arg1, $arg2.
So he clearly doesn’t even know the language enough to write even a very simple program, or he does not know enough to turn on warnings and strict.
If someone has a security vulnerability in Catalyst I am sure if it was properly reported it would be fixed. -jnap
Is the implicit single argument open() behavior of <> appropriate any more?
$ cat foo #!/usr/bin/env perl use Modern::Perl; my $x = "ARGV"; while () { say $_; } # execute as: foo 'ipconfig|'If I was Perl, I would sue Netanel Rubin for slander.
Correction:
while (<$x>) { say $_; }(after preview, I found that the diamond has to be entered as <$x> into the text box :-)
Single argument open is fine; the real question is whether piped open via ARGV magic is appropriate at all - which is the only valid point of Netanel Rubin’s talk. Is that a bug or a feature?
Even the -dangerous - ARGV magic is covered in the docs. From perlop:
Since the null filehandle uses the two argument form of “open” in perlfunc it interprets special characters, so if you have a script like this:
while (<>) { print; }and call it with “perl dangerous.pl ‘rm -rfv *|’”, it actually opens a pipe, executes the “rm” command and reads “rm“‘s output from that pipe. If you want all items in @ARGV to be interpreted as file names, you can use the module “ARGV::readonly” from CPAN.
So, yes. He does not only not learn the language, but also doesn’t read the docs of the stuff he’s talking about. Nuff said.
Yes, everybody should use static languages. For example Java.
“… Going forward, developers should take this as an example of why it’s not safe to unserialize untrusted data. Unfortunately in the Java world, so much is built on the concept that this is okay, it’s going to take a long time to move away from that. …”
http://foxglovesecurity.com/2015/11/06/what-do-weblogic-websphere-jboss-jenkins-opennms-and-your-application-have-in-common-this-vulnerability/
https://jenkins-ci.org/content/mitigating-unauthenticated-remote-code-execution-0-day-jenkins-cli