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

‘Zero-click’ hacks are growing in popularity

bloombergquint.com

Post reply on HN
Print view View original

321–330 of 408 posts

Re: ‘Zero-click’ hacks are growing in popularity

#321

Post by InvertedRhodium »

Tanjreeve wrote: post #309
tptacek wrote: post #278

Earlier quoted context omitted.

Start with the fact that practically all software development at Apple and Google would cease for multiple months while people dealt with the Rust learning curve, which is not gentle, and proceed from there to the fact that Rust demands (or, at least, urgently requests) architectural changes from typical programs designed in other languages. Now: rewrite 20 years worth of code. Let's make sure we're clear: I agree --…

When you say architectural changes how do you mean? Most of the memory stuff isn't particularly exotic there's a lot of different syntax/Functional programming influences but I'm curious why it would be wildly exotic compared to most C++ code or have I misunderstood?

It doesn't matter how exotic something is when you're taking about rewriting an entire platform - the sheer amount of man hours required to reimplement something for an advantage the vast majority of customers simply don't value enough is the limiting factor.

In that context, even a small architectural difference can be seen as a high barrier.

Re: ‘Zero-click’ hacks are growing in popularity

#322

Post by parentheses »

xavxav wrote: post #45

Not to go all 'Rust Evangelism Strike Force' but almost universally, these exploits leverage memory unsafety somewhere in the stack, usually in a parser of some kind (image, text, etc). The fact that this is still tolerated in our core systems is a pox on our industry. You don't have to use Rust, and it won't eliminate every bug (far from it), but memory safety is not optional . We truly need to work more towards eli…

the core problem is trusting a byte you read and use to make decisions. this is the superset of memory safety and not protected against by any language as of now.

let’s kill bytes. :P

Re: ‘Zero-click’ hacks are growing in popularity

#323

Post by shukantpal »

e40 wrote: post #269
tuwtuwtuwtuw wrote: post #266

Earlier quoted context omitted.

Forcing their employees to learn rust doesn't mean Google has the capacity to rewrite all their software in rust. They have tons and tons of code which would need to be rewritten from scratch. Of course if they dropped all other development and told their employees to rewrite to rust, they may end up with a piece of software written in rust but no customers.

I agree, but there's so many people at Google (132,000 if you can believe the search results), it's hard for me to believe they couldn't devote a small percentage of them to moving to a secure stack.

And you don't realize their codebase must also be really large like their number of employees. They must have a lot of code per employee.

Re: ‘Zero-click’ hacks are growing in popularity

#324

Post by fsflover »

bastawhiz wrote: post #254
fsflover wrote: post #20

Qubes OS defends even from such attacks: it doesn't show non-ASCII symbols in window titles in dom0: https://www.qubes-os.org/doc/config-files . I think this OS deserves more attention. By the way, new version 4.1 is out: https://www.qubes-os.org/news/2022/02/04/qubes-4-1-0/ .

If you have so little faith in your system that Unicode characters will lead to an exploit that you block them in window titles, your problem isn't Unicode, the problem is your code that processes and renders it. You still have a problem, you're just making it the user's burden to bear.

You should not have faith in software. You should verify and isolate.

Re: ‘Zero-click’ hacks are growing in popularity

#325

Post by falsenapkin »

abecedarius wrote: post #225
falsenapkin wrote: post #123

Earlier quoted context omitted.

It's baffling that they won't at least disable previews for senders not in your contacts. Ideally they would provide a way to block certain types of senders outright. I will NEVER want to receive an iMessage from an unknown email address, but that's where all of the spam crap comes from. Recently I was on my phone when I received an email address iMessage and the toast showed an absolutely insane link, when I opened…

Does it solve this to set a different app as your default app for texts? (Hopefully a more secure app.)

I want to trust Apple more than a random 3rd party app in general but regardless I don't think you have an option for alternate SMS on iOS. Anyway the problem here, I think, is that you can somehow send an iMessage (not SMS?) via an account that is backed by an email address instead of a phone number. So even if texts/SMS could have an alternate app, iMessage would still be accepting messages from bad accounts.

Re: ‘Zero-click’ hacks are growing in popularity

#326

Post by assttoasstmgr »

phendrenad2 wrote: post #243
xavxav wrote: post #45

Not to go all 'Rust Evangelism Strike Force' but almost universally, these exploits leverage memory unsafety somewhere in the stack, usually in a parser of some kind (image, text, etc). The fact that this is still tolerated in our core systems is a pox on our industry. You don't have to use Rust, and it won't eliminate every bug (far from it), but memory safety is not optional . We truly need to work more towards eli…

You don't know what you're asking for. In reality, you'll end up replacing C code with memory unsafely with Rust code written by people who understand Rust less than they understand C. The problem? The Rust Evangelism Strike Force always assumes that if you replace a C program with a Rust program, it'll be done by a top-tier expert Rust programmer. If that isn't the case (which it won't be), then the whole thing fall…

