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

241–250 of 408 posts

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

#241

Post by rrradical »

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,…

Well to some extent these companies are self sabotaging by centering interviews around algorithm problems, not only by selecting a certain kind if talent for further investment of resources, but also by signaling to the market the kinds of training needed to land a good job.

If instead, the talent pool were incentivized to increase their ability to understand abstractions, and we selected for that kind of talent, it might not be so hard to use new languages.

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

#242

Post by jerf »

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?

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 Java has it because statically-typed languages like that don't generally have the ability to do that, but Java put a lot of work into building this into its language. Ruby has a very large issue with this a few years back where YAML submitted to an Ruby on Rails site would be automatically deserialized and execute a payload before it got to the logic that would reject it if nothing was looking for it. Python's pickle class has been documented as being capable of this for a long time, so the community is constantly on the lookout for things that use pickle that shouldn't, and so far they've mostly succeeded, but in principle the same thing could happen with that, too.

It would be nearly impossible for Go (a GC'd language) to have that class of catastrophic security error, because there is nowhere the runtime can go to get a list of "all classes" for any reason, including deserialization purposes. You have to have some sort of registry of classes. It's possibly to register something that can do something stupid upon unmarshaling, but you have to work a lot harder at it.

Go is not unique. You don't see the serialization bugs of this type in C or C++ either (non-GC'd languages), because there's no top-level registry of "all classes/function/whatever" in the system to access at all. You might get lots of memory safety issues, but not issues from deserializing classes that shouldn't be deserialized simply because an attacker named them. Many other languages make this effectively impossible because most languages don't have that top-level registry built in. That's the key thing that makes this bug likely.

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

#243

Post by phendrenad2 »

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 falls apart. There are vulnerabilities in JS and Ruby code, languages that are even easier (and just as type-safe) as Rust.

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

#244

Post by NohatCoder »

anon_123g987 wrote: post #175
NohatCoder wrote: post #169

Earlier quoted context omitted.

Nothing wrong with Rust, but I still think making operating systems with airtight sandboxing and proper permission enforcement is the only thing that can truly solve these issues.

And what language should we use to create such an OS? Maybe Rust?

It is a better choice than C++ for sure.

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

#245

Post by AlotOfReading »

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

Earlier quoted context omitted.

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-langu…

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 C doesn't have a way to actually handle detected unsafety and no amount of compiler magic will resolve that.

You have to change the code. Whether that's by using another language annotations or through annotations like checked C is an interesting (but separate) discussion in its own right.

As for the point that programs with memory unsafety aren't standards conforming; correct but irrelevant. Every nontrivial C program ever written is nonconformant. It's not a matter of "just write better code" at this point.

[1] https://www.usenix.org/system/files/conference/atc12/atc12-f...

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

#246

Post by phendrenad2 »

rrradical wrote: post #241
tptacek wrote: post #228

Earlier quoted context omitted.

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,…

Well to some extent these companies are self sabotaging by centering interviews around algorithm problems, not only by selecting a certain kind if talent for further investment of resources, but also by signaling to the market the kinds of training needed to land a good job. If instead, the talent pool were incentivized to increase their ability to understand abstractions, and we selected for that kind of talent, it…

Abstractions are fun, security isn't. I doubt there are even that many programmers who enjoy writing (correct, safe) Rust.

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

#247

Post by AlotOfReading »

toast0 wrote: post #229
AlotOfReading wrote: post #216

Earlier quoted context omitted.

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.

Based on recent experience, you'd really want your media decoders compiled with a safe compiler, and if it crashes, don't show the media and move on. Performance is an issue, but given the choice between RCE and DoS, DoS is preferable. It would be nice if everything was memory safe, but making media decoding memory safe would help a lot.

I absolutely agree that it's a step in the right direction. My point is that we can't get all the way to where we want to be simply by incremental improvements in compilers. At some point we have to change the code itself because it's impossible to fully retrofit safety onto C.

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

#248

Post by fsflover »

bouke wrote: post #36
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/ .

Not supporting unicode as a feature leaves out most of the world’s population. I’m not interested in such “features” as a non-native English speaker.

If you open my link, you will find how to switch it on.

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

#249

Post by [deleted] »

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.

[deleted]

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

#250

Post by [deleted] »

retrac wrote: post #207
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…

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.

[deleted]
Post reply on HN