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

Netanel Rubin held a talk about an alleged 20 year old vulnerability in perl named "The Perl Jam: Exploiting a 20 Year-old Vulnerability" at 31C3 [PDF].

Basically he claims that this is a problem:

my @a = qw(8 foo 666);
my %h = (foo => 100,
	 bar => 333,
	 san => @a);
print Dumper(\%h);

$VAR1 = { 'san' => 8, 'bar' => 333, 'foo' => 666 };

As you can see, the array @a is assigned as a value to the key 'san' of the hash %h. But since it's not assigned as a array reference, the array dissolves into the hash and its values overwrite the keys 'foo' and 'san'.

The "vulnerability" Netanel found, is in the CGI module. The method 'param()' of this module returns an array if a CGI parameter occurs more than once. If the output of that method is being used unchecked in a hash assignment as shown above, then it is possible to overwrite certain values of that hash. This leaded for example to the vulnerability CVE-2014-1572 in Bugzilla.

Netanel's conclusion: perl is broken, horrible, hazardous, bizarre and should not be used anymore.

Wow.

He is wrong on multiple levels. Arrays dissolving into hashes is not a bug and not bad, but intended behavior and very well documented. In fact, I use it alot. I even love it! If you take a look into the function new() of about 80% of all perl modules on CPAN, you'll find, that they support hash arguments, and feed @_ into a hash. Pretty standard for perl people. Others might find it ugly or weird, but hey, it's a free world (mostly), choose another language if you don't like the concept.

Then Netanel has been asked if he knows about references and in response complained about using a backslash in order to assign a reference to a hash (or array) to a variable. He called it "escaping", but that's utter nonsense. \%hash ist pure perl syntax, not escaping.

The talk sounds funny in the first place, but is unsubstancial. Yes there are flaws in perl code which uses CGI.pm in the wrong way. But that's not a perl problem, it's a CGI.pm problem. And it's solved since a long time. Modern web stuff written in perl uses Dancer, Mojolicious or Catalyst and not CGI.pm.


30.12.2014 10:11 CC0 en kritik opensource perl Source

Similar posts

4 Commentare zu Re: The Perl Jam: Exploiting a 20 Year-old Vulnerability [31c3]

#1 Struppi meinte am 31.12.2014 17:08:
I won't even blame CGI.pm for that. It's the problem of the code. You won't run in this problem, if you make your code warning free (use warnings) and if you check input from the outside.

Since it's useful to get a list of cgi values i some cases, it is the responsibility for the program to check the input.

But I am suprised that the author of bugzilla don't do. Do they really don't use strict&warnings?
#2 Tom meinte am 01.01.2015 12:00:
You're right, CGI.pm isn't to blame. However, strict and warnings doesn't help either.

use warnings; use strict; use Data::Dumper; my @a = qw(8 foo 666); my %h = (foo => 100, san => @a); print Dumper(\%h);

prints:

$VAR1 = { 'san' => '8', 'foo' => '666' };

No warning or error by perl here. And why should it? Complaining about intended and documented behavior doesn't make any sense.
#3 Raphael meinte am 02.01.2015 04:06:
Rule #1: Never write CGI code without input validation.
#4 Tom meinte am 02.01.2015 14:56:
Yes, that's why I wrote Data::Validate::Struct (http://search.cpan.org/dist/Data-Validate-Struct/) which doesn't only validate content but the structure of the input as well. An error as the one we're talking about here would have been catched by this module.


Add Comment:
Aus welchem Land kommen Sie?
Land*:
Your comment will only displayed publicly after my approval! Fields marked with * are mandatory.
If you include an email address, it will be deleted automatically after one month. Nothing else will be stored.