Live data from Hacker News

Beacown (Linux WiFi Exploit)

github.com

21–26 of 26 posts

Re: Beacown (Linux WiFi Exploit)

#21
post #11
post #9

Earlier quoted context omitted.

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.

> Promoting Rust might feel good, but it does not have the desired effect.

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.

Re: Beacown (Linux WiFi Exploit)

#22
post #19
post #11

Earlier quoted context omitted.

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.

Rust isn't the only game in town moving into safer lands. > 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…

> Rust isn't the only game in town moving into safer lands.

No, it's not. Only security through isolation is a viable approach, see https://qubes-os.org.

Re: Beacown (Linux WiFi Exploit)

#23
post #19

Earlier quoted context omitted.

Rust isn't the only game in town moving into safer lands. > 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…

> Rust isn't the only game in town moving into safer lands. No, it's not. Only security through isolation is a viable approach, see https://qubes-os.org .

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.

Re: Beacown (Linux WiFi Exploit)

#24
post #23

Earlier quoted context omitted.

> Rust isn't the only game in town moving into safer lands. No, it's not. Only security through isolation is a viable approach, see https://qubes-os.org .

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?…

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.

See also: http://www.qubes-os.org/news/2017/04/26/qubes-compromise-rec....

Re: Beacown (Linux WiFi Exploit)

#25
post #23

Earlier quoted context omitted.

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?…

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. See also:…

Thanks for the overview.

Re: Beacown (Linux WiFi Exploit)

#26
post #10
post #8

Earlier quoted context omitted.

Plenty of Android devices have kernels that are too old to be vulnerable. Versions 5.1 and newer are vulnerable.

Which versions of Android would that translate to?

It seems to me that Android version and kernel version are not linked in any meaningful way.

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).

Post reply on HN