Live data from Hacker News

Beacown (Linux WiFi Exploit)

github.com

11–20 of 26 posts

Re: Beacown (Linux WiFi Exploit)

#11
post #9
post #7

Quoted post unavailable.

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.

Re: Beacown (Linux WiFi Exploit)

#12
post #8
post #6

Earlier quoted context omitted.

Just to be clear, everyone really should panic. Right?

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

Older kernels are instead vulnerable to older bugs, since fixed, of not less severity, but more systematically exploited.

Re: Beacown (Linux WiFi Exploit)

#14
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.

[deleted]

Re: Beacown (Linux WiFi Exploit)

#15
post #7

Quoted post unavailable.

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

Re: Beacown (Linux WiFi Exploit)

#16
post #12
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.

Older kernels are instead vulnerable to older bugs, since fixed, of not less severity, but more systematically exploited.

Do you have any particular exploits in mind?

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.

Re: Beacown (Linux WiFi Exploit)

#17
post #3

[x] Catchy name [ ] 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.

Some sort of evil bee/cow hybrid with psychic (wifi) waves would work well as a logo, to help generate buzz.

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.

Re: Beacown (Linux WiFi Exploit)

#18
post #7

Quoted post unavailable.

It remains to be seen how the new Bluetooth stack introduced in Android 11 will get exploits.

The old one has plenty of them to show off due to typical memory corruptions handling network packets.

Re: Beacown (Linux WiFi Exploit)

#19
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.

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.org/t/implementing-parts-of-the-swift-c...

Re: Beacown (Linux WiFi Exploit)

#20
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.

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.

Post reply on HN