0:00:00.000,0:00:08.755
<i>preroll music</i>

0:00:10.084,0:00:13.459
Herald: And I'm gonna introduce Netanel Rubin.

0:00:14.698,0:00:19.502
He has been here last year with a talk [br]that he got some bashing for.

0:00:19.760,0:00:23.738
This year he's gonna ensure,[br]it's not the programmer's fault,

0:00:23.789,0:00:27.426
it's the language itself. No?

0:00:27.507,0:00:30.293
Well, here we go, well here we go.

0:00:30.379,0:00:33.598
Netanel, he is working for [br]PerimeterX in Tel Aviv,

0:00:33.631,0:00:36.318
welcome on stage, your talk!

0:00:36.374,0:00:41.134
Netanel: Thank you, thank you![br]<i>applause</i>

0:00:45.167,0:00:52.755
Last year I stood right on this very stage[br]and I talked about several of Perl's

0:00:52.755,0:00:55.911
less thought out "features".

0:00:56.396,0:01:04.787
Now, I got some bashing from the Perl community, [br]but mainly what happened was,

0:01:04.839,0:01:10.323
that the Perl community completely rejected my talk [br]claiming that the language

0:01:10.371,0:01:16.357
is completely fine and great [br]and all of this stuff are just improvements.

0:01:17.823,0:01:20.724
It was clear I had to give another talk.

0:01:22.021,0:01:28.505
This is why I'm very proud to present [br]"Perl Jam 2 – The Camel strikes back"!

0:01:29.109,0:01:34.078
<i>applause</i>

0:01:34.148,0:01:36.188
Thank you

0:01:38.325,0:01:45.963
At the last talk, I showed that "lists" are expressions, [br]used in… many confusing ways.

0:01:46.013,0:01:52.921
I also showed CGI parameters can create lists, [br]directly from user input.

0:01:52.921,0:02:00.165
But most importantly, I showed [br]that when these two things combine, shit happens.

0:02:01.996,0:02:02.926
Great

0:02:04.720,0:02:08.950
But the really interesting part [br]was the PerlMonks response.

0:02:08.950,0:02:16.203
The Perl community[br]<i>laughter</i>

0:02:20.064,0:02:24.451
The Perl community had a long discussion [br]at the PerlMonks forum.

0:02:24.451,0:02:29.475
It started with the words [br]"Sad news from Germany".

0:02:29.475,0:02:32.231
A bit dramatic, but who am I to judge?

0:02:32.231,0:02:38.931
So, after a long, long discussion, [br]they came to the unavoidable conclusion

0:02:38.931,0:02:47.997
that my talk was, in fact, a "polemic shit", [br]and they should all just "piss on it". Wink.

0:02:47.997,0:02:55.756
They also realized that I'm just a [br]"script kiddie preaching to other script kiddies",

0:02:55.756,0:03:01.162
and not just any script kiddies, the CCC audience is a

0:03:01.162,0:03:06.435
"heterogeneous group of chaotic punks [br]who love to see themselves in the hacker

0:03:06.435,0:03:18.091
image of Hollywood media". [br]<i>applause and whistling from audience</i>

0:03:18.091,0:03:24.075
What hacker image? [br]What are they talking about?

0:03:24.075,0:03:26.448
We have no hacker image.

0:03:26.770,0:03:34.281
Anyway, it got quite surreal, as in some point [br]they even critized

0:03:34.281,0:03:41.994
the "crude use of propaganda [br]in the camel images". WAT.

0:03:42.731,0:03:46.015
<i>laughing</i>[br]<i>applause</i>

0:03:46.015,0:03:50.737
Propaganda in the camel images. Alright.

0:03:50.737,0:03:58.348
Anyway, they completely rejected the entire talk, [br]even though the technical points were valid.

0:03:58.348,0:04:03.603
They rejected it because of [br]some jokes and camel images.

0:04:03.603,0:04:12.814
But still, they got so offended they just threw [br]lame excuses as to why their language sucks.

0:04:12.814,0:04:19.622
Two of these lame excuses were [br]repeated over and over again.

0:04:19.622,0:04:24.733
The first was that I should [br]read the fucking manual, which is funny

0:04:24.733,0:04:27.413
because I thought I was the only one who did…

0:04:27.413,0:04:29.184
<i>laughter</i>

0:04:29.184,0:04:30.753
…and the second is that

0:04:30.753,0:04:35.378
I'm using the old, ancient Perl, [br]and not the new, modern Perl.

0:04:35.378,0:04:39.920
<i>more laughter</i>

0:04:40.811,0:04:46.317
Remember these two points carefully [br]as I'll later break them in the presentation.

0:04:46.317,0:04:52.167
But, enough with the intro, [br]let's start with the new madness.

0:04:52.167,0:04:58.788
So, Perl allows declaring variables [br]without specifying their data type.

0:04:58.788,0:05:03.131
Of course, this functionally exists [br]in many dynamic languages,

0:05:03.131,0:05:06.884
and is completely fine and very convenient.

0:05:06.884,0:05:12.773
But, as usual, Perl took it [br]to a whole different level.

0:05:12.773,0:05:19.200
Perl went as far as removing [br]data type declarations from function arguments.

0:05:19.200,0:05:20.854
You can see that in this example

0:05:20.854,0:05:27.760
I'm just receiving two different arguments [br]without knowing what type they are.

0:05:27.760,0:05:29.760
Let me be clear about that,

0:05:29.760,0:05:34.536
you don't get to choose whether you want [br]to specify argument data types or not,

0:05:34.536,0:05:41.053
you can't specify [br]what data types you're expecting to get.

0:05:41.053,0:05:44.764
So even if I built a function [br]that only works with strings,

