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.
I know that if you craft your buffer overflow just right it will overwrite other parts of memory with the new function.
But how do you know what parts will get overwritten?
Does that mean the new function can do almost anything?