I'm surprised no one has mentioned OpenBSD yet. Theo touches on this topic in this presentation: https://www.youtube.com/watch?v=fYgG0ds2_UQ&t=2200s

Some follow-up commentary: https://marc.info/?l=openbsd-misc&m=151233345723889

Re: ‘Zero-click’ hacks are growing in popularity

#327

Post by nickelpro »

radford-neal wrote: post #275
AlotOfReading wrote: post #245

Earlier quoted context omitted.

I brought up ASAN because it's a real thing that already exists and gets run regularly. The broad details of how ASAN is implemented are best summarized in the original paper [1]. The practical short of it is that there are essentially no false negatives in anything remotely approaching real-world use. A malicious attacker could get around it, but any "better algorithm" would still run into the underlying issue that…

From the linked ASAN paper: "...at the relatively low cost of 73% slowdown and 3.4x increased memory usage..." That's too big a performance hit for production use - much bigger than you would get with the approach I outlined. I don't agree that any nontrivial C program is nonconformant, at least if you're talking about nonconformance due to invalid memory references. Referencing invalid memory locations is not the so…

That's a low cost for detecting the memory unsafe behvior. It is not intended to run in production, it's intended to run with your test suite.

Re: ‘Zero-click’ hacks are growing in popularity

#328

Post by staticassertion »

tptacek wrote: post #228
xavxav wrote: post #45

Not to go all 'Rust Evangelism Strike Force' but almost universally, these exploits leverage memory unsafety somewhere in the stack, usually in a parser of some kind (image, text, etc). The fact that this is still tolerated in our core systems is a pox on our industry. You don't have to use Rust, and it won't eliminate every bug (far from it), but memory safety is not optional . We truly need to work more towards eli…

It's worth engaging with the fact that essentially nobody disagrees with this (someone will here, but they don't matter), and that it's not happening not because Apple and Google don't want it to happen, but because it's incredibly, galactically hard to pull off. The Rust talent pool required to transition the entire attack surface of an iPhone from C, C++, and ObjC to Rust (substitute any other memory safe language,…

You don't need to move the entire attack surface of the iphone to Rust. There are plenty of smaller areas that tend to have the most vulnerabilities. They could absolutely write a check to radically reduce these sorts of issues.

It'll take years to have impact, but so what? They can start now, they have the money.

> nobody disagrees with this (someone will here, but they don't matter)

There are so many people out there who don't understand the basics. HN can be sadly representative.

Re: ‘Zero-click’ hacks are growing in popularity

#329

Post by staticassertion »

phendrenad2 wrote: post #243
xavxav wrote: post #45

Not to go all 'Rust Evangelism Strike Force' but almost universally, these exploits leverage memory unsafety somewhere in the stack, usually in a parser of some kind (image, text, etc). The fact that this is still tolerated in our core systems is a pox on our industry. You don't have to use Rust, and it won't eliminate every bug (far from it), but memory safety is not optional . We truly need to work more towards eli…

You don't know what you're asking for. In reality, you'll end up replacing C code with memory unsafely with Rust code written by people who understand Rust less than they understand C. The problem? The Rust Evangelism Strike Force always assumes that if you replace a C program with a Rust program, it'll be done by a top-tier expert Rust programmer. If that isn't the case (which it won't be), then the whole thing fall…

> There are vulnerabilities in JS and Ruby code, languages that are even easier (and just as type-safe) as Rust.

This is completely misleading. The vulnerabilities that exist in those languages are completely different. They often are also far less impactful.

Memory safety vulnerabilities typically lead to full code execution. It is so so so much easier to avoid RCE in memory safe languages - you can grep for "eval" and "popen" and you're fucking 99% done, you did it, no more RCE.

Re: ‘Zero-click’ hacks are growing in popularity

#330

Post by closeparen »

tptacek wrote: post #228
xavxav wrote: post #45

Not to go all 'Rust Evangelism Strike Force' but almost universally, these exploits leverage memory unsafety somewhere in the stack, usually in a parser of some kind (image, text, etc). The fact that this is still tolerated in our core systems is a pox on our industry. You don't have to use Rust, and it won't eliminate every bug (far from it), but memory safety is not optional . We truly need to work more towards eli…

It's worth engaging with the fact that essentially nobody disagrees with this (someone will here, but they don't matter), and that it's not happening not because Apple and Google don't want it to happen, but because it's incredibly, galactically hard to pull off. The Rust talent pool required to transition the entire attack surface of an iPhone from C, C++, and ObjC to Rust (substitute any other memory safe language,…

Do you think Apple is already at the frontier of what can be done to detect or refactor out these bugs in their existing languages? Static analysis, Valgrind, modern C++, etc?
Post reply on HN