0:05:44.764,0:05:49.332
I have no way of forcing that [br]at the function declaration.

0:05:49.332,0:05:51.318
Now that's annoying.

0:05:51.318,0:05:57.704
But, the real kicker [br]is how this feature is used.

0:05:57.704,0:06:03.828
Apparently, it is very common to write [br]two completely different blocks of code,

0:06:03.828,0:06:07.675
one that handles scalar types, [br]like strings or ints,

0:06:07.675,0:06:13.217
and one that handles non-scalar types, [br]like arrays or hashes.

0:06:13.217,0:06:15.338
Let me repeat that:

0:06:15.338,0:06:23.796
Writing multiple code, for multiple data-types, [br]in one function, is a Perl standard.

0:06:23.796,0:06:31.782
And that's sad. You shouldn't write redundant code [br]because the language lacks the capability

0:06:31.782,0:06:35.971
of letting you decide [br]which cases you don't want to handle.

0:06:35.971,0:06:40.493
By the way, Python doesn't let you [br]declare your function argument data types too,

0:06:40.493,0:06:45.723
but unlike Perl, writing redundant code [br]to cover that up

0:06:45.723,0:06:49.726
is definitely not the standard.

0:06:49.726,0:06:54.723
Anyway, sad as this may be, [br]this Perl convention is not dangerous.

0:06:54.723,0:06:56.894
The dangerous part begins

0:06:56.894,0:07:02.956
when hashes and arrays [br]are considered as "secure" data types,

0:07:02.956,0:07:07.738
mainly because they can't be created [br]by user input.

0:07:07.738,0:07:10.374
This results in this kind of code,

0:07:10.374,0:07:14.187
where if the function argument [br]is a hash, for example,

0:07:14.187,0:07:18.708
it is used un-escaped in dangerous functions.

0:07:18.708,0:07:24.191
Hashes, specifically, are considered so secure, [br]that even if you use "taint mode",

0:07:24.191,0:07:28.883
which is some kind of safe mode for Perl,

0:07:28.883,0:07:33.532
hash keys are not tainted, meaning [br]that, even if you use safe mode,

0:07:33.532,0:07:36.719
they can be still used in dangerous functions

0:07:36.719,0:07:41.639
without any validation, [br]as opposed to other data type.

0:07:41.639,0:07:46.619
Now this kind of code appears a lot [br]in Perl applications,

0:07:46.619,0:07:49.759
and apart from the many bugs [br]this method can cause,

0:07:49.759,0:07:54.635
it also makes your code exploitable.

0:07:54.635,0:07:58.369
So we know function arguments are of unknown data type.

0:07:58.369,0:08:03.073
And we know developers treat hashes and arrays [br]as "secure" data types,

0:08:03.073,0:08:06.603
inserting their values into dangerous functions.

0:08:06.603,0:08:09.140
But this practices isn't something

0:08:09.140,0:08:14.056
that was created a long time ago, [br]and found only on redundant code.

0:08:14.056,0:08:20.341
Because of how the language is built, [br]it's supposedly restriction-less type of developing,

0:08:20.341,0:08:26.898
even now it is the natural way to code [br]when you're using Perl.

0:08:26.898,0:08:31.185
And that's the real problem: [br]Perl is like a shotgun,

0:08:31.185,0:08:36.552
with one trigger you know about [br]and a dozen that you don't.

0:08:36.552,0:08:40.821
For now, we know [br]that if we'll somehow manage

0:08:40.821,0:08:46.051
to create these "secure" data types, [br]with our user input,

0:08:46.051,0:08:49.010
we could exploit the code.

0:08:49.010,0:08:53.997
So the only question remaining really [br]is what are we gonna exploit?

0:08:53.997,0:08:58.185
And the answer, again, [br]is Bugzilla.

0:08:58.185,0:09:02.768
<i>laughter</i>

0:09:03.178,0:09:08.713
Like every other Perl project, [br]Bugzilla is heavily using functions

0:09:08.713,0:09:13.277
that treat scalar and non-scalar [br]argument types very differently.

0:09:13.277,0:09:17.404
This is one of them: [br][br]The load from DB function is responsible

0:09:17.404,0:09:21.541
for extracting object specific data [br]out of the database.

0:09:21.541,0:09:28.945
Like I just said, it treats scalars, [br]and in this case hashes, very differently.

0:09:28.945,0:09:34.146
If the function argument is a hash, [br]it takes one of its values

0:09:34.146,0:09:39.845
and inserts it as is, un-escaped, [br]into an SQL statement.

0:09:39.845,0:09:44.598
Again, because hashes [br]are considered secure,

0:09:44.598,0:09:47.807
so there's no point of escaping them.

0:09:47.807,0:09:50.919
On the other hand, [br]if the argument is a scalar,

0:09:50.919,0:09:55.798
it converts it into an integer [br]and only then use it in an SQL statement.

0:09:55.798,0:09:59.020
Because scalar values, are not secure.

0:09:59.020,0:10:00.680
hashes: secure

0:10:00.680,0:10:03.064
scalar: not secure

0:10:03.064,0:10:06.241
This means that if we could control [br]the function argument entirely,

0:10:06.241,0:10:10.964
including its data type, [br]we could control the SQL query,

0:10:10.964,0:10:14.405
affectively exploiting an SQL injection attack,

0:10:14.405,0:10:17.720
by inserting a hash [br]containing that specific value.

0:10:17.720,0:10:21.234
But…

0:10:21.234,0:10:26.862
CGI input doesn't allow hashes, right?

0:10:26.862,0:10:32.339
The whole Perl security module [br]is built on that assumption.

0:10:32.339,0:10:37.314
The problem is that, like us, [br]developers are assuming

0:10:37.314,0:10:42.487
CGI input is the only input method available.

