Re:Exploiting a heap overflow in the FreeBSD wi-fi stack
by comex on Thursday June 16, 2022 @08:38PM
(#31772731)
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.
Re:Exploiting a heap overflow in the FreeBSD wi-fi stack
by throwawaymaths on Thursday June 16, 2022 @07:06PM
(#31772107)
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
Re:Exploiting a heap overflow in the FreeBSD wi-fi stack
by pjmlp on Friday June 17, 2022 @01:32AM
(#31774434)
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.
Re:Exploiting a heap overflow in the FreeBSD wi-fi stack
by NavinF on Friday June 17, 2022 @01:53AM
(#31774538)
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.
Re:Exploiting a heap overflow in the FreeBSD wi-fi stack
by nix23 on Friday June 17, 2022 @07:36AM
(#31776692)
>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. ;)
>>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.
Re:Exploiting a heap overflow in the FreeBSD wi-fi stack
by naniwaduni on Friday June 17, 2022 @04:49PM
(#31784177)
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.
Re:Exploiting a heap overflow in the FreeBSD wi-fi stack
by trasz on Monday June 20, 2022 @10:01AM
(#31810455)
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.
Re:Exploiting a heap overflow in the FreeBSD wi-fi stack
by gryph0n on Friday June 17, 2022 @12:22PM
(#31780507)
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.
>>The OpenZFS project brings together developers from the Linux, FreeBSD, illumos, MacOS, and Windows platforms. OpenZFS is supported by a wide range of companies.
I hope it's not a vuln...
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...
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.
True but since 13.1 you can enable it in the installation-tui (in the hardening dialog)
/s
like... where is linux behind?
It's a dead-end design, you say? Bah, that's quitter talk!
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.
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.
Haha, have fun with that Clown College of a Filesystem.
ZFS is not part of Linux.
https://www.freebsdnews.com/2019/01/10/zfs-on-freebsd-zof-is...
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.
Like ~every other Filesystem? Not sure if you just lack that knowledge.