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

351–360 of 408 posts

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

#351

Post by staticassertion »

greiskul wrote: post #350
foxtrottbravo wrote: post #140

Earlier quoted context omitted.

I was about to ask whether I'm missing something here. "Zero Click" just means no user interaction is required right?So from my Perspektive this is just another way of saying Remote Code Execution? There really isn't something new here other than a fancy name - or I am not seeing the point.

A non zero click remote code execution would be for example the attacker sends the victim a message, with a link or attachment, that if the victim interacts with it, the attacked gets to run code they wrote in the victims device. A zero click remote code execution, would be for example where the attacker send a message, and their phone just processing the message on it's own is enough for the attacker to execute code…

The terms are all stupid and were made up 40 years ago. Trying to tease out nuance is pointless.

You get owned without clicking hence zero click. Is it different from RCE? A subset? Doesn't matter. Title could have said RCE.

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

#352

Post by staticassertion »

bilbo0s wrote: post #38
simion314 wrote: post #21

Earlier quoted context omitted.

>People will still write apps. And those apps, probably upwards of 99.999999% of them will be unsafe. This can be avoided if you have a cross platform high level language like say C# with a big standard library like .Net , the field needs then to make sure the language and core library are safe, most programs use existing libraries and put some business logic on top, I remember that memory safety was a thing before R…

Respectfully, an enormous amount of work has gone into making sure things like Python, .NET, and Rust are secure. And the security researchers still regularly find bugs and sell 0-days. That's not even counting the work that's gone into the gold standard that is the JVM. Any serious minded security expert could tell you that guaranteeing security on any of these platforms is a sysiphean effort. Your platform is state…

> How does one provide 100% safe access to the GPU?

Presumably through pointer capabilities.

> The file system?

File system namespacing and virtualization.

I disagree with most of your assertions.

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

#353

Post by staticassertion »

emerongi wrote: post #258
phendrenad2 wrote: post #243

Earlier quoted context omitted.

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 think the only question that matters is how much longer it takes to write a moderately-sized program in Rust vs C. If it takes around the same time, then an average C programmer will probably write code with more bugs than an average Rust programmer. If it takes longer in Rust, the Rust programmer could start taking some seriously unholy shortcuts to meet a deadline, therefore the result could be worse. All code ca…

That assumes that writing unsafe code would make you go faster. It wouldn't. In general if you want to write code in Rust more quickly you don't use unsafe, which really wouldn't help much, but you copy your data. ".clone()" is basically the "I'll trade performance for productivity" lever, not unsafe.

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

#354

Post by freshpots »

toss1 wrote: post #299
ReptileMan wrote: post #235

Earlier quoted context omitted.

You have to be a special kind of naive to not have such infrastructure behind airgap.

Yup. And yet in most organizations, airgapping is an alien concept. Even for machine tools that could kill someone. Security vs convenience...

Airgapping didn't stop Stuxnet.

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

#355

Post by rosndo »

staticassertion wrote: post #338
rosndo wrote: post #47

Years ago we used to regularly have worms that’d infect millions of computers without any clicks at all. The truth is that “Zero-Click” hacks are becoming increasingly rare. But of course everything is new for journos unfamiliar with the field.

Yes, Chrome pretty much single-handedly changed that, timed well with Vista. For about a decade we got a reprieve because: 1. Memory safety mitigations became much more common (Vista) 2. Browsers adopted sandboxing (thanks IE/Chrome) 3. Unsandboxed browser-reachable software like Flash and Java was moved into a sandbox and behind "Click to Play" before eventually being removed entirely. 4. Auto-updates became the nor…

> And that genuinely bought us about a decade. The reason things are changing is because attackers have caught back up. Browser exploitation is back. Sandboxing is amazing and drove up the cost, but it is not enough - given enough vulnerabilities any sandbox falls.

It’s still a completely different world. We’ve come a long way from back when Paunch was printing money with Blackhole.

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

#356

Post by rosndo »

greiskul wrote: post #350
foxtrottbravo wrote: post #140

Earlier quoted context omitted.

