4 ms·

The organization of these status reports is outstanding and so structured, like the rest of FreeBSD's documentation and communication. I wish more of the Harde

by cm3 10y ago

The organization of these status reports is outstanding and so structured, like the rest of FreeBSD's documentation and communication. I wish more of the HardenedBSD features would land in FreeBSD trunk. Other than that, I'm really glad to see that it's making great progress, like RISC-V support. The address randomization feature in 11 is ASR (not ASLR), per the review comments by the inventor of ASLR (PaX dev), so it's a pity the initial HardenedBSD devs decided to not continue upstreaming things after they felt the ASLR patch review was taking too long. OPNsense seems to be basing itself on HardenedBSD, so that's nice to see.

tachion 10y ago
This is not exactly what happened. People behind HardenedBSD code take criticism of their code personally and are very, very, very reluctant to adhere to advices on correction of the code, or design or even processes around their code(one of the main points aganist accepting their ASLR code was that it wasn't designed, but ...just written) so the claims of that code being well tested, well written and in general production ready quality should be taken with a grain of salt. However, its worth noting, that if it wasnt for them persistently making a lot of 'noise' around this particular feature, FreeBSD guys wouldnt come up with their own implementation anytime soon.
- cm3 10y ago
  I see, that's unfortunate. TBH, I wasn't entirely sure what to make of the comments in the ASLR Phabricator ticket, and it looked like they gave up after failing to address the VM comments. Do you know if there are there plans to implement the rest of the important mitigation techniques?
  - tachion 10y ago
    To be honest, I am not sure there are such plans. First of all, there's that discussion (and lack of agreement) between FBSD implementation author and the ASLR idea author on what's the 'L' there really is (or what it should be), and second, there is another division of opinions wether the ASLR is worth much in first place, given there were successful bruteforce (and other) cracking reports for other platforms proud ASLR implementations.
    - aseipp 10y ago
      > wether the ASLR is worth much in first place, given there were successful bruteforce (and other) cracking reports for other platforms proud ASLR implementations. That is because ASLR, by itself, is almost totally worthless, and is meant as a stop-gap to stop certain direct code attacks (vs "data only" attacks). It is a stop-gap because most modern systems are completely riddled with things like infoleaks, and you only need to leak one pointer to actually defeat the setup completely. The real vector that's sitting around to be killed is control-flow based exploits (e.g. ROP, simple stack smashing, vtable ptr overwrites, all those de jour exploit techniques). You need a powerful form of control-flow integrity to stop this at the software level. You also need a method to actually help mitigate information leaks so they can do less damage, and increase attacker cost (e.g. "execute only pages" are worthless if all users have the same kernel image. I can just download your GENERIC kernel elf image, and just find the opcodes to do e.g. a ROP attack anyway. grsecurity uses compiler plugins that randomize kernel stacks and the compilation method with a particular private seed, at compile-time, so every compiled grsecurity kernel is different from the last one). TBQH: FreeBSD is probably better off copying the other twenty gazillion exploit mitigation features from grsecurity that can reasonably stop exploits, even by themselves, dead in their tracks - like UDEREF, KERNEXEC, refcount overflows, triggering the kernel on unmarked signed overflow, the compiler plugin features, etc. Those will actually ban classes of exploits outright, every time, and always work, without wasting time through lots of wincing over the finer details, like ASLR. You won't get to parade "look at our weak ASLR implementation!" (thankfully), but I feel we already have enough of that going around.
      - cm3 10y ago
        From what I understand, HardenedBSD basically ported GRsecurity features and added stuff like default-PIE compilation and a couple userspace tools.
- bch 10y ago
  An implementation of FreeBSD sensor framework[0] suffered a similar fate/criticism -- it was incorporated as a GSoC project (ported from OpenBSD iirc), and presented at BSDCan but happened to be ripped out just before (again, iirc) the presentation[1]... and phk[2] said (roughly) that "'good enough' is the enemy of 'good'", which as a phrase is simple, catchy, and worth remembering (I obviously did). The discourse around things like engineering decisions in the *BSD camps is mostly civilized, and a treat to witness... [0] https://www.openbsd.org/papers/bsdcan08-sensors.pdf https://www.openbsd.org/papers/bsdcan08-sensors.pdf [1] I attended the BSDCan this was presented at, and sat close to phk and witnessed the exchanges about the technical merits, problems, "'good enough' vs 'good'", but am recalling from memory. [2] Poul-Henning Kamp, https://twitter.com/bsdphk https://twitter.com/bsdphk
- digi_owl 10y ago
  That sounds oddly similar to GRSec. Sometimes i really do wonder about the _sec world...

by cm3 10y ago

tachion 10y ago

This is not exactly what happened. People behind HardenedBSD code take criticism of their code personally and are very, very, very reluctant to adhere to advices on correction of the code, or design or even processes around their code(one of the main points aganist accepting their ASLR code was that it wasn't designed, but ...just written) so the claims of that code being well tested, well written and in general production ready quality should be taken with a grain of salt. However, its worth noting, that if it wasnt for them persistently making a lot of 'noise' around this particular feature, FreeBSD guys wouldnt come up with their own implementation anytime soon.

cm3 10y ago
I see, that's unfortunate. TBH, I wasn't entirely sure what to make of the comments in the ASLR Phabricator ticket, and it looked like they gave up after failing to address the VM comments. Do you know if there are there plans to implement the rest of the important mitigation techniques?
- tachion 10y ago
  To be honest, I am not sure there are such plans. First of all, there's that discussion (and lack of agreement) between FBSD implementation author and the ASLR idea author on what's the 'L' there really is (or what it should be), and second, there is another division of opinions wether the ASLR is worth much in first place, given there were successful bruteforce (and other) cracking reports for other platforms proud ASLR implementations.
  - aseipp 10y ago
    > wether the ASLR is worth much in first place, given there were successful bruteforce (and other) cracking reports for other platforms proud ASLR implementations. That is because ASLR, by itself, is almost totally worthless, and is meant as a stop-gap to stop certain direct code attacks (vs "data only" attacks). It is a stop-gap because most modern systems are completely riddled with things like infoleaks, and you only need to leak one pointer to actually defeat the setup completely. The real vector that's sitting around to be killed is control-flow based exploits (e.g. ROP, simple stack smashing, vtable ptr overwrites, all those de jour exploit techniques). You need a powerful form of control-flow integrity to stop this at the software level. You also need a method to actually help mitigate information leaks so they can do less damage, and increase attacker cost (e.g. "execute only pages" are worthless if all users have the same kernel image. I can just download your GENERIC kernel elf image, and just find the opcodes to do e.g. a ROP attack anyway. grsecurity uses compiler plugins that randomize kernel stacks and the compilation method with a particular private seed, at compile-time, so every compiled grsecurity kernel is different from the last one). TBQH: FreeBSD is probably better off copying the other twenty gazillion exploit mitigation features from grsecurity that can reasonably stop exploits, even by themselves, dead in their tracks - like UDEREF, KERNEXEC, refcount overflows, triggering the kernel on unmarked signed overflow, the compiler plugin features, etc. Those will actually ban classes of exploits outright, every time, and always work, without wasting time through lots of wincing over the finer details, like ASLR. You won't get to parade "look at our weak ASLR implementation!" (thankfully), but I feel we already have enough of that going around.
    - cm3 10y ago
      From what I understand, HardenedBSD basically ported GRsecurity features and added stuff like default-PIE compilation and a couple userspace tools.
bch 10y ago
An implementation of FreeBSD sensor framework[0] suffered a similar fate/criticism -- it was incorporated as a GSoC project (ported from OpenBSD iirc), and presented at BSDCan but happened to be ripped out just before (again, iirc) the presentation[1]... and phk[2] said (roughly) that "'good enough' is the enemy of 'good'", which as a phrase is simple, catchy, and worth remembering (I obviously did). The discourse around things like engineering decisions in the *BSD camps is mostly civilized, and a treat to witness... [0] https://www.openbsd.org/papers/bsdcan08-sensors.pdf https://www.openbsd.org/papers/bsdcan08-sensors.pdf [1] I attended the BSDCan this was presented at, and sat close to phk and witnessed the exchanges about the technical merits, problems, "'good enough' vs 'good'", but am recalling from memory. [2] Poul-Henning Kamp, https://twitter.com/bsdphk https://twitter.com/bsdphk
digi_owl 10y ago
That sounds oddly similar to GRSec. Sometimes i really do wonder about the _sec world...