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

141–150 of 159 posts

Re: WhatsApp Remote Code Execution in Video Call

#141

Post by pjmlp »

nicoburns wrote: post #96
ianbutler wrote: post #83

Earlier quoted context omitted.

I think that’s true of all software, people are fallible open source or not. I’d love to see average time to discovery and reporting in closed versus open source though. I’ve always heard it’s better in open source, which intuitively makes sense, and by the nature of closed source I think gathering the data will be challenging but valuable to see a tight comparison.

It's definitely a lot better in memory safe languages (and especially in those applications that don't depend on C libraries under the hood). You can still have security bugs due to logic errors, but you won't ever get remote code execution or ability to read arbitrary memory. And in general bugs are much more likely to cause a crash rather than give the attacker access. I suspect once C has been supplanted all the w…

C should have been kept as a more type safe than a raw macro assembler.

The problem is that many think they need to write their application using a macro assembler to this day.

Actually, macro assemblers are better than C regarding security, because they don't do optimizations that wipe out code sections.

Re: WhatsApp Remote Code Execution in Video Call

#142

Post by fulafel »

Forbo wrote: post #69
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?

Negligence as a term implies liability. But there's mostly no liability in software for some reason.

Re: WhatsApp Remote Code Execution in Video Call

#143

Post by selfmodruntime »

nyanpasu64 wrote: post #101

Out-of-bounds indexing is always fun. I'm interested in programming languages with mostly-watertight spatial memory safety, which can prevent many exploits at a minimal ergonomic/flexibility cost, compared to temporal memory safety which requires a borrow checker and endless compiler complexity (plus I find it easier to statically verify you don't use-after-free in the limited code interacting with resource lifetimes…

Any language can implement safe vector / array accessing with a `get` call returning either a sum type of throwing an exception when the element does not exist at the index.

Quite frankly, manually indexing into an array should be entirely avoided if possible, even more so with safety critical software.

Re: WhatsApp Remote Code Execution in Video Call

#144

Post by selfmodruntime »

yjftsjthsd-h wrote: post #113
orangepurple wrote: post #51

Earlier quoted context omitted.

"sketchy c code" is a tautology

No, OpenBSD and sqlite exist; "sketchy c code" is only mostly redundant.

Sqlite has had multiple CVEs featuring use-after-free, heap overflows, usage of null pointers, use of uninitialized memory, and array bounds overflows. [1]

Those could all be avoided by not using C.

[1]: https://www.sqlite.org/cves.html

Re: WhatsApp Remote Code Execution in Video Call

#145

Post by roastedpeacock »

gunwithdots wrote: post #32

On this subject, I like to quote Pavel Durov, the founder of Telegram: "Since the creation of WhatsApp, there's hardly been a moment in which it was secure: every few months researchers uncover a new security issue in the app. I wrote about this in detail 2 years ago (read here if you missed it). Nothing has changed since then. It would be hard to believe that the technical team of WhatsApp is so consistently incompe…

No one remember how Telegram likes to reinvent the wheel with their encryption and raise subtle implications that Signal is magically backdoored?

For starters: https://nitter.net/durov/status/873870658874355713

Re: WhatsApp Remote Code Execution in Video Call

#146

Post by GoblinSlayer »

danielheath wrote: post #128
mattnewton wrote: post #118

Earlier quoted context omitted.

That sounds like a huge hit to energy use, if it is even feasible for something like implementing webrtc because of communication costs with the native process.

Hrm. If you had a specific WASM engine embedded in the app, you might be able to get it to precompile the bytecode (to avoid violating the runtime modification policy); that might be low-enough overhead (since you also control the communications layer & could make it cheaper).

Video decoder in bytecode?

Re: WhatsApp Remote Code Execution in Video Call

#147

Post by UncleMeat »

javajosh wrote: post #132
UncleMeat wrote: post #93

Earlier quoted context omitted.

Lots of people have attempted this sort of analysis. You can find attempts at this in ICSE of FSE or whatever. But frankly there is no way to make effective science out of this. All of the data are always messy and make huge compromises to get anything even close to resembling an apples-to-apples comparison. I don't believe that anybody who claims it is meaningfully better in open source has any actual data really ba…

Seems straightforward to compare open-source vs closed-source bug fix performance. The tricky part is adjusting for size. "Many eyes make all bugs shallow" but I wonder how many eyes are on the typical random java library that's been built into Spring Boot forever and no-one even thinks about anymore (there are probably 30+ of these). How often does any company using Spring Boot, even the very security conscious ones…

> Seems straightforward to compare open-source vs closed-source bug fix performance.

You can publish a best-paper in ICSE if you could pull this off. There are so many things that make this challenging. For starters, we don't even have the ground truth for what bugs exist. Even just looking at bugs we've already skewed our process dramatically based on the various different development processes of different projects.

You are right to question how many eyes are on typical random libraries. The answer is zero. Even huge libraries have extremely few eyes on them. When it comes to "many eyes" it is actually basically just the linux kernel and a very small number of other projects that get this sort of attention. The large majority of all open source projects, even those used by millions of projects, get zero meaningful attention beyond "hey I threw my tool at everything on github and spammed owners with nearly useless reports."

Re: WhatsApp Remote Code Execution in Video Call

#148

Post by UncleMeat »

nicoburns wrote: post #116
UncleMeat wrote: post #109

Earlier quoted context omitted.

It is true that memory-safe languages are a massive massive massive boon! I believe that the entire industry needs to be making plans to find a way to shift all applications that operate on untrusted data away from C and C++. But this is completely orthogonal to the purported security benefits of making your source available.

IMO it’s not entirely orthogonal. One of the main benefits (from a security perspective) of open sourcing your app is to allow it to be audited more thoroughly. But even with that kind of auditing it’s hard to make thing secure in non memory safe languages. If you have both, then we might expect open sourcing to more reliably lead to an actually secure app.

I don't understand. Is the idea that memory errors are too hard to find but that once we've eliminated them at the language level that now auditors can review OSS projects effectively to verify that they are free of vulns? log4j should be a very clear example of how that'll fall over.

Re: WhatsApp Remote Code Execution in Video Call

#149

Post by GoblinSlayer »

nyanpasu64 wrote: post #101

Out-of-bounds indexing is always fun. I'm interested in programming languages with mostly-watertight spatial memory safety, which can prevent many exploits at a minimal ergonomic/flexibility cost, compared to temporal memory safety which requires a borrow checker and endless compiler complexity (plus I find it easier to statically verify you don't use-after-free in the limited code interacting with resource lifetimes…

It's easier to name languages without ergonomic bound checks: Assembler and C. They were done in STL for ages, but only in debug mode, which makes them useless, but it's not a technical problem.

Re: WhatsApp Remote Code Execution in Video Call

#150

Post by GoblinSlayer »

flatiron wrote: post #117
yalogin wrote: post #110

What is the impact of this vulnerability? I don’t see what an attacker can do if they successfully exploited this. Since this is in a bundled library does it help me get past the iOS sandbox for example? If so can one steal WhatsApp keys? What is the fallout, does anyone know?

It runs as whatsapp so if you allowed it access to photos, location, etc you gain that. Very powerful stuff.

And message history.
Post reply on HN