I was thinking something similar. A cow with x's over the eyes, possibly glowing red; with antennae's instead of horns with wifi waves coming off them.
The idea that you could gain RCE without the user doing anything except being in range of a wifi hotspot—no need to run an app, load a website, or even open an image—strikes me as exceptionally concerning. It's not quite the holy grail of "connect this device to the internet anywhere in the world and get hacked within minutes", but it's coming close.
Even as a Rust user, I'd prefer to reduce the attack surface by having a userspace network stack. Tanenbaum gets the last laugh.
Of course, once it's in userspace you can write it in whatever language you want. But as a network-facing component, yes, it should preferably be written in a memory-safe language as much as possible, since it's extremely high-risk and the first target for remote adversaries.
Promoting Rust might feel good, but it does not have the desired effect. Promoting action that would have the desired effect would tend more to have the desired effect, even though less personally gratifying. Your choice, but being seen to choose reveals.
> I propose that we start requiring an existing Swift compiler to build the Swift compiler. This opens the door to non-optional (mandatory) parts of the compiler to be implemented in Swift.
While much better, and also a reason why plugins should go back to OS IPC instead of shared libraries when security is a priority, it also isn't bullet proof.
How does QubeOS prevent black box attacks?
Meaning, finding a sequence of process interactions that eventually lead to data corruption on the process in-memory data structures, which might enabled a specific execution sequence to do B instead of the expected A?
Process is still inside its sandbox, no way to own it via an exploit, however that sequence (if achieved) has enabled the attacker to influence its execution behaviour.
Qubes provides security through compartmentalization: https://www.qubes-os.org/faq/#how-does-qubes-os-provide-secu.... It does not care about a single compromised VM. It is designed with the assumption that any VM might be compromised. If you suspect a compromise, you recreate the VM from a trusted template. You also use a disposable VM for untrusted operations and offline VMs for security-critical things.
What do you mean? Keeping it on the kernel but written in Rust is certainly safer than keeping it on the kernel and written in C. In particular, Rust tends to catch bugs like exactly this one being exploited here (although the kernel developers may decide to turn this check off).
But, anyway, up to now there has been no project for rewriting the network stack. So you are arguing against a strawmen, and interestingly, losing.
Why is this certain? Nobody has written a wifi stack, or even a single wifi driver, for Linux. Until they do, we won't know if Rust will help with these kinds of security flaws.
> promoting kernel Rust will not fix anything, howsoever personally gratifying it may feel to engage in it.
I totally agree, you'd need to fix the broken things to fix anything, hopefully without writing more broken things on your way there and back, and ideally in a way that is unambiguous and easy to parse, unlike this sentence.
25 comments
[ 2.9 ms ] story [ 71.3 ms ] thread[ ] Catchy logo
Poor effort, only 50% of the way there. (No marks awarded for a working exploit, marketing doesn't care about that)
Edit: Marks should also be deducted for a lack of scary text claiming that everyone should panic.
My phone is Android 12 and the kernel is 4.19.x, which initially came out in 2018 (but is an LTS one, so it's fine).
The idea that you could gain RCE without the user doing anything except being in range of a wifi hotspot—no need to run an app, load a website, or even open an image—strikes me as exceptionally concerning. It's not quite the holy grail of "connect this device to the internet anywhere in the world and get hacked within minutes", but it's coming close.
Of course, once it's in userspace you can write it in whatever language you want. But as a network-facing component, yes, it should preferably be written in a memory-safe language as much as possible, since it's extremely high-risk and the first target for remote adversaries.
> Swift adoption continues its exponential climb and surpassed C++ this year.
From https://blog.timac.org/2022/1005-state-of-swift-and-swiftui-...
> I propose that we start requiring an existing Swift compiler to build the Swift compiler. This opens the door to non-optional (mandatory) parts of the compiler to be implemented in Swift.
From https://forums.swift.org/t/implementing-parts-of-the-swift-c...
No, it's not. Only security through isolation is a viable approach, see https://qubes-os.org.
How does QubeOS prevent black box attacks?
Meaning, finding a sequence of process interactions that eventually lead to data corruption on the process in-memory data structures, which might enabled a specific execution sequence to do B instead of the expected A?
Process is still inside its sandbox, no way to own it via an exploit, however that sequence (if achieved) has enabled the attacker to influence its execution behaviour.
See also: http://www.qubes-os.org/news/2017/04/26/qubes-compromise-rec....
But, anyway, up to now there has been no project for rewriting the network stack. So you are arguing against a strawmen, and interestingly, losing.
Why not? I don't have a bone in the fight (never written any Rust), but memory safe languages seem like such a no-brainer to me.
I totally agree, you'd need to fix the broken things to fix anything, hopefully without writing more broken things on your way there and back, and ideally in a way that is unambiguous and easy to parse, unlike this sentence.
The old one has plenty of them to show off due to typical memory corruptions handling network packets.