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

361–370 of 408 posts

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

#361

Post by dreamcompiler »

ReptileMan wrote: post #235
skybrian wrote: post #213

Earlier quoted context omitted.

Both attacks and defenses have gotten a lot better. Meanwhile, the consequences of hacks keep going up every year. You didn't have viruses disrupting shipping or gas pipelines before, because they didn't depend as much on computers.

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

There are a number of organizations out there who think they are airgapped. And then some employee in the basement decides he needs to run a test while he's on the road, or monitor the water treatment plant from home because he's been exposed to COVID and can't come in, so he gets his buddy to install an LTE hotspot and boom! Now the company's not airgapped any more.

It's a special kind of naive to assume that airgapping is a technological problem rather than a human behavior problem.

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

#362

Post by derkades »

rosndo wrote: post #356
greiskul wrote: post #350

Earlier quoted context omitted.

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?

An exploit that achieves remote code execution just by a browser performing an HTTP request (for example a malicious ad) would be considered a zero-click exploit.

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

#363

Post by rosndo »

derkades wrote: post #362
rosndo wrote: post #356

Earlier quoted context omitted.

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

An exploit that achieves remote code execution just by a browser performing an HTTP request (for example a malicious ad) would be considered a zero-click exploit.

But then most exploits that involve sending links would also be zero-click, just not deployed in that manner.

I think this just goes to show how silly this new terminology is.

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

#364

Post by SCHiM »

staticassertion wrote: post #359
rosndo wrote: post #355

Earlier quoted context omitted.

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

I think it's different for good now. Detection is better, response is better. The exploits used in blackhole would be patched really quickly, and detected really quickly.

I think it would be detected quickly because the most likely payload dropped would be ransomware. which makes it immediately obvious to users they got owned. I don't think it would take longer than a day to discover a zero day exists in $BROWSER once a group starts a campaign using it.

All software distributors that expose attack surface to a large consumer base have all had plenty of time to learn how to deal with a major security hole that needs to be patched asap. Once a researcher tweets about a 0day in $BROWSER, there'll be an incomplete patch 1 day later. 4 days later the final patch is out. Auto updates ensure every user has the patch the moment they go online.

But I do think we can still see a CCG using a browser exploit to infect people, but I don't think we'd see exploits packaged and sold inside exploit kits.

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

#365

Post by gmadsen »

thelittleone wrote: post #347
Natsu wrote: post #287

Earlier quoted context omitted.

Mostly because it's not clear that from-scratch rewrites produce better results. They can if the entire architecture needs to be different, but for many libraries it just devolves into an exercise in bikeshedding. This is particularly true of the US government which, if you've seen their IT systems, is not going to be anyone sane's first choice for doing from-scratch rewrites.

I disagree. I think governments prioritise spending, jobs and votes over "better results".

so you agree with the comment then? you are both criticizing the government

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

#366

Post by staticassertion »

SCHiM wrote: post #364
staticassertion wrote: post #359

Earlier quoted context omitted.

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.

I think it's different for good now. Detection is better, response is better. The exploits used in blackhole would be patched really quickly, and detected really quickly. I think it would be detected quickly because the most likely payload dropped would be ransomware. which makes it immediately obvious to users they got owned. I don't think it would take longer than a day to discover a zero day exists in $BROWSER onc…

There are definitely significant economic changes - the turnaround time for discovery, patch, rollout is way tighter.

I suppose that could make a generalized kit much harder to sell. Once it's sold once you basically have to assume it'll be burned soon.

Time will tell.

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

#367

Post by spankalee »

lupire wrote: post #310
Dinux wrote: post #296

Earlier quoted context omitted.

Fuchsia isn't Unix afaik

"Fuchsia implements some parts of Posix, but omits large parts of the Posix model." -- fuchsia.dev

There is an RFC for full Linux binary compatibility: https://fuchsia.dev/fuchsia-src/contribute/governance/rfcs/0...

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

#368

Post by AlotOfReading »

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…

I usually find it safe to assume that compiler folks are conscious of optimization opportunities and make pretty intelligent tradeoffs on that spectrum. This is one such case. There's a long history of bounds checking compilers. The first that I know of is bcc in the 80s, which had a 10x slowdown! Austin et al. [1] came along a few years later way back in '94 and improved things to a mere 2-5x slowdown. That's pretty much where things stood for the next two decades because pointer accesses are everywhere in C and register pressure is nothing to sneeze at. Moreover, changing pointer sizes breaks your ability to link external things that weren't compiled with the same flags, like the system libc. ABI compatibility is make-or-break for a C compiler. You can get around that by breaking up the metadata from the actual pointer (e.g. softbound), but the performance cost is still ~3-4x [2].

ASAN was notable because

1) it was very efficient. That initial 73% was utterly fantastic at the time.

2) It was production-usable (i.e. worked on big codebases)

3) With hardware support, the performance hit is often under 10%. HWAsan on modern platforms is low-cost enough to run it all the time.

And no, I'm saying that pretty much every nontrivial C program has UB, not that they're specifically memory unsafe.

[1] https://minds.wisconsin.edu/bitstream/handle/1793/59822/TR11... [2] https://insights.sei.cmu.edu/blog/performance-of-compiler-as...

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

#369

Post by jerf »

formerly_proven wrote: post #257
jerf wrote: post #242

Earlier quoted context omitted.

The underlying bug in log4j is having a deserialization mechanism that can automatically deserialize to any class in the system, combined with method code that runs upon deserialization that does dangerous things. It has nothing to do with GC at all. It's a recurring problem in dynamic scripting languages where the language by its very nature tends to support this sort of functionality. It's actually a bit weird that…

> The underlying bug in log4j is having a deserialization mechanism that can automatically deserialize to any class in the system Getting objects out of a directory services is what JNDI is all about, I'm hesitant to call it a bug. The bug is that Java is way too keen on dynamically loading code at runtime. Probably because it was created in the 90s, where doing that was kinda all the rage. I think retrospectively th…

"Getting objects out of a directory services is what JNDI is all about, I'm hesitant to call it a bug."

I didn't call it a bug. I called it a bit of functionality that makes the security problem possible. There are many things that result in security issues that come from some programmer making something just too darned convenient, but are otherwise "features", not some mistake or something.

It's the underlying problem. You should have to declare what classes are able to be deserialized. To the extent that it's inconvenient, well, so was the log4j issue.

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

#370

Post by SAI_Peregrinus »

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…

You can enable Rust's overflow checks in release mode, FYI. Doesn't help the default case, but you can at least choose to do so.
Post reply on HN