Return to Video

Netanel Rubin: The Perl Jam 2

  • Not Synced
    *preroll music*
  • Not Synced
    Herald: And I'm gonna introduce Netanel Rubin.
  • Not Synced
    He has been here last year with a talk
    that he got some bashing for.
  • Not Synced
    This year he's gonna ensure,
    it's not the programmer's fault,
  • Not Synced
    it's the language itself.
  • Not Synced
    No? Well, here we go, well here we go.
  • Not Synced
    Netanel, he is working for
    PerimeterX in Tel Aviv,
  • Not Synced
    welcome on stage, your talk!
  • Not Synced
    Netanel: Thank you, thank you!
  • Not Synced
    Last year I stood right on this very stage
    and I talked about several of Perl's
  • Not Synced
    less thought out "features".
  • Not Synced
    Now, I got some bashing from the Perl community,
    but mainly what happened was,
  • Not Synced
    that the Perl community completely rejected my talk
    claiming that the language
  • Not Synced
    is completely fine and great
    and all of this stuff are just improvements.
  • Not Synced
    It was clear I had to give another talk.
  • Not Synced
    This is why I'm very proud to present
    "Perl Jam 2 – The Camel strikes back"!
  • Not Synced
    *applause*
  • Not Synced
    Thank you
  • Not Synced
    At the last talk, I showed that "lists" are expressions,
    used in… many confusing ways.
  • Not Synced
    I also showed CGI parameters can create lists,
    directly from user input.
  • Not Synced
    But most importantly, I showed
    that when these two things combine, shit happens.
  • Not Synced
    Great
  • Not Synced
    But the really interesting part
    was the PerlMonks response.
  • Not Synced
    The Perl community
    *laughter*
  • Not Synced
    The Perl community had a long discussion
    at the PerlMonks forum.
  • Not Synced
    It started with the words
    "Sad news from Germany".
  • Not Synced
    A bit dramatic, but who am I to judge?
  • Not Synced
    So, after a long, long discussion,
    they came to the unavoidable conclusion
  • Not Synced
    that my talk was, in fact, a "polemic shit",
    and they should all just "piss on it". Wink.
  • Not Synced
    They also realized that I'm just a
    "script kiddie preaching to other script kiddies",
  • Not Synced
    and not just any script kiddies, the CCC audience is a
  • Not Synced
    "heterogeneous group of chaotic punks
    who love to see themselves in the hacker
  • Not Synced
    image of Hollywood media".
    *applause and whistling from audience*
  • Not Synced
    What hacker image?
    What are they talking about?
  • Not Synced
    We have no hacker image.
  • Not Synced
    Anyway, it got quite surreal, as in some point
    they even critized
  • Not Synced
    the "crude use of propaganda
    in the camel images". WAT.
  • Not Synced
    *laughing*
    *applause*
  • Not Synced
    Propaganda in the camel images. Alright.
  • Not Synced
    Anyway, they completely rejected the entire talk,
    even though the technical points were valid.
  • Not Synced
    They rejected it because of
    some jokes and camel images.
  • Not Synced
    But still, they got so offended they just threw
    lame excuses as to why their language sucks.
  • Not Synced
    Two of these lame excuses were
    repeated over and over again.
  • Not Synced
    The first was that I should
    read the fucking manual, which is funny
  • Not Synced
    because I thought I was the only one who did…
  • Not Synced
    *laughter*
  • Not Synced
    …and the second is that
  • Not Synced
    I'm using the old, ancient Perl,
    and not the new, modern Perl.
  • Not Synced
    *more laughter*
  • Not Synced
    Remember these two points carefully
    as I'll later break them in the presentation.
  • Not Synced
    But, enough with the intro,
    let's start with the new madness.
  • Not Synced
    So, Perl allows declaring variables
    without specifying their data type.
  • Not Synced
    Of course, this functionally exists
    in many dynamic languages,
  • Not Synced
    and is completely fine and very convenient.
  • Not Synced
    But, as usual, Perl took it
    to a whole different level.
  • Not Synced
    Perl went as far as removing
    data type declarations from function arguments.
  • Not Synced
    You can see that in this example
  • Not Synced
    I'm just receiving two different arguments
    without knowing what type they are.
  • Not Synced
    Let me be clear about that,
  • Not Synced
    you don't get to choose whether you want
    to specify argument data types or not,
  • Not Synced
    you can't specify
    what data types you're expecting to get.
  • Not Synced
    So even if I built a function
    that only works with strings,
  • Not Synced
    I have no way of forcing that
    at the function declaration.
  • Not Synced
    Now that's annoying.
  • Not Synced
    But, the real kicker
    is how this feature is used.
  • Not Synced
    Apparently, it is very common to write
    two completely different blocks of code,
  • Not Synced
    one that handles scalar types,
    like strings or ints,
  • Not Synced
    and one that handles non-scalar types,
    like arrays or hashes.
  • Not Synced
    Let me repeat that:
  • Not Synced
    Writing multiple code, for multiple data-types,
    in one function, is a Perl standard.
  • Not Synced
    And that's sad. You shouldn't write redundant code
    because the language lacks the capability
  • Not Synced
    of letting you decide
    which cases you don't want to handle.
  • Not Synced
    By the way, Python doesn't let you
    declare your function argument data types too,
  • Not Synced
    but unlike Perl, writing redundant code
    to cover that up
  • Not Synced
    is definitely not the standard.
  • Not Synced
    Anyway, sad as this may be,
    this Perl convention is not dangerous.
  • Not Synced
    The dangerous part begins
  • Not Synced
    when hashes and arrays
    are considered as "secure" data types,
  • Not Synced
    mainly because they can't be created
    by user input.
  • Not Synced
    This results in this kind of code,
  • Not Synced
    where if the function argument
    is a hash, for example,
  • Not Synced
    it is used un-escaped in dangerous functions.
  • Not Synced
    Hashes, specifically, are considered so secure,
    that even if you use "taint mode",
  • Not Synced
    which is some kind of safe mode for Perl,
  • Not Synced
    hash keys are not tainted, meaning
    that, even if you use safe mode,
  • Not Synced
    they can be still used in dangerous functions
  • Not Synced
    without any validation,
    as opposed to other data type.
  • Not Synced
    Now this kind of code appears a lot
    in Perl applications,
  • Not Synced
    and apart from the many bugs
    this method can cause,
  • Not Synced
    it also makes your code exploitable.
  • Not Synced
    So we know function arguments are of unknown data type.
  • Not Synced
    And we know developers treat hashes and arrays
    as "secure" data types,
  • Not Synced
    inserting their values into dangerous functions.
  • Not Synced
    But this practices isn't something
  • Not Synced
    that was created a long time ago,
    and found only on redundant code.
  • Not Synced
    Because of how the language is built,
    it's supposedly restriction-less type of developing,
  • Not Synced
    even now it is the natural way to code
    when you're using Perl.
  • Not Synced
    And that's the real problem:
    Perl is like a shotgun,
  • Not Synced
    with one trigger you know about
    and a dozen that you don't.
  • Not Synced
    For now, we know
    that if we'll somehow manage
  • Not Synced
    to create these "secure" data types,
    with our user input,
  • Not Synced
    we could exploit the code.
  • Not Synced
    So the only question remaining really
    is what are we gonna exploit?
  • Not Synced
    And the answer, again,
    is Bugzilla.
  • Not Synced
    *laughter*
  • Not Synced
    Like every other Perl project,
    Bugzilla is heavily using functions
  • Not Synced
    that treat scalar and non-scalar
    argument types very differently.
  • Not Synced
    This is one of them:

    The load from DB function is responsible
  • Not Synced
    for extracting object specific data
    out of the database.
  • Not Synced
    Like I just said, it treats scalars,
    and in this case hashes, very differently.
  • Not Synced
    If the function argument is a hash,
    it takes one of its values
  • Not Synced
    and inserts it as is, un-escaped,
    into an SQL statement.
  • Not Synced
    Again, because hashes
    are considered secure,
  • Not Synced
    so there's no point of escaping them.
  • Not Synced
    On the other hand,
    if the argument is a scalar,
  • Not Synced
    it converts it into an integer
    and only then use it in an SQL statement.
  • Not Synced
    Because scalar values, are not secure.
  • Not Synced
    hashes: secure
  • Not Synced
    scalar: not secure
  • Not Synced
    This means that if we could control
    the function argument entirely,
  • Not Synced
    including its data type,
    we could control the SQL query,
  • Not Synced
    affectively exploiting an SQL injection attack,
  • Not Synced
    by inserting a hash
    containing that specific value.
  • Not Synced
    But…
  • Not Synced
    CGI input doesn't allow hashes, right?
  • Not Synced
    The whole Perl security module
    is built on that assumption.
  • Not Synced
    The problem is that, like us,
    developers are assuming
  • Not Synced
    CGI input is the only input method available.
  • Not Synced
    CGI.
  • Not Synced
    But CGI isn't the only way to go.
  • Not Synced
    Bugzilla developers missed the fact
    that their own system
  • Not Synced
    is also featuring an XMLRPC and a JSONRPC,
  • Not Synced
    both supporting input of non-scalar data types
    like arrays and hashes!
  • Not Synced
    But I'm not blaming them.
  • Not Synced
    Yes, they forgot that there are more ways
    for user to input than CGI,
  • Not Synced
    but still, they're just the product
    of how Perl programming is taught,
  • Not Synced
    filled with false assumptions and inconsistencies.
  • Not Synced
    Expecting anything but this kind
    of security problems is just naive.
  • Not Synced
    But back to the vulnerability.
  • Not Synced
    If we'll use one of these RPCs,
  • Not Synced
    sending our input parameter with a malicious hash,
  • Not Synced
    instead of just a regular numeric parameter,
  • Not Synced
    we will be able to exploit the SQL Injection!
  • Not Synced
    So, if we'll send this regular request,
    using the JSONRPC interface,
  • Not Synced
    the number 1 will be used
    as the ID of a bug to extract,
  • Not Synced
    but if we'll send this request,
  • Not Synced
    where instead of an integer we'll supply a hash,
  • Not Synced
    than suddenly we will be able
    to inject any SQL we'd like
  • Not Synced
    into that statement, affectively
    compromising the entire database.
  • Not Synced
    Now when you look at this request, you realize
  • Not Synced
    that this is not a sophisticated vulnerability.
  • Not Synced
    All I did was just change the input data type
    from scalar in this case to a hash,
  • Not Synced
    and that's it, the system is compromised.
  • Not Synced
    It was so heavily built on the assumption
  • Not Synced
    that hashes are secure, that it offered me
  • Not Synced
    almost unlimited access security wise.
  • Not Synced
    The funny thing about that is, that
    although it's so simple,
  • Not Synced
    the attack has existed for over 5 years.
  • Not Synced
    That's the year I was born in.
  • Not Synced
    So, we now proved this "unknown-argument-type" feature
  • Not Synced
    is a huge source for problems.
  • Not Synced
    We also know writing different code
    to handle different data types
  • Not Synced
    just causes a lot of false assumptions.
  • Not Synced
    But most importantly, treating non-scalar
    data types such as hashes as "secure",
  • Not Synced
    just because they supposedly can't be created by the user,
  • Not Synced
    is very, Very, BAD. Just ask Bugzilla.
  • Not Synced
    But the shocking part really, is that, again,
    this is the Perl Standard!
  • Not Synced
    You're not expected to use it, you have to
  • Not Synced
    as you don't have any other choice.
  • Not Synced
    This security-mess
    is a fundamental part of the language.
  • Not Synced
    The problem is that creating non-scalar data types
    is impossible in some cases.
  • Not Synced
    We can't rely that some kind of RPC
  • Not Synced
    will exist in the code
    and support different data types,
  • Not Synced
    and we can't create data types
    using regular user input… Right?
  • Not Synced
    Well, let's have a look at
  • Not Synced
    how different CGI modules
    handle different kind of input.
  • Not Synced
    First, we'll take the most trivial scenario.
  • Not Synced
    A single valued parameter,
    something that looks like this request,
  • Not Synced
    where the "foo" parameter
    is assigned the string "bar".
  • Not Synced
    In this case, a scalar is created on all three CGI modules,
  • Not Synced
    which doesn't really help us,
    but is pretty much what we've expected.
  • Not Synced
    It is secure.
  • Not Synced
    What happens if instead of
    sending a single-valued parameter,
  • Not Synced
    we'll send a multi-valued parameter,
    like in this request?
  • Not Synced
    Now things are starting to get complicated.
  • Not Synced
    On CGI.PM, as we already know,
    a list is created,
  • Not Synced
    which is very useful for us,
    but not what we're after.
  • Not Synced
    But let's have a look at
    what the "new" Perl modules are creating.
  • Not Synced
    We'll see that both of them are returning
    arrays containing our values.
  • Not Synced
    Arrays! WAT?
  • Not Synced
    I thought you can't create
    these kind of data types with regular input,
  • Not Synced
    after all, they're considered safe.
  • Not Synced
    But let's continue.
  • Not Synced
    What happens if instead of sending a regular value,
  • Not Synced
    we'll try and upload a file in that parameter?
  • Not Synced
    Now things are really getting out of hand,
  • Not Synced
    because CGI.PM now returns a file descriptor,
    and Catalyst and Mojolicious returns a hash.
  • Not Synced
    WAT?
  • Not Synced
    We just exploited
    the most popular Perl project in the world
  • Not Synced
    because they assumed hashes can't be created by the user,
  • Not Synced
    and now we're finding out
    that not only we can create hashes,
  • Not Synced
    it is a god-damned feature?!
  • Not Synced
    That's insane!
  • Not Synced
    The whole Perl security standard is built on the assumption
  • Not Synced
    that users can't create non-scalar data-types
  • Not Synced
    and now suddenly these are features?
  • Not Synced
    Let's send a multi-file upload request
    as in several files in the same parameter.
  • Not Synced
    Watch closely, because this is where it gets ridiculous.
  • Not Synced
    Now, CGI.PM returns a list of File Descriptors,
  • Not Synced
    Catalyst returns a list of Hashes
  • Not Synced
    and Mojolicious returns an array of objects! WAT?!
  • Not Synced
    *laughter and applause*
  • Not Synced
    Almost any Perl project in the world
  • Not Synced
    uses one of these modules
    for parsing CGI input.
  • Not Synced
    Just think how many developers assumed
    the exact same thing Bugzilla assumed
  • Not Synced
    and treated hashes and arrays as secure data types.
  • Not Synced
    So if you're using CGI.PM,
  • Not Synced
    instead of the expected scalar value you could be getting
  • Not Synced
    a list, a file descriptor or a list of file descriptors
  • Not Synced
    and if you're using Catalyst
  • Not Synced
    you could receive a scalar, an array, a hash or a list,
  • Not Synced
    which is basically any data type.
  • Not Synced
    So expecting your function… yeah
  • Not Synced
    *audience chuckling*
  • Not Synced
    So expecting your function arguments
    to be of a specific data type is false.
  • Not Synced
    Expecting hashes and arrays to be secure is also false.
  • Not Synced
    Expecting scalar only user input
  • Not Synced
    is a major false.
  • Not Synced
    And to be honest, it seems that in Perl expecting is false!
  • Not Synced
    *laughter and applause*
  • Not Synced
    You just can't expect anything
  • Not Synced
    even the most basic of things
    such as what data type your variable is made of.
  • Not Synced
    You just don't know.
  • Not Synced
    But I felt all of these points will
    go un-noticed
  • Not Synced
    without an extreme example of Perl's absurdity.
  • Not Synced
    So I found an extreme example.
  • Not Synced
    One that will clearly show
  • Not Synced
    the ridiculous nature of the language.
  • Not Synced
    And this is it:
  • Not Synced
    All this code does is print an uploaded file's content.
  • Not Synced
    And to show you how basic and simple that code is,
    I'll explain each line.
  • Not Synced
    The first line just creates a new CGI instance,
    so we could get the file from the user.
  • Not Synced
    The second line checks if a file
    has been uploaded in the "file" parameter.
  • Not Synced
    The third line gets the file descriptor from the CGI module,
  • Not Synced
    while the forth line loops through the file
    and the fifths prints it.
  • Not Synced
    That's it. Again: all this code does
    is get a file and print it.
  • Not Synced
    *clapping*
    That's it.
  • Not Synced
    A user has uploaded a file to the server
    and the server is just returning its content.
  • Not Synced
    It's not saving it anywhere,
    it's not moving it anywhere,
  • Not Synced
    it just prints its content.
  • Not Synced
    There should be absolutely
    nothing dangerous in this code,
  • Not Synced
    it contains literally five lines.
  • Not Synced
    Yet, It's demo time.
  • Not Synced
    *laughter*
  • Not Synced
    So trust me, you don't need to see the text,
  • Not Synced
    all you need to see is that
    when I'm sending a regular request nothing happens.
  • Not Synced
    When I send it now, nothing happens,
    I'm just getting the file content.
  • Not Synced
    We're having fun, you don't see the burp…
  • Not Synced
    Now, nice. Okay
  • Not Synced
    So…
    …L't me just…
  • Not Synced
    …I have no idea where my mouse is, okay.
  • Not Synced
    So…
  • Not Synced
    I'm sending a regular request,
    nothing happens, just getting the content.
  • Not Synced
    I know, you can't see the text…
    …and…
  • Not Synced
    when I'm sending my malicious request,
  • Not Synced
    something interesting will pop up.
  • Not Synced
    Watch closely! It's gonna be quick.
  • Not Synced
    Ready?
  • Not Synced
    Oh, you haven't seen it, it's on the different screen.
  • Not Synced
    Just a second… oh… duplicate…
  • Not Synced
    (from audience): … magnify it!
  • Not Synced
    Netanel: I'll magnify it.
  • Not Synced
    *laughter*
  • Not Synced
    Alright, so… watch closely.
  • Not Synced
    Ohh, uuh? What was that?
  • Not Synced
    Let's see it again.
  • Not Synced
    *mocking* Uuuuuh?!
  • Not Synced
    *laughter and applause*
  • Not Synced
    Yupp, *clearing throat*
  • Not Synced
    … just a second.
  • Not Synced
    Nice.
  • Not Synced
    So you're probably asking yourself right now
  • Not Synced
    "What the fuck did I just see?"
    *laughter*
  • Not Synced
    "Was that a terminal screen?"
  • Not Synced
    And the answer is … "Yes"
    Yes, it was
  • Not Synced
    specifically the "ipconfig" command output.
  • Not Synced
    Or in other words: What you just saw
  • Not Synced
    was me exploiting that five lines
    with a remote code execution attack.
  • Not Synced
    So now that you saw the magic happens,
    I think it's time for some explanations.
  • Not Synced
    The first line, responsible for checking
  • Not Synced
    if a file has been uploaded in the "file" parameter,
  • Not Synced
    doesn't exactly do as it says.
  • Not Synced
    Instead of checking if the "file"
    parameter is an uploaded file,
  • Not Synced
    it checks if one of it values is a file descriptor.
  • Not Synced
    Let me clarify that, instead of checking
    if the parameter is only a file,
  • Not Synced
    it checks if the parameter is also a file.
  • Not Synced
    *laughter*
  • Not Synced
    Meaning that uploading a file
  • Not Synced
    and assigning another scalar value to the same parameter
  • Not Synced
    will still work and bypass the check!
  • Not Synced
    WAT?
  • Not Synced
    *more laughter and applause*
  • Not Synced
    Creative fellows those guys are.
  • Not Synced
    So now we can assign the "file" parameter
    both a regular file and a scalar value.
  • Not Synced
    But what happens when we try to get
    the "file" parameter value?
  • Not Synced
    In a regular request, it should return
    the uploaded file descriptor,
  • Not Synced
    but now that we're adding another value to that parameter,
  • Not Synced
    param() returns a list containing all the values we send:
  • Not Synced
    the file we've uploaded and our scalar value.
  • Not Synced
    But the "file" variable
    can't contain two values, right?
  • Not Synced
    So instead of converting
    the returned list into an array
  • Not Synced
    Perl only uses the first element of that list.
  • Not Synced
    So if we'll send our scalar values
    before we send our file,
  • Not Synced
    the $file variable will be assigned
    our scalar value
  • Not Synced
    instead of the uploaded file descriptor.
  • Not Synced
    Which means, that $file
    is now a regular string!
  • Not Synced
    *in high pitched voice:* WAT?
  • Not Synced
    But what happens to this operator
    when we use a string
  • Not Synced
    instead of a file descriptor?
  • Not Synced
    Well, the brackets operator
    doesn't work with strings, right?
  • Not Synced
    It works with file descriptors,
    why should it work with strings?
  • Not Synced
    Well, that appears true
  • Not Synced
    unless that string is "ARGV".
  • Not Synced
    *laughter and applause*
  • Not Synced
    That's not a crazy part.
  • Not Synced
    *more laughter*
  • Not Synced
    In that case the brackets operator, listen closely,
  • Not Synced
    loops through the script arguments,
  • Not Synced
    which in CGI comes directly from the
    query string instead the command line,
  • Not Synced
    and it treats them as file paths,
    inserting each one into an open() call!
  • Not Synced
    *again laughter*
  • Not Synced
    WAT?
  • Not Synced
    Yeah, that made sense on some point, I guess.
  • Not Synced
    All of this basically means that now,
  • Not Synced
    instead of displaying
    our own uploaded file content,
  • Not Synced
    we can display the content
    of any file on the server.
  • Not Synced
    But that's not the end,
    as we haven't executed code yet.
  • Not Synced
    To execute code, we have
    to look at the open() function.
  • Not Synced
    Again, this is the function being called
    with the ARGV values as file paths.
  • Not Synced
    open() is responsible for opening
    a file descriptor to a given file.
  • Not Synced
    Unless a "pipe" character is added
  • Not Synced
    to the end of the string,
    *laughter*
  • Not Synced
    in that case instead of opening the file,
  • Not Synced
    it executes it…
    *applause rising*
  • Not Synced
    …acting as an exec() call!
    *more applause*
  • Not Synced
    So … when we send our exploit,
  • Not Synced
    containing our uploaded file,
    the "ARGV" malicious scalar value,
  • Not Synced
    and the ipconfig command followed by a pipe
  • Not Synced
    this is what we get.
    WAT?
  • Not Synced
    WAT?
    *applause*
  • Not Synced
    I know, I'm shocked too, but I'm not done yet.
    *laughter*
  • Not Synced
    Truth be told, I didn't write that code.
  • Not Synced
    Remember that PerlMonks told me
    that I should read their fucking manual?
  • Not Synced
    *more laughter*
    Guess where that code came from:
  • Not Synced
    the official CGI documentation!
    *big applause and audience whistling*
  • Not Synced
    But, I'm not blaming CGI.PM developers.
  • Not Synced
    Nor am I blaming developers
    who copied from CGI.PM examples.
  • Not Synced
    After all, who could have known
    that this is what this code will do?
  • Not Synced
    This is how it could be exploited?
  • Not Synced
    There's no exec calls,
    the file is not saved anywhere,
  • Not Synced
    and we're only using a "print".
  • Not Synced
    The sole responsible for this mess,
    is the Perl language.
  • Not Synced
    Perl is the one silently expanding lists,
  • Not Synced
    Perl is the one mixing up your data types,
  • Not Synced
    Perl is the one executing user input
    with no exec calls,
  • Not Synced
    Perl is the problem,
  • Not Synced
    not its developers.
    *applause rising*
  • Not Synced
    And until this god-damned, bizarre,
    dangerous language is fixed,
  • Not Synced
    you could only
    stop
  • Not Synced
    using
  • Not Synced
    Perl!
  • Not Synced
    Thank you!
    *more applause*
  • Not Synced
    Herald: So I guess
    we have some time for questions now.
  • Not Synced
    *laughter*
    Netanel: Maybe
  • Not Synced
    Herald: And I have the funny feeling,
    we will have some questions now.
  • Not Synced
    Ok, so we have some microphones here.
    Please queue up.
  • Not Synced
    Please do not shout in, because we need
    to record it on the stream.
  • Not Synced
    Well, here we go.
  • Not Synced
    And we also have some questions
    from the internet, don't we?
  • Not Synced
    Signal angel: Oh yes, we do!
    *laughter*
  • Not Synced
    Signal: but before we come
    to the technical questions,
  • Not Synced
    the IRC wants you to know,
    what you did to it:
  • Not Synced
    it felt like there were explosions
    and camels everywhere.
  • Not Synced
    Netanel *laughing*: That's the point
  • Not Synced
    Signal: And incidently they want to know,
    if you have a list of those camel pics somewhere?
  • Not Synced
    Netanel: I think Google has it?
    *more laughter*
  • Not Synced
    Just there search camels.
  • Not Synced
    Signal: So for the first question.
    Opello(?) wants to know,
  • Not Synced
    if the take-away is, that Perl project authors
    so shouldn't trust input
  • Not Synced
    and instead verify types with REF
    and always use prepared SQL statements?
  • Not Synced
    Netanel: That's a good question. The take-away should be…
    *laughter*
  • Not Synced
    well, how will I phrase it …
  • Not Synced
    I think I have a slide … somewhere …
    *more laughter*
  • Not Synced
    Oh wait, where's my slide?
  • Not Synced
    Don't worry, have it right here.
  • Not Synced
    But really, trusting user input
    is always a bad idea
  • Not Synced
    and most developers know it.
  • Not Synced
    The problem is, that…
  • Not Synced
    well, at least from the code I saw reading Perl,
  • Not Synced
    and that's a lot of code, trust me
  • Not Synced
    …is that hashes and arrays
    are almost always considered secured
  • Not Synced
    as they supposedly can't be
    created by user input, as I said.
  • Not Synced
    But, when you're expecting your user input
    to be a scalar, a string or even a list
  • Not Synced
    and instead you get a hash from unexpected
    directions, you get confused.
  • Not Synced
    And you can't always
    live in the fear of not knowing
  • Not Synced
    what data type you're trying to handle.
  • Not Synced
    Well, not trusting scalar data types
    it's a wise decision, because it's dangerous.
  • Not Synced
    But not trusting your hashes,
    as well not trusting your arrays?
  • Not Synced
    What's next? Not trusting your own code?
  • Not Synced
    You just can't expect anything
    to really work as it should.
  • Not Synced
    When you're writing Perl,
  • Not Synced
    you are constantly attacked
    by all these different directions.
  • Not Synced
    And even the data type direction is a problem now.
  • Not Synced
    I hope that answers the question
    beside the slide.
  • Not Synced
    Herald: Well, than we're gonna go over
    and start with number one
  • Not Synced
    Questioner: So thank you for opening our eyes.
  • Not Synced
    Even I use Perl, I would say,
    for cooking and yes …
  • Not Synced
    Netanel: I remember you
    Q: Sorry?
  • Not Synced
    N: I remember you from the last talk!
    Q: No no
  • Not Synced
    N: Oh, you're new? Oh… *smirking*
    Q: I'm new, I'm new…
  • Not Synced
    Q: So… I can't say, I'm not guilty of that,
    but I still would say yes,
  • Not Synced
    Perl is a bit like cooking with my mum.
  • Not Synced
    Sometimes I put something into…
    the… with the boiling thing…
  • Not Synced
    and sometimes she, sometimes I go away,
    sometimes she go away
  • Not Synced
    and the only thing you can do is always taste.
  • Not Synced
    And yes, you're maybe right, Perl is a language
  • Not Synced
    where you never know what comes out,
    but it's real cool!
  • Not Synced
    If you get the right response you can use it,
  • Not Synced
    if you use it to write web applications
    I would agree.
  • Not Synced
    Web applications, the professional ones
    at least, are not for cooking,
  • Not Synced
    but for doing funny things and
    have some fun, I think it's a perfect language.
  • Not Synced
    N: I think Perl is a lot of fun.
    *laughter*
  • Not Synced
    I completely agree on that. *laughing*
  • Not Synced
    Herald: Then we go over to two
  • Not Synced
    Question: Was your life ever threatened
    while interacting with the Perl community?
  • Not Synced
    *laughter*
    N: Could you please repeat that? I …
  • Not Synced
    Q: Was your life ever threatened
    while interacting with the Perl community?
  • Not Synced
    N: Defenitely. Defenitely,
  • Not Synced
    I'm getting hate mail every day,
    living in fear …
  • Not Synced
    H: And over to the three please
  • Not Synced
    Q: I think I speak for all of us,
    when I thank you for this wonderful talk,
  • Not Synced
    N: Uh, thank you. Thank you really! Thank you.
    *applause*
  • Not Synced
    Q: Brilliantly executed, but… ehm…
    you spoke about Perl 5 I think
  • Not Synced
    N: Yes, you are absolutely right
    Q: As some of you might know, this christmas…
  • Not Synced
    *laughter*
    Q: …so tomorrow Ingo Blechschmidt
  • Not Synced
    will give a talk about how Perl 6
    will make everything better
  • Not Synced
    and how everyone should start
    using Perl 6 and…
  • Not Synced
    N: It also craps rainbows
    Q: Yeah, of course…
  • Not Synced
    Q: My personal comment is:
    wouldn't it have happened
  • Not Synced
    with a statically typed language?
  • Not Synced
    So I think some nice folks at Haskell
    in IRC are waiting for you Perl developers
  • Not Synced
    to please come, join us … Thank you!
    N: *smirking*
  • Not Synced
    *Herald and Netanel start speaking simultaneously*
  • Not Synced
    H: …sorry, to answer first, where am I… sorry
    N: I… no thanks… *unclear*
  • Not Synced
    just a quick note to Perl 6.
    This talk is all about Perl 5, alright?
  • Not Synced
    I … Perl 6 came out a couple of days ago and …
  • Not Synced
    From … at least what I saw,
    Perl 6 is to Perl as…
  • Not Synced
    C++ is to C. It's the same name,
    but it's a whole different language.
  • Not Synced
    So yes, this is Perl 5.
    Maybe I'll come back next year about Perl 6?
  • Not Synced
    *laughter*
    Who knows?
  • Not Synced
    Herald: I'm looking forward to that already
    *applause*
  • Not Synced
    *Herald pointing to signal angel*
  • Not Synced
    Signal: Yeah… Joerd(?) wants to know:
    of course you talked a lot about CGI.PM
  • Not Synced
    which you know was removed from repository from Perl
    even before your talk last year.
  • Not Synced
    So what about it's replacements
    from CPAN like CGI::Simple.
  • Not Synced
    Netanel: I don't know, I haven't checked it.
    When I decided on which modules to check,
  • Not Synced
    I took CGI.PM because even though it is old,
    it is the most popular in the world as of today
  • Not Synced
    and I took Mojolicious and Catalyst because
    they were really popular, too.
  • Not Synced
    So I didn't take the newest modules,
    I take the most popular modules.
  • Not Synced
    And I think, that's the important
    aspect of … deciding.
  • Not Synced
    Herald: and over to one please
  • Not Synced
    Questioner: Hi… uhm… part of the Perl community, and…
    *laughter*
  • Not Synced
    N: Hi!
    Q: But I just start with Perl – 5
  • Not Synced
    N: Uhh… ehm… uhh… didn't you… nhaa…
    *laughter*
  • Not Synced
    Q: We use Perl for almost every modules
    that we have at work
  • Not Synced
    and this worked really fine.
    N: …yeah…
  • Not Synced
    Q: And I don't know why you're picking Perl as language to attack.
  • Not Synced
    It's a really old language, it's also every language
    that we can pick, that has problems.
  • Not Synced
    But it doesn't mean this has to die or
    stop using it. So I don't know why…
  • Not Synced
    N: …you're right, you're right.
    First of all, you're completely right,
  • Not Synced
    because a language shouldn't die, it should improve.
  • Not Synced
    C got critized and it improved.
    PHP got critized and it improved.
  • Not Synced
    Why can't Perl be critized, too?
  • Not Synced
    Why is it like a code, when you say
    something bad about Perl then,
  • Not Synced
    I don't know, a horde of PerlMonks jumps on you?
  • Not Synced
    Why don't improve the language?
    Don't use it in your work though,
  • Not Synced
    it's dangerous.
    *laughter and applause*
  • Not Synced
    H: Then we gonna jump over to five please
  • Not Synced
    Q: Hi. I'm not a Perl developer,
    but I use a lot of Ruby and Python.
  • Not Synced
    Is this really limited to Perl or
  • Not Synced
    does this apply to more or less
    any dynamic language?
  • Not Synced
    N: As I said in one of the first few slides,
  • Not Synced
    some of it also applys to Python.
    Specifically the thing
  • Not Synced
    when you can't specify the data types
    your function arguments can get.
  • Not Synced
    But, what's unique to Perl is that
    writing different code
  • Not Synced
    for different data types in one function
    is very, very common.
  • Not Synced
    You can do it in every language, of course!
  • Not Synced
    But it is very common only in Perl!
    And that is unique about it,
  • Not Synced
    of course besides the thing
    that hashes and arrays are secure.
  • Not Synced
    That's of course Perls only fault.
  • Not Synced
    H: Good, than we gonna go over to six please
  • Not Synced
    Q: Hey! Did you say WAT more
    while preparing this talk or while holding it?
  • Not Synced
    N: Uhm. Both. *Laughing*.
    Did I rant? That was the … right?
  • Not Synced
    Q: Did you say it more
    while preparing it or while holding it?
  • Not Synced
    N: I'm missing your word, man.
  • Not Synced
    Ahh, wat… WAT! Ohh… Yeah, both!
    *laughter*
  • Not Synced
    H: Ok, do we have another from the internet?
  • Not Synced
    Signal: Does your exploit
    also work in tainted mode?
  • Not Synced
    N: No, I believe not. No, it doesn't.
  • Not Synced
    H: And another one
  • Not Synced
    S: Is there any Perl obfuscated code exploits
    like this for Catalyst or Mojolicious?
  • Not Synced
    N: I've no idea, man maybe.
    I didn't check it of course.
  • Not Synced
    I didn't check every module
    for every exploit, I ever want to create, but
  • Not Synced
    on CGI.PM, which is again
    the most popular CGI library, it did.
  • Not Synced
    So, maybe the internet
    can find more exploits. I know it can.
  • Not Synced
    H: Bring it on. That's it?
    N: That's it?
  • Not Synced
    Thank you!
  • Not Synced
    *applause*
  • Not Synced
    Herald: Thank you very much!
    Netanel: Thank you!
  • Not Synced
    *postroll music*
  • Not Synced
  • Not Synced
Title:
Netanel Rubin: The Perl Jam 2
Description:

more » « less
Video Language:
English
Duration:
40:24

English subtitles

Revisions Compare revisions