‘Zero-click’ hacks are growing in popularity
bloombergquint.com
bloombergquint.com
Every programming language can result in bugs, but some are worse/more frequent/harder to solve afterwards than others.
Better yet, why wasn't "rebuild commonly used standard libraries" in the US Infrastructure bill last year? The government could pay programmers a lot, and pay whitehat pen-testers a lot (+ per bug discovered) and in a few years of iteration, we'd have incredibly hardened, durable software infrastructure that would benefit us for decades to come, in the public domain.
I mean, on some level you can try to make your own custom TempleOS for everything, but that only gets you (possibly) reduced scrutiny and hiring issues simply because nobody knows how to use it. But if you're already a target, the reduced scrutiny is probably a bad thing since the good guys won't point out the bugs to get them fixed.
-- fuchsia.dev
It would not be enough to provide new, more secure options; and not enough to make them the default - to actually reduce the attack surface, you'd want to remove the nonsecure options, if required, at the cost of compatibility.
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.
So there's no guarantee that the replacements would be bug-free. If anything, the current stuff is battle tested through the years and gets better with each scar. I would guess that they are also employing all kind of hacks, i.e things that are not supposed to be like that but are like that and they will break a lot of things if they make the new code work the way it is supposed to work.
There's even XKCD for that: https://xkcd.com/1172/
> "With a sufficient number of users of an API, it does not matter what you promise in the contract: all observable behaviors of your system will be depended on by somebody."
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/.
Seems like one of the least interesting aspects of qubes. Was there a zero day in the font renderer? I would assume such a thing would be more about homograph attacks.
As far as I'm concerned, freetype is another spelling for CVE. There have been multiple high impact vulns. Though it usually seems to require crafted fonts, so I wouldn't be too concerned about window titles using system fonts. Web fonts on the other hand.. disable 'em.
I didn't even notice the unicode thing. But it doesn't surprise me. They have various similar conservative features. For instance, by default an app in a VM cannot get full screen access. To full-screen a video in youtube you have to full-screen in app and then hit Alt-F11. The concern is that the app somehow tricks the user into thinking that they're interacting with the host OS desktop. Also the host OS doesn't have Internet access; update package files are downloaded by another VM and copied over.
It's fairly paranoid by design, and their tagline is "a reasonably secure operating system".
Ah, the elusive quadruple-negative.
Qubes runs Debian in a VM and isolates it to defend the user from threats.
It would take a sea change in the mindsets of software engineers globally to centralize the software development process around a security mindset. That's not going to happen unfortunately. The vast majority of us have neither the expertise, nor the time, to develop 100% secure code. The best most of us conscientious types can do is to provide comprehensive monitoring, so that a user can use those tools to know if and when something is amiss.
99% of the problem is just wanting to not have to rewrite a hundred parsers in memory-safe languages.
It's just economics and engineering.
They don't have to change everyone's minds or fix the world. They'd need to invest a lot but so far nobody really thinks it's worth it.
Isolation, mitigation and prevention of exploitation is common.
This can be avoided if you have a cross platform high level language like say C# with a big standard library like .Net , the field needs then to make sure the language and core library are safe, most programs use existing libraries and put some business logic on top, I remember that memory safety was a thing before Rust was born, the issue was that either the languages were too slow, were not cross platform or had weird license or were "garbage".
If this gaints like Apple, Google, Facebook would contribute on rewriting or prove that the core libraries they use are correct then things would improve, but how would they continue to increase their obscene profits ?
The essential problem is features. Devs want features. So Python, .NET, etc, and even the browsers try to provide access to those features. But some of those features are simply inherently unsafe. Someone will find a way to compromise this feature or that. How does one provide 100% safe access to the GPU? The file system? And so on. It's not really possible. At some point, the app level dev will have to keep a security mindset when writing his code. Don't do things on the GPU that compromise the system. But that has to be on the app developer if that developer is demanding that the browsers give him/her access to the GPU.
I don't know if I'm being clear? But I hope you can see what I'm trying to say.
Do you have a proof that it is impossible to have a secure calculator application?
About .Net and Python, they are using a lot of wrappers around old unsafe code, so we would need to put more work and eliminate that, MS failed because of their shity Windows first ideals and their FUD,
Easier said than done…
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 hidden in the proprietary drivers too".
Presumably through pointer capabilities.
> The file system?
File system namespacing and virtualization.
I disagree with most of your assertions.
You'll end up making a standard library so big that it will never be secure. And even more portantly, you'll strangle innovation by disallowing improvements to the standard library.
Something like JVM or.Net would be part of the solution because you could pacify developers because they can use their darling language but target the same platform as the others. We still need true engineers to create an OS and Standard library from the ground up, designed for security and not chaotically evolved.
Wanting those things is fine but delivering those things is extremely difficult. JSON/XML/Zip have so many weird edge cases it's maybe impossible to write parsers that are complete to the spec yet also truly secure. XML and Zip bombs aren't explicit features of either format but they're side effects of not being explicitly forbidden.
You're also want "good" parsers without specifying in which dimension you want them to be "good". You can have a complete parser that's reasonably secure but then pay for that with CPU cycles and memory. You can have a small and fast parser that's likely incomplete or has exploitable holes.
We probably need to create better specifications, probably using a log/math language that can verify the specifications are valid and clear. It will be hard since people will need to learn to be more clear but it might also simplify things , say we would have a simple replacement for html and css if the guys creating it would have to do it in such a language.
The giants use json right, so they could put some money together find some experts to write a specification, if json is flawed they can write a new version of it that is correct, then when specification is coded they can release it, and after that this giants can pay some developers to implement it and prove the implementation correctness.
They should repeat it for one image format, they can chose what is a decent image format and do that, then do it for html, audio, video... it will save them money if less security issues happen on their servers or in their users devices. But it will save them money only if it would cost them when their devices get owned, this means we should stop apologizing this bugs with extreme fake stuff like "99.9% of applications have security issues"
Apps are sandboxed, so the damage should be limited to only the exploited app.
Pegasus exploits exploited iMessage et al, which are Apple's own apps with special permissions.
Or rather would be great if Pegasus was the only 0-day out there. It'd be even better if Pegasus were the only 0-click out there.
Here's the thing though, it's not.
That's the world we live in. So the question is, given that fact, how do we get to a world where we can have some level of security? My belief is that everyone from the users to the app devs have to adopt a security mindset.
Users should not download that free app that lets you see what you would look like as your favorite French pastry. They should not click on the link in that sms they got from that strange phone number. They should be careful about giving out their phone number. Give everyone your gmail google phone number instead and let them send texts to that. Then check those texts on your gmail google phone if you're a high profile target. (Or even just a guy/gal who has a few people out there who really don't like them.) Keep a buffer between the world and your phone. Etc etc etc.
Devs want access to the file system. Awesome, but they'd better make sure in using that filesystem they are not inadvertently allowing users to take any actions deleterious to the system. Devs want access to the GPU. Again, no problem. But you'd better know how to write secure GPU code. There is no way a browser, or .NET, or Python or an OS can provide you access to a GPU "safely". If they give you the gun, they expect you will use it responsibly.
Browsers and other platform providers should also act responsibly. I understand developers want features. At the same time, is it responsible to hand out access to these features without some kind of plan to keep irresponsible devs from compromising security at scale? Sometimes there just is no way to do that, and I understand. (Access to the GPU is an example. Devs just have to know what they're doing.) But sometimes it is possible to do things in a more secure fashion, or to just wait on delivering that feature altogether.
Point is, for a secure environment, everyone has to play their part. There are so many of these 0-clicks and 0-days out there in the wild. Everyone wants to make a better environment. Well, I'm not seeing how that happens without getting everyone's cooperation. Or, at a minimum, getting everyone to be a bit more careful with their behaviors.
AFAIK, the hacker broke out of the sandbox in addition to rooting iMessage.
Also, the surface area available to a sandbox is too large. Firecracker like VM isolation is required for safety, which Apple seems to be moving towards when it comes to parsing from their apps at least.
(instead of taking the time to wait for research results, best practices, security reviews and privacy concerns up-front at design-time, and even -- shock -- perhaps deciding not to build some societally risky products in the first place)
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.
Nothing is impossible unless it disobeys the laws of physics(which are also limited to what we currently know)
It would be equivalent to saying, well it isn't economic enough for energy companies to simply create nuclear fusion reactors...
Some things are just extremely hard and there's no obvious answer even if you had "unlimited" funds.
Recently I was on my phone when I received an email address iMessage and the toast showed an absolutely insane link, when I opened iMessage (not even that conversation) to go delete the thread my phone screen went blank quickly 2 or 3 times in a row, something I've never seen before. I deleted the thread and turned the thing off.
Oops, I must've been remembering Android. Well, it's one way Apple could fix this unconscionably lasting security hole.
What kind of logic behind a URL preview can bypass everything? I think companies like NSO Group are just finding backdoors not software bugs.
Really worth the read, it was quite eye-opening.
> JBIG2 doesn't have scripting capabilities, but when combined with a vulnerability, it does have the ability to emulate circuits of arbitrary logic gates operating on arbitrary memory. So why not just use that to build your own computer architecture and script that!? That's exactly what this exploit does. Using over 70,000 segment commands defining logical bit operations, they define a small computer architecture with features such as registers and a full 64-bit adder and comparator which they use to search memory and perform arithmetic operations. It's not as fast as Javascript, but it's fundamentally computationally equivalent.
> The bootstrapping operations for the sandbox escape exploit are written to run on this logic circuit and the whole thing runs in this weird, emulated environment created out of a single decompression pass through a JBIG2 stream. It's pretty incredible, and at the same time, pretty terrifying.
Exploits for mobile phones in the "open market" are in the millions of dollars, for a single working exploit.
But the incentive is growing as these devices are becoming the center of our lives.
> In December, security researchers at Google analyzed a zero-click exploit they said was developed by NSO Group, which could be used to break into an iPhone by sending someone a fake GIF image through iMessage.
And the thread from back then:
https://news.ycombinator.com/item?id=29568625
That Project Zero blog post lays out the details under the "One weird trick" header.
All you can do is reduce attack surface, and most of all, monitor.
Another comment blames Apple, and financial incentives. Sure, there may be some of that.
But the reality is that safe code is impossible. Now, you may say "But...", yet think about this.
For all of computing history, all of it, no matter what language, no matter how careful, there is always a vulnerability to be had.
Thinking about software, and security any other way, is an immediate fail.
Arguing the contrary, is arguing that the endless litany of endless security updates, for the stuff discovered, doesn't exist.
And those updates oyly cover stuff discovered. There are endless zero days right now, being exploited in the wild, without patches, of which we are unaware.
We're seen vulnerabilities on every kernel, in mainline software, on every platform, sitting for years too. And you know those are discovered by black hats, and used for a long time before being found out by the rest of the community.
Humans cannot write safe software. Ever. No matter what.
Get over it.
Only detailed, targeted monitoring can help you detect intrusion attempts, expose as little as possible, keep updated, and do your best.
> Humans cannot write safe software. Ever. No matter what.
Formally proven code does what it says on the box? Do we have different definitions of safe perhaps?
It becomes an infinite recursion of "how do we know the proof of the proof of the..." is what we actually want?
I guess that's why security issues, even in massively peer reviewed code, are a thing of the past, right?
Do your best, code as safely and securely as you know how, peer review and test and fuzz...
Then when you deploy your code, treat it as vulnerable, because history days it likely is.
Treat your phone as compromised. Anything network connected as compromised.
Because history says it can be, and easily.
Monitoring is one of the most important security measures for a reason.
Are you trying to claim that the above proof will never be invaldated?
You're really just proving mt point here. You think thongs can be secure.
That's of course only a part of the story, the spec or the hardware can still be broken.
The weak spot when it comes to security is not the hardware or the software, it's the human mind.
Humans cannot write bug-free software[1]. Then if you're soft has security-related things to do (like credential management etc.) you cannot be sure there won't be a way to bypass it.
But here we're talking almost exclusively about remote execution bugs coming from memory-safety issues, which are indeed preventable. Any managed language does the trick, and if they are not fast enough for your use-case there is Rust. (And, before anyone mentions it, since this isn't some low-level/hardware related thing, you don't need to use unsafe Rust).
Rewrites are costly and take time, but we're talking about the wealthiest company on Earth, and this issues has been around for years so they don't really have an excuse…
[1]: at least without using formal verification tools, which are admittedly not practical enough…
(Yes people, and Apple should try, but...)
Taking Rust as an example (use Swift or even Java if that works better for your use-case), we know how to write Rust code that is guaranteed to be free from common classes of bugs that these zero-click attacks exploit.
Yes, we aren't going to get rid of all bugs, yes, zero-click attacks might still be possible once in a while, but we can make it much, much harder and more expensive, and therefore greatly reduce the set of people who have access to such attacks, and reduce their frequency.
No we don't.
You are trying to shift the sands, by saying "But.. this one thing we can do...", except even that isn't true.
If we did, it wouldn't keep happening, year after year, decade after decade.
But even with peer reviews, with people supposedly knowing how, well.. it just keeps happening.
Do you think every occurrence is random chance? Or is it, maybe, just maybe, that humans can't write bug free code?
Safe Rust code could trigger a compiler bug that leads to use-after-free, or trigger a bug unsafe Rust code (i.e., code explicitly marked "unsafe") that leads to use-after-free; the latter are rare, and the former are even rarer. In practice I've been writing Rust code full time for six years and encountered the latter exactly once, and the former never. In either case the bug would not be in the safe code I wrote.
I'm certainly not claiming that humans can write bug-free code. The claim is that with the right languages you can, in practice, eliminate certain important classes of bugs.
So there will be no human error? And rust will have zero compile time bugs, ever?
I'm not against improvement, but the absurd assumption that anything is safe. Because nothing is.
> 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 and make a lot of desirable outcomes safe and relatively convenient.
However, Rust also allows certain behavior that a lot of us consider undesirable; they just define the language so that it's allowed. Take integer overflow, for instance https://github.com/rust-lang/rfcs/blob/26197104b7bb9a5a35db2... . In debug mode, Rust panics on integer overflow. Good. In release mode, it wraps as two's complement. Bad. I mean, it's in the language definition, so fine, but as far as I'm concerned that's about as bad as the C https://stackoverflow.com/a/12335930 and C++ https://stackoverflow.com/a/29235539 language definitions referring to signed integer overflow as undefined behavior.
I assume the Rust developers figure you'll do enough debugging to root out integer overflow happens, and maybe that's true for the average system, but not all! I once had to write a C++ program to compute Hilbert data for polynomial ideals. The data remained relatively small for every ideal that could reasonably be tested in debug mode, since debug mode is much slower, after all. But once I got into release mode and work with larger ideals, I started to encounter strange errors. It took a while to dig into the code, add certain manual inspections and checks; finally I realized that the C++ compiler was wrapping the overflow on 64 bit integers! which is when I realized why several computer algebra systems have gmp https://gmplib.org/ as a dependency.
OK, that's the problem domain; sucks to be me, right? But I wasted a lot of time realizing what the problem was simply because the language designers decided that speed mattered more than correctness. As far as I'm concerned, Rust is repeating the mistake made by C++; they're just dressing it up in a pretty gown and calling it a princess.
This is only one example. So, sure, Rust is about as fast as C, and a lot safer, but a lot of people will pay for that execution boost with errors, and will not realize the cause until they've lost a lot of time digging into it... all to boast, what? a 1% improvement in execution time?
IMHO the better design choice is to make it extremely hard to override those overflow checks. There's a reason Ada has historically been a dominant language in aerospace and transportation controls; they have lots of safety checks, and it's nigh impossible to remove them from production code. (I've tried.) Nim seems more like Ada than Rust in this respect: to eliminate the overflow check, you have to explicitly select the very-well-named --danger option. If only for that reason, Nim will seem slower than Rust to a lot of people who never move outside the safe zone of benchmarks that are designed to test speed rather than safety.
To be fair, once you remove all these ~1% slowdown checks, you get a much higher performance boost. And Rust really is a huge improvement on C/C++ IMHO, with very serious static analysis and a careful language design that isn't encumbered by an attempt to be backwards compatible with C. So if you're willing to make that tradeoff, it's probably a perfectly reasonable choice. Just be aware of the choice you're making.
The key takeaway is the following: Rust programs will contain bugs, but none of those bugs will lead to the kind of crazy vulnerabilities that allow those “zero-click attacks”. Is that perfect? No, but it's an enormous improvement over the status quo.
That only makes sense if all your code is in Rust, but I suspect this is not true for foreign libraries, even bulletproof ones. It was my understanding that to convince Rust of their safety, you need blocks of "unsafe" code...or not? For example, if I want to embed Chez Scheme into a Rust program, even safely, I apparently can't do that without "unsafe" code. And that's by no means exclusively a "low-level/hardware related thing".
OpenSSH has been exposed to the public Internet for over two decades, with nothing resembling this type of security problem. OpenSSH runs the protocol parser without permissions on the local filesystem, yet Apple thinks an ancient tiff library with scripting abilitites can be run with full permissions. Of course there is a discussion of financial incentives and customer expectations to be had here.
URL previews are an anti feature for a many users. We could not care less. But it gets shoved upon users by product feature teams for whom a continous stream of new features are their reason for being. That's how we develop commercial software, but that's not the only way.
It doesn't. That is just one step in a chain of exploits.
Mobile security is a huge mess because of planned obsolescence. There should exist no security reasons that force me to junk a device faster than 10 years if the manufacturer is still in business.
Regulatory action is required, that should think past the traditional "warranty" periods, removing security support is a remote confiscation of private property.
A Saudi woman's iPhone revealed hacking around the world - https://news.ycombinator.com/item?id=30393530 - Feb 2022 (158 comments)
Before that:
A deep dive into an NSO zero-click iMessage exploit: Remote Code Execution - https://news.ycombinator.com/item?id=29568625 - Dec 2021 (341 comments)
https://www.weforum.org/agenda/2019/03/5-charts-that-reveal-...
I don't blame you for not seeing that though. The propaganda about Israel being in serious danger from stones and home made rockets is quite effective.
Anyone interested in learning more about how NSO group operates can check out digitalviolence: https://www.digitalviolence.org/#/
What are the options now?
As an example, I consider that a secure phone MUST have boot-time full disk encryption passphrase, which needs to be different from lockscreen. For obvious reasons (which is that the user will tend forget their password), you can't have this even as an option on general purpose phones.
That being said. GrapheneOS is IMO a pretty good option wrt security (like they chose to disable JIT, which impacts performance, but supposedly improve security), even though lately their focus is no longer security for business reasons.
Architecture-wise, the best smartphone are pinephones/Librem, because of separation of modem (which is in the case of state-actors, an actual danger), and you can force encryption of all communications (it's even possible to do VoLTE encryption CPU-side rather than modem-side), but I think at the moment their OS really lags behind Android when it comes to security.
Context?
People keep saying RIR is some how pointless but the reality is that its impossible to keep ahead of those vulnerabilities that aren't found yet.
A.K.A. 'Hacks' (as opposed to social engineering)
I think both should be considered hacks, but zero click is much scarier, so it makes sense to distinguish them
If you are only doing text email (or some very restricted HTML interpretation) then there is no extra risk in using a local email client. The lack of a HTML interpreter probably means you would be safer than with a webmail client.
If you are doing some form of email as a precaution, you still need a secure place to do it. That might not be a typical smart phone.
both statements are not true. a) zero click hacks have always been popular b) of course there are ways to stop them.
IMO complexity and churn remain the biggest problems but people are not willing to engage it. There's always at least one legitimate use case for some faddy trendy new feature, always a reason for more complexity, fuck anyone who doesn't want it. And so you get a massive body of constantly changing code that auditors can't keep on top of.
What would it be like if your chat app was max 3000 lines of code and received no more than a handful of small patches per year since 2008? You could audit that in an evening or two and be reasonably confident in its security, and you could also be reasonably confident that it hasn't grown a bunch of new vulns in the next three releases, and you could quickly audit it again to be sure.
Alas, practically nobody takes you seriously if you advocate for simplicity. Usually it's the opposite; I tend to get attacked if I suggest that a program/system might be too complex.
I think you never saw how pledge works.
SeLinux is complex. Pledge can be a piece of cake.
We truly need to work more towards eliminating every memory unsafe language in use today, until then we're fighting a forest fire with a bucket of water.
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).
So with regard to C, I would say it is not objectively inferior like QWERTY became, it's actually pretty well designed. It does produce fast code. I use it myself sometimes, not a bad language for simple algorithm prototypes of under 60 lines. But it's based to a huge degree on characters, the difference between code that works and code that fails can come down to characters, C is about characters, pretty much any character, there's no margin of error. Whereas with Lisp, you have parentheses for everything, you have an interpreter but you can also compile it, I am actually able to trust Lisp in a way that is out of the question with C. There's just so incredibly many gotchas and pitfalls, buffer overflows, it's endless, you have to really know what you're doing if you want to do stunts with pointers, memory, void types.
I guess the bottom line is if you're want your code to be perfect, and you write it in C, you can't delegate to the language, you yourself have to code that code perfectly in the human capacity of perfection.
Clarifying that what I mean by this is that it's not realistic to expect large C codebases to be perfect. Bug-free, with no exploits. Perfect. Same thing.
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.
One might make the argument that Oberon, with its System module, provides the same memory control abilities but few of the disabilities of C.
> so claiming C is only good for 60-line prototypes is just weird.
That seems like a misrepresentation of the claim above?
> 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.
Well, not really. Lisp is actually about trees of objects. The evaluator doesn't even understand sequences of characters. That you can enter it as a sequence of characters is purely coincidental, but there have been structured syntactic tree editors (sadly they went down for being proprietary and expensive at the time).
Sure, and that would be a good argument, there are several interesting languages out there that do various things better than C. I'm not intimately familiar with the Wirth languages, but I thought Oberon provided garbage collection?
> [...] misrepresentation [...]
Fine, they never claimed it was only good for that, but I still find it weird to claim that "it's fine, it's great for X" where X is a thing that the language is not particularly good at, while ignoring Y, the thing it's well known for.
> [...] trees of objects [...]
I just don't think that "about characters" or "about trees of objects" is an interesting way to differentiate between programming languages, and I think that this discussion is actually confusing between two different properties. First, is how the source code is represented and edited. It's almost always as a plain text file. Some languages have variants on the plain text file: SQL stored procedures are stored on the RDBMS, Smalltalk stores source code in a live environment image. There are other approaches, such as visual editing as-in Scratch, or Projectional Editing (https://martinfowler.com/bliki/ProjectionalEditing.html) as in... um... Cedalion? I don't actually know any well-known ones.
The other property is how the language internally represents its own code. Sure, Lisp has the neat property that its code is data that it can manipulate, but other languages represent their code as (abstract) syntax trees, too. Basically every compiler or interpreter for a 3rd generation language or above, i.e., anything higher-level than assembly language, parses source code the same way: tokenization then parsing into an abstract syntax tree using either manually-coded recursive descent, or a compiler generator (Bison, Yacc, Antlr, Parser combinators, etc.) So your point that the Lisp evaluator doesn't even understand sequences of characters is true for any compiler, they all operate on the AST.
I think that there's a point to be made somewhere in here that one language's syntax can be more error-prone than another's, but that wasn't the argument being made... Not that I understood, anyway.
Lisp does not really operate on an AST. It operates on nested token lists, without syntax representation. For example (postfix 1 2 +) can be legal in Lisp, because it does not (!) parse that code according to a syntax before handing it to the evaluator.
Lisp code consists of nested lists of data. Textual Lisp code uses a data format for these nested lists, which can be read and printed. A lot of Lisp code, though, is generated without being read/printed -> via macros.
What you say about Lisp code being generated without being read or printed is of course true, and while Lisp takes that idea and runs with it, it's not exactly unique to Lisp either; Rust's macro can do the same thing, without S-expressions. In other languages you usually generate source code, for example Java has a lot of source code generators (e.g., JAXB's XJC that used to come with the JDK).
There are lots of language with code generators. Lisp does this as core part of the language and can do it at runtime as part of the evaluation machinery.
The constitutents of the list are not "tokens" in Common Lisp. ANSI CL makes it clear that the characters "postfix", in the default read table, are token constituents; they get gathered into a token until the space appears. That token is then converted into a symbol name, which is interned to produce a symbol. That symbol is no longer a "token".
I'm not quite sure that this is what actually happened: https://repository.kulib.kyoto-u.ac.jp/dspace/bitstream/2433...
Or given how new it is, it's likely majority written in Swift when presenting a native app
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 Haskell Lego Edition is better than no Haskell at all, and Rust is cool because now that it’s proven affine/linear typing can work, someone will probably get it right soon.
But if I can buy shares in: “shit still gets rocked constantly”, I’d like to know where.
Gatekeeping much?
I think I’ve paid my cover-fee on an opinion.
Or were you just dissing knowing things?
Rust won't solve logic bugs but it can help bring up the foundations. So long as memory safety bugs are so pervasive we can't even properly reason on a theoretical level about logic bugs. The core theorem of any type system is "type safety" which states that a well-typed program never goes wrong (gets stuck, aka UB). Only then can you properly tackle correctness issues.
> Rust is cool because Haskell Lego Edition is better than no Haskell at all, and Rust is cool because now that it’s proven affine/linear typing can work, someone will probably get it right soon.
I don't understand the condescending remarks about "Haskell Lego Edition". I do agree that Rust has shown that substructural type systems work and are useful, and that they will be a 'theme' in the next batch of languages (or I can hope).
I could just as easily throw around words like “anti-intellectual” if my goal was to distract from the point rather substantially replying.
But the attitude is an invitation to getting made fun of. It’s absurdly intellectually dishonest when Rust-as-Religion people actively hassle anyone writing C and then get a little precious when anyone mentions Haskell and then extremely precious when they step on the landmine of the guy who likes Rust enough to know the standard, the compiler, the build tool, the people who wrote the build tool, and generally enough to put it in its place from a position of knowledge.
SSH servers? Yeah, I’d go with Rust. Web browsers? In a perfect world, lot of work. Even for Mozilla who timed the fuck out on it.
Everything ever so no security problem ever exists ever again? Someone called it the “green energy of software security” on HN like this year.
It’s not the coolest look that one of my “blow off some steam” hobbies is making those people look silly, but there are worse ways to blow off some steam.
Comparisons to other languages like Haskell don't really work, since they don't fit in the same space nor have the same goals as Rust or C.
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.
I'm searching your posts in this topic trying to find something of value and coming up short. You assert that you know rust, and therefor your opinions have merit, but... lots of people know rust and disagree. But somehow your opinions are More Right and the others are just religious Rust shills.
I don't think you know what you're talking about honestly. If you want to pick fights on HN that's cool, we all get that urge, but you're really bad at it.
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.
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.
I think regardless, you’re right, we will still have logic bugs… but that example is also an “exception proves the rule” kind of thing.
https://news.ycombinator.com/item?id=19138602
https://www.zdnet.com/article/chrome-70-of-all-security-bugs...
- sane integers: no unsafe implicit cast, more ergonomic overflow/saturate/checked casts
- sane strings: slices with length, standardized and safe UTF-8 operations
- expressive typing preventing API misuse: monads like Optional/Result, mandatory exception handling, better typedefs, ADTs vs tagged unions
And even without the full Rust ownership model, I'd expect the following to solve a majority of the memory safety problems:
- array bounds checks (also string bounds checks)
- typed alloc (alloc a specific type rather than N bytes)
- non-null types by default
- double-free, use-after-free analysis
- thread-save std APIs
In the write-up you linked, Section 2 is a missing error check => Result<T> would surface that. The macOS case contains a relative path vs string comparison => expressive typing of Path would disallow that. DriverKit exploit is a Non-NULL vs NULL API mistake. Kernel PAC is a legit ASM logic bug, but requires a confusion of kernel stack vs. user stack => might have been typed explicitly in another language.
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...
Surely we should compare tight Rust (with some 'tight' unsafe sections) against tight C?
I just think if mistakes need to be literally low as possible you’ve got a better bet than Rust unsafe.
The language spec is smaller, the static analyzers have been getting tuned for decades, and the project leaders arent kinda hostile to people using it in the first place.
&mut aliasing is a good example of running into instant UB in unsafe rust, but there are many more that you have to be aware of.
I would check out the unsafe rust "book" for yourself and see what you think. There is a section where you implement Vec and some other data structures from scratch!
Besides equivocating between a pervasively unsafe-by-default language and one with an explicit bounded opt-in is a little disingenuous. Time after time, it has been shown that even expert C developers cannot write memory safe C consistently, each line of code is a chance to blow up your entire app's security.
https://steveklabnik.com/writing/you-can-t-turn-off-the-borr...
99% of the time if you're fighting the borrow checker and just want a quick solution, that solution is `clone` or `Arc<Mutex<T>>`, not `unsafe`. Those solutions will sacrifice performance, but not safety.
I've seen unsound unchecked casts from &UnsafeCell or *mut to &mut in multiple codebases, including Firefox itself: https://github.com/emu-rs/snes-apu/blob/13c1752c0a9d43a32d05..., https://searchfox.org/mozilla-central/rev/7142c947c285e4fe4f....
And, most of the time unsafe code is not required. I think many people will just use clone too much, or Arc rather than unsafe. Additionally, I have never seen unsafe code at least where I work.
Also backwards compatibility is a feature many wouldn't give away for extra security, at least not now.
https://medium.com/@tinocaer/how-microsoft-is-adopting-rust-...
https://preettheman.medium.com/this-is-what-apple-uses-rust-...
- Add reference counting to ObjC to get rid of a lot of use after free bugs (still of course possible because it's just a language suggestion and not strictly enforced like Rust or Swift)
- push for adding ObjC notations to let the tooling help catch some set of bugs. Still not perfect by any means but helps a little.
- created an entirely new memory safe language as Swift.
Cyber security is national security is the people’s security. Ever since my aunt was doxxed and had her online banking money stolen I’ve become a cyber security hardliner.
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.
Airtight sandboxing would be easier in a memory safe language prevents certain classes of bugs.
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.
Log4Shell wasn't a bug, log4j worked as expected and documented. It's just a stupid idea for a logging library to work in such a way.
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.
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.
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.
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.
struct dev { int a, b; } *p; p = (struct dev *) 0x12345678;
int *q = (int *) p; q[2] = 0;
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.
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...
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 sort of thing that good programmers tolerate. (Of course, such references may occur when there are bugs - that's the reason for the run-time check - but not when a well-written program is operating as intended.)
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...
Don’t get me wrong, I often fell into this as well, but I think programmers really should get a bit of an ego-check sometimes, because (not you) it often affect discussions in other fields as well where we don’t know jackshit about.
1. I can get my ego so wrapped up in my own idea that, even once I have the necessary information to see that it's wrong, I still don't abandon it. In fact, this always happens to some extent; when I change my mind it's always embarrassing in retrospect how blind I was. But the phenomenon can be more or less extreme.
2. In a context where posturing to appear smart and competent is demanded, such as marketing, advocating totally stupid ideas puts me at a disadvantage, even if I recant later. Maybe especially then, because it reminds people who might have forgotten.
3. People who know even less than I do about a subject may be misled by my wrong ideas.
4. This approach is most productive when people who know more than I do about a subject are kind enough to take the time to explain why my ideas are wrong. This happens surprisingly often, both because people are often kind and because the people who know the most about a subject are generally very interested in it, which means they like to talk about it. Still, attention of experts is a valuable, limited resource.
5. People who know more than I do about a subject can get angry and defensive when I question something they said about it, particularly if they're mediocre and insecure. The really top people never act this way, in my experience; if they pay attention at all, either they can explain immediately why I'm wrong, as AlotOfReading did here (though I may not understand!) or they go "Hmm, now that's interesting," before figuring out why I'm wrong. (Or, occasionally, not.) But people with a good working understanding of a field may know I'm wrong without knowing why. And there are always enormously more of those in any field than really top people.
So, I try to do as much of the process as possible in my own notebook rather than on permanently archived public message boards. The worst is when group #3 and #5 start arguing with each other, producing lots of heat but no light.
My theory about why the angry and defensive people in group #5 are never the top people is that they stopped learning when they reached a minimal level of competence, because their ego became so attached to their image of competence that they stopped being able to recognize when they were wrong about things, so they are limited by whatever mistaken beliefs they still had when they reached that level. But maybe I'm just projecting from my own past experience :)
It would be nice if everything was memory safe, but making media decoding memory safe would help a lot.
There is probably not a check Apple can write to fix this problem with memory safe programming languages. And Apple can write all possible checks. There's something profound about that.
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.
Of course if they dropped all other development and told their employees to rewrite to rust, they may end up with a piece of software written in rust but no customers.
Now: rewrite 20 years worth of code.
Let's make sure we're clear: I agree --- and, further, assert that every other serious person agrees --- that memory safety is where the industry needs to go, urgently.
In that context, even a small architectural difference can be seen as a high barrier.
And a lot of that was design work that still holds, and a lot of that was code that has been obsoleted.
That decreases the amount of code to replace, doesn't it?
For code added in the past, more evolution means that for every X lines of code written, a smaller and smaller fraction of X still exists. Which means less work to replace the end product.
Languages and understanding them is not special, but decades of development of two different kernels is a huge time investment. Even though Linus Torvalds wrote the basic Linux kernel in 5 months, it was very simple at first.
I doubt writing an entire POSIX-compatible replacement for a kernel would be a small or quick endeavor, and Apple has shown resistance to adopting anything with a GPL 3 license iirc. That is why they switched to ZSH from Bash.
Still a gargantuan effort, but for them it doesn't require everyone learn Rust, just to learn Swift, which is kind of table stakes for a lot of user facing dev I'm sure there.
It'll take years to have impact, but so what? They can start now, they have the money.
> nobody disagrees with this (someone will here, but they don't matter)
There are so many people out there who don't understand the basics. HN can be sadly representative.
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.
Writing things in C correctly takes more time than in rust (once you get past the initial learning curve)
Writing things in C that appear to work may take less time.
I think we can be reasonably sure that Apple didn't introduce those image parsing bugs intentionally. But that means they thought it was correct.
Part of that is because I'm working in code where security is constantly paramount, and trying to reason about a C or C++ codebase is incredibly difficult. Maybe I get lucky and things are using some kind of smart ptr, RAII and/or proper move semantics, but if they're not then I have to think about the entire call chain. In rust I can focus very locally on the logic and not have to try and keep the full codebase in my head
For instance, in the past I worked at a sort of active directory but in the cloud company. We identified parsers of user submitted profile pictures in login windows as a privilege escalation issue. We couldn't find memory safe parsers for some of these formats that we could run in all these contexts, and ended up writing a backend service that had memory safe parsers and would recompress the resulting pixel array.
Rust parsers at the time would have greatly simplified the workflow, and I'm not sure how we would have addressed the problem except as whack-a-mole at the time if there wasn't our central service in the middle (so MMS can't do that).
Some follow-up commentary: https://marc.info/?l=openbsd-misc&m=151233345723889
1. In the video he's saying that you can't replace memory safety mitigation techniques like ASLR with memory safe languages. He notes that there will always be some unsafe code and that mitigation techniques are free, so you'll always want them.
No one should disagree with that. ASLR is effectively "free", and unsurprisingly all Rust code has ASLR support and rapidly adopts new mitigation techniques as well as other methods of finding memory unsafety.
2. The link about replacing gnu utils has nothing to do with memory safety. At all.
Even if it were related, it would simply be an argument from authority.
This is completely misleading. The vulnerabilities that exist in those languages are completely different. They often are also far less impactful.
Memory safety vulnerabilities typically lead to full code execution. It is so so so much easier to avoid RCE in memory safe languages - you can grep for "eval" and "popen" and you're fucking 99% done, you did it, no more RCE.
The C in use today wasn't written by experts either. And if it was, we can leave it alone for now, or at least until said experts get tired of maintaining it.
let’s kill bytes. :P
The truth is that “Zero-Click” hacks are becoming increasingly rare.
But of course everything is new for journos unfamiliar with the field.
That or maybe drive-by downloads / java/activeX code execution, which have become more rare
Guy’s a boss.
There really isn't something new here other than a fancy name - or I am not seeing the point.
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 on the victims device.
A non zero click vulnerability can be mitigated by being cautious. A zero click vulnerability cannot.
You get owned without clicking hence zero click. Is it different from RCE? A subset? Doesn't matter. Title could have said RCE.
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?
I think this just goes to show how silly this new terminology is.
RCE occurs on a system with a listening daemon/service (e.g. web, SQL, DNS SSH).
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).
> 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 to make an artificial distinction based on some irrelevant L4 differences.
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 useful as a distinction in your line of work doesn't necessarily mean that it's not useful to anyone ...
iMessage isn’t meaningfully different from Apache, instead of listening on a TCP number it listens on your Apple user id.
From any useful perspective, RCE and zero-click exploits are the same thing. The latter is just a fancy name for the moron journalists like the one who wrote this article to bandy about to lure in some readers.
And you're definitely right that they are far more rare. Worms used to be nasty is now fast and easily they spread. Security has come a long way since then.
That said, we could go further on security. But is selling people on using more secure software and hardware. Even something as simple as bounds checking has a cost. Look at the reception of the Windows 11 change to have Virtualization Based Security turned on by default. People are upset about it because it takes away performance for security that they claim they don't need on their home computer.
And then there's resistance from developers. For some reason people get really upset about mechanisms designed to improve security without increasing runtime overhead when they make compile time take longer. If your application is used by any significant number of people, surely the amount of runtime you're saving dwarfs the amount of extra time to compile.
Few vaguely reliable RCE bugs aren’t wormable. Even ones requiring significant user interaction are wormable, office macros are wormable.
Workable bugs are far more common than actual worms.
Most of it is not behind air gap. And unless things get a lot worse it wont be.
Proper air gaping is hard, expensive and pain in the ass, on the ongoing basis.
That's why almost none does it. Not even most military systems are air gaped.
And yet in most organizations, airgapping is an alien concept. Even for machine tools that could kill someone.
Security vs convenience...
It's a special kind of naive to assume that airgapping is a technological problem rather than a human behavior problem.
Systems need to work assuming that they are bathed in a hostile environment at all times.
1. Memory safety mitigations became much more common (Vista)
2. Browsers adopted sandboxing (thanks IE/Chrome)
3. Unsandboxed browser-reachable software like Flash and Java was moved into a sandbox and behind "Click to Play" before eventually being removed entirely.
4. Auto-updates became the norm for browsers.
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.
So it's not that security is getting worse, it's that security got better really really quickly, we basically faffed around for a decade more or less making small, incremental wins, and attackers figured out techniques for getting around our barriers.
If we want another big win, it's obvious. Sandboxing and memory safety have to be paired together. Anything else will be an expensive waste of time.
It’s still a completely different world. We’ve come a long way from back when Paunch was printing money with Blackhole.
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.
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.