0:10:42.487,0:10:46.121
CGI.

0:10:46.121,0:10:49.375
But CGI isn't the only way to go.

0:10:49.375,0:10:53.218
Bugzilla developers missed the fact [br]that their own system

0:10:53.218,0:10:57.723
is also featuring an XMLRPC and a JSONRPC,

0:10:57.723,0:11:05.388
both supporting input of non-scalar data types [br]like arrays and hashes!

0:11:05.388,0:11:07.048
But I'm not blaming them.

0:11:07.048,0:11:12.492
Yes, they forgot that there are more ways [br]for user to input than CGI,

0:11:12.492,0:11:16.697
but still, they're just the product [br]of how Perl programming is taught,

0:11:16.697,0:11:20.679
filled with false assumptions and inconsistencies.

0:11:20.679,0:11:25.983
Expecting anything but this kind [br]of security problems is just naive.

0:11:25.983,0:11:28.547
But back to the vulnerability.

0:11:28.547,0:11:30.429
If we'll use one of these RPCs,

0:11:30.429,0:11:34.136
sending our input parameter with a malicious hash,

0:11:34.136,0:11:37.204
instead of just a regular numeric parameter,

0:11:37.204,0:11:39.991
we will be able to exploit the SQL Injection!

0:11:39.991,0:11:44.428
So, if we'll send this regular request, [br]using the JSONRPC interface,

0:11:44.428,0:11:48.611
the number 1 will be used [br]as the ID of a bug to extract,

0:11:48.611,0:11:51.272
but if we'll send this request,

0:11:51.272,0:11:53.993
where instead of an integer we'll supply a hash,

0:11:53.993,0:11:57.365
than suddenly we will be able [br]to inject any SQL we'd like

0:11:57.365,0:12:03.016
into that statement, affectively [br]compromising the entire database.

0:12:03.561,0:12:07.048
Now when you look at this request, you realize

0:12:07.048,0:12:11.396
that this is not a sophisticated vulnerability.

0:12:11.396,0:12:20.859
All I did was just change the input data type [br]from scalar in this case to a hash,

0:12:20.859,0:12:24.980
and that's it, the system is compromised.

0:12:24.980,0:12:29.072
It was so heavily built on the assumption

0:12:29.072,0:12:32.223
that hashes are secure, that it offered me

0:12:32.223,0:12:36.676
almost unlimited access security wise.

0:12:36.676,0:12:41.659
The funny thing about that is, that [br]although it's so simple,

0:12:41.659,0:12:45.970
the attack has existed for over 5 years.

0:12:45.970,0:12:48.912
That's the year I was born in.

0:12:48.912,0:12:55.087
So, we now proved this "unknown-argument-type" feature

0:12:55.087,0:12:58.232
is a huge source for problems.

0:12:58.232,0:13:02.901
We also know writing different code [br]to handle different data types

0:13:02.901,0:13:06.953
just causes a lot of false assumptions.

0:13:06.953,0:13:13.534
But most importantly, treating non-scalar [br]data types such as hashes as "secure",

0:13:13.534,0:13:17.354
just because they supposedly can't be created by the user,

0:13:17.354,0:13:22.955
is very, Very, BAD. Just ask Bugzilla.

0:13:22.955,0:13:30.145
But the shocking part really, is that, again, [br]this is the Perl Standard!

0:13:30.145,0:13:33.892
You're not expected to use it, you have to

0:13:33.892,0:13:36.645
as you don't have any other choice.

0:13:36.645,0:13:43.829
This security-mess [br]is a fundamental part of the language.

0:13:43.829,0:13:51.777
The problem is that creating non-scalar data types [br]is impossible in some cases.

0:13:51.777,0:13:54.914
We can't rely that some kind of RPC

0:13:54.914,0:13:58.859
will exist in the code [br]and support different data types,

0:13:58.859,0:14:05.361
and we can't create data types [br]using regular user input… Right?

0:14:05.361,0:14:07.057
Well, let's have a look at

0:14:07.057,0:14:10.526
how different CGI modules [br]handle different kind of input.

0:14:10.526,0:14:13.917
First, we'll take the most trivial scenario.

0:14:13.917,0:14:17.807
A single valued parameter, [br]something that looks like this request,

0:14:17.807,0:14:22.210
where the "foo" parameter [br]is assigned the string "bar".

0:14:22.210,0:14:26.819
In this case, a scalar is created on all three CGI modules,

0:14:26.819,0:14:31.198
which doesn't really help us, [br]but is pretty much what we've expected.

0:14:31.198,0:14:32.914
It is secure.

0:14:32.914,0:14:37.846
What happens if instead of [br]sending a single-valued parameter,

0:14:37.846,0:14:42.377
we'll send a multi-valued parameter, [br]like in this request?

0:14:42.377,0:14:46.032
Now things are starting to get complicated.

0:14:46.032,0:14:50.551
On CGI.PM, as we already know, [br]a list is created,

0:14:50.551,0:14:55.013
which is very useful for us, [br]but not what we're after.

0:14:55.013,0:15:01.847
But let's have a look at [br]what the "new" Perl modules are creating.

0:15:01.847,0:15:09.987
We'll see that both of them are returning [br]arrays containing our values.

0:15:09.987,0:15:14.549
Arrays! WAT?

0:15:14.549,0:15:19.278
I thought you can't create [br]these kind of data types with regular input,

0:15:19.278,0:15:22.442
after all, they're considered safe.

0:15:22.442,0:15:24.236
But let's continue.

0:15:24.236,0:15:27.637
What happens if instead of sending a regular value,

0:15:27.637,0:15:31.883
we'll try and upload a file in that parameter?

0:15:31.883,0:15:35.229
Now things are really getting out of hand,

