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.166,0:00:18.640
He has been here last year with a talk [br]that he got some bashing for.

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

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

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

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

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

0:00:35.521,0:00:37.634
Netanel: Thank you very much, <i>applause</i>

0:00:37.674,0:00:41.134
thank you, thank you!

0:00:44.747,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:56.411
less thought out "features".

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

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

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

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

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

0:01:29.049,0:01:33.618
<i>applause</i>

0:01:33.618,0:01:36.188
Thank you

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

0:01:45.873,0:01:52.921
I also showed how 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.696,0:02:04.066
Great

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

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

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

0:02:24.451,0:02:29.475
that 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:49.717,0:02:55.756
They also realized 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.218
We have no hacker image.

0:03:26.310,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.461,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 functionality 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.394
But, the real kicker [br]is how this feature is used.

0:05:57.444,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:25.661
Hashes, specifically, are considered so secure, [br]that even if you use "taint mode",

0:07:25.661,0:07:28.293
which is some kind of safe mode for Perl,

0:07:28.293,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 types.

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.395
it also makes your code exploitable.

0:07:54.395,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]its supposedly restriction-less type of developing,

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

0:08:26.688,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
So 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: 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
effectively 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:45.581
CGI.

0:10:45.581,0:10:48.545
But CGI isn't the only way to go.

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

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

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

0:11:05.048,0:11:06.498
But I'm not blaming them.

0:11:06.498,0:11:12.492
Yes, they forgot that there are more ways [br]for a 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
then suddenly we will be able [br]to inject any SQL we'd like

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

0:12:03.121,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.031
and we can't create data types [br]using regular user input… Right?

0:14:05.031,0:14:06.937
Well, let's have a look at

0:14:06.937,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
But 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
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 that 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
But 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:53.444,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.522
Just think how many developers assumed [br]the exact same thing Bugzilla assumed

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

0:17:15.854,0:17:17.752
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.724
a list, a file descriptor or a list of file descriptors

0:17:25.724,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:14.517
And to show you how basic and simple that code is, [br]I'll explain each line.

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

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

0:19:26.785,0:19:31.549
The third line gets the file descriptor from the CGI module,

0:19:31.549,0:19:37.438
while the fourth line loops through the file [br]and the fifth 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.521
<i>clapping</i>[br]That's it.

0:19:45.521,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.412,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:34.685,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.230
I'm sending a regular request, [br]nothing happens, just getting the content.

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

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

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

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

0:20:55.092,0:20:56.684
Ready?

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

0:21:00.520,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 you!

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

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

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

0:21:24.467,0:21:26.559
Let's see it again.

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

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

0:21:36.893,0:21:40.442
Yupp, <i>clearing throat</i>

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

0:21:44.800,0:21:46.084
Nice.

0:21:46.084,0:21:49.277
So you're probably asking yourself right now

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

0:21:52.411,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.370
was me exploiting that five lines [br]with a remote code execution attack.

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

0:22:20.513,0:22:22.487
The first line, responsible for checking

0:22:22.487,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:33.803
Instead of checking if the "file" [br]parameter is an uploaded file,

0:22:33.803,0:22:39.230
it checks if one of its values is a file descriptor.

0:22:39.230,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:50.476
<i>laughter</i>

0:22:50.476,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.066,0:23:15.715
Creative fellows those guys are.

0:23:15.715,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.224
But what happens when we try to get [br]the "file" parameter value?

0:23:26.224,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:40.596
param() returns a list containing all the values we sent:

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

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

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

0:23:55.221,0:23:59.331
Perl only uses the first element of that list.

0:23:59.331,0:24:05.564
So if we'll send our scalar value [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:19.623
Which means, that $file [br]is now a regular string!

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

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

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

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

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

0:24:36.548,0:24:39.200
Well, that appears true

0:24:39.200,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.470,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.693
In that case the brackets operator, listen closely,

0:25:04.693,0:25:07.668
loops through the script arguments,

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

0:25:12.487,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:19.977
<i>again laughter</i>

0:25:19.977,0:25:22.655
WAT?

0:25:25.632,0:25:29.485
Yeah, that made sense in 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:39.749
we can display the content [br]of any file on the server.

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

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

0:25:48.808,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.054
open() is responsible for opening [br]a file descriptor to a given file.

0:26:03.054,0:26:05.874
Unless a "pipe" character is added

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

0:26:09.036,0:26:13.259
and in that case instead of opening the file,

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

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

0:26:22.576,0:26:28.512
So … when we send our exploit,

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

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

0:26:37.635,0:26:42.487
this is what we get.[br]WAT?

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

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

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

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

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

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

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

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

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

0:27:46.913,0:27:49.237
This is how it could be exploited?

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

0:27:54.311,0:27:58.163
and we're only using a "print".

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

0:28:07.333,0:28:11.412
Perl is the one silently expanding lists,

0:28:11.412,0:28:14.552
Perl is the one mixing up your data types,

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

0:28:19.884,0:28:22.800
Perl is the problem,

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

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

0:28:31.879,0:28:34.216
you could only [br]stop

0:28:34.216,0:28:35.319
using

0:28:35.319,0:28:40.207
Perl!

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

0:28:59.025,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.174
Herald: And I have the funny feeling, [br]we will have some questions now.

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

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

0:29:17.959,0:29:19.156
Well, here we go.

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

