9:59:59.000,9:59:59.000
<i>preroll music</i>

9:59:59.000,9:59:59.000
Herald: And I'm gonna introduce Netanel Rubin.

9:59:59.000,9:59:59.000
He has been here last year with a talk [br]that he got some bashing for.

9:59:59.000,9:59:59.000
This year he's gonna ensure,[br]it's not the programmer's fault,

9:59:59.000,9:59:59.000
it's the language itself. No?

9:59:59.000,9:59:59.000
Well, here we go, well here we go.

9:59:59.000,9:59:59.000
Netanel, he is working for [br]PerimeterX in Tel Aviv,

9:59:59.000,9:59:59.000
welcome on stage, your talk!

9:59:59.000,9:59:59.000
Netanel: Thank you, thank you![br]<i>applause</i>

9:59:59.000,9:59:59.000
Last year I stood right on this very stage[br]and I talked about several of Perl's

9:59:59.000,9:59:59.000
less thought out "features".

9:59:59.000,9:59:59.000
Now, I got some bashing from the Perl community, [br]but mainly what happened was,

9:59:59.000,9:59:59.000
that the Perl community completely rejected my talk [br]claiming that the language

9:59:59.000,9:59:59.000
is completely fine and great [br]and all of this stuff are just improvements.

9:59:59.000,9:59:59.000
It was clear I had to give another talk.

9:59:59.000,9:59:59.000
This is why I'm very proud to present [br]"Perl Jam 2 – The Camel strikes back"!

9:59:59.000,9:59:59.000
<i>applause</i>

9:59:59.000,9:59:59.000
Thank you

9:59:59.000,9:59:59.000
At the last talk, I showed that "lists" are expressions, [br]used in… many confusing ways.

9:59:59.000,9:59:59.000
I also showed CGI parameters can create lists, [br]directly from user input.

9:59:59.000,9:59:59.000
But most importantly, I showed [br]that when these two things combine, shit happens.

9:59:59.000,9:59:59.000
Great

9:59:59.000,9:59:59.000
But the really interesting part [br]was the PerlMonks response.

9:59:59.000,9:59:59.000
The Perl community[br]<i>laughter</i>

9:59:59.000,9:59:59.000
The Perl community had a long discussion [br]at the PerlMonks forum.

9:59:59.000,9:59:59.000
It started with the words [br]"Sad news from Germany".

9:59:59.000,9:59:59.000
A bit dramatic, but who am I to judge?

9:59:59.000,9:59:59.000
So, after a long, long discussion, [br]they came to the unavoidable conclusion

9:59:59.000,9:59:59.000
that my talk was, in fact, a "polemic shit", [br]and they should all just "piss on it". Wink.

9:59:59.000,9:59:59.000
They also realized that I'm just a [br]"script kiddie preaching to other script kiddies",

9:59:59.000,9:59:59.000
and not just any script kiddies, the CCC audience is a

9:59:59.000,9:59:59.000
"heterogeneous group of chaotic punks [br]who love to see themselves in the hacker

9:59:59.000,9:59:59.000
image of Hollywood media". [br]<i>applause and whistling from audience</i>

9:59:59.000,9:59:59.000
What hacker image? [br]What are they talking about?

9:59:59.000,9:59:59.000
We have no hacker image.

9:59:59.000,9:59:59.000
Anyway, it got quite surreal, as in some point [br]they even critized

9:59:59.000,9:59:59.000
the "crude use of propaganda [br]in the camel images". WAT.

9:59:59.000,9:59:59.000
<i>laughing</i>[br]<i>applause</i>

9:59:59.000,9:59:59.000
Propaganda in the camel images. Alright.

9:59:59.000,9:59:59.000
Anyway, they completely rejected the entire talk, [br]even though the technical points were valid.

9:59:59.000,9:59:59.000
They rejected it because of [br]some jokes and camel images.

9:59:59.000,9:59:59.000
But still, they got so offended they just threw [br]lame excuses as to why their language sucks.

9:59:59.000,9:59:59.000
Two of these lame excuses were [br]repeated over and over again.

9:59:59.000,9:59:59.000
The first was that I should [br]read the fucking manual, which is funny

9:59:59.000,9:59:59.000
because I thought I was the only one who did…

9:59:59.000,9:59:59.000
<i>laughter</i>

9:59:59.000,9:59:59.000
…and the second is that

9:59:59.000,9:59:59.000
I'm using the old, ancient Perl, [br]and not the new, modern Perl.

9:59:59.000,9:59:59.000
<i>more laughter</i>

9:59:59.000,9:59:59.000
Remember these two points carefully [br]as I'll later break them in the presentation.

9:59:59.000,9:59:59.000
But, enough with the intro, [br]let's start with the new madness.

9:59:59.000,9:59:59.000
So, Perl allows declaring variables [br]without specifying their data type.

9:59:59.000,9:59:59.000
Of course, this functionally exists [br]in many dynamic languages,

9:59:59.000,9:59:59.000
and is completely fine and very convenient.

9:59:59.000,9:59:59.000
But, as usual, Perl took it [br]to a whole different level.

9:59:59.000,9:59:59.000
Perl went as far as removing [br]data type declarations from function arguments.

9:59:59.000,9:59:59.000
You can see that in this example

9:59:59.000,9:59:59.000
I'm just receiving two different arguments [br]without knowing what type they are.

9:59:59.000,9:59:59.000
Let me be clear about that,

9:59:59.000,9:59:59.000
you don't get to choose whether you want [br]to specify argument data types or not,

9:59:59.000,9:59:59.000
you can't specify [br]what data types you're expecting to get.

9:59:59.000,9:59:59.000
So even if I built a function [br]that only works with strings,

9:59:59.000,9:59:59.000
I have no way of forcing that [br]at the function declaration.

9:59:59.000,9:59:59.000
Now that's annoying.

9:59:59.000,9:59:59.000
But, the real kicker [br]is how this feature is used.

9:59:59.000,9:59:59.000
Apparently, it is very common to write [br]two completely different blocks of code,

9:59:59.000,9:59:59.000
one that handles scalar types, [br]like strings or ints,

9:59:59.000,9:59:59.000
and one that handles non-scalar types, [br]like arrays or hashes.

9:59:59.000,9:59:59.000
Let me repeat that:

9:59:59.000,9:59:59.000
Writing multiple code, for multiple data-types, [br]in one function, is a Perl standard.

9:59:59.000,9:59:59.000
And that's sad. You shouldn't write redundant code [br]because the language lacks the capability

9:59:59.000,9:59:59.000
of letting you decide [br]which cases you don't want to handle.

9:59:59.000,9:59:59.000
By the way, Python doesn't let you [br]declare your function argument data types too,

9:59:59.000,9:59:59.000
but unlike Perl, writing redundant code [br]to cover that up

9:59:59.000,9:59:59.000
is definitely not the standard.

9:59:59.000,9:59:59.000
Anyway, sad as this may be, [br]this Perl convention is not dangerous.

9:59:59.000,9:59:59.000
The dangerous part begins

9:59:59.000,9:59:59.000
when hashes and arrays [br]are considered as "secure" data types,

9:59:59.000,9:59:59.000
mainly because they can't be created [br]by user input.

9:59:59.000,9:59:59.000
This results in this kind of code,

9:59:59.000,9:59:59.000
where if the function argument [br]is a hash, for example,

9:59:59.000,9:59:59.000
it is used un-escaped in dangerous functions.

9:59:59.000,9:59:59.000
Hashes, specifically, are considered so secure, [br]that even if you use "taint mode",

9:59:59.000,9:59:59.000
which is some kind of safe mode for Perl,

9:59:59.000,9:59:59.000
hash keys are not tainted, meaning [br]that, even if you use safe mode,

9:59:59.000,9:59:59.000
they can be still used in dangerous functions

9:59:59.000,9:59:59.000
without any validation, [br]as opposed to other data type.

9:59:59.000,9:59:59.000
Now this kind of code appears a lot [br]in Perl applications,

9:59:59.000,9:59:59.000
and apart from the many bugs [br]this method can cause,

9:59:59.000,9:59:59.000
it also makes your code exploitable.

9:59:59.000,9:59:59.000
So we know function arguments are of unknown data type.

9:59:59.000,9:59:59.000
And we know developers treat hashes and arrays [br]as "secure" data types,

9:59:59.000,9:59:59.000
inserting their values into dangerous functions.

9:59:59.000,9:59:59.000
But this practices isn't something

9:59:59.000,9:59:59.000
that was created a long time ago, [br]and found only on redundant code.

9:59:59.000,9:59:59.000
Because of how the language is built, [br]it's supposedly restriction-less type of developing,

9:59:59.000,9:59:59.000
even now it is the natural way to code [br]when you're using Perl.

9:59:59.000,9:59:59.000
And that's the real problem: [br]Perl is like a shotgun,

9:59:59.000,9:59:59.000
with one trigger you know about [br]and a dozen that you don't.

9:59:59.000,9:59:59.000
For now, we know [br]that if we'll somehow manage

9:59:59.000,9:59:59.000
to create these "secure" data types, [br]with our user input,

9:59:59.000,9:59:59.000
we could exploit the code.

9:59:59.000,9:59:59.000
So the only question remaining really [br]is what are we gonna exploit?

9:59:59.000,9:59:59.000
And the answer, again, [br]is Bugzilla.

9:59:59.000,9:59:59.000
<i>laughter</i>

9:59:59.000,9:59:59.000
Like every other Perl project, [br]Bugzilla is heavily using functions

9:59:59.000,9:59:59.000
that treat scalar and non-scalar [br]argument types very differently.

9:59:59.000,9:59:59.000
This is one of them: [br][br]The load from DB function is responsible

9:59:59.000,9:59:59.000
for extracting object specific data [br]out of the database.

9:59:59.000,9:59:59.000
Like I just said, it treats scalars, [br]and in this case hashes, very differently.

9:59:59.000,9:59:59.000
If the function argument is a hash, [br]it takes one of its values

9:59:59.000,9:59:59.000
and inserts it as is, un-escaped, [br]into an SQL statement.

9:59:59.000,9:59:59.000
Again, because hashes [br]are considered secure,

9:59:59.000,9:59:59.000
so there's no point of escaping them.

9:59:59.000,9:59:59.000
On the other hand, [br]if the argument is a scalar,

9:59:59.000,9:59:59.000
it converts it into an integer [br]and only then use it in an SQL statement.

9:59:59.000,9:59:59.000
Because scalar values, are not secure.

9:59:59.000,9:59:59.000
hashes: secure

9:59:59.000,9:59:59.000
scalar: not secure

9:59:59.000,9:59:59.000
This means that if we could control [br]the function argument entirely,

9:59:59.000,9:59:59.000
including its data type, [br]we could control the SQL query,

9:59:59.000,9:59:59.000
affectively exploiting an SQL injection attack,

9:59:59.000,9:59:59.000
by inserting a hash [br]containing that specific value.

9:59:59.000,9:59:59.000
But…

9:59:59.000,9:59:59.000
CGI input doesn't allow hashes, right?

9:59:59.000,9:59:59.000
The whole Perl security module [br]is built on that assumption.

9:59:59.000,9:59:59.000
The problem is that, like us, [br]developers are assuming

9:59:59.000,9:59:59.000
CGI input is the only input method available.

9:59:59.000,9:59:59.000
CGI.

9:59:59.000,9:59:59.000
But CGI isn't the only way to go.

9:59:59.000,9:59:59.000
Bugzilla developers missed the fact [br]that their own system

9:59:59.000,9:59:59.000
is also featuring an XMLRPC and a JSONRPC,

9:59:59.000,9:59:59.000
both supporting input of non-scalar data types [br]like arrays and hashes!

9:59:59.000,9:59:59.000
But I'm not blaming them.

9:59:59.000,9:59:59.000
Yes, they forgot that there are more ways [br]for user to input than CGI,

9:59:59.000,9:59:59.000
but still, they're just the product [br]of how Perl programming is taught,

9:59:59.000,9:59:59.000
filled with false assumptions and inconsistencies.

9:59:59.000,9:59:59.000
Expecting anything but this kind [br]of security problems is just naive.

9:59:59.000,9:59:59.000
But back to the vulnerability.

9:59:59.000,9:59:59.000
If we'll use one of these RPCs,

9:59:59.000,9:59:59.000
sending our input parameter with a malicious hash,

9:59:59.000,9:59:59.000
instead of just a regular numeric parameter,

9:59:59.000,9:59:59.000
we will be able to exploit the SQL Injection!

9:59:59.000,9:59:59.000
So, if we'll send this regular request, [br]using the JSONRPC interface,

9:59:59.000,9:59:59.000
the number 1 will be used [br]as the ID of a bug to extract,

9:59:59.000,9:59:59.000
but if we'll send this request,

9:59:59.000,9:59:59.000
where instead of an integer we'll supply a hash,

9:59:59.000,9:59:59.000
than suddenly we will be able [br]to inject any SQL we'd like

9:59:59.000,9:59:59.000
into that statement, affectively [br]compromising the entire database.

9:59:59.000,9:59:59.000
Now when you look at this request, you realize

9:59:59.000,9:59:59.000
that this is not a sophisticated vulnerability.

9:59:59.000,9:59:59.000
All I did was just change the input data type [br]from scalar in this case to a hash,

9:59:59.000,9:59:59.000
and that's it, the system is compromised.

9:59:59.000,9:59:59.000
It was so heavily built on the assumption

9:59:59.000,9:59:59.000
that hashes are secure, that it offered me

9:59:59.000,9:59:59.000
almost unlimited access security wise.

9:59:59.000,9:59:59.000
The funny thing about that is, that [br]although it's so simple,

9:59:59.000,9:59:59.000
the attack has existed for over 5 years.

9:59:59.000,9:59:59.000
That's the year I was born in.

9:59:59.000,9:59:59.000
So, we now proved this "unknown-argument-type" feature

9:59:59.000,9:59:59.000
is a huge source for problems.

9:59:59.000,9:59:59.000
We also know writing different code [br]to handle different data types

9:59:59.000,9:59:59.000
just causes a lot of false assumptions.

9:59:59.000,9:59:59.000
But most importantly, treating non-scalar [br]data types such as hashes as "secure",

9:59:59.000,9:59:59.000
just because they supposedly can't be created by the user,

9:59:59.000,9:59:59.000
is very, Very, BAD. Just ask Bugzilla.

9:59:59.000,9:59:59.000
But the shocking part really, is that, again, [br]this is the Perl Standard!

9:59:59.000,9:59:59.000
You're not expected to use it, you have to

9:59:59.000,9:59:59.000
as you don't have any other choice.

9:59:59.000,9:59:59.000
This security-mess [br]is a fundamental part of the language.

9:59:59.000,9:59:59.000
The problem is that creating non-scalar data types [br]is impossible in some cases.

9:59:59.000,9:59:59.000
We can't rely that some kind of RPC

9:59:59.000,9:59:59.000
will exist in the code [br]and support different data types,

9:59:59.000,9:59:59.000
and we can't create data types [br]using regular user input… Right?

9:59:59.000,9:59:59.000
Well, let's have a look at

9:59:59.000,9:59:59.000
how different CGI modules [br]handle different kind of input.

9:59:59.000,9:59:59.000
First, we'll take the most trivial scenario.

9:59:59.000,9:59:59.000
A single valued parameter, [br]something that looks like this request,

9:59:59.000,9:59:59.000
where the "foo" parameter [br]is assigned the string "bar".

9:59:59.000,9:59:59.000
In this case, a scalar is created on all three CGI modules,

9:59:59.000,9:59:59.000
which doesn't really help us, [br]but is pretty much what we've expected.

9:59:59.000,9:59:59.000
It is secure.

9:59:59.000,9:59:59.000
What happens if instead of [br]sending a single-valued parameter,

9:59:59.000,9:59:59.000
we'll send a multi-valued parameter, [br]like in this request?

9:59:59.000,9:59:59.000
Now things are starting to get complicated.

9:59:59.000,9:59:59.000
On CGI.PM, as we already know, [br]a list is created,

9:59:59.000,9:59:59.000
which is very useful for us, [br]but not what we're after.

9:59:59.000,9:59:59.000
But let's have a look at [br]what the "new" Perl modules are creating.

9:59:59.000,9:59:59.000
We'll see that both of them are returning [br]arrays containing our values.

9:59:59.000,9:59:59.000
Arrays! WAT?

9:59:59.000,9:59:59.000
I thought you can't create [br]these kind of data types with regular input,

9:59:59.000,9:59:59.000
after all, they're considered safe.

9:59:59.000,9:59:59.000
But let's continue.

9:59:59.000,9:59:59.000
What happens if instead of sending a regular value,

9:59:59.000,9:59:59.000
we'll try and upload a file in that parameter?

9:59:59.000,9:59:59.000
Now things are really getting out of hand,

9:59:59.000,9:59:59.000
because CGI.PM now returns a file descriptor, [br]and Catalyst and Mojolicious returns a hash.

9:59:59.000,9:59:59.000
WAT?

9:59:59.000,9:59:59.000
We just exploited [br]the most popular Perl project in the world

9:59:59.000,9:59:59.000
because they assumed hashes can't be created by the user,

9:59:59.000,9:59:59.000
and now we're finding out [br]that not only we can create hashes,

9:59:59.000,9:59:59.000
it is a god-damned feature?!

9:59:59.000,9:59:59.000
That's insane!

9:59:59.000,9:59:59.000
The whole Perl security standard is built on the assumption

9:59:59.000,9:59:59.000
that users can't create non-scalar data-types

9:59:59.000,9:59:59.000
and now suddenly these are features?

9:59:59.000,9:59:59.000
Let's send a multi-file upload request [br]as in several files in the same parameter.

9:59:59.000,9:59:59.000
Watch closely, because this is where it gets ridiculous.

9:59:59.000,9:59:59.000
Now, CGI.PM returns a list of File Descriptors,

9:59:59.000,9:59:59.000
Catalyst returns a list of Hashes

9:59:59.000,9:59:59.000
and Mojolicious returns an array of objects! WAT?!

9:59:59.000,9:59:59.000
<i>laughter and applause</i>

9:59:59.000,9:59:59.000
Almost any Perl project in the world

9:59:59.000,9:59:59.000
uses one of these modules [br]for parsing CGI input.

9:59:59.000,9:59:59.000
Just think how many developers assumed [br]the exact same thing Bugzilla assumed

9:59:59.000,9:59:59.000
and treated hashes and arrays as secure data types.

9:59:59.000,9:59:59.000
So if you're using CGI.PM,

9:59:59.000,9:59:59.000
instead of the expected scalar value you could be getting

9:59:59.000,9:59:59.000
a list, a file descriptor or a list of file descriptors

9:59:59.000,9:59:59.000
and if you're using Catalyst

9:59:59.000,9:59:59.000
you could receive a scalar, an array, a hash or a list,

9:59:59.000,9:59:59.000
which is basically any data type.

9:59:59.000,9:59:59.000
So expecting your function… yeah

9:59:59.000,9:59:59.000
<i>audience chuckling</i>

9:59:59.000,9:59:59.000
So expecting your function arguments [br]to be of a specific data type is false.

9:59:59.000,9:59:59.000
Expecting hashes and arrays to be secure is also false.

9:59:59.000,9:59:59.000
Expecting scalar only user input

9:59:59.000,9:59:59.000
is a major false.

9:59:59.000,9:59:59.000
And to be honest, it seems that in Perl expecting is false!

9:59:59.000,9:59:59.000
<i>laughter and applause</i>

9:59:59.000,9:59:59.000
You just can't expect anything

9:59:59.000,9:59:59.000
even the most basic of things [br]such as what data type your variable is made of.

9:59:59.000,9:59:59.000
You just don't know.

9:59:59.000,9:59:59.000
But I felt all of these points will [br]go un-noticed

9:59:59.000,9:59:59.000
without an extreme example of Perl's absurdity.

9:59:59.000,9:59:59.000
So I found an extreme example.

9:59:59.000,9:59:59.000
One that will clearly show

9:59:59.000,9:59:59.000
the ridiculous nature of the language.

9:59:59.000,9:59:59.000
And this is it:

9:59:59.000,9:59:59.000
All this code does is print an uploaded file's content.

9:59:59.000,9:59:59.000
And to show you how basic and simple that code is, [br]I'll explain each line.

9:59:59.000,9:59:59.000
The first line just creates a new CGI instance, [br]so we could get the file from the user.

9:59:59.000,9:59:59.000
The second line checks if a file [br]has been uploaded in the "file" parameter.

9:59:59.000,9:59:59.000
The third line gets the file descriptor from the CGI module,

9:59:59.000,9:59:59.000
while the forth line loops through the file [br]and the fifths prints it.

9:59:59.000,9:59:59.000
That's it. Again: all this code does [br]is get a file and print it.

9:59:59.000,9:59:59.000
<i>clapping</i>[br]That's it.

9:59:59.000,9:59:59.000
A user has uploaded a file to the server [br]and the server is just returning its content.

9:59:59.000,9:59:59.000
It's not saving it anywhere, [br]it's not moving it anywhere,

9:59:59.000,9:59:59.000
it just prints its content.

9:59:59.000,9:59:59.000
There should be absolutely [br]nothing dangerous in this code,

9:59:59.000,9:59:59.000
it contains literally five lines.

9:59:59.000,9:59:59.000
Yet, It's demo time.

9:59:59.000,9:59:59.000
<i>laughter</i>

9:59:59.000,9:59:59.000
So trust me, you don't need to see the text,

9:59:59.000,9:59:59.000
all you need to see is that [br]when I'm sending a regular request nothing happens.

9:59:59.000,9:59:59.000
When I send it now, nothing happens,[br]I'm just getting the file content.

9:59:59.000,9:59:59.000
We're having fun, you don't see the burp…

9:59:59.000,9:59:59.000
Now, nice. Okay

9:59:59.000,9:59:59.000
So…[br]…L't me just…

9:59:59.000,9:59:59.000
…I have no idea where my mouse is, okay.

9:59:59.000,9:59:59.000
So…

9:59:59.000,9:59:59.000
I'm sending a regular request, [br]nothing happens, just getting the content.

9:59:59.000,9:59:59.000
I know, you can't see the text…[br]…and…

9:59:59.000,9:59:59.000
when I'm sending my malicious request,

