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

211–220 of 408 posts

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

#211

Post by rosndo »

raesene9 wrote: post #198
rosndo wrote: post #148

Earlier quoted context omitted.

There is no meaningful distinction between the two. > Zero-click describes an issue on a client system where usually a user would have to click something to trigger it, but doesn't as parsing/processing happens before the user actually sees anything (e.g. via an SMS on a phone). Historically these have been referred to as RCE. FWIW You are essentially describing a service listening on the network. It’s silly to try t…

That's a view of the world for sure :) Personally I don't think it's irrelevant. From a threat modelling perspective, exposed services are expected to be attacked. Client services with zero interaction, have traditionally been regarded as safer, usually for client side attacks we'd expect a trigger from user action (e.g. a link being clicked, a PDF file being opened). Just because you don't find something to be usefu…

Client services like these are also expected to be attacked.

iMessage isn’t meaningfully different from Apache, instead of listening on a TCP number it listens on your Apple user id.

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

#212

Post by mastax »

rmbyrro wrote: post #58
pyman wrote: post #50

There are no laws in Israel preventing companies like NSO from building and selling zero-day and zero-click exploits? Without proper regulations the Israeli government is creating a sophisticated and dangerous platform for these kind of illegal attacks.

The Israeli government is exploiting NSO as a global diplomacy leverage. In exchange for approving the export of NSO software, they request foreign State support for their interests abroad, ranging from UN voting to commercial deals and anything in between.

Essentially works like arms exports, which makes a lot of sense.

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

#213

Post by skybrian »

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.

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.

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

#214

Post by tester756 »

chromanoid wrote: post #210
tester756 wrote: post #201

Earlier quoted context omitted.

What makes you think so?

While I think garbage collected languages produce programs that are more safe, I also think they are often enablers for new classes of security issues. For example ysoserial, log4j etc.

(This is genuine question)

Is log4j's bug actually unique to Java/C#/gc-based languages?

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

#215

Post by xavxav »

radford-neal wrote: post #202
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…

Wouldn't it be a lot easier to just use a C compiler that produces memory-safe code? I'm sure someone else has already thought of this, but in case not... All you need to do is represent a pointer by three addresses - the actual pointer, a low bound, and a high bound. Then *p = 0 compiles to code that checks that the pointer is in bounds before storing zero there. I believe such a compiler would conform to the C stan…

There are similar approaches, ie: Checked-C which work surprisingly well. However, I'm not sure that this approach would be expressive enough to handle the edge cases of C craziness and pointer arithmetic. There's more to memory unsafety than writing to unallocated memory, even forcing a write to slightly wrong memory (ie setting `is_admin = true`) can be catastrophic.

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

#216

Post by AlotOfReading »

radford-neal wrote: post #202
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…

Wouldn't it be a lot easier to just use a C compiler that produces memory-safe code? I'm sure someone else has already thought of this, but in case not... All you need to do is represent a pointer by three addresses - the actual pointer, a low bound, and a high bound. Then *p = 0 compiles to code that checks that the pointer is in bounds before storing zero there. I believe such a compiler would conform to the C stan…

That's essentially what ASAN is, with some black magic for performance and scope reasons. The problem is that ensuring that your code will detect or catch memory unsafety isn't enough, because the language itself isn't designed to incorporate the implications of that. If you're writing a system messenger for example, you can't just crash unless you want to turn all memory unsafety into a zero-click denial of service.

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

#217

Post by radford-neal »

xavxav wrote: post #215
radford-neal wrote: post #202

Earlier quoted context omitted.

Wouldn't it be a lot easier to just use a C compiler that produces memory-safe code? I'm sure someone else has already thought of this, but in case not... All you need to do is represent a pointer by three addresses - the actual pointer, a low bound, and a high bound. Then *p = 0 compiles to code that checks that the pointer is in bounds before storing zero there. I believe such a compiler would conform to the C stan…