0:15:35.229,0:15:44.409
because CGI.PM now returns a file descriptor, [br]and Catalyst and Mojolicious returns a hash.

0:15:44.409,0:15:46.384
WAT?

0:15:46.384,0:15:54.012
We just exploited [br]the most popular Perl project in the world

0:15:54.012,0:15:58.226
because they assumed hashes can't be created by the user,

0:15:58.226,0:16:02.984
and now we're finding out [br]that not only we can create hashes,

0:16:02.984,0:16:05.477
it is a god-damned feature?!

0:16:05.477,0:16:07.161
That's insane!

0:16:07.161,0:16:11.504
The whole Perl security standard is built on the assumption

0:16:11.504,0:16:14.954
that users can't create non-scalar data-types

0:16:14.954,0:16:19.867
and now suddenly these are features?

0:16:19.867,0:16:27.693
Let's send a multi-file upload request [br]as in several files in the same parameter.

0:16:27.693,0:16:34.183
Watch closely, because this is where it gets ridiculous.

0:16:34.183,0:16:39.426
Now, CGI.PM returns a list of File Descriptors,

0:16:39.426,0:16:42.551
Catalyst returns a list of Hashes

0:16:42.551,0:16:49.282
and Mojolicious returns an array of objects! WAT?!

0:16:49.282,0:16:53.340
<i>laughter and applause</i>

0:16:54.124,0:16:58.105
Almost any Perl project in the world

0:16:58.105,0:17:03.470
uses one of these modules [br]for parsing CGI input.

0:17:03.470,0:17:10.523
Just think how many developers assumed [br]the exact same thing Bugzilla assumed

0:17:10.523,0:17:15.854
and treated hashes and arrays as secure data types.

0:17:15.854,0:17:17.753
So if you're using CGI.PM,

0:17:18.380,0:17:21.268
instead of the expected scalar value you could be getting

0:17:21.268,0:17:25.725
a list, a file descriptor or a list of file descriptors

0:17:25.725,0:17:27.644
and if you're using Catalyst

0:17:27.644,0:17:30.895
you could receive a scalar, an array, a hash or a list,

0:17:30.895,0:17:35.375
which is basically any data type.

0:17:36.320,0:17:39.425
So expecting your function… yeah

0:17:40.089,0:17:44.091
<i>audience chuckling</i>

0:17:45.943,0:17:53.997
So expecting your function arguments [br]to be of a specific data type is false.

0:17:53.997,0:18:00.119
Expecting hashes and arrays to be secure is also false.

0:18:00.119,0:18:02.972
Expecting scalar only user input

0:18:02.972,0:18:06.833
is a major false.

0:18:06.833,0:18:13.156
And to be honest, it seems that in Perl expecting is false!

0:18:13.156,0:18:17.337
<i>laughter and applause</i>

0:18:21.422,0:18:25.923
You just can't expect anything

0:18:25.923,0:18:32.455
even the most basic of things [br]such as what data type your variable is made of.

0:18:32.455,0:18:35.761
You just don't know.

0:18:37.870,0:18:42.934
But I felt all of these points will [br]go un-noticed

0:18:42.934,0:18:48.632
without an extreme example of Perl's absurdity.

0:18:48.632,0:18:52.599
So I found an extreme example.

0:18:52.599,0:18:55.249
One that will clearly show

0:18:55.249,0:18:59.204
the ridiculous nature of the language.

0:18:59.204,0:19:00.898
And this is it:

0:19:00.898,0:19:06.829
All this code does is print an uploaded file's content.

0:19:06.829,0:19:15.077
And to show you how basic and simple that code is, [br]I'll explain each line.

0:19:15.077,0:19:20.993
The first line just creates a new CGI instance, [br]so we could get the file from the user.

0:19:20.993,0:19:27.475
The second line checks if a file [br]has been uploaded in the "file" parameter.

0:19:27.475,0:19:31.909
The third line gets the file descriptor from the CGI module,

0:19:31.909,0:19:37.438
while the forth line loops through the file [br]and the fifths prints it.

0:19:37.438,0:19:44.459
That's it. Again: all this code does [br]is get a file and print it.

0:19:44.459,0:19:45.871
<i>clapping</i>[br]That's it.

0:19:45.871,0:19:52.126
A user has uploaded a file to the server [br]and the server is just returning its content.

0:19:52.126,0:19:55.683
It's not saving it anywhere, [br]it's not moving it anywhere,

0:19:55.683,0:19:58.771
it just prints its content.

0:19:58.771,0:20:03.519
There should be absolutely [br]nothing dangerous in this code,

0:20:03.519,0:20:07.087
it contains literally five lines.

0:20:07.087,0:20:09.830
Yet, It's demo time.

0:20:09.830,0:20:12.332
<i>laughter</i>

0:20:12.792,0:20:15.020
So trust me, you don't need to see the text,

0:20:15.020,0:20:19.820
all you need to see is that [br]when I'm sending a regular request nothing happens.

0:20:19.820,0:20:23.585
When I send it now, nothing happens,[br]I'm just getting the file content.

0:20:23.585,0:20:26.240
We're having fun, you don't see the burp…

0:20:26.240,0:20:30.425
Now, nice. Okay

0:20:30.425,0:20:34.184
So…[br]…L't me just…

0:20:35.085,0:20:37.182
…I have no idea where my mouse is, okay.

0:20:37.388,0:20:38.323
So…

0:20:39.181,0:20:42.780
I'm sending a regular request, [br]nothing happens, just getting the content.

0:20:42.780,0:20:45.713
I know, you can't see the text…[br]…and…

0:20:45.713,0:20:49.519
when I'm sending my malicious request,

