Re: Proposing amd64-hardened architecture for Debian
previously on this list Aaron Zauner contributed:
I agree with MACs being questionable in that they are an extra
*FINAL* layer only really effective on simple systems where they
arguably aren't needed, can be circumvented by kernel exploits and
often MACs are used on systems despite the wide ranging capabilities of
DACs being ignored which are more reliable and less complex
(RedHat/Fedora failing to realise the power of existing tech like groups
is a classic example, Debian is better here).
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'm aware of this. Some of them also implement PaX (or W^X in OpenBSDs
> case). That said, it will probably improve security a bit, in particular
> against skiddies just running scripts of the web. But any serious
> attacker may circumvent stack canaries anyway. Thats not deep magic
> anymore. There are now automated tools to make ROP/return-to-lib-c
> attacks particularly easy to pull off (finding ROP gadgets
> automatically, even writing weaponized exploit code and so forth).
Your links are very old and miss out combining security features.
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?
The average linux system is lagging behind.
http://www.openbsd.org/papers/ru13-deraadt/
The linux code may be less integrated as it is just the kernel but is
all there as shown below and mentioned in Theo's Talk above.
http://pax.grsecurity.net/docs/pax.txt
http://pax.grsecurity.net/docs/PaXTeam-LATINOWARE12-PaX-linux-security.pdf
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).
_______________________________________________________________________
Personally I look forward to the day that code is written with these
security features in mind and it is realised that browser rendering
speed is important but JIT needs to go.
WRT heartbleed it is quite shocking that this memory handling was
applied to all builds.
http://www.tedunangst.com/flak/post/analysis-of-openssl-freelist-reuse
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.
--
_______________________________________________________________________
'Write programs that do one thing and do it well. Write programs to work
together. Write programs to handle text streams, because that is a
universal interface'
(Doug McIlroy)
In Other Words - Don't design like polkit or systemd
_______________________________________________________________________
I have no idea why RTFM is used so aggressively on LINUX mailing lists
because whilst 'apropos' is traditionally the most powerful command on
Unix-like systems it's 'modern' replacement 'apropos' on Linux is a tool
to help psychopaths learn to control their anger.
(Kevin Chadwick)
_______________________________________________________________________
Reply to: