Hacker News Reader

Comment by RavlaAlvar | Hacker News Reader

Does anyone have any technical detail of that story. It is hard to imagine how a bug in the image parse library can be utilise to steal text message.

View on HN

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.

https://www.okta.com/blog/2020/04/what-the-jeff-bezos-whatsa...

Does anyone have a "explain it like I'm 5 but took some CS classes back in college"?

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?

There are multiple techniques that might be used (and countermeasures that might have to be bypassed) but these links should get you started -

https://stackoverflow.com/questions/14760587/how-does-a-nop-...

https://stackoverflow.com/questions/49620893/return-into-lib...

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.

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.”

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.

5) Send to Bezos.

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.

> 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.

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

oh bugs in the parsing libraries are the things MOSTLY used for attacks like this.

Parsing is hard, and parsers are buggy and lead to all kind of unsafe C code

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.

It starts with a buffer overflow. This then will allow you to execute your own code.

Reply on news.ycombinator.com