0:20:49.519,0:20:52.795
something interesting will pop up.

0:20:52.901,0:20:54.990
Watch closely! It's gonna be quick.

0:20:55.502,0:20:56.684
Ready?

0:20:58.270,0:21:01.639
Oh, you haven't seen it, it's on the different screen.

0:21:02.090,0:21:06.641
Just a second… oh… duplicate…

0:21:07.809,0:21:09.236
(from audience): … magnify it!

0:21:09.236,0:21:11.781
Netanel: I'll magnify it.

0:21:11.781,0:21:14.247
<i>laughter</i>

0:21:14.611,0:21:18.136
Alright, so… watch closely.

0:21:19.184,0:21:22.772
Ohh, uuh? What was that?

0:21:24.797,0:21:26.942
Let's see it again.

0:21:27.719,0:21:29.528
<i>mocking</i> Uuuuuh?!

0:21:30.340,0:21:37.335
<i>laughter and applause</i>

0:21:37.793,0:21:41.082
Yupp, <i>clearing throat</i>

0:21:41.612,0:21:44.650
… just a second.

0:21:45.410,0:21:46.579
Nice.

0:21:46.714,0:21:49.747
So you're probably asking yourself right now

0:21:49.747,0:21:52.951
"What the fuck did I just see?"[br]<i>laughter</i>

0:21:52.951,0:21:55.814
"Was that a terminal screen?"

0:21:55.814,0:22:00.237
And the answer is … "Yes"[br]Yes, it was

0:22:00.237,0:22:04.468
specifically the "ipconfig" command output.

0:22:04.468,0:22:07.414
Or in other words: What you just saw

0:22:07.414,0:22:15.820
was me exploiting that five lines [br]with a remote code execution attack.

0:22:15.820,0:22:20.873
So now that you saw the magic happens, [br]I think it's time for some explanations.

0:22:20.873,0:22:22.917
The first line, responsible for checking

0:22:22.917,0:22:26.221
if a file has been uploaded in the "file" parameter,

0:22:26.221,0:22:29.956
doesn't exactly do as it says.

0:22:29.956,0:22:34.013
Instead of checking if the "file" [br]parameter is an uploaded file,

0:22:34.013,0:22:39.540
it checks if one of it values is a file descriptor.

0:22:39.540,0:22:45.110
Let me clarify that, instead of checking [br]if the parameter is only a file,

0:22:45.110,0:22:48.981
it checks if the parameter is also a file.

0:22:48.981,0:22:51.196
<i>laughter</i>

0:22:51.196,0:22:52.842
Meaning that uploading a file

0:22:52.842,0:22:57.023
and assigning another scalar value to the same parameter

0:22:57.023,0:23:00.147
will still work and bypass the check!

0:23:00.147,0:23:01.460
WAT?

0:23:01.460,0:23:06.435
<i>more laughter and applause</i>

0:23:12.616,0:23:16.165
Creative fellows those guys are.

0:23:16.165,0:23:22.137
So now we can assign the "file" parameter [br]both a regular file and a scalar value.

0:23:22.137,0:23:26.384
But what happens when we try to get [br]the "file" parameter value?

0:23:26.384,0:23:31.183
In a regular request, it should return [br]the uploaded file descriptor,

0:23:31.183,0:23:35.821
but now that we're adding another value to that parameter,

0:23:35.821,0:23:41.176
param() returns a list containing all the values we send:

0:23:41.176,0:23:44.365
the file we've uploaded and our scalar value.

0:23:44.365,0:23:49.521
But the "file" variable [br]can't contain two values, right?

0:23:49.521,0:23:55.641
So instead of converting [br]the returned list into an array

0:23:55.641,0:23:59.781
Perl only uses the first element of that list.

0:23:59.781,0:24:05.564
So if we'll send our scalar values [br]before we send our file,

0:24:05.564,0:24:09.989
the $file variable will be assigned [br]our scalar value

0:24:09.989,0:24:14.308
instead of the uploaded file descriptor.

0:24:14.308,0:24:20.013
Which means, that $file [br]is now a regular string!

0:24:20.013,0:24:22.114
<i>in high pitched voice:</i> WAT?

0:24:22.618,0:24:26.127
But what happens to this operator [br]when we use a string

0:24:26.127,0:24:29.025
instead of a file descriptor?

0:24:29.025,0:24:32.962
Well, the brackets operator [br]doesn't work with strings, right?

0:24:32.962,0:24:36.958
It works with file descriptors, [br]why should it work with strings?

0:24:36.958,0:24:39.580
Well, that appears true

0:24:39.580,0:24:42.817
unless that string is "ARGV".

0:24:42.817,0:24:47.644
<i>laughter and applause</i>

0:24:55.860,0:24:57.627
That's not a crazy part.

0:24:57.627,0:24:59.763
<i>more laughter</i>

0:24:59.763,0:25:04.953
In that case the brackets operator, listen closely,

0:25:04.953,0:25:07.988
loops through the script arguments,

0:25:07.988,0:25:12.887
which in CGI comes directly from the [br]query string instead the command line,

0:25:12.887,0:25:18.844
and it treats them as file paths, [br]inserting each one into an open() call!

0:25:18.844,0:25:20.497
<i>again laughter</i>

0:25:20.497,0:25:22.655
WAT?

0:25:25.952,0:25:29.485
Yeah, that made sense on some point, I guess.

0:25:29.485,0:25:32.487
All of this basically means that now,

0:25:32.487,0:25:35.874
instead of displaying [br]our own uploaded file content,

0:25:35.874,0:25:40.829
we can display the content [br]of any file on the server.

0:25:40.829,0:25:42.344
But that's not the end, [br]as we haven't executed code yet.