There are similar approaches, ie: Checked-C which work surprisingly well. However, I'm not sure that this approach would be expressive enough to handle the edge cases of C craziness and pointer arithmetic. There's more to memory unsafety than writing to unallocated memory, even forcing a write to slightly wrong memory (ie setting `is_admin = true`) can be catastrophic.

I think it handles all standards-conforming uses of pointer arithmetic. Even systems-level stuff like coercing an address used for memory-mapped IO may work. For example,

    struct dev { int a, b; } *p; p = (struct dev *) 0x12345678;
should be able to set up p with bounds that allow access only to the a and b fields - eg, producing an error with

    int *q = (int *) p; q[2] = 0;
Of course, it doesn't fix logic errors, such as setting a flag to true that shouldn't be set to true.

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

#218

Post by 41b696ef1113 »

tester756 wrote: post #214
chromanoid wrote: post #210

Earlier quoted context omitted.

While I think garbage collected languages produce programs that are more safe, I also think they are often enablers for new classes of security issues. For example ysoserial, log4j etc.

(This is genuine question) Is log4j's bug actually unique to Java/C#/gc-based languages?

>Is log4j's bug actually unique to Java/C#/gc-based languages?

Not to my understanding. It would be possible in any language with or without a GC.

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

#219

Post by GeekyBear »

lionkor wrote: post #102
benreesman wrote: post #70

Earlier quoted context omitted.

Honestly at this point I’ve given in and am now advocating that we rewrite every damned widget from scratch in Rust, because by the time we’re mostly done, my career will be winding down, and seeing that shit still gets pwned like, exactly as much, will be “good TV”. Rust is cool because it’s got a solid-if-slow build story that doesn’t really buy into the otherwise ubiquitous .so brain damage. Rust is cool because H…

The flaw in the idea of "rewrite it in rust" is that, next to the memory issues, the biggest issues are logic bugs. Rewriting something from scratch isnt going to magically not have bugs, and the legacy system likely has many edge cases covered that a modern new implementation will have to learn about first.

>next to the memory issues, the biggest issues are logic bugs

When you look at the percentage of security issues that derive from memory safety, it certainly makes memory safety a good place to start.

>The Chromium project finds that around 70% of our serious security bugs are memory safety problems.

https://www.chromium.org/Home/chromium-security/memory-safet...

>Around 70 percent of all the vulnerabilities in Microsoft products addressed through a security update each year are memory safety issues.

https://www.zdnet.com/article/microsoft-70-percent-of-all-se...

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

#220

Post by radford-neal »

AlotOfReading wrote: post #216
radford-neal wrote: post #202

Earlier quoted context omitted.

Wouldn't it be a lot easier to just use a C compiler that produces memory-safe code? I'm sure someone else has already thought of this, but in case not... All you need to do is represent a pointer by three addresses - the actual pointer, a low bound, and a high bound. Then *p = 0 compiles to code that checks that the pointer is in bounds before storing zero there. I believe such a compiler would conform to the C stan…

That's essentially what ASAN is, with some black magic for performance and scope reasons. The problem is that ensuring that your code will detect or catch memory unsafety isn't enough, because the language itself isn't designed to incorporate the implications of that. If you're writing a system messenger for example, you can't just crash unless you want to turn all memory unsafety into a zero-click denial of service.

Programs that would crash when using the memory-safe compiler aren't standards conforming. If you're worried that programs crashing due to bugs can be used for a denial-of-service attack... Well, yes, that is a thing.

Low-level OS and device-handling code may need to do something that won't be seen as memory safe, but I expect that for such cases you'd need to do something similarly unsafe (eg, call an assembly-language routine) in any "memory safe" language.

I'm not familiar with how ASAN is implemented, but since it doesn't change the number of bytes in a pointer variable, I expect that it either doesn't catch all out-of-bounds accesses or has a much higher (worst case) performance impact than what I outlined.

Post reply on HN