4 ms·

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 failin

by 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.

by cm3 10y ago

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.