0:25:44.674,0:25:49.168
To execute code, we have [br]to look at the open() function.

0:25:49.168,0:25:56.676
Again, this is the function being called [br]with the ARGV values as file paths.

0:25:56.676,0:26:03.284
open() is responsible for opening [br]a file descriptor to a given file.

0:26:03.284,0:26:06.544
Unless a "pipe" character is added

0:26:06.544,0:26:09.486
to the end of the string,[br]<i>laughter</i>

0:26:09.486,0:26:13.819
in that case instead of opening the file,

0:26:13.819,0:26:16.828
it executes it…[br]<i>applause rising</i>

0:26:16.828,0:26:22.796
…acting as an exec() call![br]<i>more applause</i>

0:26:23.096,0:26:29.172
So … when we send our exploit,

0:26:29.172,0:26:34.631
containing our uploaded file, [br]the "ARGV" malicious scalar value,

0:26:34.631,0:26:38.045
and the ipconfig command followed by a pipe

0:26:38.045,0:26:42.697
this is what we get.[br]WAT?

0:26:42.697,0:26:46.639
WAT?[br]<i>applause</i>

0:26:49.585,0:26:56.705
I know, I'm shocked too, but I'm not done yet. [br]<i>laughter</i>

0:26:56.705,0:27:01.193
Truth be told, I didn't write that code.

0:27:01.193,0:27:06.159
Remember that PerlMonks told me [br]that I should read their fucking manual?

0:27:06.159,0:27:11.360
<i>more laughter</i>[br]Guess where that code came from:

0:27:11.360,0:27:19.149
the official CGI documentation![br]<i>big applause and audience whistling</i>

0:27:32.545,0:27:36.867
But, I'm not blaming CGI.PM developers.

0:27:36.867,0:27:41.365
Nor am I blaming developers [br]who copied from CGI.PM examples.

0:27:41.365,0:27:47.443
After all, who could have known [br]that this is what this code will do?

0:27:47.443,0:27:49.657
This is how it could be exploited?

0:27:49.657,0:27:54.961
There's no exec calls, [br]the file is not saved anywhere,

0:27:54.961,0:27:58.493
and we're only using a "print".

0:27:58.493,0:28:07.823
The sole responsible for this mess, [br]is the Perl language.

0:28:07.823,0:28:11.722
Perl is the one silently expanding lists,

0:28:11.722,0:28:14.832
Perl is the one mixing up your data types,

0:28:14.832,0:28:20.064
Perl is the one executing user input [br]with no exec calls,

0:28:20.064,0:28:23.010
Perl is the problem,

0:28:23.010,0:28:26.122
not its developers.[br]<i>applause rising</i>

0:28:26.122,0:28:32.159
And until this god-damned, bizarre, [br]dangerous language is fixed,

0:28:32.159,0:28:34.536
you could only [br]stop

0:28:34.536,0:28:35.629
using

0:28:35.629,0:28:40.333
Perl!

0:28:40.637,0:28:47.005
Thank you![br]<i>more applause</i>

0:28:59.485,0:29:02.754
Herald: So I guess [br]we have some time for questions now.

0:29:02.754,0:29:04.348
<i>laughter</i>[br]Netanel: Maybe

0:29:04.348,0:29:08.594
Herald: And I have the funny feeling, [br]we will have some questions now.

0:29:08.594,0:29:12.384
Ok, so we have some microphones here. [br]Please queue up.

0:29:12.384,0:29:18.469
Please do not shout in, because we need [br]to record it on the stream.

0:29:18.469,0:29:19.936
Well, here we go.

0:29:19.936,0:29:22.956
And we also have some questions [br]from the internet, don't we?

0:29:22.956,0:29:27.794
Signal angel: Oh yes, we do![br]<i>laughter</i>

0:29:27.794,0:29:30.413
Signal: but before we come [br]to the technical questions,

0:29:30.413,0:29:33.691
the IRC wants you to know, [br]what you did to it:

0:29:33.691,0:29:37.135
it felt like there were explosions [br]and camels everywhere.

0:29:37.135,0:29:39.915
Netanel <i>laughing</i>: That's the point

0:29:39.915,0:29:43.682
Signal: And incidently they want to know, [br]if you have a list of those camel pics somewhere?

0:29:43.682,0:29:49.843
Netanel: I think Google has it? [br]<i>more laughter</i>

0:29:49.843,0:29:54.336
Just there search camels.

0:29:54.336,0:29:59.224
Signal: So for the first question. [br]Opello(?) wants to know,

0:29:59.224,0:30:04.293
if the take-away is, that Perl project authors [br]so shouldn't trust input

0:30:04.293,0:30:11.287
and instead verify types with REF [br]and always use prepared SQL statements?

0:30:12.016,0:30:20.628
Netanel: That's a good question. The take-away should be… [br]<i>laughter</i>

0:30:22.079,0:30:27.968
well, how will I phrase it …

0:30:29.894,0:30:33.684
I think I have a slide … somewhere … [br]<i>more laughter</i>

0:30:33.684,0:30:37.843
Oh wait, where's my slide?

0:30:38.071,0:30:40.204
Don't worry, have it right here.

0:30:44.644,0:30:49.480
But really, trusting user input [br]is always a bad idea

0:30:49.480,0:30:52.071
and most developers know it.

0:30:52.071,0:30:54.521
The problem is, that…

0:30:54.521,0:30:57.498
well, at least from the code I saw reading Perl,

0:30:57.498,0:31:00.601
and that's a lot of code, trust me

0:31:00.601,0:31:05.154
…is that hashes and arrays [br]are almost always considered secured

0:31:05.154,0:31:09.543
as they supposedly can't be [br]created by user input, as I said.

0:31:09.543,0:31:17.966
But, when you're expecting your user input [br]to be a scalar, a string or even a list

