Exploiting a heap overflow in the FreeBSD wi-fi stack

https://www.thezdi.com/blog/2022/6/15/cve-2022-23088-exploiting-a-heap-overflow-in-the-freebsd-wi-fi-stack

by todsacerdoti • 4 years ago

137 27 4 years ago

thezdi.com

lukestateson• 4 years ago

TIL: FreeBSD has wi-fi stack

teaearlgraycold• 4 years ago

lol. No 802.11ac yet.

NavinF3• 4 years ago

Oh wow I thought you were joking, but they’re literally 3 generations behind. I was recently complaining about the slow adoption of Wi-Fi 6E in phones, but now I know that true despair looks like.

nazgulsenpai• 4 years ago

Will be interesting to see if the PlayStation 4 jail breaking community can find some use for this!

djcannabiz• 4 years ago

Memory safe languages!!!!!

throwawaymaths• 4 years ago

This is a heap overflow; not a UAF/DF vulnerability. Since there's a lot of pressure to make networking code fast, What you kind of want is array bounds checking on by default and set unchecked on a method by method basis once you know that a particular array access is in the hot path and an index check is known to be rate limiting. That besides, having the kernel panic on bounds violation can be an entry point into other vulnerabilities, even though rebooting your machine is almost certainly better than rogue memory access

pjmlp• 4 years ago

Yeah, except bounds checking isn't something that C has, and one reason they happen all the time in C code, is that manually checking for them is a continuous proof of failure for the last 50 years.

theamk• 4 years ago

Doesn't FreeBSD have KASLR? It would make thus attack much harder.

rs_rs_rs_rs_rs• 4 years ago

It does not have KASLR and it does not even have userland binaries ASLR enabled by default(not that it matters for this vulnerability).

https://twitter.com/wdormann/status/1528742791383334917

It would make thus attack much harder

It won't make it much harder, just a teensy bit harder.

https://grsecurity.net/kaslr_an_exercise_in_cargo_cult_secur...

comex• 4 years ago

grsecurity is very… opinionated. In reality, it may or may not be possible to use this vulnerability without knowing any addresses beforehand. If it’s not, then if the KASLR implementation is good enough, successful exploitation would be impossible without an extra infoleak vulnerability, which is certainly nontrivial to find for a remote attack like this one. (Though even when it comes to local attacks, the post somewhat exaggerates how difficult it is to prevent such vulnerabilities.)

Also, in this particular case, if there are multiple vulnerable devices in the vicinity, it might be hard to ensure that your crafted beacon frame only reaches one of them and not the others. So it’s helpful if the exploit payload is fixed rather than needing to be customized per target - something which is much less likely to be possible with KASLR.

nix237• 4 years ago

ASLR enabled by default

True but since 13.1 you can enable it in the installation-tui (in the hardening dialog)

jokoon• 4 years ago

Unrelated, but I have an Intel wifi chip, and i regularly have to restart the wifi firmware/chip, it just seems to crash.

I hope it's not a vuln...

Exploiting a heap overflow in the FreeBSD wi-fi stack

Related Stories