In this networked world, it really is a terrible language, there is no excuse for it
The only authority this program should have is network access, some compute time and permission to create and write to one or more files. Nothing more.
Though this is where almost all of our currently popular programming languages and operating systems are failing. They are fundamentally broken. Just on account of security, monolithic kernels are a terrible idea. And sandboxing hasn't even been an afterthought in most languages and virtual machines. Even on the hardware level, secure compartmentalization and access mechanisms are a joke.
That would be a good start, because it would allow one to "hollow out the attack surface" - a great concept I've encountered in the erights community. Primitives that allow one to gradually secure a system in the future when the need arises.
Though unfortunately it doesn't provide the level of expressivity and flexibility that a full capability security architecture would.
The world has a great deal to learn from the likes of KeyKOS, seL4 and Genode, i don't see any of these issues going away without their adoption (or at least their ideas, in other systems).
Those are two separate things though. C is more vulnerable than Rust, but either way we should properly sandbox our applications even if they are written in a memory-safe language like Rust (which is not infallable, it's just safer).
One issue is if cURL is allowed to write to "one or more files", then how do you prevent it from writing to a key configuration file or sensitive one that has a lot of downstream effect or write a Bash script that could launch further attacks?
Edit: Just because it seems pertinent, I noticed the line """"50% of past curl vulnerabilities are "C mistakes"""" in the slides linked by the post above.
Why hasn't Apple rewritten libtiff, libpng, libjpeg, libwebp, et c in Swift?
Their flagship moneymaker keeps getting popped via these, and they have thousands of engineers and a memory safe first party language. The zeroclick from a few weeks ago relied on a chain, the second most important of which (CVE-2023-41064) was in libwebp. (The first most important was a kernel privilege escalation. XNU is c and cpp, of course.)
I really can't imagine that writing performant replacements for these libraries would be that daunting a task for them, and it would permanently shut down an entire class of repeated, ongoing vulnerabilities. I really don't understand why Apple relies on 3p code for format parsing/decoding when it has proven over and over again to be a source of brand damage.
I’m gonna guess apple has considered the ROI on this, the negative publicity can’t be good for them but in the context of apple id somewhat agree. I consider iOS probably more secure than desktop operating systems, and it’s the Crown Jewels of my life.
Curl is maintained by a much smaller set of people, and is delivered for free.
I'm talking about for use in Apple's first-party apps, like PassKit/Wallet, which is how the zeroclick happened recently. Apple gets to choose what codecs PassKit uses.
They also use them in Safari, AFAIK.
I'm also pretty sure most consumers of them are using them via ImageIO, which is under Apple's exclusive control.
Swift is probably not quite good enough for that type of library actually. There was a lot of hype about it being an everything language, but I'm not sure if it actually is for a low level graphics decoding library. For example, a core internal library of SwiftUI is written in C++, ActionGraph, and that is a pretty new thing!
Also apple can be slow to write things in new coding languages internally, there is a lot of stuff still in Objective-C and will be for many, many years.
Let’s wait and see what the vulnerability is. Maybe it doesn’t have anything to do with the pitfalls of C. But if it does, expect to read a lot more comments like this.
I wonder whether we'll ever get to a point where the kernel, the drivers and the userland software are all written in memory safe languages, possibly with other safe mechanisms and abstractions thrown in; yet to have it become mainstream and as popular as Linux is now.
Might take decades of work though and probably nobody cares enough for something like that.
Android has been replacing a lot of core components with Rust and other memory safe languages. The Asahi team built a GPU driver in Rust recently. Seems like things are moving in the right direction.
Android makes frequent use of unsafe but in their blog post they claim an unsafe rust line has never caused a memory issue. Because they are such a small and focused selection of the code, full scrutiny can be used for any unsafe lines.
Google has actually audited using cargo-vet every crate that chromiumos and fucshia depend on that have unsafe in it. They also have some additional rules related to cryptographic algorithms. I'm pretty surprised they haven't done the same for rust usage in android. https://github.com/google/rust-crate-audits
Kernels and device drivers have to read and write from hardware registers. Doing so is fundamentally "unsafe", by Rust's definition. Hardware is a big bag of external state which can often be mutated external to any software running on the CPU. It's a device driver's job to abstract away this unsafe interface and (ideally) try to present a safe one.
That's not to say there aren't benefits to using languages other than C for this stuff. But a Rust kernel will necessarily rely on `unsafe` blocks to do its job.
All software handling untrusted input should be sandboxed really. Even if curl was written in a language that prioritises memory safety, there would still be plenty of opportunity for harmful, exploitable bugs to be introduced.
This is correct (assuming the same facetiousness as the gp comment), and even extends to algorithmic oversights and hardware errors. Your threads not stepping on each other's toes and your memory boundaries being automatically checked doesn't make you invulnerable.