0:31:17.966,0:31:26.256
and instead you get a hash from unexpected [br]directions, you get confused.

0:31:26.256,0:31:31.149
And you can't always [br]live in the fear of not knowing

0:31:31.149,0:31:33.963
what data type you're trying to handle.

0:31:33.963,0:31:40.575
Well, not trusting scalar data types [br]it's a wise decision, because it's dangerous.

0:31:40.575,0:31:46.369
But not trusting your hashes, [br]as well not trusting your arrays?

0:31:46.369,0:31:49.901
What's next? Not trusting your own code?

0:31:49.901,0:31:54.754
You just can't expect anything [br]to really work as it should.

0:31:54.754,0:31:56.094
When you're writing Perl,

0:31:56.094,0:32:04.629
you are constantly attacked [br]by all these different directions.

0:32:04.629,0:32:09.029
And even the data type direction is a problem now.

0:32:09.029,0:32:12.962
I hope that answers the question [br]beside the slide.

0:32:12.962,0:32:16.695
Herald: Well, than we're gonna go over [br]and start with number one

0:32:16.695,0:32:20.074
Questioner: So thank you for opening our eyes.

0:32:20.074,0:32:24.354
Even I use Perl, I would say, [br]for cooking and yes …

0:32:24.354,0:32:25.788
Netanel: I remember you[br]Q: Sorry?

0:32:25.788,0:32:27.377
N: I remember you from the last talk! [br]Q: No no

0:32:27.377,0:32:31.028
N: Oh, you're new? Oh… <i>smirking</i>[br]Q: I'm new, I'm new…

0:32:31.028,0:32:36.288
Q: So… I can't say, I'm not guilty of that, [br]but I still would say yes,

0:32:36.288,0:32:39.508
Perl is a bit like cooking with my mum.

0:32:39.508,0:32:46.315
Sometimes I put something into…[br]the… with the boiling thing…

0:32:46.315,0:32:51.434
and sometimes she, sometimes I go away, [br]sometimes she go away

0:32:51.434,0:32:51.684
and the only thing you can do is always taste.

0:32:51.684,0:32:58.514
And yes, you're maybe right, Perl is a language

0:32:58.514,0:33:02.332
where you never know what comes out, [br]but it's real cool!

0:33:02.332,0:33:04.903
If you get the right response you can use it,

0:33:04.903,0:33:09.088
if you use it to write web applications [br]I would agree.

0:33:09.088,0:33:13.464
Web applications, the professional ones [br]at least, are not for cooking,

0:33:13.464,0:33:18.856
but for doing funny things and [br]have some fun, I think it's a perfect language.

0:33:18.856,0:33:22.626
N: I think Perl is a lot of fun. [br]<i>laughter</i>

0:33:22.626,0:33:26.633
I completely agree on that. <i>laughing</i>

0:33:26.633,0:33:29.144
Herald: Then we go over to two

0:33:29.144,0:33:33.741
Question: Was your life ever threatened [br]while interacting with the Perl community?

0:33:33.741,0:33:36.064
<i>laughter</i>[br]N: Could you please repeat that? I …

0:33:36.064,0:33:39.995
Q: Was your life ever threatened [br]while interacting with the Perl community?

0:33:39.995,0:33:43.145
N: Defenitely. Defenitely,

0:33:43.145,0:33:47.109
I'm getting hate mail every day, [br]living in fear …

0:33:47.109,0:33:48.928
H: And over to the three please

0:33:48.928,0:33:53.261
Q: I think I speak for all of us, [br]when I thank you for this wonderful talk,

0:33:53.261,0:34:01.666
N: Uh, thank you. Thank you really! Thank you.[br]<i>applause</i>

0:34:01.666,0:34:07.010
Q: Brilliantly executed, but… ehm… [br]you spoke about Perl 5 I think

0:34:07.010,0:34:11.745
N: Yes, you are absolutely right[br]Q: As some of you might know, this christmas…

0:34:11.745,0:34:15.472
<i>laughter</i>[br]Q: …so tomorrow Ingo Blechschmidt

0:34:15.472,0:34:20.047
will give a talk about how Perl 6 [br]will make everything better

0:34:20.047,0:34:24.162
and how everyone should start [br]using Perl 6 and…

0:34:24.162,0:34:27.893
N: It also craps rainbows[br]Q: Yeah, of course…

0:34:27.893,0:34:31.391
Q: My personal comment is: [br]wouldn't it have happened

0:34:31.391,0:34:33.945
with a statically typed language?

0:34:33.945,0:34:39.570
So I think some nice folks at Haskell [br]in IRC are waiting for you Perl developers

0:34:39.570,0:34:44.753
to please come, join us … Thank you![br]N: <i>smirking</i>

0:34:44.753,0:34:46.456
<i>Herald and Netanel start speaking simultaneously</i>

0:34:46.456,0:34:49.886
H: …sorry, to answer first, where am I… sorry[br]N: I… no thanks… <i>unclear</i>

0:34:49.886,0:34:55.856
just a quick note to Perl 6. [br]This talk is all about Perl 5, alright?

0:34:55.856,0:34:59.478
I … Perl 6 came out a couple of days ago and …

0:34:59.478,0:35:06.848
From … at least what I saw, [br]Perl 6 is to Perl as…

0:35:06.848,0:35:11.932
C++ is to C. It's the same name, [br]but it's a whole different language.

0:35:11.932,0:35:17.311
So yes, this is Perl 5. [br]Maybe I'll come back next year about Perl 6?

0:35:17.311,0:35:19.051
<i>laughter</i>[br]Who knows?

0:35:19.051,0:35:23.415
Herald: I'm looking forward to that already[br]<i>applause</i>

