@ytg6663 It is no longer exploitable, as it was fixed both within a WhatsApp patch (2.19.244), and within the android-gif-drawable library. Facebook reserved CVE-2019-11932 for this issue.
Kinda cool, the principles of these kinds of low level exploits are not so different from how speedrunners achieve arbitrary code execution in old games, mess around with pointers until they point to the memory address of the code you want to run next, and they do this by exploiting glitches during gameplay
Genuinely, what a great explanation of the double free vulnerability! Really love the detail and this can be very useful for anyone getting into binary exploitation techniques. For me this really solidified the basics I saw here and there, with a nice practical example
Good video. the title however is misleading, it's not ANY android phone it's android phones that already have a malicious application installed and whatsapp, additionally the title implies that the exploit can be used right now, even though it was patched years ago by both whatsapp and android
also i would argue that this is really just a whatsapp exploit because the reverse shell gained is just the same privileges as whatsapp is currently allowed by android, so access to all user files if the user ever had previously attached something in whatsapp and allowed the permission, also the "android gif library" isn't used by all android apps not by a long shot, it just happened to be imported into whatsapp's source code and be what whatsapp used to render gifs, there isn't any real priviliege escalation exploit here
Well at the last second you took away its powers by explaining that the user would have needed to basically download a virus first. But I could see this working for a malicious company that creates popular apps with the goal being to use the app as the “virus” agent to get that local address saved and get the user’s phone number through a sign up or something. And with the local address and the phone number, sending them a gif on WhatsApp (if they have WhatsApp) would work. Seems like it would work best if you had a huge database of potential victims. Thx for explaining this stuff bro. edit: I was wrong about how this works
It's actually a lot easier than that. I didn't mean to take away from the vulnerability too much. As mentioned in the video, the required memory addresses are constant values, and ONLY change during system reboots. Any application has access to these addresses. An app would not even need to harvest the targets phone number, NOR send the user a GIF in the first place. It could merely craft the GIF itself, and save it to the phones file system locally. That's it. The next time the victim opens their media gallery in WhatsApp, the GIF will be rendered directly, without the need to even receive a message. Thanks for watching, and I'm glad you enjoyed!
The vulnerability is actually 3-fold: 1. Android OS returning the same memory address twice after a double free 2. The android-gif-drawable library causing a double free in the first place 3. WhatsApp double parsing GIFs, enabling any real harm to be caused from the double free You would need all three of these conditions to be present for this to be exploitable. Just using an old version of WhatsApp would not be enough, as both WhatsApp and the GIF library were both patched.
This wasn’t mentioned in the video, but the presented vulnerability is merely an example of what can be done. OP mentions that there are potentially more complicated methods to leak relative addresses allowing us to do ROP to mitigate read-only pages. Without getting too far into it, the deterministic way android handles double frees enables us to, within the same gif, leak a valid instruction pointer and then use different techniques with that executable memory location to execute our shellcode
More like a 'performance bug' or some thumbnail generation, etc... Let's say you wanna show the first frame of the gif as a preview and the user should tap on the image to actually start playing the gif. You can do it different ways but it is easy to image they choose a method to reread the gif twice. First to acquire an initial frame and a second time when the user want to play the gif.
How the researcher discovered gifs were rendered twice in whatsapp is very interesting. I mean i know some people who does reversing on major android apps or iphone app ipa files but i dont know they do the research with that depth of knowlege.
Great comparison between these two channels, got me thinking more about my upcoming videos. And I have asked my self the question you end on I just need to make it more clear who I'm targeting in my titles
I went to college in 1990, and they were still teaching C for first year programming. Java was still new to the game, so you had a choice of Pascal or C. I remember the professor told us that after the 3rd week we can expect half the class to drop. The 3rd week is when he introduced pointers. He wasn't wrong. This is a great video that helps illustrate the concept behind pointers. I think part of the problem was the professor, but I wasn't going to say anything. I taught myself assembler when I was 14, so pointers to me were already natural and I had no issue understand them. Half the class struggled immensely and wound up dropping before the first mid-term.
😆 in 2020 ppl were saying they'd leave the USA if Trump was elected. I'm ready to leave to get away from the valley girl accent that's so popular with the hipstERS & liberal medIAAA. 😣🔫
It would. All commands would be executed within WhatsApp context, allowing one to steal files from the WhatsApp sandbox, including the message database, as Awakened mentioned in his original report. I should have explained this in more detail within the video.
Heck yeah~ this made me curious what other kind of exploits there are, so I start to look at the standard linux kernel 6.6 and instantly I noped tf out of there Not because I wouldn't eventually be able to get a grasp on the madness that's called code (tho it is organized), but because I already have too many coding projects lol @@DanielBoctor
The thing about double free is that it allows you to edit a free chunk, in glibc (I am not sure if its in android kernel) free chunks are linked via fd & bk pointers which is pretty much a double-linked list (this also depends on the size of the free chunk which is categorized to which bin list) , modifying these pointer in a free chunk can allowed you to malloc in arbitrary address since malloc related operation retrieve chunks in the free list if exist rather than creating a new one
I see, sorry for the confusion! To clarify, under regular circumstances in a regular environment, this is absolutely correct, as mentioned @ 4:35. It is Android itself that caused the predetermined realloc behaviour, as mentioned @ 5:00 and 5:30. The vulnerability is actually 3-fold: 1. Android OS returning the same memory address twice after a double free 2. The android-gif-drawable library causing a double free in the first place 3. WhatsApp double parsing GIFs, enabling any real harm to be caused from the double free You would need all three of these conditions to be present for this to be exploitable. The Android behaviour you are pointing out is actually contributing to the exploit (which should NOT be happening).
@@DanielBoctor Sorry, it might be that my question was unclear. As per standard realloc should always return a pointer, that can be passed to free/realloced with size 0. That means that, as long as you use the pointer returned by realloc (and don't reuse the pointer you passed to realloc) you could call realloc infinitely often. Even with size 0.
@@DanielBoctor ooh, I looked at the commit that it was patched. The problem is, that realloc returning NULL is valid behaviour for size 0 realloc. This however gets interpreted as an error bc of low memory. In that case, the pointer doesn't get updated and will be passed again to realloc the next frame (but it was already freed).
Similar to how originals of edited jpeg images were recovered in an exploit that manipulated leftover space inside a buffer to reconstruct the bits of the original. For the most part you would recover only the later bits corresponding to pixels of the original because of how the file would be saved coupled with the top-down rendering of your device. The jpeg once saved after editing/cropping/redactions could therefore still have the information, but this gif exploit would basically take that one step further in regards to abusing the rendering method, by re-filling up the empty space with (insert any smol footprint exploit payload) And the beauty of gif, is that can be looped. Which can also be a bigger issue if the gif allows itself to talk directly into terminal with certain commands. Persistence can be achieved and hidden (in perpetuity) if done correctly.
Is there a version of this gif that just roots your phone without the need of reinstalling the entire OS and losing your data? I always wonder why nobody uses exploits like this to just make easy no-fuss rooting tool.
It's pretty darn easy to root, people just want to use the most latest devices, which some are currently not root able. Like us verisons of Samsung phones but European verisons are able to root because of unlocked bootloader. The one plus series are the most easiest to root even the brand new one.
@@Slowburnripz I think a distinction should be made between actual rooting, which lets you access all your own info / hidden app data / etc, and bootloader unlocking, which explicitly deletes it.
@@Slowburnripz Not if you want to keep your files on the device though. Also "easy" is relative, since all known methods require you to install some weird software and connect your phone to your computer. Ideally EU or some other entity would enforce a single click root for all the devices. Why is there no switch in the Android's menu to easily root phone, similar to "developer settings" one is beyond me.
6:27 any number greater than 21 to trigger realloc condition, right? Great video btw! Your explanations are easy to follow despite the complexity of the topic!
10:18 did the attacker write the gadget or was it already written? Are x0, x8, and x19 registers or mem addresses? Would x19 need to be the address of frame 1 / gif info?
You said function pointer and I literally went WHAT IN THE LIVING SECURITY HOLE IS THIS SHIT Needed to say no more, I instantly understood the gravity of this exploit
"this gif can backdoor any android phone!*" * as long as the phone is this specific model made between these 2 specific dates with this specific version of android and needs to have this specific version of a specific app installed and needs a cosmic ray to flip a specific bit in a specific part of memory at this specific time
Sometimes, but first of all if you spread it to thousands of devices you're going to hit a lot, and second of all this one just needs your firmware + whatsapp version to be older than newest. But I have to admit this shell is pretty much useless without privilege escalation
Assembly, memory allocation, graphics programming, for an attack? Are you kidding me? Who is going to go for all this trouble? It has to be some government or a large interprise.
Does comp sci teach that the word asterisk is asterix or something. Beautiful video. Smart lad, amazing explanation, clearly understand hardware and software and programming languages super well. And then asterix. You get my sub, but my question as well.
but it will not give you root access, only sandboxed access to the application that has the rce, which makes it pretty much useless. there needs to be another step before an attacker gets access to your phone, it needs a root shell.
boy i have news for you... Android is literally a Linux distro. It comes with toybox in all versions since Android 6, where it serves the same function that " *GNU coreutils* " does on _most_ other Linux distros. This exploit is technically an exploit in *WhatsApp* and that "android gif library" it uses, which is not used by all apps. Since it's a Java library implemented partly in C, ironically it would be more likely to be used by apps written mostly in Java than apps written mostly in C and C++, which would be more likely to use older, more robustly tested C libraries. Contrary to whatever else you might also have heard, no not all Android apps are 99% Java, many apps are more like 5% Java 95% other stuff.
Maybe that's why they needed a hardened memory allocator... I suspect this would not affect it, plus upstream has been updated anyway. Can't say with certainty though.
Yep, he posts all of his music publicly and lets other creators use them. Gotta love LEMMiNO. It's credited in my description too - I used 2 of his songs in this video.
It seems like rather than backdooring ANY Android phone it can only backdoor phones with both WhatsApp AND a second, specifically malicious app already installed?
so to get this vulnerability which allows you to gain access to the phone, first you have to gain access to the phone to get the function addresses, got it
Should have went into more detail on this. In this case, the RCE would be within WhatsApp context. One could read files from the WhatsApp sandbox, including the message database, as Awakened mentioned in his original report. A separate application would only have its own perms, making it of little real value. This can almost be thought of as privilege escalation in a way.
I agree. I couldn't even make it through the video with every sentence sounding like it was a question. Also known as "High rising terminal." I will try your suggestion and just read the captions next time.
Thanks for this. It was noted in my previous video as well. I wasn't really conscious of it when I filmed this video - still pretty new to all of this. I'll try and correct this going forward.
I was very interested in this material but also had to scan the comments to see if anyone else noticed this. Nice to see the creator of the video be thankful for the feedback. Respect.
So glad I didn't have to make the comment. I've never came across a male doing this. He must've spent a lot of time with women or something. I don't think people naturally talk this way, they usually pick it up from someone else. What came first, the chicken or the egg. 😂
Call me dumb or ignorant but why is it even allowed to have exactly one dimension be 0? Wouldn't you need two integers of at least 1 to even display anything? As I understand it this bug would be a non-issue if there's only one possible "aspect ratio" (if you can even call it that for 1-dimension) involving 0. The fix could literally be (pseudo-code) if(height0); assuming we derive a binary (single digit) boolean from the arithmetic operation denoting if the other dimension exists/>0 with either 1 or 0, we can just multiply it (dunno if it's actually faster with the if, otherwise replicate the last line switching height & width).
#Intriguing would this fall under software development and\or IT Security? I ask because I am looking to invest into a second major; and I very much would like to learn how to read and write computer code. Thank you.
IT security is probably going to focus more on firewalls, network monitoring, toolkits that you can deploy as an network admin, that kind of stuff. Writing code that uses malloc and free properly is going to be a software engineering issue, or maybe computer science. Every software developer needs to have a basic understanding of the most common security exploits and how to avoid them. It helps if you use a language that does not require you to manage malloc() and free() yourself. C is great for things like embedded systems, but you have to be very careful. C++ is better imho, because you can use paradigms like RAII, where you release resources and free memory in destructors, you have standard containers that allocate memory for you, so you really don't have to touch new/malloc and delete/free that often. Of course the evangelical memory safe language is Rust, and you will find no shortage of people to tell you why... there's also garbage collected languages like Java and C#, and that's great until an exploit like log4j comes out and affects everything running Java. But it also got patched pretty quickly. There's a term in software development called "not my problem" lol... just make sure the libraries you depend on are actively maintained. Good luck in your educational efforts. School won't teach you everything, but it's a good way to get started. Keep learning every day.
WE HAVE A DISCORD NOW! discord.gg/WYqqp7DXbm
Is this Exploit still exist ? What is the cve ?
@TDS2023 Thank you! I appreciate the words! Glad you liked it 😊
@ytg6663 It is no longer exploitable, as it was fixed both within a WhatsApp patch (2.19.244), and within the android-gif-drawable library. Facebook reserved CVE-2019-11932 for this issue.
@@DanielBoctor Why do you speak with upspeak? its fvcking annoying
@@DanielBoctorcan this exploit happen anywhere other That's WhatsApp? I don't use WhatsApp?
Kinda cool, the principles of these kinds of low level exploits are not so different from how speedrunners achieve arbitrary code execution in old games, mess around with pointers until they point to the memory address of the code you want to run next, and they do this by exploiting glitches during gameplay
How to obtain bedrock in minecraft:
very cool, never thought about it like that
They're both the same thing. Both involve injecting code into memory by exploiting a vulnerability.
true
This was exactly my thought
as soon as i realized the gif struct had a function pointer it was over
LOOOOOOOOL that will do it
Hi bro,could you teacher me how to do it?
Genuinely, what a great explanation of the double free vulnerability! Really love the detail and this can be very useful for anyone getting into binary exploitation techniques.
For me this really solidified the basics I saw here and there, with a nice practical example
Thanks for the wholesome comment, it means a lot
@@DanielBoctor- Complicated exploit but well dissected. BTW you sound a bit like the male version of Christina Hall. hehe
do I really? I can't say I notice the resemblance myself lol. I'm glad your liking my videos, thanks for the support
@@DanielBoctor- Check out the way Christina Hall talks in her "Jacuzzi" commercial,. enunciating the end of words. lol
Good video.
the title however is misleading, it's not ANY android phone it's android phones that already have a malicious application installed and whatsapp, additionally the title implies that the exploit can be used right now, even though it was patched years ago by both whatsapp and android
I agree but it’s for the views and he deserves the views. Very well put video. Very informative.
@@AlienzOnlyBruhindeed
also i would argue that this is really just a whatsapp exploit because the reverse shell gained is just the same privileges as whatsapp is currently allowed by android, so access to all user files if the user ever had previously attached something in whatsapp and allowed the permission, also the "android gif library" isn't used by all android apps not by a long shot, it just happened to be imported into whatsapp's source code and be what whatsapp used to render gifs, there isn't any real priviliege escalation exploit here
@@AlienzOnlyBruhme when the judge asks why i robbed the bank
@@AlienzOnlyBruhI mean I'm disliking and leaving 34 seconds in lol
Amazing explanation! I like how you managed to dive pretty deep without making the video super long
One of the best explanations ever of an exploit that goes into technical detail!
You are one awesome fella thanks for the support
Well at the last second you took away its powers by explaining that the user would have needed to basically download a virus first. But I could see this working for a malicious company that creates popular apps with the goal being to use the app as the “virus” agent to get that local address saved and get the user’s phone number through a sign up or something. And with the local address and the phone number, sending them a gif on WhatsApp (if they have WhatsApp) would work. Seems like it would work best if you had a huge database of potential victims. Thx for explaining this stuff bro.
edit: I was wrong about how this works
It's actually a lot easier than that. I didn't mean to take away from the vulnerability too much. As mentioned in the video, the required memory addresses are constant values, and ONLY change during system reboots. Any application has access to these addresses.
An app would not even need to harvest the targets phone number, NOR send the user a GIF in the first place. It could merely craft the GIF itself, and save it to the phones file system locally. That's it. The next time the victim opens their media gallery in WhatsApp, the GIF will be rendered directly, without the need to even receive a message.
Thanks for watching, and I'm glad you enjoyed!
that's crazy bro lol sorry I misunderstood@@DanielBoctor
@@DanielBoctor But should the person run an old version of whatsapp or not to do this?
The vulnerability is actually 3-fold:
1. Android OS returning the same memory address twice after a double free
2. The android-gif-drawable library causing a double free in the first place
3. WhatsApp double parsing GIFs, enabling any real harm to be caused from the double free
You would need all three of these conditions to be present for this to be exploitable. Just using an old version of WhatsApp would not be enough, as both WhatsApp and the GIF library were both patched.
This wasn’t mentioned in the video, but the presented vulnerability is merely an example of what can be done. OP mentions that there are potentially more complicated methods to leak relative addresses allowing us to do ROP to mitigate read-only pages. Without getting too far into it, the deterministic way android handles double frees enables us to, within the same gif, leak a valid instruction pointer and then use different techniques with that executable memory location to execute our shellcode
"for whatever reason they're parsed twice" sounds like intentional backdoor to me.
More like a 'performance bug' or some thumbnail generation, etc... Let's say you wanna show the first frame of the gif as a preview and the user should tap on the image to actually start playing the gif. You can do it different ways but it is easy to image they choose a method to reread the gif twice. First to acquire an initial frame and a second time when the user want to play the gif.
How the researcher discovered gifs were rendered twice in whatsapp is very interesting. I mean i know some people who does reversing on major android apps or iphone app ipa files but i dont know they do the research with that depth of knowlege.
Fantastic video Daniel, I cant wait for the next video!
Thank you
Your videos are great! Thanks so much.
Thanks! Glad you liked it 😊
I like the way you explain, it's amazing and interesting, thank you. 👍🏻
I'm glad you liked it! Means a lot
Great comparison between these two channels, got me thinking more about my upcoming videos.
And I have asked my self the question you end on I just need to make it more clear who I'm targeting in my titles
What a GOAT!!! The way you edit the videos to match as you explain is amazing, specially the “under the hood” explanations! Legend in the making
THANK YOU INIVEK ❤️❤️❤️❤️❤️❤️
Your intonation has "burger king foot-lettuce" vibes 💀
yeah ik but I think i finally fixed it in my most recent video
Awesome video🔥 RCE is so cool, tnx for explaining everything!!
I really is lol. Glad you have you here! Thanks for the kind words, keep on doing what you're doing 😊
I went to college in 1990, and they were still teaching C for first year programming. Java was still new to the game, so you had a choice of Pascal or C. I remember the professor told us that after the 3rd week we can expect half the class to drop. The 3rd week is when he introduced pointers. He wasn't wrong. This is a great video that helps illustrate the concept behind pointers. I think part of the problem was the professor, but I wasn't going to say anything. I taught myself assembler when I was 14, so pointers to me were already natural and I had no issue understand them. Half the class struggled immensely and wound up dropping before the first mid-term.
I'm going to hack my own self to understand more of this
epic video, didn’t understand it much but it was cool, maybe even better than your previous one
LOL, it do be like that sometimes
I think a malicious actor must've hacked your voice box and spammed question marks all throughout your sentences.
Underrated comment 😂
😆 in 2020 ppl were saying they'd leave the USA if Trump was elected. I'm ready to leave to get away from the valley girl accent that's so popular with the hipstERS & liberal medIAAA.
😣🔫
It’s pronounced “Jif” like the peanut butter according to Steve Wilhite, creator of GIF.
MAN YOUR CHANNEL IS INTERESTING! KEEP IT UP!
THANK YOU!!! GLAD TO HAVE YOU HERE 😊
Damn as a Cybersecurity reasercher this video was dope!
Interesting, but a six-year-old vulnerability is not "zero-day."
can u tell me the best way to install malware in someone mobile without click
Would the reverse shell and commands sent to it have the same permissions as Whatsapp in this case?
It would. All commands would be executed within WhatsApp context, allowing one to steal files from the WhatsApp sandbox, including the message database, as Awakened mentioned in his original report. I should have explained this in more detail within the video.
Just found your channel. Great stuff!!
Glad to have you here!
Great video. Looking forward to seeing future content.
Glad you liked it! More is on the way 🚀🚀🚀
amazing video and very interesting topic, this deserves way more attention! you have my sub, keep up the good work!
Thank you! Glad you have you apart of the community
You did a very solid job explaining everything. That's awesome man, ty for the vid
Thank you for being apart of it! Glad to have you here 😊
Heck yeah~ this made me curious what other kind of exploits there are, so I start to look at the standard linux kernel 6.6 and instantly I noped tf out of there
Not because I wouldn't eventually be able to get a grasp on the madness that's called code (tho it is organized), but because I already have too many coding projects lol
@@DanielBoctor
I'll fix the title for you "This GIF can't Backdoor ANY Android Phone"
good for me that i understand C lingo. this is so cool to know.
The thing about double free is that it allows you to edit a free chunk, in glibc (I am not sure if its in android kernel) free chunks are linked via fd & bk pointers which is pretty much a double-linked list (this also depends on the size of the free chunk which is categorized to which bin list) , modifying these pointer in a free chunk can allowed you to malloc in arbitrary address since malloc related operation retrieve chunks in the free list if exist rather than creating a new one
The people that find these are on another level 🧠
I know, it really is incredible 🤯
Am I missing something? Reallocing with size 0 should never return the same pointer? (as mentioned in 5:15)
I see, sorry for the confusion! To clarify, under regular circumstances in a regular environment, this is absolutely correct, as mentioned @ 4:35.
It is Android itself that caused the predetermined realloc behaviour, as mentioned @ 5:00 and 5:30.
The vulnerability is actually 3-fold:
1. Android OS returning the same memory address twice after a double free
2. The android-gif-drawable library causing a double free in the first place
3. WhatsApp double parsing GIFs, enabling any real harm to be caused from the double free
You would need all three of these conditions to be present for this to be exploitable. The Android behaviour you are pointing out is actually contributing to the exploit (which should NOT be happening).
@@DanielBoctor Sorry, it might be that my question was unclear. As per standard realloc should always return a pointer, that can be passed to free/realloced with size 0.
That means that, as long as you use the pointer returned by realloc (and don't reuse the pointer you passed to realloc) you could call realloc infinitely often.
Even with size 0.
@@DanielBoctor ooh, I looked at the commit that it was patched. The problem is, that realloc returning NULL is valid behaviour for size 0 realloc. This however gets interpreted as an error bc of low memory. In that case, the pointer doesn't get updated and will be passed again to realloc the next frame (but it was already freed).
Similar to how originals of edited jpeg images were recovered in an exploit that manipulated leftover space inside a buffer to reconstruct the bits of the original. For the most part you would recover only the later bits corresponding to pixels of the original because of how the file would be saved coupled with the top-down rendering of your device. The jpeg once saved after editing/cropping/redactions could therefore still have the information, but this gif exploit would basically take that one step further in regards to abusing the rendering method, by re-filling up the empty space with (insert any smol footprint exploit payload)
And the beauty of gif, is that can be looped. Which can also be a bigger issue if the gif allows itself to talk directly into terminal with certain commands. Persistence can be achieved and hidden (in perpetuity) if done correctly.
Classic, not the first time realloc breaks something
yup, gotta love C
I love the technical details usually you.dont get to see such detailed explanations for needs like us . Thkx amazing content
Glad you liked it!
We should really start thinking about virtualizing apps on every platform...
More virtualization needs more memory
@@25_26 you'd think we have plenty... I wouldn't mind spending extra $50 knowing my phone is secure
Maybe I'm stupid, why does it let you define a zero width/height? What possible use case would that serve?
Honesty theses people who found this vulnerability first are very consistent
Is there a version of this gif that just roots your phone without the need of reinstalling the entire OS and losing your data?
I always wonder why nobody uses exploits like this to just make easy no-fuss rooting tool.
That'd be great
Even temp root would be better than nothing. I would settle for google cloud app data backups that work.
It's pretty darn easy to root, people just want to use the most latest devices, which some are currently not root able. Like us verisons of Samsung phones but European verisons are able to root because of unlocked bootloader. The one plus series are the most easiest to root even the brand new one.
@@Slowburnripz I think a distinction should be made between actual rooting, which lets you access all your own info / hidden app data / etc, and bootloader unlocking, which explicitly deletes it.
@@Slowburnripz Not if you want to keep your files on the device though. Also "easy" is relative, since all known methods require you to install some weird software and connect your phone to your computer.
Ideally EU or some other entity would enforce a single click root for all the devices. Why is there no switch in the Android's menu to easily root phone, similar to "developer settings" one is beyond me.
I remember when a picture would backdoor any android phone..ahh how the times have changed
damn thats sick, love your content. its really hard to find videos this detailed.♥
THANK YOU ♥
Holy crap. This is very elaborate!
6:27 any number greater than 21 to trigger realloc condition, right?
Great video btw!
Your explanations are easy to follow despite the complexity of the topic!
I waited all the way to the end to find out I couldn't do this to myself to give me root.
Really good video!
Thanks! Glad you liked it 😊. Keep on spreading that positivity
Commenting for the algorithm. Love the low level explanation of these vulnerabilities.
My first 'commenting for the algorithm' comment LOOOOOOOL. Thank you for the support!! Means a lot 😊
10:18 did the attacker write the gadget or was it already written?
Are x0, x8, and x19 registers or mem addresses?
Would x19 need to be the address of frame 1 / gif info?
You said function pointer and I literally went WHAT IN THE LIVING SECURITY HOLE IS THIS SHIT
Needed to say no more, I instantly understood the gravity of this exploit
yep, that will do it LOL
Nicely explained!
Thank God! I never used WhatsApp!
"this gif can backdoor any android phone!*"
* as long as the phone is this specific model made between these 2 specific dates with this specific version of android and needs to have this specific version of a specific app installed and needs a cosmic ray to flip a specific bit in a specific part of memory at this specific time
or at least that's how I see most "brand new 0 day 0 click (some other fancy words) exploits that will kill your dog"
Sometimes, but first of all if you spread it to thousands of devices you're going to hit a lot, and second of all this one just needs your firmware + whatsapp version to be older than newest.
But I have to admit this shell is pretty much useless without privilege escalation
Very informative.
Thanks!!
I wonder why they changed that instead of leaving it as it was in upstream
Assembly, memory allocation, graphics programming, for an attack? Are you kidding me? Who is going to go for all this trouble?
It has to be some government or a large interprise.
Amazing explanation
Thank you
Can this exploit work on other messaging application that are not patched yet ? and where i found that gif exploit.
Does comp sci teach that the word asterisk is asterix or something. Beautiful video. Smart lad, amazing explanation, clearly understand hardware and software and programming languages super well. And then asterix. You get my sub, but my question as well.
LOL, didn't really think of the pronunciation while I was filming. Thanks for the feedback!
What if I want to use Obelix instead?
but it will not give you root access, only sandboxed access to the application that has the rce, which makes it pretty much useless.
there needs to be another step before an attacker gets access to your phone, it needs a root shell.
great video ! thanks for it !
Thanks!! Glad you have you here!
Reminds me of those funny adult ads in gif format..
10:16 is 0x00 thru 0x8F frame 1 of the gif? But the gif is 8x21 = 168 bytes and 0x00 to 0x8F represents 0x90 bytes, i.e. 9x16 = 144 bytes, right?
great and clear explanation
Thanks! Means a lot
ROP is certainly a fun way to program.
But doesn't this exploit require the page where the gif is stored to have code execution access? and it most likely will only have read-write
awesome video with clear explanations thank you
I don't know why I clapped when I finished watching the video. What an amazing explanation. Im still learning but this was a lot of fun!
What a wholesome comment LOL. Means a lot
Did you absolutely have to select the valley girl voice for the narration?
bruh this is like 2022 gif incident on discord ... reboot
Okay, but isn't toybox something the victim has to already have installed? I mean, most people don't install shells on their android phones.
boy i have news for you... Android is literally a Linux distro. It comes with toybox in all versions since Android 6, where it serves the same function that " *GNU coreutils* " does on _most_ other Linux distros. This exploit is technically an exploit in *WhatsApp* and that "android gif library" it uses, which is not used by all apps. Since it's a Java library implemented partly in C, ironically it would be more likely to be used by apps written mostly in Java than apps written mostly in C and C++, which would be more likely to use older, more robustly tested C libraries. Contrary to whatever else you might also have heard, no not all Android apps are 99% Java, many apps are more like 5% Java 95% other stuff.
@@tacokoneko okay, i thought it's some alternative to busybox.
amazing, it's sooo old school tech movie getting control of a device with a gif... I can't beleive it hahaha
What about grapheneos?
Maybe that's why they needed a hardened memory allocator... I suspect this would not affect it, plus upstream has been updated anyway. Can't say with certainty though.
ah its crazy internation dude 🎉
I couldn't understand this even if this was drawn and explained to me 1 million times in a row.
Wow that is brilliant!
I know lol 🤯
Fadcinating to hear music made by one UA-camr (lemmino's cicaida) in another UA-camr's video
Yep, he posts all of his music publicly and lets other creators use them. Gotta love LEMMiNO. It's credited in my description too - I used 2 of his songs in this video.
Wow, awesome 🙂
This GIF COULD.. thank you very much...
It seems like rather than backdooring ANY Android phone it can only backdoor phones with both WhatsApp AND a second, specifically malicious app already installed?
That's why I use Signal and Matrix, and I have any auto download media disabled on my phone.
so to get this vulnerability which allows you to gain access to the phone, first you have to gain access to the phone to get the function addresses, got it
What the hell is an executable function pointer doing in a GIF info structure?
LEMMiNO background music is 🔥
I couldn't agree with you more. LEMMiNO is the GOAT.
We got to love the clickbait...
11:26 A malicious application installed on the victim's phone is sufficient for RCE
Should have went into more detail on this. In this case, the RCE would be within WhatsApp context. One could read files from the WhatsApp sandbox, including the message database, as Awakened mentioned in his original report. A separate application would only have its own perms, making it of little real value. This can almost be thought of as privilege escalation in a way.
I'm FREE! FREE! Oh crap, its a double free statement.
Wow i didnt understand anything but it was very informative , thank you
I think the background music is taken from Lemmino channel.
It is! He puts out all of his music on a creative commons 🤯. You'll always find the specific ones I used in my description 😊
Bro a reverse shell zero day by gifs
Can you disable automatic GIF looping in Whatsapp as a workaround?
I don't use FB or Whatsapp
Honest feedback - I can only stand this with captions and sound off. The 'speaking up' intonations are intolerable.
I agree. I couldn't even make it through the video with every sentence sounding like it was a question. Also known as "High rising terminal." I will try your suggestion and just read the captions next time.
Thanks for this. It was noted in my previous video as well. I wasn't really conscious of it when I filmed this video - still pretty new to all of this. I'll try and correct this going forward.
@@DanielBoctor You do you and don't necessarily try and please the masses dude. I just wanted to give honest feedback :) Your content is good.
I was very interested in this material but also had to scan the comments to see if anyone else noticed this. Nice to see the creator of the video be thankful for the feedback. Respect.
So glad I didn't have to make the comment. I've never came across a male doing this. He must've spent a lot of time with women or something. I don't think people naturally talk this way, they usually pick it up from someone else. What came first, the chicken or the egg. 😂
Call me dumb or ignorant but why is it even allowed to have exactly one dimension be 0? Wouldn't you need two integers of at least 1 to even display anything?
As I understand it this bug would be a non-issue if there's only one possible "aspect ratio" (if you can even call it that for 1-dimension) involving 0.
The fix could literally be (pseudo-code)
if(height0);
assuming we derive a binary (single digit) boolean from the arithmetic operation denoting if the other dimension exists/>0 with either 1 or 0, we can just multiply it (dunno if it's actually faster with the if, otherwise replicate the last line switching height & width).
This smells like a engineered backdoor. Too many "very strange" triggers, that would make no sense to have in the code to begin with.
lol why did they re-implement rendering a gif anyways?
seems intentional.
Hey what's the CVE number of this exploit?
Facebook reserved CVE-2019-11932 for this issue.
If the data is sandboxed it should not be a problem right something like grapheneos should be able to deal with this.
#Intriguing
would this fall under software development and\or IT Security?
I ask because I am looking to invest into a second major; and I very much would like to learn how to read and write computer code.
Thank you.
IT security is probably going to focus more on firewalls, network monitoring, toolkits that you can deploy as an network admin, that kind of stuff. Writing code that uses malloc and free properly is going to be a software engineering issue, or maybe computer science. Every software developer needs to have a basic understanding of the most common security exploits and how to avoid them. It helps if you use a language that does not require you to manage malloc() and free() yourself. C is great for things like embedded systems, but you have to be very careful. C++ is better imho, because you can use paradigms like RAII, where you release resources and free memory in destructors, you have standard containers that allocate memory for you, so you really don't have to touch new/malloc and delete/free that often. Of course the evangelical memory safe language is Rust, and you will find no shortage of people to tell you why... there's also garbage collected languages like Java and C#, and that's great until an exploit like log4j comes out and affects everything running Java. But it also got patched pretty quickly. There's a term in software development called "not my problem" lol... just make sure the libraries you depend on are actively maintained.
Good luck in your educational efforts. School won't teach you everything, but it's a good way to get started. Keep learning every day.
How is a Human able to find such a specific interaction of multiple exploit? Do they really search for them or do they find them by chance?
Basically by guessing from experience what can happen and then trying everything.
And of course you can also analyse the actual code.