Very true, but it’s tough that it’s only $20,000. The sad reality is that such a “small” quantity means you rely on the morality of the white hat hacker rather than the economic incentive, since surely there are millions of dollars of potential payout for zero-day exploits on major SCM platforms in an immoral market.
@huchie it's a real issue for sure. In September 2023, Operation Zero raised it's payouts for iOS and Android RCE exploits to $20,000,000. For comparison, the Apply bug bounty program is only offering up to $1,000,000 for the same type of exploit, if reported.
Coming from the bloke who designed PHP? The language that can't decide if it wants to be a libc(3) front-end, a templating language, a general-purpose programming language, or a glue language for webservers? That's rich.
@@DanielBoctor i recently learnt that, you shouldn't trust user input even after successful database query, I'm not talking about SQL injection, I'm talking about character encoding.
@@twitchizle Absolutely. God forbid you use regex, but in case you need to, you have to think twice before passing user input directly in to a regex without any form of sanitization. It will simplify the regex as well so you don't have to handle all kinds of edge cases that are likely to make it exploitable to ReDoS.
I was ready to write snarky "wouldn't happen in Rust", but the bug is so bizarre, it wouldn't happen in C. In fact using eval seems like a clever trick. And "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it" comes from Kernighan himself.
Well using "eval" for anything but executing code from string violates "minimal authority" principle. Also, I pretty sure, djvu's list of escaped symbols do not match perl's list of escaped symbols
It still amazes me how many people fail to adequately check user input. If you're reading something that comes from an external source or that can be modified by a user of the system, that is most definitely user input and should be checked.
13:44 The buggy code wasn’t fixed. It was made unexploitable; but the bug remains. As someone else mentioned, the simple and straight forward approach is to deal with escapes and finding the closing quote in one pass.
It's sneaky, but @teeesen is right. It was a strange choice indeed. The underlying bug originated on line 227, which was due to the misuse of the dollar symbol within the regular expression. When you look at what was patched (full diff is in my description), no changes were made to line 227. Only the eval line was replaced. Technically, the bug still exists ($tok would continue to contain the same string), however it was made unexploitable due to the removal of the eval line, which is what caused the harm. You would need both lines to pull off the exploit. Link to the still present regex POST PATCH: github.com/exiftool/exiftool/blob/cf0f4e7dcd024ca99615bfd1102a841a25dde031/lib/Image/ExifTool/DjVu.pm#L227 Link to the diff github.com/exiftool/exiftool/commit/cf0f4e7dcd024ca99615bfd1102a841a25dde031
In the interest of pedantry: while the eval _call_ was removed, the /e modifier on the regex substitution means that the replacement half of the regex will be evaluated by Perl. What the new regex does is look up the escaped character in a hash table. If it's present, it substitutes in the corresponding value; if not, it leaves the escape sequence as-is (using short circuit evaluation). Presumably the more naïve solution would be preferable: consume the string character-by-character, keeping track of whether the preceding character was an unescaped backslash (using an escape sequence whitelist as they've done in their patch probably isn't a bad idea). I'm not sure if this would have a meaningful performance impact when parsing very large numbers of files. Regardless, security is more important.
@@DanielBoctorIf they then blindly deem the bug patched and the code secure, what would happen if they decide to directly use the output from the code somewhere else in another program?
@@TheJamesM I'd actually expect the naive solution to be more performant, since even that regex is way more complicated than just flipping a boolean variable. Also I find the code way harder to read than it needs to be. Someone tried to be clever and make it beautiful, but it requires a lot more thought to work with.
True, but this one could be found with grep. ANYTHING that calls eval is bound to have an issue like this. (I won't count the number of times I've seen this is stupid in "web applications" - perl, php, python, ...)
There are so many microscopic bells and whistles you have to focus on while making a website, so many ways of remote code execution by some small file format from 20 years ago where the specific exif metadata allows for direct access to the database, like it's difficult even for an entire team of people. If making websites was more streamlined and didn't require so many random libraries and so much of the same repetitive manual labor we wouldn't have issues like this. Web frameworks do help but not nearly enough
@@s1nistr433 And there's the problem: no one actually builds a website anymore, they just install and glue together whatever shiny they see. (and then ignore any security alerts / patches. Wordpress anyone?) That's what happened here. They grabbed EXIF and never cared to look at what it _can_ do.
jeez this is horrible security, languages should not be able to evaluate code from user input during runtime, even if its *almost* always "safely" sanitized.
It's not really up to the language to decide whether code should be executed or not. It doesn't know or care where the code came from. Even if it did, there'd be ways to subvert it.
@@dennisestenson7820 like writing to a file, then using include to include it as code... if include is disabled, lots of stuff fails, and timestamp checking could cause other bugs, if it is intended behaviour, for example
About 20 seconds in, I turned my headset up to max volume because I thought I was hearing the "Cicada 3301" video by LEMMiNo! Checked your description and saw the mentions, good choice!
Thank you for the very informative video! Besides the horrific use of `eval` here, I can't understand why they used regexes for this in the first place. The whole escape processing and finding the closing quote can be done together with a single loop pass. There's must be a law that you have to use regex everywhere in Perl. Just take a look at the patch! (13:41).
Glad you liked it! It definitely seems that it could have been done differently. It's already alarming enough when you find this commented directly above the function lol. # Notes: The DjVu annotation syntax is not well documented, so I make a number of assumptions here!
nice comment. ive seen people using regex becauae its 'fancy' but they themselves dont really understand it. and even if they do it makes it harder to understand for other devs, and more expensive to maintain. since now you require more knowledgable devs to deal with that.
Naturally, using eval for this task was a bad idea (or lazy), but don't put all your faith in regex. It's cool and saves a lot of dev time, but, honestly, it's kind of slow (and requires a lot of testing with different inputs when your match pattern gets really complex). Sometimes you have to just go back to the basic loops and simple tests (gasp!) - that eliminates ambiguity, but doesn't look as "cool" - though a potential exploit would reveal itself immediately (not so with regex). This is all relative to the skills of the dev for these high level functions we take for granted, of course.
I think it's a pretty good demonstration of how languages with roughly equivalent capabilities can lead people to code quite differently by way of the languages' respective design choices. Perl treats regular expressions as an integral part of the language to the degree that there are operators for regex matching and substitution. That doesn't necessarily correspond to any greater efficiency behind the scenes, but psychologically it feels that much more natural to use them. If nothing else, the resultant code will be shorter, which on some level feels like it ought to be faster.
This reminds me about how you used to be able to run console commands in Garry's Mod by sending a chat message containing "; ...because the chatbox just ran the 'say' command and you can cut the quote early. It's not sanitised. Then the semicolon tells the console that a second command is being typed. So, typing the following: man i'm dead"; kill would get interpreted as say "man i'm dead"; kill This no longer works as they now properly escape double quotes in the chatbox.
As soon as you mentioned metadata, my first thought was "somebody used it to inject code into memory." Sometimes the worst issues come from the simplest oversights.
Ugh. Surely rather than using regex, just iterating the string one character at a time and figuring out the escapes along the way would be simpler, safer and faster?
It would be easier and safer to just grab the string, make sure the size is not too big, and iterate over the entire string, and convert them, Its entirely possible there are libraries already made for this. Not sure why this is what ended up in prod. eval sucks
I agree. Regex saves time and makes difficult parsing tasks easier. On the flip side, it has all that extra overhead to handle generalized cases. This means it is slower (a lot of throughput tests done over the years shows this to be true). For this particular task, it's overkill (like using a microcontroller to make a blinking light instead of single transistor).
the hidden semantics in the $ of the regex is wild, but parsing a string literal with the approach showed in the video is still a clever trick. I only know to scan the literal and handle escape sequences on site. I will keep doing that though
Keep in mind that this was done in ExifTool, which is a 3rd party library that GitLab was using. They didn't write it themselves, but yeah, it shouldn't have been used regardless.
Running an external Perl program (or any script) in a non-isolated environment sounds very stupid! Specially since Perl is something between Bash and Python! And with low readability!
What an amazing video, always learning from you Dan! I missed the OG background music 😁 The sandwich analogy is literally clutch, new way of looking into backslashes and quotes!
Never is a hard word. WOuld you also say that user provided data should never be sent to SQL? You just need to correctly escape and sanitize the data. But you need it, you cannot avoid using it. If you don't you get SQL injection, or in this case unautorized code execution. It could have been avoided here, but there are use cases where it is needed by design (eg. scripting). In this scenario the process running Exif also should never have had permission to run system calls, which exif doesn't need, but that is beside the point, a last measure of protection when all rest fails.
@@marsovac Technically parameterized queries/prepared statements are made in a way that user input sanitization is not necessary, as the statement and the parameters are processed completely separately, bypassing the problem of SQL injection altogether. I only wanted to mention this to remind everyone that even SQL doesn't require an "eval". Sanitizing string input works well but you never know, someone could find a way to escape it under weird circumstances!
I expensively use regex when I need to analyze some text data on my local. But when I write a code for production, I avoid regex most of the time. I always feel safer to write string parsers manually.
I'm really thinking about move to cybersec at the moment, but these clever moves looks so fun and so scary at the same time... thanks for the explanation!
Incredible! I used to write a lot of code in perl like 20-30 years ago but even then I would have never used the eval function on data which came from the outside. Actually I probably wouldn’t have used it at all because it is inherently dangerous. I can’t believe that this code was still present in a tool used in 2023.
I really enjoy your videos! However, I suggest slightly lowering the volume of the background music to enhance the overall experience. 😅 Keep up the fantastic work! ❤️❤❤
Eval is quite useful for dynamic feature check, but it is often misunderstood and used for either data processing or breaking the boundary of trust. Everything passed to eval should come only from sources that already have execution access. But this specific usage of eval fails on both cases. Here there is another bug due to infinite loops. All data (especially untrusted data) should be under a length constraint. 1GiB of key or a value in a metadata is not valid metadata, parser loops passing such data should be finite and reasonably small.
What a ridiculous algorithm. You can scan forward until you find the first ", then if you find a \, you just read the next character raw, without checking for ". The algorithm is fundamentally flawed ...
Mind boggling that Workhorse would determine filetype based off extension, like it isnt even difficult to implement a solution to fix that (i.e. just run it through `file` on most Linux distros).
They are really well done indeed. They come from a collection of "Visualising AI" animations from Google DeepMind. Here is the source if you want to check it out! deepmind.google/discover/visualising-ai/
I just got to the part with “eval-ing” the string just to process escapes. I facepalmed hard and even though I didn’t see the rest of the video yet, I’m pretty sure this is the problem
damn, i thought i'm watching the same video, when that "on april 7th 2021" came in. it looks definetrly the same as, the other video with "on april 7th 2020"
Why do you put escape sequences into ()? That probably confuses people who don't understand it in depth thinking that () are actually a marker of the escape sequence as well
For someone who knows their shit like this, youd figure they would do a lot more with SEO. Which you should. Because you deserve way more views than this
Right now, SquareX is pre earnings startup. They're running on funding they raised apart of a seed round led by Sequoia Capital. In the future, they plan on launching a paid version of their service, however they will always offer a free tier, even after monetization.
yup, it's a real issue. In September 2023, Operation Zero raised it's payouts for mobile RCE exploits to $20,000,000. For comparison, the Apply bug bounty program is only offering up to $1,000,000 for the same type of exploit, if reported.
honestly I think you should have to use a flag when executing to enable eval (i.e. ‘python whatever.py --enable-eval-unsafe’). I guarantee this would not have passed review if that were the case.
@@thewhitefalcon8539 but eval in particular because as you’ve seen, it is not a question of *if* but *when* it will be exploited if the code interacts with data from users basically at all. It is literally Arbitrary code execution, which when exploited is generally considered the most severe vulnerability possible. The only reason to use eval is if the input will change in ways that cannot be accounted for by just writing the code normally, and since there is almost always a way to do something without eval, this means there is only a very slim number of cases where it is truly necessary, and given the known potential for security disasters, programmers should be forced to either find a way around using it, or have to explain to anyone who runs the code why it really is necessary. This would make sure anyone running the code knows that it uses eval without having to look through every line of code, and then they can make their own decision from there.
Either heavily sanitize the input, strip all and recreate it from scratch, take whole words and no strings, remove all floating point numbers or round up numbers, remove all tags besides date and name. The f are they doing.
Even ignoring the use of eval (which can be justified for exactly these kinds of situations where you want to handle escape sequences), that is a *terrible* way of parsing a string literal. You are already using regex. Just define a regex that cleanly matches an entire string literal, it's really not that hard and can be debugged and checked for correctness in isolation.
I'm am getting this video in my notifications now? That attack will work as you hitting the lottery now days. The vulnerability was in djvu that doesn't work anymore
Why TF does Perl expand the escape sequences in the argument of eval again? Even Python doesn't do that. 13:18 Even shell scripting is not this bad. The string content is being textually replaced into the line like a C macro. Why does it still do that if $tok is already quoted? I have never used Perl but I already hate it.
@@DanielBoctor I thought I'd give this Jpeg metadata thingy a try in Notepad++ , here is my little effort... aS5wb3N0aW1nLmNjL3E3anpNQjNyL1dob3MtYXQtdGhlLURpbmVyLmpwZw
7:40 I'm now uncertain, since this part of the video dealt with RegEx, and there's frankly a lot of ways to mishandle RegEx. The algorithm looks solid, but I don't use RegEx enough to be certain.
8:15 (This is the comment where, as the video predicted around 10:15, I confidently assumed "eval is evil" and was not yet aware of the qq. Obviously I'm getting ahead of things, so while I basically see where this is going, I'm not going to make any more predictions on how they escaped the string.)
THANKS FOR WATCHING ❤
JOIN THE DISCORD! 👉 discord.gg/WYqqp7DXbm
👇 Let me know what type of bug bounty reports you would like to see next! 👇
Epic move from the GitLab team paying 100% bounty for a vulnerability in the code they didn't even write
I know, GitLab made a good move. A good reputation among bug hunters can be very valuable.
You could argue that the way they validate file types is part of the exploit, at least on their end.
Very true, but it’s tough that it’s only $20,000. The sad reality is that such a “small” quantity means you rely on the morality of the white hat hacker rather than the economic incentive, since surely there are millions of dollars of potential payout for zero-day exploits on major SCM platforms in an immoral market.
@@hunchie i mean 20k is 20k, still a lot of money
@huchie it's a real issue for sure. In September 2023, Operation Zero raised it's payouts for iOS and Android RCE exploits to $20,000,000. For comparison, the Apply bug bounty program is only offering up to $1,000,000 for the same type of exploit, if reported.
I think the inventor of PHP once said about eval: “If eval is the answer, you’re almost certainly asking the wrong question.”
beautifully said
Even PHP guys knows it 🧐
🤣
Coming from the bloke who designed PHP? The language that can't decide if it wants to be a libc(3) front-end, a templating language, a general-purpose programming language, or a glue language for webservers? That's rich.
Anytime I see user input being passed to eval it sends shivers down my spine. There's always the question _when_ (not if) it will be exploited.
yup, guess someone never learned about defensive programming 😔
@@DanielBoctor i recently learnt that, you shouldn't trust user input even after successful database query, I'm not talking about SQL injection, I'm talking about character encoding.
@@twitchizle Absolutely. God forbid you use regex, but in case you need to, you have to think twice before passing user input directly in to a regex without any form of sanitization. It will simplify the regex as well so you don't have to handle all kinds of edge cases that are likely to make it exploitable to ReDoS.
Why do people use eval in production code in the first place?
@@twitchizle
Wait, shouldn't trust input after successful database query?
Are you doing input validation after using the input to query a database?
As soon as you said "metadata", I was expecting a buffer overflow. Instead I got regex *and* eval. Double evil!
eval the oldest trick in the book still works time to time
Eval and regex together. Delicious.
the forbidden combo
I was ready to write snarky "wouldn't happen in Rust", but the bug is so bizarre, it wouldn't happen in C.
In fact using eval seems like a clever trick. And "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it" comes from Kernighan himself.
You will never be a woman
Well using "eval" for anything but executing code from string violates "minimal authority" principle. Also, I pretty sure, djvu's list of escaped symbols do not match perl's list of escaped symbols
It still amazes me how many people fail to adequately check user input. If you're reading something that comes from an external source or that can be modified by a user of the system, that is most definitely user input and should be checked.
Im glad it wasn't sanitized and they deserve it.
Im surprised they didnt just rm -rf their db1 again to solve the problem
underrated comment
@@DanielBoctor underated reply
13:44 The buggy code wasn’t fixed. It was made unexploitable; but the bug remains. As someone else mentioned, the simple and straight forward approach is to deal with escapes and finding the closing quote in one pass.
Would you mind explaining how? The eval call was removed
It's sneaky, but @teeesen is right. It was a strange choice indeed.
The underlying bug originated on line 227, which was due to the misuse of the dollar symbol within the regular expression. When you look at what was patched (full diff is in my description), no changes were made to line 227. Only the eval line was replaced. Technically, the bug still exists ($tok would continue to contain the same string), however it was made unexploitable due to the removal of the eval line, which is what caused the harm.
You would need both lines to pull off the exploit.
Link to the still present regex POST PATCH:
github.com/exiftool/exiftool/blob/cf0f4e7dcd024ca99615bfd1102a841a25dde031/lib/Image/ExifTool/DjVu.pm#L227
Link to the diff
github.com/exiftool/exiftool/commit/cf0f4e7dcd024ca99615bfd1102a841a25dde031
In the interest of pedantry: while the eval _call_ was removed, the /e modifier on the regex substitution means that the replacement half of the regex will be evaluated by Perl. What the new regex does is look up the escaped character in a hash table. If it's present, it substitutes in the corresponding value; if not, it leaves the escape sequence as-is (using short circuit evaluation).
Presumably the more naïve solution would be preferable: consume the string character-by-character, keeping track of whether the preceding character was an unescaped backslash (using an escape sequence whitelist as they've done in their patch probably isn't a bad idea).
I'm not sure if this would have a meaningful performance impact when parsing very large numbers of files. Regardless, security is more important.
@@DanielBoctorIf they then blindly deem the bug patched and the code secure, what would happen if they decide to directly use the output from the code somewhere else in another program?
@@TheJamesM I'd actually expect the naive solution to be more performant, since even that regex is way more complicated than just flipping a boolean variable.
Also I find the code way harder to read than it needs to be. Someone tried to be clever and make it beautiful, but it requires a lot more thought to work with.
This is hugely interesting it’s crazy how people can find these over looked bugs
Some of these bug hunters are on another level
True, but this one could be found with grep. ANYTHING that calls eval is bound to have an issue like this. (I won't count the number of times I've seen this is stupid in "web applications" - perl, php, python, ...)
There are so many microscopic bells and whistles you have to focus on while making a website, so many ways of remote code execution by some small file format from 20 years ago where the specific exif metadata allows for direct access to the database, like it's difficult even for an entire team of people.
If making websites was more streamlined and didn't require so many random libraries and so much of the same repetitive manual labor we wouldn't have issues like this. Web frameworks do help but not nearly enough
@@s1nistr433 And there's the problem: no one actually builds a website anymore, they just install and glue together whatever shiny they see. (and then ignore any security alerts / patches. Wordpress anyone?) That's what happened here. They grabbed EXIF and never cared to look at what it _can_ do.
They likely just searched the opensource code for usage of "eval", and figured: I can hack that.
jeez this is horrible security, languages should not be able to evaluate code from user input during runtime, even if its *almost* always "safely" sanitized.
So true, the laziness and carelessness of some programmer is astonishing.
And especially not inside a library or tool that others consume without knowing what risks they are accepting.
it's*
It's not really up to the language to decide whether code should be executed or not. It doesn't know or care where the code came from. Even if it did, there'd be ways to subvert it.
@@dennisestenson7820 like writing to a file, then using include to include it as code... if include is disabled, lots of stuff fails, and timestamp checking could cause other bugs, if it is intended behaviour, for example
About 20 seconds in, I turned my headset up to max volume because I thought I was hearing the "Cicada 3301" video by LEMMiNo! Checked your description and saw the mentions, good choice!
haha I know! He's an inspiration to me. It's cool that you picked up on it!
DJVU isn't an obscure file format, it's the standard way to share things like book scans and is much better at that than PDF
Sounds like "specialist" would have been a better description.
i'd rather manually write an image in binary than try to edit a PDF so i'm sure it's better
@@aiexzs Why would you not edit the PDF in binary, then? Its structure is extensible but quite straightforward.
@@JohnGardnerAlhadis isn't it XML and a bunch of raw data mixed in? i'd definitely write an svg manually over that
Thank you for the very informative video!
Besides the horrific use of `eval` here, I can't understand why they used regexes for this in the first place. The whole escape processing and finding the closing quote can be done together with a single loop pass.
There's must be a law that you have to use regex everywhere in Perl. Just take a look at the patch! (13:41).
Glad you liked it! It definitely seems that it could have been done differently. It's already alarming enough when you find this commented directly above the function lol.
# Notes: The DjVu annotation syntax is not well documented, so I make a number of assumptions here!
nice comment. ive seen people using regex becauae its 'fancy' but they themselves dont really understand it. and even if they do it makes it harder to understand for other devs, and more expensive to maintain. since now you require more knowledgable devs to deal with that.
Naturally, using eval for this task was a bad idea (or lazy), but don't put all your faith in regex. It's cool and saves a lot of dev time, but, honestly, it's kind of slow (and requires a lot of testing with different inputs when your match pattern gets really complex). Sometimes you have to just go back to the basic loops and simple tests (gasp!) - that eliminates ambiguity, but doesn't look as "cool" - though a potential exploit would reveal itself immediately (not so with regex). This is all relative to the skills of the dev for these high level functions we take for granted, of course.
I think it's a pretty good demonstration of how languages with roughly equivalent capabilities can lead people to code quite differently by way of the languages' respective design choices. Perl treats regular expressions as an integral part of the language to the degree that there are operators for regex matching and substitution. That doesn't necessarily correspond to any greater efficiency behind the scenes, but psychologically it feels that much more natural to use them. If nothing else, the resultant code will be shorter, which on some level feels like it ought to be faster.
This reminds me about how you used to be able to run console commands in Garry's Mod by sending a chat message containing ";
...because the chatbox just ran the 'say' command and you can cut the quote early. It's not sanitised.
Then the semicolon tells the console that a second command is being typed. So, typing the following:
man i'm dead"; kill
would get interpreted as
say "man i'm dead"; kill
This no longer works as they now properly escape double quotes in the chatbox.
That Perl code looks like something out of an obfuscated programming competition...
So basically just standard Perl then. 😂They don’t call it a write-only programming language for nothing!
As soon as you mentioned metadata, my first thought was "somebody used it to inject code into memory." Sometimes the worst issues come from the simplest oversights.
Ugh. Surely rather than using regex, just iterating the string one character at a time and figuring out the escapes along the way would be simpler, safer and faster?
It would be easier and safer to just grab the string, make sure the size is not too big, and iterate over the entire string, and convert them, Its entirely possible there are libraries already made for this. Not sure why this is what ended up in prod. eval sucks
I agree. Regex saves time and makes difficult parsing tasks easier. On the flip side, it has all that extra overhead to handle generalized cases. This means it is slower (a lot of throughput tests done over the years shows this to be true). For this particular task, it's overkill (like using a microcontroller to make a blinking light instead of single transistor).
Yeah, do it the way the specification is defined: left to right in atomic units.
Wow, the production quality is like a channel with 100k+ subscribers. I subscribed. This is awesome!
Thank you! Glad to have you apart of the community. If you thought this one was good, just wait until my next one 😜
the hidden semantics in the $ of the regex is wild, but parsing a string literal with the approach showed in the video is still a clever trick. I only know to scan the literal and handle escape sequences on site. I will keep doing that though
A lot of people already told me how dangerous eval is, and I'm surprised that even big companies do this..
Keep in mind that this was done in ExifTool, which is a 3rd party library that GitLab was using. They didn't write it themselves, but yeah, it shouldn't have been used regardless.
@@DanielBoctor it is still their end though, they couldn't have used a tool that is vulnerable to exploits, or review them before even using it.
An offering for the algorithm gods. Keep it up!
Thank you!
Very well edited and very interesting ..thanks! **edit .. I wonder how long it took him to find that 0day
Thanks! Glad you liked it 😊. Me too - these bug hunters are unreal. One day I hope to make one of these videos where I am the one who found the bug 😆
@@DanielBoctor same!!
@@DanielBoctor or sell it to zerodium and retire
Running an external Perl program (or any script) in a non-isolated environment sounds very stupid! Specially since Perl is something between Bash and Python! And with low readability!
What an amazing video, always learning from you Dan! I missed the OG background music 😁
The sandwich analogy is literally clutch, new way of looking into backslashes and quotes!
Thank you @TheControlMastr! You're a real one for all the support. Thanks for watching 😊
I got a GitLab ad on this video 😂
no way LOL. I didn't think they would be running ads on UA-cam since they're main customers are enterprises.
We need more people like you :simle:
Glad to have you apart of the community. Thanks for the kind words, keep on doing what you're doing 😊
using eval to unescape strings 💀
bro really used eval 💀
I might superstitious, but eval should NEVER be used in production code. Especially with user input, "sanitized" or not. No exception.
It should definitely be avoided whenever possible. It's not only a massive risk, but also unnecessary most of the time.
Never is a hard word. WOuld you also say that user provided data should never be sent to SQL?
You just need to correctly escape and sanitize the data. But you need it, you cannot avoid using it.
If you don't you get SQL injection, or in this case unautorized code execution. It could have been avoided here, but there are use cases where it is needed by design (eg. scripting).
In this scenario the process running Exif also should never have had permission to run system calls, which exif doesn't need, but that is beside the point, a last measure of protection when all rest fails.
@@marsovac In SQL you can also use parametrized queries instead of escaping user input inside a query string. I think that's the safest choice.
@@ratchy1231 i know, but that is the same thing, except you don't do the escaping yourself, but let it to a framework.
@@marsovac Technically parameterized queries/prepared statements are made in a way that user input sanitization is not necessary, as the statement and the parameters are processed completely separately, bypassing the problem of SQL injection altogether. I only wanted to mention this to remind everyone that even SQL doesn't require an "eval". Sanitizing string input works well but you never know, someone could find a way to escape it under weird circumstances!
3:39 RAM pictures are the old DIMM sticks, nice
very observant lol
Loved the video! Just wanted to point out that WhatsApp is native instead of Electron as of mid 2023.
Thanks! Also good catch, thanks for pointing this out. I stand corrected. Also, did you comment this on the wrong video? lol
@@DanielBoctor HUH HOW DID THE COMMENT END UP HERE WHAT??? Maybe it autoplayed while I was typing it lol
I expensively use regex when I need to analyze some text data on my local. But when I write a code for production, I avoid regex most of the time. I always feel safer to write string parsers manually.
I'm really thinking about move to cybersec at the moment, but these clever moves looks so fun and so scary at the same time...
thanks for the explanation!
Cyber is definitely a blast. Glad you enjoyed the video!
Incredible! I used to write a lot of code in perl like 20-30 years ago but even then I would have never used the eval function on data which came from the outside. Actually I probably wouldn’t have used it at all because it is inherently dangerous. I can’t believe that this code was still present in a tool used in 2023.
You deserve a lot more views!
I can hope! Thank you for the support - I appreciate it
truly the root of all eval
regex and eval? seems like a recipy for disaster
couldn't have said it better myself
Tbh I wasn't expecting it to be this simple. Sometimes some things are really over looked
20 k is so little for how importand of a bug he found .
I really enjoy your videos! However, I suggest slightly lowering the volume of the background music to enhance the overall experience. 😅
Keep up the fantastic work! ❤️❤❤
Thank you!! I appreciate the support ❤. Means a lot
Eval is quite useful for dynamic feature check, but it is often misunderstood and used for either data processing or breaking the boundary of trust. Everything passed to eval should come only from sources that already have execution access. But this specific usage of eval fails on both cases.
Here there is another bug due to infinite loops. All data (especially untrusted data) should be under a length constraint. 1GiB of key or a value in a metadata is not valid metadata, parser loops passing such data should be finite and reasonably small.
8:10 eval -- oh no. Just no. Never execute anything that is untrusted!!
rule #1 was broken 😔
What a ridiculous algorithm. You can scan forward until you find the first ", then if you find a \, you just read the next character raw, without checking for ". The algorithm is fundamentally flawed ...
Mind boggling that Workhorse would determine filetype based off extension, like it isnt even difficult to implement a solution to fix that (i.e. just run it through `file` on most Linux distros).
An other master piece ! thanks you !
Thank you too! Glad you liked it 😊
Dan delivers phenomenal content again. Make sure to subscribe so we can have the most ultimate world changing ping pong game you have ever seen.
LOOOOOOL we're so close
It always amazes me how big part of all exploits are running user input string as code
Good video thanks for making it daniel
Glad you liked it!
Great video but I wonder how I could understand this at a deeper level. If I had to explain this I'd find it challenging.
Interesting comment - would you say this was because of how I made the video? Would there be anything you suggest I do differently?
The video sequences when nothing is happening, are those AI generated or stock? Looking very professional.
They are really well done indeed. They come from a collection of "Visualising AI" animations from Google DeepMind. Here is the source if you want to check it out!
deepmind.google/discover/visualising-ai/
Also you forgot .MP3 files that display the cover art album artist name release date genre number on the album which disc it is on
This is pure quality!
Thank you! Glad you liked it
I just got to the part with “eval-ing” the string just to process escapes. I facepalmed hard and even though I didn’t see the rest of the video yet, I’m pretty sure this is the problem
20k is too cheap. He deserves 200k
Your sponsor actually seems interesting. Rarely do I hear useful sponsors.
Excellent vid! Subbed!!
Thank for watching!
damn, i thought i'm watching the same video, when that "on april 7th 2021" came in. it looks definetrly the same as, the other video with "on april 7th 2020"
Second I heard "Eval" I chuckled.
Why do you put escape sequences into ()? That probably confuses people who don't understand it in depth thinking that () are actually a marker of the escape sequence as well
Awesome breakdown!
Not as awesome as you
For someone who knows their shit like this, youd figure they would do a lot more with SEO. Which you should. Because you deserve way more views than this
I appreciate the support LOL. I'm trying my best
Many years ago I heard the phrase "eval is the root of all evil" when using eval in JS. Still true.
Title made me think of an old psp exploit that used .tiff images
interesting, never heard of that one before
Wow! What an amazing video!
Thank you!!
well worth the $20k
you say that disposable browser is free… what’s the catch?
Right now, SquareX is pre earnings startup. They're running on funding they raised apart of a seed round led by Sequoia Capital. In the future, they plan on launching a paid version of their service, however they will always offer a free tier, even after monetization.
20.000 dollars for that? What a rats
$20k for these exploits are chump change compared to the potential damage they could cause. Surprised bounty hunters put up with it.
yup, it's a real issue. In September 2023, Operation Zero raised it's payouts for mobile RCE exploits to $20,000,000. For comparison, the Apply bug bounty program is only offering up to $1,000,000 for the same type of exploit, if reported.
honestly I think you should have to use a flag when executing to enable eval (i.e. ‘python whatever.py --enable-eval-unsafe’). I guarantee this would not have passed review if that were the case.
you could say that about every language feature though
@@thewhitefalcon8539 but eval in particular because as you’ve seen, it is not a question of *if* but *when* it will be exploited if the code interacts with data from users basically at all. It is literally Arbitrary code execution, which when exploited is generally considered the most severe vulnerability possible. The only reason to use eval is if the input will change in ways that cannot be accounted for by just writing the code normally, and since there is almost always a way to do something without eval, this means there is only a very slim number of cases where it is truly necessary, and given the known potential for security disasters, programmers should be forced to either find a way around using it, or have to explain to anyone who runs the code why it really is necessary. This would make sure anyone running the code knows that it uses eval without having to look through every line of code, and then they can make their own decision from there.
This is a brilliant video!
Glad you liked it!
Eval is the biggest evil
Either heavily sanitize the input, strip all and recreate it from scratch, take whole words and no strings, remove all floating point numbers or round up numbers, remove all tags besides date and name.
The f are they doing.
Nice video
glad you liked it
Honestly that code just smells, multiple regex, eval, commented out code.
Jeez, and I thought my codes are bad
as soon as I saw eval I understood that code injection was possible, argh!
LEMMINO MUSIC !
a living legend
11/10 explanation
Glad you think so
Love your content!
love you more
Gitlab populates 40% of the top 20 bug bounty list….
The should rewrite it in Rust already
8:10 IT'S A FOUR-LETTER WORD
i sense GitHub roast coming
eval in a parser. genius
Even ignoring the use of eval (which can be justified for exactly these kinds of situations where you want to handle escape sequences), that is a *terrible* way of parsing a string literal. You are already using regex. Just define a regex that cleanly matches an entire string literal, it's really not that hard and can be debugged and checked for correctness in isolation.
Good work.
Thanks!
I'm am getting this video in my notifications now? That attack will work as you hitting the lottery now days.
The vulnerability was in djvu that doesn't work anymore
“Written in perl” say no more fam.
Very entertaining!
Thanks! Glad you liked it 😊
Why TF does Perl expand the escape sequences in the argument of eval again? Even Python doesn't do that.
13:18 Even shell scripting is not this bad. The string content is being textually replaced into the line like a C macro. Why does it still do that if $tok is already quoted?
I have never used Perl but I already hate it.
gitlab was indeed at fault for trusting an extension and sending the file to an universal third party lib
Interpolate doesn't mean the same thing as interpret.
Cool video.
not as cool as you
RCE - Remote code execution
Brilliant!
Brilliant indeed. Thanks for watching!
@@DanielBoctor I thought I'd give this Jpeg metadata thingy a try in Notepad++ , here is my little effort...
aS5wb3N0aW1nLmNjL3E3anpNQjNyL1dob3MtYXQtdGhlLURpbmVyLmpwZw
2:00 I have a guess where this is going:
is one of the metadata tags in djvu (and supported by EXIF) a "run this thing" tag?
4:15 Seems my guess is probably wrong. New guess: Buffer overflow in the code that interprets the C-string
7:40 I'm now uncertain, since this part of the video dealt with RegEx, and there's frankly a lot of ways to mishandle RegEx. The algorithm looks solid, but I don't use RegEx enough to be certain.
7:50 wait, what happens if the string never has a true closing quote?
8:15 (This is the comment where, as the video predicted around 10:15, I confidently assumed "eval is evil" and was not yet aware of the qq. Obviously I'm getting ahead of things, so while I basically see where this is going, I'm not going to make any more predictions on how they escaped the string.)
Ahh, yes, passing caller provided data to eval... Something you should probably avoid unless you absolutely need it and know what you're doing.
I say we ban it! 😅
What is a valid use case for eval?
Regex L
I think $tok is like token
that it what it's short for
approximately 19x mine