 I'm gonna introduce Nathaniel Rubin he has been here last year with a talk that he got some bashing for This year. He's gonna ensure. It's not the programmers fault. It's the language in itself No Well, here we go. Well, here we go. Nathaniel. He's working for parameter X in Tel Aviv. Well come on stage your talk Thank you very much Thank you. Thank you Last year I stood right on this very stage and I talked about several of pearls less thought-out features now, I Got some bashing from the pearl community but Mainly what happened was that the pearl community completely rejected my talk claiming that the the language is completely fine and great and All of those stuff are just improvements It was clear I had to give another talk This is why I am very proud to present Pearl gem to the camel strikes back At the last talk I showed that lists are expressions used in Many confusing ways. I also showed how CGI parameters can create lists Directly from user input, but most importantly I showed then when these two things combine Shit happens But the real interesting part was the pearl monks response The pearl community The pearl community had a long discussion at the pearl monks forum that started with the words sad news from Germany a Bit dramatic, but who am I to judge so after a long long discussion They came to the unavoidable conclusion that my talk was in fact Apollemic shit and they should all just piss on it Wink they also realized. I'm just a script kitty preaching to other script kitties and Not just any script kitties the CCC audience is a heterogeneous group of Chaotic punks who love to see themselves in the hacker image of Hollywood media We have no hacker image Anyway It got quite surreal as in some point they even criticized the crude use of propaganda in the camel images All right, anyway They completely rejected the entire talk even though the technical points were valid They rejected it because of some jokes and camel images But still they got so offended they just threw lame excuses as to why their language So they rejected it because of some jokes and camel images Just threw lame excuses as to why their language suck a repeated the two of these lame Excuses were repeated over and over again. The first was that I should read the fucking manual Which is funny because I thought I was the only one who did and The second is that I am using the old ancient pearl and not the new modern pearl Remember these two points carefully as I later break them in the presentation, but enough with the intro Let's start with the new madness So Pearl allows declaring variables without specifying their data type of course This functionality exists in many dynamic languages and it's completely fine and very convenient But as usual Pearl took it to a whole different level Pearl went as far as removing data type declarations from function arguments You can see that in this example, I'm just receiving two different arguments without knowing what type there are Let me be clear about that. You don't get to choose whether you want to specify argument that types or not You can't specify what data types you're expecting to get So even if I build a function that only works with strings I have no way of forcing that at the function declaration. No, that's annoying but the real kicker is How this feature is used Apparently it is very common to write two completely different blocks of code One that handles scalar types like strings or ints and one that handle non scalar types like arrays or hashes Let me repeat that Write in multiple code for multiple data data types in one function is a pearl standard and that's sad You shouldn't write Redundant code because the language lacks the capability of letting you decide which cases you don't want to handle By the way, Python doesn't let you declare your function argument data types to but unlike Pearl Writing redundant code to cover that up is definitely not the standard Anyway said as this may be this pearl convention is not dangerous The dangerous part begins when hashes and arrays are considered as secure data types Mainly because they can't be created by user input These results in this kind of code where if the function argument is a hash For example, it is used unescaped in dangerous functions hashes Specifically are considered so secure that even if you use taint mode, which is some kind of safe mode for pearl Hash keys are not tainted meaning that even if you use that safe mode They can be still used in dangerous functions without any validation as opposed to other data types Now this kind of code appears a lot in pearl applications and apart from the many bugs This method can cause it also makes your coid exploitable So we know function arguments are of unknown data type and we know developers treat hashes and arrays as secure data types inserting their values into dangerous functions But these practices isn't something that was created a long time ago and found only on redundant code Because of how the language is built. It's supposedly Restrictionless type of developing even now it is the natural way to code when you're using pearl and That's the real problem pearl is like a shotgun with one trigger, you know about and a dozen that you don't So for now we know that if we'll somehow manage to create these secure data types with our user input We could exploit the code So the only question remaining really is What are we gonna exploit and the answer again? Is bugzilla? Like every other pearl project bugzilla is heavily using Functions that treat scalar and non-scalar argument types very differently This is one of them the load from DB function is responsible for extracting object specific data Out of the database like I just said it treat scolars and in this case hashes very differently If the function argument is a hash It takes one of its values and insert it as is Unescaped into an SQL statement Again because hashes are considered secure. So there's no point of escaping them on the other hand if the argument is a scalar it converts it into an integer and Only then use it in an SQL statement because scalar values are not secured Hashes secure scalar not secure This means that if we could control the function argument Entirely including its data type. We could control the SQL query Effectively exploiting an SQL injection attack by inserting a hash containing that specific value but CGI input doesn't allow hashes, right? The whole pearl security module is built on that assumption The problem is that like us Developers are assuming CGI input is the only input method available CGI But CGI isn't the only way to go Baxilla developers miss the fact that their own System is also featuring an XML RPC and a JSON RPC both Supporting input of non-scalar data types like arrays and hashes But I'm not blaming them. Yes, they forgot that there are more ways for a user to input than CGI But still they're just the product of how parallel programming is taught Filled with false assumptions and inconsistencies Expecting anything, but this kind of security problems is just naive But back to the vulnerability if we'll use one of these RPCs Sending our input parameter with a malicious hash instead of just a regular numeric parameter We will be able to exploit the SQL injection So if we'll send this regular request using the JSON RPC interface The number one will be used as the idea of a bug to extract But if we'll send this request where instead of an integer will supply a hash Then suddenly we will be able to inject any SQL we'd like into that statement effectively compromising the entire database Now when you look at this request You realize that this is not a sophisticated vulnerability All I did was just change the input data type from Scalar in this case to a hash and that's it The system is compromised It was so heavily built on the assumption that hashes are secure that it offered me almost Unlimited access Security-wise The funny thing about that is that although it's so simple The attack has existed for over five years that that's there. I was born in So we now proved this unknown argument type feature is a huge source for problems We also know writing different code to handle different data types just causes a lot of false assumptions but most importantly Treating non-scalar data types such as hashes as secure just because they suppose they can be created by the user is Very very bad. Just x-esque bugzilla But the shocking part really is that again? This is the pearl Standard you're not Expected to use it you have to as you don't have any other choice This security mess is a fundamental part of the language The problem is that creating non-scalar data types is impossible in some cases We can't rely that some kind of RPC will exist in the code and support different data types And we can't create data types using regular user inputs, right? Let's have a look at how different CGI modules and a different kind of input First we'll take the most trivial scenario a single values parameter Something that looks like this request where the few pro full parameter is assigned a string bar in this case a Scalar is created on all three CGI modules Which doesn't really help us, but it's pretty much what we've expected it is secure but what happens if Instead of sending a single valued parameter will send a multi-valued parameter like in this request Now things are starting to get complicated on CGI PM as we already know at least is created Which is very useful for us? But not what we're after Let's have a look at what the new Perl modules are creating. We'll see that both of them are returning arrays containing our values Arrays What I thought you can't create this kind of data types with regular input after all they're considered safe But let's continue What happens if instead of sending a regular value will try and upload the file in that parameter? Now things are really getting out of hand because CGI PM now returns a file descriptor and catalysis and modularity modules returns a hash What? We just Exploited the most popular Perl project in the world because they assumed hashes can't be created by the user and Now we're finding out that not only we can create hashes. It is a goddamn feature That's insane. The whole Perl security standard is built on that assumption That user can't create non-scaler data types and now suddenly these are features But let's send a Multifile upload request as in several files in the same parameter Watch closely Because this is where it gets ridiculous now CGI PM returns a list of file descriptors Catalyst returns a list of hashes and modularity returns an array of objects What? Almost any Perl project in the world Uses one of these modules for parsing CGI input Just think how many developers assumed the exact same thing Baxilla assumed and treated hashes and arrays as secure data types So if you're using CGI PM Instead of the expected scalar value you could be getting a list a file descriptor or a list of file descriptors And if you're using catalyst you could receive a scalar an array a hash or a list which is basically any data type So expecting your function Yeah, so expecting your function argument to be of a specific data type is false Expecting hashes and arrays to be secure is also false Expecting a scalar only user input Is a major false and to be honest it seems that in Perl Expecting is false You just can't expect anything Even the most basic of things such as what data type your variable is made of you just Don't know But I felt all of these points Will go unnoticed Without an extreme example of Perl's absurdity So I found an extreme example One that will clearly show the ridiculous nature of the language and this is it All this code does is sprint and uploaded files Content and to show you how basic and simple that code is I'll explain each line The first line just creates a new CGI instance so we could get the file from the user The second line checks if a if a file has been uploaded in the file parameter The third line gets the file descriptor from the CGI module While the fourth line loops through the file and the fifth prints it That's it again. All this code does is get a file and print it That's it a user has uploaded a file to the server and the server is just returning its content It's not saving it anywhere. It's not moving it anywhere. It just prints its content There should be absolutely nothing dangerous in this code It contains literally five lines yet It's demo time So trust me, you don't need to see the text. All you need to see is that when I'm sending a regular request Nothing happens. We're gonna send it now. Nothing happens. I'm just getting the file content. We're having fun You don't see the burp. Okay. No nice, okay, so Me just I Have no idea where my mouse is. Okay, so I'm sending a regular request. Nothing happens. Just getting the content. I know you can see the text and When I'm sending my malicious request Something interesting will pop up watch closely. It's gonna be quick Ready. Oh, you haven't seen it. Oh, it's in the different skin. Just a second Duplicate I'll magnify you So Watch closely Well, whoo, what was that? Let's see it again Well, just a second So you're probably asking yourself right now. What the fuck did I just see? Was that a terminal screen? And the answer is yes. Yes, it was Specifically the IP config command outputs or in other words what you just saw Was me exploiting that five lines With an remote code execution attack So now that you saw the magic happens. I think it's time for some explanations The first line responsible for checking if a file has been uploaded in the file parameter Doesn't exactly do as it says Instead of checking if the file parameter is an uploaded file It checks if one of its of its values is a file descriptor Let me clarify that Instead of checking if the parameter is only a file. It checks if the parameter is also a file I Mean that uploading a file and assigning another scalar value to the same parameter will still work and bypass that check What? creative fellows those guys are So now we can assign the file parameter both a regular file and a scalar value But what happens when we try to get the file parameter value in a regular request? It should return the uploaded file descriptor But now that we're adding another value to that parameter param returns a list Containing all the values we sent the file we've uploaded and our scalar value But the file variable can't contain two values, right? So instead of converting the returned list into an array Pearl only uses the first element of that list So if we'll send our scalar value Before we send our file The file variable will be assigned our scalar value Instead of the uploaded file descriptor Which means that file is now a regular string What? But what happens to this operator when we use a string instead of a file descriptor? Well, the break it operator doesn't work with strings, right? It works with file descriptors. Why should it work with strings? Well, that appears true Unless that string is argv That's not a crazy part in that case the break its operator closely Loops through the script arguments Which in CGI comes directly from the query string instead a command line and it treats them as file paths inserting each one into an open call What that made sense in some point, I guess So all of this basically means that now instead of displaying our own uploaded file content We can display the content of any file on the server But that's not the end as we haven't executed code yet To execute code We have to look at the open function again This is the function being called with the argv values as file paths Open is responsible for opening a file descriptor to a given file Unless a pipe character is added to the end of the string And in that case Instead of opening the file it executes it Acting as an exec all Full sender exploit containing our uploaded file The argv malicious scalar value and the ipconfig command followed by a pipe This is what we get What? What? I'm I'm shocked too, but I'm not done yet Truth be told, I didn't try that code Remember that Poel Monks told me that I should read the fucking manual guess where that code came from The official CGI documentation But I'm not blaming CGI PM developers Nor am I blaming developers who copied from CGI PM examples After all who could have known that this is what this code will do? This is how it could be exploited. There's no exec alls The file is not saved anywhere and we're only using a print The soul responsible for this mess Is the pearl language? Pearl is the one silently expanding glyph Pearl is the one mixing up your data types pearl is the one executing user input with no exec for calls Pearl is the problem Not its developers And until this god damn bizarre dangerous language is fixed You could only stop Using pearl so I guess we have some time for questions now Maybe and I have the funny feeling we will have some questions now Okay, so we have some microphones here. Please queue up. We are not please do not shout in Because we need to record it on the stream Well, here we go. And we also have some questions from the internet. Don't we? Oh, oh, yes, we do But before you we come to the technical questions the IRC wants you to know what you did to it It felt like there were explosions and camels everywhere and incidentally They want to know if you have a list of those camel pigs somewhere. I think Google has it Just your search camels So for the first for the first question or Pella wants to know if the takeaway is that pearl project authors So shouldn't trust input and instead verify types with ref and always use prepared as well statements That's a good question the takeaway should be the takeaway should be that Well, how will I phrase it? I don't know. I think I have a slide Somewhere. Oh wait Where's my slide? Don't worry. I have it right here but really Trusting user input is always a bad idea and most developers know it the problem is that Well, at least from the code I saw written in pearl and that's a lot of code trust me is That hashes and arrays are almost always considered secured as they supposedly can't be created by user input as I said but When you're expecting your user your user input to be a scalar a string Or even a list. I don't know and instead you get a hash from I don't know unexpected directions You get confused and You can't always live in the fear of not knowing what Data type you're trying to handle. Well, not trusting scalar data types is a wise decision because It's not it's dangerous, but not trusting your hashes as well not trusting your arrays What's next like not trusting your own code? You just can't expect Anything to really work as it should when you're writing pale. You're all since you're constantly constantly Attacked by by all of these different directions and even the data type direction is a problem now. I Hope that answered the question Beside the slide. Well, then we're gonna go over and start with number one So, thank you for opening our eyes. So even I use pearl I would say for cooking and I remember you sorry, I remember from the last talk. No, no. Oh, you're new So I can say I'm not guilty of that, but I still would say yes pearl is like cooking a bit like cooking with my mom so sometimes I put something into the The with the boiling thing and sometimes she sometimes I go away sometimes she go away and the only thing you can do is always taste and Yes, you are maybe right pearl is a language where you never know what comes out But it's real cool. So if you get the right response, you can use it if you use it to write web applications I would agree web applications a professional one at least are not for cooking But for doing funny things and have some fun. I think it's perfect language. I think pearl is a lot of fun. I Completely agree on that Then we're gonna go over to two Was your life ever threatened while interacting with the poll community? Could you please repeat that? I was your life ever threatened while interacting with the poll community. Definitely Definitely, I'm getting hate mail every day living in a fear and Over to the three, please. I think I speak for all of us and thank you for this wonderful talk Thank you Thank you, really Brilliantly executed, but you spoke about Five I think yes, and as some of you might know this Christmas So tomorrow Ingo Blechschmidt is going to give a talk about how Post six will make everything better and how everyone should start using post six and it also grabs rainbows. Yeah, of course My personal comment is wouldn't have happened with a statically type language, so I think some Nice folks at Haskell on IRC are waiting for you poll developers to please come join us Thank you We're gonna take the next one. Oh, sorry answer first one. I'm sorry. I'm not answering. I'm just a quick note about pearl six This talk is all about pearl five. All right. I pearl six came out like a couple of days ago and From at this point what I saw pearl six is to pearl as C++ is to see It's the same name, but it's a whole different language. So yes, this is pearl five Maybe I'll come back next year about pearl six. Who knows I'm looking forward to that already Yeah, you're the ones to know Of course you talked a lot about CGI PM Which you knew was removed from a repository from Pearl even before your talk last year So what about it's replacements from C-Pen like CGI simple? I don't know. I haven't checked it when I've Decided on which modules to check I took CGI PM because even though it is old It is the most popular in the world as of today and I took modulations and cat and Catalyst catalyst because they were a Really popular too. So I didn't take the newest modules. I take the most popular modules and I think that's the important aspect of Deciding and over to one, please Hi part of the port community and But I just start with pearl five and I Didn't you We use pearl for almost every module what we have at work and it's work really fine and Yeah, I don't know why you're picking pearl as a language to attack. It's a really old language It's also every language that you can pick that has Problems, but it doesn't mean this has to die or stop using it You're right on the why you're right. You're right. First of all, you're completely right because a language shouldn't die It should improve see got criticized and it improved PHP got criticized and it improved Why can't pearl be criticized too? Why why is it like a cult when you say something bad about pearl then I know a herd of pelomonics jumps on you Why don't improve the language? Don't use it in your work though. It's dangerous Then we're gonna jump over to five please Hi I'm not a pearl developer, but I use a lot of Ruby and Python Is this really limited to pearl or does this apply to more or less any dynamic language? As I said in the one of the first few slides Some of it also applies to Python specifically that the thing when you can't specify what data types your argument your function arguments can get but What's unique to pearl is that? Writing different code for different data types in one function is very very common You can do it in every language of course, but it is very common only in pearl and That's what unique about it. Of course besides the thing that hashes and errors are secure. That's That's of course pearl pearls only fault Good. Now we're gonna go over to six, please Hey Did you say wet more while preparing the stock or while holding it? Both Did they rent that was the right Did you say it more while preparing it or while holding it? I'm missing your word man. Can you ah? What what? Oh Yeah, both Yeah, okay, do we have another from the internet? Does your exploit also work in tainted mode? I know I believe not no it doesn't and another one Is there any pearl of you? Op you skated code exploits like this for a catalyst or a motorless yours? I have no idea man. Maybe I didn't check it. Of course. I didn't check every module for every exploit I ever want to create but On on cgi pm, which is again the most popular cgi library So Maybe the internet can find more exploits. I Know it. I know it can Bring it on. That's it That's it Thank you Thank you very much. Thank you