Live data from Hacker News

‘Zero-click’ hacks are growing in popularity

bloombergquint.com

201–210 of 408 posts

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

#201
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…

Following this idea, using a memory managed language like Go, Java or C# should also prevent most security issues (at least in non-core systems). Somehow I don't think this would work.

What makes you think so?

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

#202
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 standard. Of course, programs that assume that a pointer is 64-bits in size and such won't work. But well-written "application level" programs (eg, a text editor) that have no need for such assumptions should work fine. There would be a performance degradation, of course, but it should be tolerable.

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

#203
post #107

Earlier quoted context omitted.

I’d love to red team the program that thinks Rust unsafe is easier to get right than tight ANSI C.

Why compare 'non-tight' Rust against 'tight' C? Surely we should compare tight Rust (with some 'tight' unsafe sections) against tight C?

I think it's easier to write correct safe Rust than C, I wouldn't say it's easier to write correct Rust with unsafe blocks than C (many operations strip provenance, you can't free a &UnsafeCell created from a Box, you can't mix &mut and const but you might be able to mix Vec and const (https://github.com/rust-lang/unsafe-code-guidelines/issues/2...), self-referential &mut or Pin is likely unsound but undetermined), and it's absolutely more difficult to write sound unsafe Rust than C (sound unsafe Rust must make it impossible for callers to induce UB through any possible set of safe operations including interior mutability, logically inconsistent inputs, and panics).

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

#204

Earlier quoted context omitted.

It sounds like you’re saying, you spent a lot of time focused on learning rust, so now you like to discuss its shortcomings as abrasively as you can for sport.

Upthread I’ve already surrendered. There are certain gangs you just don’t pick a fight with. I’m a slow learner in some ways but I get the message. Got it, learning Rust nuts and bolts only makes it worse to say anything skeptical about it.

Nearly every answer you gave in this thread doesn't address the parent comments point at all.

It seems you are just raging and reading subtext and drama where there is none.

Further up someone mentioned Rust and Haskell aren't similar and you go on about Rust-religion and where to use Rust. Why don't you just address the point? "Lego" is also not a synonym or metaphor for simplified.

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

#205
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…

Quoted post unavailable.

It doesn't have to be Rust. But for all the people who insisted for more than a decade that GCs and VMs don't necessarily compromise performance of practical applications, there has never been an acceptable browser engine in C#, Java, D, Common Lisp, Go, OCaml, Haskell or any of the others. Meanwhile Apple uses Objective-C with its ARC (and later Swift, which is even more like Rust) for everything and it was great.

So the community tried to make OCaml with the memory model of ObjC and as much backwards compatibility with C as they could muster. In context, this doesn't seem like a weird strategy.

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

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

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.

'Zero-Click' is just a new buzzword, it probably got popular due to Pegasus and NSO.

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

#207
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…

Yes, such approaches can be compliant. There's even a few C interpreters. Very popular back in the day for debugging C programs when you didn't have full OS debugging support for breakpoints and etc. Such an approach would be quite suitable for encapsulating untrusted code. There is definitely some major overhead, but I don't see why you couldn't use JIT.

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

#209

Earlier quoted context omitted.

If say a Game or 3D program crashes the system or causes a security issue the problem is the driver or the hardware. A correct driver and hardware should not allow any user level application to cause issues. I know is hard, this GPU companies need to keep backward compatibility, support different operating systems(and versions), support old stuff that worked by mistake. and probably some "benchmark cheeting might be…

Drivers and hardware are not designed by application developers.

I understand. But my point is we can have safe application if GPU makers would care for safety , at this moment they care to impress people with benchmarks to they make money, probably people that run GPU servers will visualize them and put zero pressure on the driver maker to produce safety that might reduce a bit of speed.

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

#210

Earlier quoted context omitted.

Following this idea, using a memory managed language like Go, Java or C# should also prevent most security issues (at least in non-core systems). Somehow I don't think this would work.

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.
Post reply on HN