Exploiting a heap overflow in the FreeBSD wi-fi stack(thezdi.com)
thezdi.com
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
29 comments
Will be interesting to see if the PlayStation 4 jail breaking community can find some use for this!
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...
I hope it's not a vuln...
Doesn't FreeBSD have KASLR? It would make thus attack much harder.
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...
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...
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.
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.
>ASLR enabled by default
True but since 13.1 you can enable it in the installation-tui (in the hardening dialog)
True but since 13.1 you can enable it in the installation-tui (in the hardening dialog)
Memory safe languages!!!!!
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
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.
TIL: FreeBSD has wi-fi stack
/s
/s
[deleted]
lol. No 802.11ac yet.
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.
True but Linux and Mac is also one generation behind, but in a much more important field...filesystems ;)
is that so. freebsd and linux share the same zfs code and linux also has btrfs.
like... where is linux behind?
like... where is linux behind?
Soft updates!
It's a dead-end design, you say? Bah, that's quitter talk!
It's a dead-end design, you say? Bah, that's quitter talk!
>It's a dead-end design
That's like saing journale'd filesystem are dead-end design, you don't make any sense.
No sure if you don't know it, but Netflix uses UFS2 and FreeBSD as storage on their CDN[1], on the other hand, for the easy and unreliable stuff aka containers Linux is acceptable, just restart it. ;)
[1] https://openconnect.netflix.com/en/appliances/#software
https://www.usenix.org/legacy/publications/library/proceedin...
>>Journaling Versus Soft Updates: Asynchronous Meta-data Protection in File Systems
>>10 Conclusions
>>Soft Updates exhibits some side-effects that improve performance, in some cases significantly. Its ability to delay deletes is evidenced most clearly in the microbenchmark results. For the massive data set of the Netnews benchmark, we see that Soft Updates' ordering constraints prevent it from achieving performance comparable to the asynchronous journaling systems, while for the small Postmark dataset, Soft Updates backgrounding of deletes provides superior performance. The race between increasing memory sizes and increasing data sets will determine which of these effects is most significant.
That's like saing journale'd filesystem are dead-end design, you don't make any sense.
No sure if you don't know it, but Netflix uses UFS2 and FreeBSD as storage on their CDN[1], on the other hand, for the easy and unreliable stuff aka containers Linux is acceptable, just restart it. ;)
[1] https://openconnect.netflix.com/en/appliances/#software
https://www.usenix.org/legacy/publications/library/proceedin...
>>Journaling Versus Soft Updates: Asynchronous Meta-data Protection in File Systems
>>10 Conclusions
>>Soft Updates exhibits some side-effects that improve performance, in some cases significantly. Its ability to delay deletes is evidenced most clearly in the microbenchmark results. For the massive data set of the Netnews benchmark, we see that Soft Updates' ordering constraints prevent it from achieving performance comparable to the asynchronous journaling systems, while for the small Postmark dataset, Soft Updates backgrounding of deletes provides superior performance. The race between increasing memory sizes and increasing data sets will determine which of these effects is most significant.
It's not that it isn't a fantastic design—I believe as much as the next person that UFS2 is basically best-in-class as a "traditional" dumb filesystem, and that soft updates is fundamentally a Right Approach. I wouldn't have mentioned it if I didn't!
But it's hard not to see that it's darn near barren ground for further work in filesystem design. And it's easy to see why if you scan the first paper—just look at the dependency flowcharts! Fundamentally the design is ... hard for mere mortals to work on. It's practically a miracle that it even happened once; nobody is keen on starting any new implementations.
I choose to fault filesystem implementers for not being (more) superhuman for this failing, obviously.
But it's hard not to see that it's darn near barren ground for further work in filesystem design. And it's easy to see why if you scan the first paper—just look at the dependency flowcharts! Fundamentally the design is ... hard for mere mortals to work on. It's practically a miracle that it even happened once; nobody is keen on starting any new implementations.
I choose to fault filesystem implementers for not being (more) superhuman for this failing, obviously.
I’m not sure where the legend about softupdates being more complicated then journaling came from, but even comparing number of lines of code between SU and XFS journaling is enough to disprove it.
The difficulty is not that there's too much code.
The difficulty is allegedly that the mechanism is too complex. Which seems to be just an urban legend.
>btrfs
Haha, have fun with that Clown College of a Filesystem.
ZFS is not part of Linux.
Haha, have fun with that Clown College of a Filesystem.
ZFS is not part of Linux.
The open-source IllumOS code in FreeBSD had fallen behind Linux ZoL (ZFS-On-Linux). FreeBSD adopted ZoL to keep up with new bugfixes, enhancements, etc.
https://www.freebsdnews.com/2019/01/10/zfs-on-freebsd-zof-is...
So, for open-source, ZoL is the 'mainstream' ZFS.
https://www.freebsdnews.com/2019/01/10/zfs-on-freebsd-zof-is...
So, for open-source, ZoL is the 'mainstream' ZFS.
>So, for open-source, ZoL is the 'mainstream' ZFS.
Wrong, there is no ZoL anymore "just" OpenZFS:
https://openzfs.org/wiki/Main_Page
>>The OpenZFS project brings together developers from the Linux, FreeBSD, illumos, MacOS, and Windows platforms. OpenZFS is supported by a wide range of companies.
And again ZFS is NOT part of Linux.
Wrong, there is no ZoL anymore "just" OpenZFS:
https://openzfs.org/wiki/Main_Page
>>The OpenZFS project brings together developers from the Linux, FreeBSD, illumos, MacOS, and Windows platforms. OpenZFS is supported by a wide range of companies.
And again ZFS is NOT part of Linux.
[deleted]