9:59:59.000,9:59:59.000
something interesting will pop up.

9:59:59.000,9:59:59.000
Watch closely! It's gonna be quick.

9:59:59.000,9:59:59.000
Ready?

9:59:59.000,9:59:59.000
Oh, you haven't seen it, it's on the different screen.

9:59:59.000,9:59:59.000
Just a second… oh… duplicate…

9:59:59.000,9:59:59.000
(from audience): … magnify it!

9:59:59.000,9:59:59.000
Netanel: I'll magnify it.

9:59:59.000,9:59:59.000
<i>laughter</i>

9:59:59.000,9:59:59.000
Alright, so… watch closely.

9:59:59.000,9:59:59.000
Ohh, uuh? What was that?

9:59:59.000,9:59:59.000
Let's see it again.

9:59:59.000,9:59:59.000
<i>mocking</i> Uuuuuh?!

9:59:59.000,9:59:59.000
<i>laughter and applause</i>

9:59:59.000,9:59:59.000
Yupp, <i>clearing throat</i>

9:59:59.000,9:59:59.000
… just a second.

9:59:59.000,9:59:59.000
Nice.

9:59:59.000,9:59:59.000
So you're probably asking yourself right now

9:59:59.000,9:59:59.000
"What the fuck did I just see?"[br]<i>laughter</i>

9:59:59.000,9:59:59.000
"Was that a terminal screen?"

9:59:59.000,9:59:59.000
And the answer is … "Yes"[br]Yes, it was

9:59:59.000,9:59:59.000
specifically the "ipconfig" command output.

9:59:59.000,9:59:59.000
Or in other words: What you just saw

9:59:59.000,9:59:59.000
was me exploiting that five lines [br]with a remote code execution attack.

9:59:59.000,9:59:59.000
So now that you saw the magic happens, [br]I think it's time for some explanations.

9:59:59.000,9:59:59.000
The first line, responsible for checking

9:59:59.000,9:59:59.000
if a file has been uploaded in the "file" parameter,

9:59:59.000,9:59:59.000
doesn't exactly do as it says.

9:59:59.000,9:59:59.000
Instead of checking if the "file" [br]parameter is an uploaded file,

9:59:59.000,9:59:59.000
it checks if one of it values is a file descriptor.

9:59:59.000,9:59:59.000
Let me clarify that, instead of checking [br]if the parameter is only a file,

9:59:59.000,9:59:59.000
it checks if the parameter is also a file.

9:59:59.000,9:59:59.000
<i>laughter</i>

9:59:59.000,9:59:59.000
Meaning that uploading a file

9:59:59.000,9:59:59.000
and assigning another scalar value to the same parameter

9:59:59.000,9:59:59.000
will still work and bypass the check!

9:59:59.000,9:59:59.000
WAT?

9:59:59.000,9:59:59.000
<i>more laughter and applause</i>

9:59:59.000,9:59:59.000
Creative fellows those guys are.

9:59:59.000,9:59:59.000
So now we can assign the "file" parameter [br]both a regular file and a scalar value.

9:59:59.000,9:59:59.000
But what happens when we try to get [br]the "file" parameter value?

9:59:59.000,9:59:59.000
In a regular request, it should return [br]the uploaded file descriptor,

9:59:59.000,9:59:59.000
but now that we're adding another value to that parameter,

9:59:59.000,9:59:59.000
param() returns a list containing all the values we send:

9:59:59.000,9:59:59.000
the file we've uploaded and our scalar value.

9:59:59.000,9:59:59.000
But the "file" variable [br]can't contain two values, right?

9:59:59.000,9:59:59.000
So instead of converting [br]the returned list into an array

9:59:59.000,9:59:59.000
Perl only uses the first element of that list.

9:59:59.000,9:59:59.000
So if we'll send our scalar values [br]before we send our file,

9:59:59.000,9:59:59.000
the $file variable will be assigned [br]our scalar value

9:59:59.000,9:59:59.000
instead of the uploaded file descriptor.

9:59:59.000,9:59:59.000
Which means, that $file [br]is now a regular string!

9:59:59.000,9:59:59.000
<i>in high pitched voice:</i> WAT?

9:59:59.000,9:59:59.000
But what happens to this operator [br]when we use a string

9:59:59.000,9:59:59.000
instead of a file descriptor?

9:59:59.000,9:59:59.000
Well, the brackets operator [br]doesn't work with strings, right?

9:59:59.000,9:59:59.000
It works with file descriptors, [br]why should it work with strings?

9:59:59.000,9:59:59.000
Well, that appears true

9:59:59.000,9:59:59.000
unless that string is "ARGV".

9:59:59.000,9:59:59.000
<i>laughter and applause</i>

9:59:59.000,9:59:59.000
That's not a crazy part.

9:59:59.000,9:59:59.000
<i>more laughter</i>

9:59:59.000,9:59:59.000
In that case the brackets operator, listen closely,

9:59:59.000,9:59:59.000
loops through the script arguments,

9:59:59.000,9:59:59.000
which in CGI comes directly from the [br]query string instead the command line,

9:59:59.000,9:59:59.000
and it treats them as file paths, [br]inserting each one into an open() call!

9:59:59.000,9:59:59.000
<i>again laughter</i>

9:59:59.000,9:59:59.000
WAT?

9:59:59.000,9:59:59.000
Yeah, that made sense on some point, I guess.

9:59:59.000,9:59:59.000
All of this basically means that now,

9:59:59.000,9:59:59.000
instead of displaying [br]our own uploaded file content,

9:59:59.000,9:59:59.000
we can display the content [br]of any file on the server.

9:59:59.000,9:59:59.000
But that's not the end, [br]as we haven't executed code yet.

