Hi Kevin, Kevin Chadwick wrote: > > However I do believe Debian and Linux should be doing a lot more > outside of grsec/pax/gentoo hardened. I could be wrong but I'm under the > impression that Ubuntu is ahead (maybe just as more bleeding edge and > PAE by default etc. though I am surprised they don't ship two > kernels on their install or two cds for those few idiotic years intel > laptops dropped PAE for). I totally agree. > Your links are very old and miss out combining security features. This is true, they were intended for reference to the origin of those attacks, current papers on those exploit techniques (or even combined exploit techniques) can be easily obtained from a Google query :) > OpenBSD employs randomisation all over and recently starting with the > boot loader. you would have a real hard time making it run out of > entropy too. I'm told it's Not AS good but is a good start, has debian > considered running haveged by default? As I am somewhat involved with the bettercrypto.org project, haveged has come up quite a lot. The idea behind it is sound, the only problem I see is missing (to the best of my knowledge) security audits and review by cryptographers outside of the project itself. The original paper is now very dated and I have not found and solid audit paper (or even a paper that tries to attack haveged) on the web. I'm not sure if that's a good or a bad sign. Usually the Linux kernel itself provides more than enough entropy. This can (and probably should) be enhanced but should not be done in a specific distribution. > An abstract on this very subject > _______________________________________________________________________ > > (1) introduce/execute arbitrary code > (2) execute existing code out of original program order > (3) execute existing code in original program order with arbitrary data > > For example the well known shellcode injection technique belongs to (1) > while the so-called return-to-libc style technique belongs to (2). > > Before going into the analysis of the above techniques, let's note an > often overlooked or misunderstood property of combining defense > mechanisms. Some like to look at the individual pieces of a system and > arrive at a conclusion regarding the effectivenes of the whole based on > that (or worse, dismiss one mechanism because it is not efficient > without employing another, and vice versa). In our case this approach > can lead to misleading results. Consider that one has a defense > mechanism against (1) and (2) such as NOEXEC and the future userland > changes in PaX. If only NOEXEC is employed, one could argue that it is > pointless since (2) can still be used (in practice this reason has > often been used to dismiss non-executable stack approaches, which is > not to be confused with NOEXEC however). If one protects against (2) > only then one could equally well argue that why bother at all if the > attacker can go directly for (1) and then the final conclusion comes > saying that none of these defense mechanisms is effective. As hinted at > above, this turns out to be the wrong conclusion here, deploying both > kinds of defense mechanisms will protect against both (1) and (2) at > the same time - where one defense line would fail, the other prevents > that (i.e., NOEXEC can be broken by a return-to-libc style attack only > and vice versa). > _______________________________________________________________________ Yeah. I wasn't trying to argue that PaX/W^X is a bad idea, to the contrary. I was refering to stack canaries. I do question if building all packages with -fstack-protector is a good idea, of course plattforms are very fast now, but it bloats binaries with minimal added security. > Building exploit mitigations isn’t easy. It’s difficult because the > attackers are relentlessly clever. And it’s aggravating because there’s > so much shitty software that doesn’t run properly even when it’s not > under attack, meaning that many mitigations cannot be fully enabled. > But it’s absolutely infuriating when developers of security sensitive > software are actively thwarting those efforts by using the world’s most > exploitable allocation policy and then not even testing that one can > disable it. Nothing to add here, very well said! Aaron
Attachment:
signature.asc
Description: OpenPGP digital signature