I was about to ask whether I'm missing something here. "Zero Click" just means no user interaction is required right?So from my Perspektive this is just another way of saying Remote Code Execution? There really isn't something new here other than a fancy name - or I am not seeing the point.

A non zero click remote code execution would be for example the attacker sends the victim a message, with a link or attachment, that if the victim interacts with it, the attacked gets to run code they wrote in the victims device. A zero click remote code execution, would be for example where the attacker send a message, and their phone just processing the message on it's own is enough for the attacker to execute code…

> A non zero click vulnerability can be mitigated by being cautious. A zero click vulnerability cannot.

No amount of caution will save you when the exploit is injected into a major website.

Why bother with such meaningless distinction? Does your browser never hit any http:// resources?

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

#358

Post by kibwen »

xet7 wrote: post #137
roca wrote: post #37

Earlier quoted context omitted.

We don't need to be sure of that. We already have ample evidence that code written in Rust has far fewer vulnerabilities than, say, code written in C.

Quoting from https://forum.nim-lang.org/t/8879#58025 > Someone in the thread said he has 30 years experience in programming, and the only new lang which is really close to C in speed is Rust. He has a point. Both C and release-mode Rust have minimal runtimes. C gets there with undefined behavior. Rust gets there with a very, very robust language definition that allows the compiler to reject a lot of unsafe practices…

Wrapping on integer overflow isn't a memory safety bug in Rust. It's often a memory safety bug in C because of how common pointer arithmetic is in C, and the likelihood that the overflowed integer will be used as part of that pointer arithmetic. But pointer arithmetic is so exceedingly uncommon in Rust that I've never seen it done once in my ten years of using it. This is a place where familiarity with C will mislead you regarding accurate risk assessment of Rust code; wrapping overflow isn't in the top 20 things to worry about when auditing Rust code for safety. And if you want the overflow checks even in release mode, it's trivial to enable it permanently. And a future version of Rust reserves the right to upgrade all arithmetic to panicking even in release mode, if hardware ever sufficiently catches up.

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

#359

Post by staticassertion »

rosndo wrote: post #355
staticassertion wrote: post #338

Earlier quoted context omitted.

Yes, Chrome pretty much single-handedly changed that, timed well with Vista. For about a decade we got a reprieve because: 1. Memory safety mitigations became much more common (Vista) 2. Browsers adopted sandboxing (thanks IE/Chrome) 3. Unsandboxed browser-reachable software like Flash and Java was moved into a sandbox and behind "Click to Play" before eventually being removed entirely. 4. Auto-updates became the nor…

> And that genuinely bought us about a decade. The reason things are changing is because attackers have caught back up. Browser exploitation is back. Sandboxing is amazing and drove up the cost, but it is not enough - given enough vulnerabilities any sandbox falls. It’s still a completely different world. We’ve come a long way from back when Paunch was printing money with Blackhole.

I mean, for how long? Like I said, we had a long period of time without ITW exploits for browsers. That has ended. I'm sure costs are higher today than they were before, but I'm not convinced that the economic incentives won't ultimately lead to another blackhole.

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

#360

Post by kibwen »

normac2 wrote: post #331
dataangel wrote: post #295

Earlier quoted context omitted.

This is just incorrect. The beauty of Rust is even bad programmers end up writing memory safe code because the compiler enforces it. The ONLY rule an organization needs to enforce on their crappy programmers is not allowing use of unsafe. And there are already available tools for enforcing this in CI, including scanning dependencies.

I think what they're saying is that by making devs use a less familiar language, you're going to end up with at least as many security bugs, just ones not related to memory safety. (Not weighing in either way, just clarifying.)

Keeping mind that, if you have an RCE bug, any other class of bug is irrelevant. It's a bit like diagnosing someone with the flu after their head has been cut off. And while acknowledging that you're not personally weighing in either way, I will personally call the idea that you'll end up with just as many bugs of a weaker class to be quite silly. Everyone starts as unfamiliar in every language, but not every language makes it equally easy to accidentally introduce vulnerabilities. Defaults matter, tooling matters, and community norms matter, and all of these make it less likely for a low-quality Rust programmer to introduce vulnerabilities than even a medium-quality C programmer.
Post reply on HN