Sure, the blog post below covers it, and the vulnerability was probably CVE-2019-11931. You can do an awful lot with a buffer overflow if you're clever.
With a buffer overflow, you can write your own code into a chunk of memory that ends up being run by the application. In this case, since WhatsApp already had SMS read privileges as part of the signup auth flow, the attacker also had those privileges.
The article has some detail about the remote code execution part of this exploit.
“What this means is that there was a software flaw in the WhatsApp code for handling MP4 media files. If an attacker triggered the flaw, the function in question would crash in a way that could allow a potential attacker to gain “RCE” or Remote Code Execution.
In layman's terms, this means the attacker could inject his own code into the application and, by triggering the flaw, make the application to run with all the privileges and access of the WhatsApp application itself.”
> With a buffer overflow, you can write your own code into a chunk of memory that ends up being run by the application.
This is usually no longer the case in modern applications. So attackers instead string together short snippets of code from the application itself and jump around between them to basically do what they want.
So the payload would be some corrupted video file sent to Bezo's phone. Would the attack look something like:
1) Discover/buy/steal Bezo's Whatsapp number (how did they do that...)
2) Discover/buy/steal a 0-day bug in Whatsapp.
3) Write and compile a program that reads SMS from the OS and beacons it to some server you control.
4) Create a corrupted video file that would trigger the video parsing bug, and within that video file place the compiled program from the previous step in the correct place so that it gets executed.
Yes, that seems like a reasonable summary. (3) is the kind of thing that exploit developers will have "off the shelf"; (1) is probably available in a dump of private information somewhere.
And yes, arbitrary code execution is a common goal of these exploits, though it may not always be possible--sometimes you only get a DoS attack or such.
The classic buffer overflow has the buffer on the stack, near the return address, so you can just write a new return address and jump into the code you put in the buffer.
It's become more complex due to mitigation, but the general principle is the same.
It's even harder to imagine how someone could rewrite the code to Super Mario World on an unmodified SNES to play Flappy Bird just using regular controllers, yet it's possible: https://www.youtube.com/watch?v=hB6eY73sLV0
Exactly, parsers are complicated, generally involve a lot of manipulation of memory buffers, and for performance reasons are usually written in a language without memory safety (though this is starting to change with languages like https://github.com/p-org/P and rust).
Actually their pretty common. They are complex and generally fairly old interpreters that generally have system level access. Android have had a ton of them, but they are pretty universally common.
