3 ms·

C software really needs to be used in a sandbox because this stuff is inevitable.

lithagger 3y ago
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.
- nurettin 3y ago
  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. Please do explain the negative reception.
KronisLV 3y ago
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.
- Gigachad 3y ago
  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.
  - candiddevmike 3y ago
    Is Rust memory safe if you have to use unsafe everywhere, like in the kernel?
    - Gigachad 3y ago
      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.
      - zorgmonkey 3y ago
        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 https://github.com/google/rust-crate-audits
- binary132 3y ago
  I feel that a sort of universal sandboxing is more likely
- anonymous_sorry 3y ago
  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.
deleted 3y ago
[deleted]
7373737373 3y ago
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.
- nickysielicki 3y ago
  The issue is not that there’s no way to do this, it’s that there’s no portable way to do this. A seccomp bpf implementation of https://man.openbsd.org/pledge.2 https://man.openbsd.org/pledge.2 could go a long way.
  - 7373737373 3y ago
    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).
  - chucky_z 3y ago
    like https://github.com/jart/pledge https://github.com/jart/pledge? i'm using this all over our production environment and it's very nice.
- xign 3y ago
  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?
hsbauauvhabzb 3y ago
I’m gonna start referring to these types of comments as ‘drive by rust evangelists’ Go write your own memory safe curl if one _actual_ vuln in 10 years is not within your risk appetite.
- theobeers 3y ago
  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.
  - hsbauauvhabzb 3y ago
    Does the root cause even matter when the ancestor poster is already blaming C? If we’re gonna start somewhere when it comes to memory safety, I assume fixing adobe acrobat would have a better ROI.
- sneak 3y ago
  Forget about Rust, and forget about drive-bys. 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.
  - hsbauauvhabzb 3y ago
    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.
geertj 3y ago
We shall see what the issue is next week.
- tremon 3y ago
  Sandbox escape because the C sandbox was written in C?
Joeboy 3y ago
If I skimmed this[0] right, it looks like curl is moving towards rust, in a piecemeal fashion. [0] https://daniel.haxx.se/blog/2022/02/01/curl-with-rust/ https://daniel.haxx.se/blog/2022/02/01/curl-with-rust/ 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.
xmodem 3y ago
I love hating on C as much as the next guy but I think we should wait until we see the vulnerability before jumping to conclusions.

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.

nurettin 3y ago
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. Please do explain the negative reception.

KronisLV 3y ago

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.

Gigachad 3y ago
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.
- candiddevmike 3y ago
  Is Rust memory safe if you have to use unsafe everywhere, like in the kernel?
  - Gigachad 3y ago
    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.
    - zorgmonkey 3y ago
      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 https://github.com/google/rust-crate-audits
binary132 3y ago
I feel that a sort of universal sandboxing is more likely
anonymous_sorry 3y ago
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.

deleted 3y ago

[deleted]

7373737373 3y ago

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.

nickysielicki 3y ago
The issue is not that there’s no way to do this, it’s that there’s no portable way to do this. A seccomp bpf implementation of https://man.openbsd.org/pledge.2 https://man.openbsd.org/pledge.2 could go a long way.
- 7373737373 3y ago
  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).
- chucky_z 3y ago
  like https://github.com/jart/pledge https://github.com/jart/pledge? i'm using this all over our production environment and it's very nice.
xign 3y ago
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?

hsbauauvhabzb 3y ago

I’m gonna start referring to these types of comments as ‘drive by rust evangelists’ Go write your own memory safe curl if one _actual_ vuln in 10 years is not within your risk appetite.

theobeers 3y ago
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.
- hsbauauvhabzb 3y ago
  Does the root cause even matter when the ancestor poster is already blaming C? If we’re gonna start somewhere when it comes to memory safety, I assume fixing adobe acrobat would have a better ROI.
sneak 3y ago
Forget about Rust, and forget about drive-bys. 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.
- hsbauauvhabzb 3y ago
  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.

geertj 3y ago

We shall see what the issue is next week.

tremon 3y ago
Sandbox escape because the C sandbox was written in C?

Joeboy 3y ago

If I skimmed this[0] right, it looks like curl is moving towards rust, in a piecemeal fashion. [0] https://daniel.haxx.se/blog/2022/02/01/curl-with-rust/ https://daniel.haxx.se/blog/2022/02/01/curl-with-rust/ 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.

xmodem 3y ago

I love hating on C as much as the next guy but I think we should wait until we see the vulnerability before jumping to conclusions.