Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

WhatsApp Remote Code Execution in Video Call

nvd.nist.gov

Post reply on HN
Print view View original

61–70 of 159 posts

Re: WhatsApp Remote Code Execution in Video Call

#61

Post by marcodiego »

5d8767c68926 wrote: post #22
gengear wrote: post #21

Earlier quoted context omitted.

even if you compile yourself you can't be sure. [Reflections on Trusting Trust ]( https://www.cs.cmu.edu/~rdriley/487/papers/Thompson_1984_Ref... )

Has that attack ever been observed in the wild? While I don't know if the current incarnations of Nix/Guix will succeed, I think we are slowly making progress towards reproducible builds everywhere.

> Has that attack ever been observed in the wild?

Yes: https://www.quora.com/What-is-a-coders-worst-nightmare/answe...

Also, I remember in the 90's, people talking about a virus that infect pascal source code files. Memory is spotty about it.

> While I don't know if the current incarnations of Nix/Guix will succeed, I think we are slowly making progress towards reproducible builds everywhere.

Fortunately, the answer is also positive here.

Re: WhatsApp Remote Code Execution in Video Call

#62

Post by isp »

jaywalk wrote: post #35
beefield wrote: post #29

Earlier quoted context omitted.

Install Whatsapp on a virtual android on your computer?

Can virtual Android simulate your phone number?

It doesn't need to.

The WhatsApp authentication SMS message can be sent to your (real) phone, and then manually transcribe the auth code into WhatsApp on the Android VM.

I did this for a while.

Re: WhatsApp Remote Code Execution in Video Call

#63

Post by UncleMeat »

marcodiego wrote: post #55
UncleMeat wrote: post #30

Earlier quoted context omitted.

Being open source doesn't actually save you from exploitable vulns related to integer arithmetic.

I enables independent, non-involved, non-interested parties to check it. Also when the protocol is open, it enables multiple implementations; keeping a known-by-few trojan style bug in all of them is specially difficult.

That's true. And yet, the linux kernel consistently has bugs like these in it. If you want exploitable vulns in literal media codecs go have fun taking a look at the history of ffmpeg.

I love open source. In so many ways it is uniquely responsible for the development of our technology landscape. It is observably not a meaningfully different path to secure code than closed source development.

Re: WhatsApp Remote Code Execution in Video Call

#64

Post by mhoad »

kingnothing wrote: post #31
nonasktell wrote: post #26

Earlier quoted context omitted.

if you can't trust Meta, why could you trust apple?

Apple has been building their brand on privacy and trust for at least a couple of years now. Can you be sure they're not sending everything to the NSA? Of course not. But they also make their money by directly charging users for services unlike the ad-based companies. There have also been many attempts by various governments to publicly force Apple to insert backdoors or prevent them from fixing security vulnerabilit…

I really need you to understand the difference between their marketing claims and reality. Apple is really not the champion for privacy they claim to be beyond the extent that they can try and hurt Google in their marketing.

Re: WhatsApp Remote Code Execution in Video Call

#65

Post by omniglottal »

UncleMeat wrote: post #53
LtWorf wrote: post #46

Earlier quoted context omitted.

It saves you from obviously planted ones that can be found by code scanners.

Is there any evidence that this overflow was easily found with straightforward static analysis?

Seems you might be missing a key point - see, without transparent, open access to the source code, there is nothing easily found. At a certain point, if a murderer keeps "losing" the murder weapon, you might consider the evidence you find to be that of criminal obstruction. There is evidence that everything is more easily found when it's not hidden, obfuscated, or obstructed.

Re: WhatsApp Remote Code Execution in Video Call

#66

Post by marcodiego »

UncleMeat wrote: post #63
marcodiego wrote: post #55

Earlier quoted context omitted.

I enables independent, non-involved, non-interested parties to check it. Also when the protocol is open, it enables multiple implementations; keeping a known-by-few trojan style bug in all of them is specially difficult.

That's true. And yet, the linux kernel consistently has bugs like these in it. If you want exploitable vulns in literal media codecs go have fun taking a look at the history of ffmpeg. I love open source. In so many ways it is uniquely responsible for the development of our technology landscape. It is observably not a meaningfully different path to secure code than closed source development.

The difference in "who you have to trust" is reason enough.

Re: WhatsApp Remote Code Execution in Video Call

#67

Post by UncleMeat »

omniglottal wrote: post #65
UncleMeat wrote: post #53

Earlier quoted context omitted.

Is there any evidence that this overflow was easily found with straightforward static analysis?

Seems you might be missing a key point - see, without transparent, open access to the source code, there is nothing easily found. At a certain point, if a murderer keeps "losing" the murder weapon, you might consider the evidence you find to be that of criminal obstruction. There is evidence that everything is more easily found when it's not hidden, obfuscated, or obstructed.

Sure. It is easier to throw an off the shelf analysis at source than worrying about binary decompilation with ghidra or whatever (well, for binaries - for bytecode it is almost exactly the same when given bytecode or source). But is this a meaningful difference? Real researchers, both academic and non-academic, do inspect open source code and report vulns they find. But this isn't actually actionable information from the perspective of a user who wants to make a risk assessment about their software choices. "Hey, you can run ${STATIC_TOOL} on this app" does not actually convert to "app is free from vulns." It just doesn't.

I love static analysis for vuln detection. I did my PhD on it. It remains my day job. It helps us find vulns. It doesn't actually convert us from unsafe software to safe software.

Re: WhatsApp Remote Code Execution in Video Call

#68

Post by UncleMeat »

marcodiego wrote: post #66
UncleMeat wrote: post #63

Earlier quoted context omitted.

That's true. And yet, the linux kernel consistently has bugs like these in it. If you want exploitable vulns in literal media codecs go have fun taking a look at the history of ffmpeg. I love open source. In so many ways it is uniquely responsible for the development of our technology landscape. It is observably not a meaningfully different path to secure code than closed source development.

The difference in "who you have to trust" is reason enough.

If your concern is about deliberately inserted exploits by the WhatsApp developers, that's got virtually nothing to do with the topic at hand.

Re: WhatsApp Remote Code Execution in Video Call

#69

Post by Forbo »

alskdjflksjdf wrote: post #2

funny how all the whatsapp advisories since 2019 just move the same vulnerability around. Always an innocent stream processor missing a bounds check. Ooops.

I noticed the same thing with Cisco vulns a while back. How many times do you hard code credentials before it becomes an intentional backdoor rather than negligence?

Re: WhatsApp Remote Code Execution in Video Call

#70

Post by dagmx »

saddlerustle wrote: post #37
mgraczyk wrote: post #13

Since the issue was in both the iOS and Android versions of the app, and it was caused by an integer overflow, does that mean that the bug was in a bundled C++ library implementing webRTC? Is there any information about the source-level cause of the issue?

Notably on iOS there's no good way to isolate unsafe native libraries from the rest of your app without violating app store policies, because Apple enforces apps to be single process and doesn't allow use of its own sandboxing apis.

I believe you’re able to use XPC Services to achieve that no?

Edit: actually no, XPC Services are Mac only so wouldn’t help on iOS.

WASI would be the closest thing to a secure runtime

Post reply on HN