9:59:59.000,9:59:59.000
To execute code, we have [br]to look at the open() function.

9:59:59.000,9:59:59.000
Again, this is the function being called [br]with the ARGV values as file paths.

9:59:59.000,9:59:59.000
open() is responsible for opening [br]a file descriptor to a given file.

9:59:59.000,9:59:59.000
Unless a "pipe" character is added

9:59:59.000,9:59:59.000
to the end of the string,[br]<i>laughter</i>

9:59:59.000,9:59:59.000
in that case instead of opening the file,

9:59:59.000,9:59:59.000
it executes it…[br]<i>applause rising</i>

9:59:59.000,9:59:59.000
…acting as an exec() call![br]<i>more applause</i>

9:59:59.000,9:59:59.000
So … when we send our exploit,

9:59:59.000,9:59:59.000
containing our uploaded file, [br]the "ARGV" malicious scalar value,

9:59:59.000,9:59:59.000
and the ipconfig command followed by a pipe

9:59:59.000,9:59:59.000
this is what we get.[br]WAT?

9:59:59.000,9:59:59.000
WAT?[br]<i>applause</i>

9:59:59.000,9:59:59.000
I know, I'm shocked too, but I'm not done yet. [br]<i>laughter</i>

9:59:59.000,9:59:59.000
Truth be told, I didn't write that code.

9:59:59.000,9:59:59.000
Remember that PerlMonks told me [br]that I should read their fucking manual?

9:59:59.000,9:59:59.000
<i>more laughter</i>[br]Guess where that code came from:

9:59:59.000,9:59:59.000
the official CGI documentation![br]<i>big applause and audience whistling</i>

9:59:59.000,9:59:59.000
But, I'm not blaming CGI.PM developers.

9:59:59.000,9:59:59.000
Nor am I blaming developers [br]who copied from CGI.PM examples.

9:59:59.000,9:59:59.000
After all, who could have known [br]that this is what this code will do?

9:59:59.000,9:59:59.000
This is how it could be exploited?

9:59:59.000,9:59:59.000
There's no exec calls, [br]the file is not saved anywhere,

9:59:59.000,9:59:59.000
and we're only using a "print".

9:59:59.000,9:59:59.000
The sole responsible for this mess, [br]is the Perl language.

9:59:59.000,9:59:59.000
Perl is the one silently expanding lists,

9:59:59.000,9:59:59.000
Perl is the one mixing up your data types,

9:59:59.000,9:59:59.000
Perl is the one executing user input [br]with no exec calls,

9:59:59.000,9:59:59.000
Perl is the problem,

9:59:59.000,9:59:59.000
not its developers.[br]<i>applause rising</i>

9:59:59.000,9:59:59.000
And until this god-damned, bizarre, [br]dangerous language is fixed,

9:59:59.000,9:59:59.000
you could only [br]stop

9:59:59.000,9:59:59.000
using

9:59:59.000,9:59:59.000
Perl!

9:59:59.000,9:59:59.000
Thank you![br]<i>more applause</i>

9:59:59.000,9:59:59.000
Herald: So I guess [br]we have some time for questions now.

9:59:59.000,9:59:59.000
<i>laughter</i>[br]Netanel: Maybe

9:59:59.000,9:59:59.000
Herald: And I have the funny feeling, [br]we will have some questions now.

9:59:59.000,9:59:59.000
Ok, so we have some microphones here. [br]Please queue up.

9:59:59.000,9:59:59.000
Please do not shout in, because we need [br]to record it on the stream.

9:59:59.000,9:59:59.000
Well, here we go.

9:59:59.000,9:59:59.000
And we also have some questions [br]from the internet, don't we?

9:59:59.000,9:59:59.000
Signal angel: Oh yes, we do![br]<i>laughter</i>

9:59:59.000,9:59:59.000
Signal: but before we come [br]to the technical questions,

9:59:59.000,9:59:59.000
the IRC wants you to know, [br]what you did to it:

9:59:59.000,9:59:59.000
it felt like there were explosions [br]and camels everywhere.

9:59:59.000,9:59:59.000
Netanel <i>laughing</i>: That's the point

9:59:59.000,9:59:59.000
Signal: And incidently they want to know, [br]if you have a list of those camel pics somewhere?

9:59:59.000,9:59:59.000
Netanel: I think Google has it? [br]<i>more laughter</i>

9:59:59.000,9:59:59.000
Just there search camels.

9:59:59.000,9:59:59.000
Signal: So for the first question. [br]Opello(?) wants to know,

9:59:59.000,9:59:59.000
if the take-away is, that Perl project authors [br]so shouldn't trust input

9:59:59.000,9:59:59.000
and instead verify types with REF [br]and always use prepared SQL statements?

9:59:59.000,9:59:59.000
Netanel: That's a good question. The take-away should be… [br]<i>laughter</i>

9:59:59.000,9:59:59.000
well, how will I phrase it …

9:59:59.000,9:59:59.000
I think I have a slide … somewhere … [br]<i>more laughter</i>

9:59:59.000,9:59:59.000
Oh wait, where's my slide?

9:59:59.000,9:59:59.000
Don't worry, have it right here.

9:59:59.000,9:59:59.000
But really, trusting user input [br]is always a bad idea

9:59:59.000,9:59:59.000
and most developers know it.

9:59:59.000,9:59:59.000
The problem is, that…

9:59:59.000,9:59:59.000
well, at least from the code I saw reading Perl,

9:59:59.000,9:59:59.000
and that's a lot of code, trust me

9:59:59.000,9:59:59.000
…is that hashes and arrays [br]are almost always considered secured

9:59:59.000,9:59:59.000
as they supposedly can't be [br]created by user input, as I said.

9:59:59.000,9:59:59.000
But, when you're expecting your user input [br]to be a scalar, a string or even a list

