Exploiting a heap overflow in the FreeBSD wi-fi stack
thezdi.com
thezdi.com
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.