As a software engineer I still don't understand how this is even possible. What kind of logic behind a URL preview can bypass everything? I think companies like NSO Group are just finding backdoors not software bugs.
‘Zero-click’ hacks are growing in popularity
251–260 of 408 posts
Re: ‘Zero-click’ hacks are growing in popularity
#252Earlier 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.
Still not enough, because apps still need to interact with the outside world, so there would have to be intentional holes in the sandbox out through which the compromised app could act maliciously.
Re: ‘Zero-click’ hacks are growing in popularity
#253Earlier quoted context omitted.
Right, but a memory unsafety but is what takes a harmless logic bug in an image parser with no filesystem access to an RCE and sandbox escape. Memory unsafety allows you to change the 'category' of the bug, you become free to do whatever whereas a logic bug forces to to work within the (flawed) logic of the original program.
Not necessarily; see https://github.com/LinusHenze/Fugu14/blob/master/Writeup.pdf for example. It's a full chain that repeatedly escalates privileges without exploiting any memory safety bugs by tricking privileged subsystems into giving it more access than it should have, all the way up through and beyond kernel code execution.
https://news.ycombinator.com/item?id=19138602
https://www.zdnet.com/article/chrome-70-of-all-security-bugs...
Re: ‘Zero-click’ hacks are growing in popularity
#254Qubes 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/ .
Re: ‘Zero-click’ hacks are growing in popularity
#255Years 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.
Re: ‘Zero-click’ hacks are growing in popularity
#256Earlier 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.
Look at how often V8’s sandboxes get exploited. It’s all developed by humans, which means there will always be errors. Saying just make airtight sandboxes is like just write bug-free code.
JavaScript is not machine code, but still a good deal harder to make fast than a language designed for fast sandboxing. Of course there have been bugs, but mostly I think the JS VMs have done a pretty good job of protecting browsers.
Re: ‘Zero-click’ hacks are growing in popularity
#257Earlier quoted context omitted.
(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…
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 the conclusion is that it may be the easiest way to make things extensible short-term, but also the worst way for long-term maintenance. Just ask Microsoft about that.
Re: ‘Zero-click’ hacks are growing in popularity
#258Not 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 fall…
All code can have bugs, it's mostly just a question of how many. Rust code doesn't have to have zero bugs to be better than C. It's not like all C programmers are top-tier programmers and all Rust programmers are the bottom of the barrel.
Re: ‘Zero-click’ hacks are growing in popularity
#259Earlier quoted context omitted.
I'd say lack of QA. Apple Music (especially on macOS) is EXTREMELY buggy, unresponsive, slow, and feels like a mess to use. Same for iMessage. Other apps are also written using the same stack with almost no bugs. I wouldn't blame the language here, but the teams working on them (or more likely their managers trying to hit unrealistic deadlines).
No, I would not blame the teams or their managers. You can't just blame a manager you've never met just because he's a manager, we're talking about the manager of Apple Music, they could very well be capable and well-minded, likely personally capable of coding. So let me give you another example in the same vein as C, where everybody uses a technology that is terrible, questioning it only at the outset, and then just…
1. You start off by saying you can't just blame the team or their manager if you're dissatisfied with a product, then instead of explaining why the people who made a piece of software aren't responsible for its faults you go off on a long non-sequitur about QWERTY.
2. Your rant on QWERTY just isn't true. You namedrop Peter Thiel and his book, so if he's your source then he's wrong too. QWERTY is not terrible, not obsolete, it was not designed to slow down typists, and there's no record of salesmen typing "typewriter quote" with just the top row. It's true that it was designed to switch common letters between the left and right hands, but that actually speeds up typing. It also does not take weeks for someone to type "the" ; and if you mean learning touch-typing, I don't know of any study that claims that alternative keyboard layouts are faster to learn.
The various alt. keyboard layouts (dvorak, coleman, workman) definitely have their advantages and can be considered better than QWERTY, sure; people have estimated that they can be up to ~30% faster, but realistically, people report increasing their typing speeds by 5-10%; or at least the ones who have previously tried to maximize their typing speeds... If learning a new layout is the first time they'd put effort into that skill, they'd obviously improve more. It's probably also true that these layouts are more efficient in the sense that they require moving the fingers less, reducing the risk of RSI (though you'd really want to use an ergonomic keyboard if that's a concern.)
QWERTY is still used because it's not terrible, it's good enough. You can type faster than you can think with it, and for most people that's all they want. There's nothing wrong with any of the alternative layouts, I agree that they're better in some respects, but they're not order-of-magnitudes better as claimed.
3. Your opinions about C are asinine.
"not objectively inferior like QWERTY" - So, is C good or not? We're talking about memory safety, C provides literally none. Is this not objectively inferior? Now, I would argue that it's not, it's an engineering trade-off that one can make, trading safety for an abstract machine that's similar to the underlying metal, manual control over memory, etc. But you're not making that point, you're just saying that it's actually good before going on to explain that it's hard to use safely, leaving your readers confused as to what you're trying to argue.
"not a bad language for simple algorithm prototypes of under 60 lines" - It's difficult to use C in this way because the standard library is rather bare. If my algorithm needs any sort of non-trivial data-structure I'll have to write it myself, which would make it over 60 lines, or find and use an external library. If I don't have all that work already completed from previous projects, or know that you'll eventually need it in C for some reason, I generally won't reach for C... I'll use a scripting language, or perhaps even C++. Additionally, the places C is commonly used for its strengths (and where it has begun being challenged by a maturing Rust) are the systems programming and embedded spaces, so claiming C is only good for 60-line prototypes is just weird.
"C is about characters" - Um, most computer languages are "about characters". There are some visual languages, but I don't think you're comparing C to Scratch here... You can misplace a parentheses with Lisp or make any number of errors that are syntactically correct yet semantically wrong and you'll have errors too, just like in C. Now, most lisps give you a garbage collector and are more strongly typed than C, for instance, features which prevent entire categories of bugs, making those lisps safer.
4. You kinda lost the point there. You started by saying that the people who wrote Apple Music "could very well be capable and well-minded, likely personally capable of coding", i.e., they're good at what they do. Fine, let's assume that. Then, your bottom line is that in C "you have to really know what you're doing" and "you yourself have to code that code perfectly in the human capacity of perfection". What's missing here is a line explaining that humans aren't perfect, and even very capable programmers make mistakes all the time, and having the compiler catch errors would actually be very nice. Then it would flow from your initial points that these are actually fine engineers, but they were hamstrung by C.
And the tangent on QWERTY just did not help at all.
Re: ‘Zero-click’ hacks are growing in popularity
#260Earlier quoted context omitted.
Or perhaps one step further (albeit verging into conspiracy theory territory): they intentionally push ahead with known-flawed approaches, projects and engineering practices because it's profitable and there's generally a net benefit to them in being more-aware and more-in-control of the vulnerabilities within that ecosystem than anyone else could be. (instead of taking the time to wait for research results, best pra…
Apple spends more on security than all but 2 other industry firms (they may spend more than those 2 as well), and has a comparable computing footprint to those firms. This is a facile complaint.
Perhaps the associated billions of dollars of spending is indeed the answer, and will translate into measurable improvements. If so, very well.
Perhaps there are Conway-style architectural issues at hand here as well, though. Can disparate teams working on (a large number of) proprietary interconnected products and features reliably produce secure results?
It seems wasteful that similarly-functioning tools -- like messaging apps -- are continuously built and rebuilt and yet the same old issues (generally exacerbated by increasing web scale) mysteriously re-appear time and again.