0:29:22.776,0:29:27.274
Signal Angel: Oh yes, we do![br]<i>laughter</i>

0:29:27.274,0:29:30.143
Signal: But before we come [br]to the technical questions,

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

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

0:29:37.425,0:29:39.575
Netanel <i>laughing</i>: That's the point

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

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

0:29:49.663,0:29:53.796
Just there search camels.

0:29:53.796,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:10.437
and instead verify types with REF [br]and always use prepared SQL statements?

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

0:30:24.039,0:30:28.428
well, how will I phrase it …

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

0:30:32.734,0:30:36.303
Oh wait, where's my slide?

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

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

0:30:49.080,0:30:51.831
and most developers know it.

0:30:51.831,0:30:54.211
The problem is, that…

0:30:54.211,0:30:57.178
well, at least from the code [br]I saw written in Perl,

0:30:57.178,0:31:00.091
and that's a lot of code, trust me

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

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

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

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

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

0:31:30.779,0:31:33.613
what data type you're trying to handle.

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

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

0:31:46.119,0:31:49.581
What's next? Not trusting your own code?

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

0:31:54.274,0:31:56.444
When you're writing Perl,

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

0:32:03.899,0:32:08.579
And even the data type direction is a problem now.

0:32:08.579,0:32:12.652
I hope that answered the question [br]beside the slide.

0:32:12.652,0:32:16.335
Herald: Well, then we're gonna go over [br]and start with number one.

0:32:16.335,0:32:19.494
Questioner: So thank you for opening our eyes.

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

0:32:24.254,0:32:25.718
Netanel: I remember you[br]Q: Sorry?

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

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

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

0:32:36.068,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:50.864
and sometimes she, sometimes I go away, [br]sometimes she go away

0:32:50.864,0:32:53.894
and the only thing you can do is always taste.

0:32:53.894,0:32:57.814
And yes, you're maybe right, Perl is a language

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

0:33:01.822,0:33:04.583
If you get the right response you can use it,

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

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

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

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

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

0:33:26.633,0:33:29.144
Herald: Then we're gonna 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:35.794
<i>laughter</i>[br]N: Could you please repeat that? I …

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

0:33:39.545,0:33:42.515
N: Definitely. Definitely,

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

0:33:46.729,0:33:48.648
H: And over to the three, please.

0:33:48.648,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:00.086
N: Uh, thank you. Thank you really! Thank you.[br]<i>applause</i>

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

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

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

0:34:15.032,0:34:20.047
is going to give a talk about how Perl 6 [br]will make everything better

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

0:34:24.161,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.450
So I think some nice folks at Haskell [br]in IRC are waiting for you Perl developers

0:34:39.450,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.446
H: …sorry, to answer first, where am I… sorry[br]N: Ah, no..., I am not answering, just...

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

0:34:55.526,0:35:01.108
I … Perl 6 came out a couple of days ago and …

0:35:01.108,0:35:06.848
...from …at least from 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:22.175
Herald: I'm looking forward to that already.[br]<i>applause</i>

0:35:22.175,0:35:25.128
<i>Herald pointing to Signal Angel</i>

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

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

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

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

0:35:48.265,0:35:55.610
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.610,0:36:03.161
and I took Mojolicious and Catalyst because [br]they were really popular, too.

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

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

0:36:17.693,0:36:20.869
Herald: And over to one, please.

0:36:20.869,0:36:29.013
Questioner: Hi… I'm… part of the Perl community, and…[br]<i>laughter</i>

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

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

0:36:40.315,0:36:44.329
Q: We use Perl for almost every module [br]that we have at work

0:36:44.329,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.099
It's a really old language, it's also every language [br]that we can pick, that has problems.

0:36:59.099,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.561
N: …you're right, you're right. [br]First of all, you're completely right,

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

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

0:37:16.880,0:37:20.163
Why can't Perl be critized, too?

0:37:20.163,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.254
I don't know, a horde of PerlMonks jumps on you?

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

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

0:37:39.506,0:37:42.109
H: Then we're gonna jump over to five, please.

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

0:37:48.513,0:37:51.061
Is this really limited to Perl or

0:37:51.061,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:03.613
some of it also applies to Python. [br]Specifically the thing

0:38:03.613,0:38:09.867
when you can't specify what data types [br]your function arguments can get.

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

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

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

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

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

0:38:32.501,0:38:37.116
That's of course Perls only fault.

0:38:37.116,0:38:40.098
H: Good, then we're gonna go over to six, please.

0:38:40.098,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:56.782
N: Uhm. Both. <i>Laughing</i>. [br]Did I rant? That was the … right?

0:38:56.782,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, can you...

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

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

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

0:39:19.420,0:39:23.663
N: No, I believe not. No, it doesn't.

0:39:24.473,0:39:26.680
H: And another one...

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

0:39:36.137,0:39:39.437
<i>someone chuckling in audience</i>

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

0:39:43.409,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:55.075
on CGI.PM, which is again [br]the most popular CGI library, it did.

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

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

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

0:40:07.775,0:40:09.157
<i>applause</i>

0:40:09.157,0:40:12.404
Herald: Thank you very much![br]Netanel: Thank you!

0:40:12.404,0:40:17.683
<i>postroll music</i>

0:40:17.683,0:40:24.000
subtitles created by c3subtitles.de[br]in the year 2016. Join, and help us!