0:35:23.415,0:35:25.578
<i>Herald pointing to signal angel</i>

0:35:25.578,0:35:31.574
Signal: Yeah… Joerd(?) wants to know: [br]of course you talked a lot about CGI.PM

0:35:31.574,0:35:37.750
which you know was removed from repository from Perl [br]even before your talk last year.

0:35:37.750,0:35:43.729
So what about it's replacements [br]from CPAN like CGI::Simple.

0:35:43.729,0:35:48.505
Netanel: I don't know, I haven't checked it. [br]When I decided on which modules to check,

0:35:48.505,0:35:55.990
I took CGI.PM because even though it is old, [br]it is the most popular in the world as of today

0:35:55.990,0:36:03.561
and I took Mojolicious and Catalyst because [br]they were really popular, too.

0:36:03.561,0:36:08.389
So I didn't take the newest modules, [br]I take the most popular modules.

0:36:08.389,0:36:14.513
And I think, that's the important [br]aspect of … deciding.

0:36:14.513,0:36:20.599
Herald: and over to one please

0:36:20.599,0:36:29.133
Questioner: Hi… uhm… part of the Perl community, and…[br]<i>laughter</i>

0:36:29.133,0:36:33.169
N: Hi![br]Q: But I just start with Perl – 5

0:36:33.169,0:36:40.715
N: Uhh… ehm… uhh… didn't you… nhaa…[br]<i>laughter</i>

0:36:40.715,0:36:44.829
Q: We use Perl for almost every modules [br]that we have at work

0:36:44.829,0:36:47.314
and this worked really fine. [br]N: …yeah…

0:36:47.314,0:36:51.920
Q: And I don't know why you're picking Perl as language to attack.

0:36:51.920,0:36:59.469
It's a really old language, it's also every language [br]that we can pick, that has problems.

0:36:59.469,0:37:05.027
But it doesn't mean this has to die or [br]stop using it. So I don't know why…

0:37:05.027,0:37:08.881
N: …you're right, you're right. [br]First of all, you're completely right,

0:37:08.881,0:37:11.958
because a language shouldn't die, it should improve.

0:37:11.958,0:37:17.040
C got critized and it improved. [br]PHP got critized and it improved.

0:37:17.040,0:37:20.563
Why can't Perl be critized, too?

0:37:20.563,0:37:24.238
Why is it like a code, when you say [br]something bad about Perl then,

0:37:24.238,0:37:27.684
I don't know, a horde of PerlMonks jumps on you?

0:37:27.684,0:37:32.643
Why don't improve the language? [br]Don't use it in your work though,

0:37:32.643,0:37:37.766
it's dangerous. [br]<i>laughter and applause</i>

0:37:39.896,0:37:41.799
H: Then we gonna jump over to five please

0:37:41.799,0:37:49.273
Q: Hi. I'm not a Perl developer, [br]but I use a lot of Ruby and Python.

0:37:49.273,0:37:51.551
Is this really limited to Perl or

0:37:51.551,0:37:54.169
does this apply to more or less [br]any dynamic language?

0:37:54.169,0:37:58.640
N: As I said in one of the first few slides,

0:37:58.640,0:38:02.483
some of it also applys to Python. [br]Specifically the thing

0:38:02.483,0:38:10.127
when you can't specify the data types [br]your function arguments can get.

0:38:10.127,0:38:16.074
But, what's unique to Perl is that [br]writing different code

0:38:16.074,0:38:20.517
for different data types in one function [br]is very, very common.

0:38:20.517,0:38:23.181
You can do it in every language, of course!

0:38:23.181,0:38:28.686
But it is very common only in Perl! [br]And that is unique about it,

0:38:28.686,0:38:32.881
of course besides the thing [br]that hashes and arrays are secure.

0:38:32.881,0:38:37.016
That's of course Perls only fault.

0:38:37.016,0:38:40.358
H: Good, than we gonna go over to six please

0:38:40.358,0:38:47.295
Q: Hey! Did you say WAT more [br]while preparing this talk or while holding it?

0:38:47.295,0:38:54.672
N: Uhm. Both. <i>Laughing</i>. [br]Did I rant? That was the … right?

0:38:54.672,0:39:00.911
Q: Did you say it more [br]while preparing it or while holding it?

0:39:00.911,0:39:02.963
N: I'm missing your word, man.

0:39:02.963,0:39:12.018
Ahh, wat… WAT! Ohh… Yeah, both![br]<i>laughter</i>

0:39:12.018,0:39:14.828
H: Ok, do we have another from the internet?

0:39:14.828,0:39:19.290
Signal: Does your exploit [br]also work in tainted mode?

0:39:19.290,0:39:23.583
N: No, I believe not. No, it doesn't.

0:39:23.583,0:39:26.470
H: And another one

0:39:26.470,0:39:36.487
S: Is there any Perl obfuscated code exploits [br]like this for Catalyst or Mojolicious?

0:39:36.487,0:39:43.729
N: I've no idea, man maybe. [br]I didn't check it of course.

0:39:43.729,0:39:48.082
I didn't check every module [br]for every exploit, I ever want to create, but

0:39:48.082,0:39:54.675
on CGI.PM, which is again [br]the most popular CGI library, it did.

0:39:54.675,0:40:01.866
So, maybe the internet [br]can find more exploits. I know it can.

0:40:01.866,0:40:06.622
H: Bring it on. That's it?[br]N: That's it?

0:40:06.622,0:40:09.575
Thank you!

0:40:09.575,0:40:11.407
<i>applause</i>

0:40:11.407,0:40:13.084
Herald: Thank you very much![br]Netanel: Thank you!

0:40:13.084,0:40:23.033
<i>postroll music</i>