This is part 3 in a series of responses to Netanel Rubin's Presentation: The Perl Jam 2, for reasons explained in Part 1

In his original presentation, Netanel over focused on the assumption that we treat Hashes and other arbitrary data structures as safe by default.

This is not really true, however, when watching him talk about it, I realised he was right in a sense, just ... not how he imagined.

Hash Keys are a Potential Security Risk.^⚓

Under taint mode, strings from external sources are marked "tainted" until somebody manually untaints them.

And then any tainting-sensitive function calls can raise a fatal exception if they are passed sensitive data.

For instance, Take the following JSON file

{ "DROP TABLES *": "DROP TABLES *" }

Now, using the following script:

use strict;
use warnings;
use JSON::MaybeXS;
use Path::Tiny qw( path );

my $structure = decode_json(path('/tmp/evil.json')->slurp_raw);
system("echo " . join q[], values %{$structure} );

This example demonstrates that the JSON back-end faithfully preserved taintness of the external data, and the code fails as expected.

$ env -i perl -T /tmp/json.pl
Insecure dependency in system while running with -T switch at /tmp/json.pl line 7.

However, hash keys are inherently different:

- system("echo " . join q[], values %{$structure} );
+ system("echo " . join q[], keys   %{$structure} );

And now we have a problem:

$ env -i perl -T /tmp/json.pl
DROP TABLES blog page site.yml static theme

Continue reading Re: The Perl Jam 2: Hashes are Insecure...

This is part 2 in a series of responses to Netanel Rubin's Presentation: The Perl Jam 2, for reasons explained in Part 1

This is on the list of things that Netanel would have best served the Perl community by filing a bug when he discovered it.

<"ARGV"> is evil^⚓

Here is the most reduced code you can have that demonstrates the vulnerability in play.

use strict;
use warnings;

# Pretend this came in through a CGI Request Paramete
@ARGV=( 'echo exploited|' );

# This function should return a filehandle, but the user did something
# to trick magical_function to return the string "ARGV"

my $filehandle = magical_function();

# TRAP
while (<$filehandle>) {
  print $_;
}

As long as $filehandle is in fact a FileHandle, nothing weird happens.

However, when $filehandle is a string, Perl does something it typically shouldn't: It treats the string as a description of a filehandle.

Continue reading Re: The Perl Jam 2: <"argv"> is evil...

I'm going to be posting a series of entries in response to Netanel Rubin's Presentation: The Perl Jam 2, and this is the first of such entries.

As a whole, I felt he grossly miss-characterised Perl and its community, and made a few glaring errors in his presentation and a few leaps of logic.

Amongst his talk, he covered a handful of Real Bugs, but his presentation made it difficult to realise what they were objectively, and his hyperbolic and rhetoric technique served not to educate, not to correct, but to mock.

I feel many of his criticisms would have been better addressed as actual bug reports, not a presentation conveying how software has bugs, and that with better clarity and less rhetorical devices, the important parts of his presentation could have been covered in 5 minutes.

So this is an attempt at clarifying the mistakes in the presentation, and serve as a more objective response where we can unpack the relevant parts, fix the actual problems, and educate our way past the cultural issues that lead people to make bad choices.

I will of course go into far more detail than is strictly necessary.

CGI Sucks^⚓

And its Documented that Nobody should use it

Netanel did not identify this quirk as such, but it underlies a significant chunk of his presentation.

Both CGI.pm and the CGI protocol imply serious limitations on the security and performance of your Web Application, and has been recommended against by everyone worth listening to, and is even documented as such IN CGI.pm itself

CGI.pm is no longer considered good practice for developing web applications, including quick prototyping and small web scripts. There are far better, cleaner, quicker, easier, safer, more scalable, more extensible, more modern alternatives available at this point in time.

The CGI protocol significantly blurs the lines between the Command Line interface, and the Web, in ways that prove to be detrimental, and can serve as an amplifier for bugs and security risks.

One of the attacks he demonstrates relies heavily on a behaviour in Perl that is deemed useful for command line programs: The ability for the caller ( that is, the user of the command line program ), to specify, by way of arguments, names of arbitrary programs to execute to retrieve their output.

This turns out to be a grave trap in a Web context, as HTTP GET Request parameters are passed to the CGI application as parameters to @ARGV, much like parameters on the command line.

And that means any code that happens to utilize that "execute arbitrary programs based on arguments in @ARGV" path ( either by intent, or by way of exploiting a bug ) is simply waiting for the day when some user on the internet can forge a request such as:

http://example.org/fake.cgi?rm -rf /|

And maybe find enough magic spice to trigger the "be a command line and execute that" condition.

And this would clearly be bad.

But this risk exists because of the Command-Line-as-a-Web-Protocol design flaw.

Continue reading Re: The Perl Jam 2: CGI Sucks...