9:59:59.000,9:59:59.000
and instead you get a hash from unexpected [br]directions, you get confused.

9:59:59.000,9:59:59.000
And you can't always [br]live in the fear of not knowing

9:59:59.000,9:59:59.000
what data type you're trying to handle.

9:59:59.000,9:59:59.000
Well, not trusting scalar data types [br]it's a wise decision, because it's dangerous.

9:59:59.000,9:59:59.000
But not trusting your hashes, [br]as well not trusting your arrays?

9:59:59.000,9:59:59.000
What's next? Not trusting your own code?

9:59:59.000,9:59:59.000
You just can't expect anything [br]to really work as it should.

9:59:59.000,9:59:59.000
When you're writing Perl,

9:59:59.000,9:59:59.000
you are constantly attacked [br]by all these different directions.

9:59:59.000,9:59:59.000
And even the data type direction is a problem now.

9:59:59.000,9:59:59.000
I hope that answers the question [br]beside the slide.

9:59:59.000,9:59:59.000
Herald: Well, than we're gonna go over [br]and start with number one

9:59:59.000,9:59:59.000
Questioner: So thank you for opening our eyes.

9:59:59.000,9:59:59.000
Even I use Perl, I would say, [br]for cooking and yes …

9:59:59.000,9:59:59.000
Netanel: I remember you[br]Q: Sorry?

9:59:59.000,9:59:59.000
N: I remember you from the last talk! [br]Q: No no

9:59:59.000,9:59:59.000
N: Oh, you're new? Oh… <i>smirking</i>[br]Q: I'm new, I'm new…

9:59:59.000,9:59:59.000
Q: So… I can't say, I'm not guilty of that, [br]but I still would say yes,

9:59:59.000,9:59:59.000
Perl is a bit like cooking with my mum.

9:59:59.000,9:59:59.000
Sometimes I put something into…[br]the… with the boiling thing…

9:59:59.000,9:59:59.000
and sometimes she, sometimes I go away, [br]sometimes she go away

9:59:59.000,9:59:59.000
and the only thing you can do is always taste.

9:59:59.000,9:59:59.000
And yes, you're maybe right, Perl is a language

9:59:59.000,9:59:59.000
where you never know what comes out, [br]but it's real cool!

9:59:59.000,9:59:59.000
If you get the right response you can use it,

9:59:59.000,9:59:59.000
if you use it to write web applications [br]I would agree.

9:59:59.000,9:59:59.000
Web applications, the professional ones [br]at least, are not for cooking,

9:59:59.000,9:59:59.000
but for doing funny things and [br]have some fun, I think it's a perfect language.

9:59:59.000,9:59:59.000
N: I think Perl is a lot of fun. [br]<i>laughter</i>

9:59:59.000,9:59:59.000
I completely agree on that. <i>laughing</i>

9:59:59.000,9:59:59.000
Herald: Then we go over to two

9:59:59.000,9:59:59.000
Question: Was your life ever threatened [br]while interacting with the Perl community?

9:59:59.000,9:59:59.000
<i>laughter</i>[br]N: Could you please repeat that? I …

9:59:59.000,9:59:59.000
Q: Was your life ever threatened [br]while interacting with the Perl community?

9:59:59.000,9:59:59.000
N: Defenitely. Defenitely,

9:59:59.000,9:59:59.000
I'm getting hate mail every day, [br]living in fear …

9:59:59.000,9:59:59.000
H: And over to the three please

9:59:59.000,9:59:59.000
Q: I think I speak for all of us, [br]when I thank you for this wonderful talk,

9:59:59.000,9:59:59.000
N: Uh, thank you. Thank you really! Thank you.[br]<i>applause</i>

9:59:59.000,9:59:59.000
Q: Brilliantly executed, but… ehm… [br]you spoke about Perl 5 I think

9:59:59.000,9:59:59.000
N: Yes, you are absolutely right[br]Q: As some of you might know, this christmas…

9:59:59.000,9:59:59.000
<i>laughter</i>[br]Q: …so tomorrow Ingo Blechschmidt

9:59:59.000,9:59:59.000
will give a talk about how Perl 6 [br]will make everything better

9:59:59.000,9:59:59.000
and how everyone should start [br]using Perl 6 and…

9:59:59.000,9:59:59.000
N: It also craps rainbows[br]Q: Yeah, of course…

9:59:59.000,9:59:59.000
Q: My personal comment is: [br]wouldn't it have happened

9:59:59.000,9:59:59.000
with a statically typed language?

9:59:59.000,9:59:59.000
So I think some nice folks at Haskell [br]in IRC are waiting for you Perl developers

9:59:59.000,9:59:59.000
to please come, join us … Thank you![br]N: <i>smirking</i>

9:59:59.000,9:59:59.000
<i>Herald and Netanel start speaking simultaneously</i>

9:59:59.000,9:59:59.000
H: …sorry, to answer first, where am I… sorry[br]N: I… no thanks… <i>unclear</i>

9:59:59.000,9:59:59.000
just a quick note to Perl 6. [br]This talk is all about Perl 5, alright?

9:59:59.000,9:59:59.000
I … Perl 6 came out a couple of days ago and …

9:59:59.000,9:59:59.000
From … at least what I saw, [br]Perl 6 is to Perl as…

9:59:59.000,9:59:59.000
C++ is to C. It's the same name, [br]but it's a whole different language.

9:59:59.000,9:59:59.000
So yes, this is Perl 5. [br]Maybe I'll come back next year about Perl 6?

9:59:59.000,9:59:59.000
<i>laughter</i>[br]Who knows?

9:59:59.000,9:59:59.000
Herald: I'm looking forward to that already[br]<i>applause</i>

9:59:59.000,9:59:59.000
<i>Herald pointing to signal angel</i>

9:59:59.000,9:59:59.000
Signal: Yeah… Joerd(?) wants to know: [br]of course you talked a lot about CGI.PM

9:59:59.000,9:59:59.000
which you know was removed from repository from Perl [br]even before your talk last year.

9:59:59.000,9:59:59.000
So what about it's replacements [br]from CPAN like CGI::Simple.

9:59:59.000,9:59:59.000
Netanel: I don't know, I haven't checked it. [br]When I decided on which modules to check,

9:59:59.000,9:59:59.000
I took CGI.PM because even though it is old, [br]it is the most popular in the world as of today

9:59:59.000,9:59:59.000
and I took Mojolicious and Catalyst because [br]they were really popular, too.

9:59:59.000,9:59:59.000
So I didn't take the newest modules, [br]I take the most popular modules.

9:59:59.000,9:59:59.000
And I think, that's the important [br]aspect of … deciding.

9:59:59.000,9:59:59.000
Herald: and over to one please

9:59:59.000,9:59:59.000
Questioner: Hi… uhm… part of the Perl community, and…[br]<i>laughter</i>

9:59:59.000,9:59:59.000
N: Hi![br]Q: But I just start with Perl – 5

9:59:59.000,9:59:59.000
N: Uhh… ehm… uhh… didn't you… nhaa…[br]<i>laughter</i>

9:59:59.000,9:59:59.000
Q: We use Perl for almost every modules [br]that we have at work

9:59:59.000,9:59:59.000
and this worked really fine. [br]N: …yeah…

9:59:59.000,9:59:59.000
Q: And I don't know why you're picking Perl as language to attack.

9:59:59.000,9:59:59.000
It's a really old language, it's also every language [br]that we can pick, that has problems.

9:59:59.000,9:59:59.000
But it doesn't mean this has to die or [br]stop using it. So I don't know why…

9:59:59.000,9:59:59.000
N: …you're right, you're right. [br]First of all, you're completely right,

9:59:59.000,9:59:59.000
because a language shouldn't die, it should improve.

9:59:59.000,9:59:59.000
C got critized and it improved. [br]PHP got critized and it improved.

9:59:59.000,9:59:59.000
Why can't Perl be critized, too?

9:59:59.000,9:59:59.000
Why is it like a code, when you say [br]something bad about Perl then,

9:59:59.000,9:59:59.000
I don't know, a horde of PerlMonks jumps on you?

9:59:59.000,9:59:59.000
Why don't improve the language? [br]Don't use it in your work though,

9:59:59.000,9:59:59.000
it's dangerous. [br]<i>laughter and applause</i>

9:59:59.000,9:59:59.000
H: Then we gonna jump over to five please

9:59:59.000,9:59:59.000
Q: Hi. I'm not a Perl developer, [br]but I use a lot of Ruby and Python.

9:59:59.000,9:59:59.000
Is this really limited to Perl or

9:59:59.000,9:59:59.000
does this apply to more or less [br]any dynamic language?

9:59:59.000,9:59:59.000
N: As I said in one of the first few slides,

9:59:59.000,9:59:59.000
some of it also applys to Python. [br]Specifically the thing

9:59:59.000,9:59:59.000
when you can't specify the data types [br]your function arguments can get.

9:59:59.000,9:59:59.000
But, what's unique to Perl is that [br]writing different code

9:59:59.000,9:59:59.000
for different data types in one function [br]is very, very common.

9:59:59.000,9:59:59.000
You can do it in every language, of course!

9:59:59.000,9:59:59.000
But it is very common only in Perl! [br]And that is unique about it,

9:59:59.000,9:59:59.000
of course besides the thing [br]that hashes and arrays are secure.

9:59:59.000,9:59:59.000
That's of course Perls only fault.

9:59:59.000,9:59:59.000
H: Good, than we gonna go over to six please

9:59:59.000,9:59:59.000
Q: Hey! Did you say WAT more [br]while preparing this talk or while holding it?

9:59:59.000,9:59:59.000
N: Uhm. Both. <i>Laughing</i>. [br]Did I rant? That was the … right?

9:59:59.000,9:59:59.000
Q: Did you say it more [br]while preparing it or while holding it?

9:59:59.000,9:59:59.000
N: I'm missing your word, man.

9:59:59.000,9:59:59.000
Ahh, wat… WAT! Ohh… Yeah, both![br]<i>laughter</i>

9:59:59.000,9:59:59.000
H: Ok, do we have another from the internet?

9:59:59.000,9:59:59.000
Signal: Does your exploit [br]also work in tainted mode?

9:59:59.000,9:59:59.000
N: No, I believe not. No, it doesn't.

9:59:59.000,9:59:59.000
H: And another one

9:59:59.000,9:59:59.000
S: Is there any Perl obfuscated code exploits [br]like this for Catalyst or Mojolicious?

9:59:59.000,9:59:59.000
N: I've no idea, man maybe. [br]I didn't check it of course.

9:59:59.000,9:59:59.000
I didn't check every module [br]for every exploit, I ever want to create, but

9:59:59.000,9:59:59.000
on CGI.PM, which is again [br]the most popular CGI library, it did.

9:59:59.000,9:59:59.000
So, maybe the internet [br]can find more exploits. I know it can.

9:59:59.000,9:59:59.000
H: Bring it on. That's it?[br]N: That's it?

9:59:59.000,9:59:59.000
Thank you!

9:59:59.000,9:59:59.000
<i>applause</i>

9:59:59.000,9:59:59.000
Herald: Thank you very much![br]Netanel: Thank you!

9:59:59.000,9:59:59.000
<i>postroll music</i>