[ubuntu-hardened] KASLR: enabling on x86 with "kaslr" option via '/etc/default/grub' file.

[Seth Arnold]

On Sun, Jul 23, 2017 at 12:57:50PM +0200, daniel curtis wrote:
> I'm using x86 architecture and I want to ask if I can enable KASLR via
> '/etc/default/grub' file? (Just as I'd mentioned in my first message etc.)

Hello Daniel,

It appears that 32 bit x86 platforms can use the KASLR but they will get
less randomization: 8 bits instead of 9. Furthermore, the physical and
virtual addresses are randomized together rather than separately, which
will increase the chances that an information leak will allow bypassing
the minimal gains in security due to KASLR.

Here's the kernel configs that I used for this paragraph:
https://cateee.net/lkddb/web-lkddb/RANDOMIZE_BASE.html

> I realize, that my questions are naive etc., but according to an article
> written by Mr Brad Spender, KASLR is... a failure. More informations can be
> found here [1]. I don't want to describe all the charges against KASLR etc.
> I think it's not needed. But there is one issue drawing my attention.

Brad's a smart guy but he has a tendency to see things in black and white
in my opinion, especially when he has a competing product to sell. :)

ASLR for applications is far more useful than ASLR for a kernel because:

- Applications are much less likely to leak information about their
  addresses than the kernel is.
- Applications can be randomized far more than the kernel can be.
- Applications get new randomizations on every execution while the kernel
  runs with the same randomization for the entire uptime.
- Applications may be built locally for a specific user or site while a
  specific compiled kernel may be used by millions of people and thus have
  its details readily available.

Before KASLR and the supporting efforts to remove kernel structure
visibility, the kernel exploits I saw would simply look up the data they
needed from the running kernel to exploit it. After KASLR and the related
leak-hardening, I've seen huge tables of kernel versions and what offsets
to probe, or even exploits that start by downloading packages from the
archive mirrors and unpack them to inspect the kernel binary to learn
where offsets are located. (Rumour has it that not being able to get to
an archive mirror meant a team's exploit failed at a recent hacking event.)

KASLR could certainly be vastly improved:

- ELF sections, or functions, or basic blocks, could be randomized
  instead of the base loading address.

- The kernel could switch to using memzero() on all structs at allocation
  time to reduce the chance of data leaking through holes or uninitialized
  members.

And I believe that a kernel-mode control-flow-integrity system would
obviate KASLR entirely.

Here's some slides on KCFI:
https://www.blackhat.com/docs/asia-17/materials/asia-17-Moreira-Drop-The-Rop-Fine-Grained-Control-Flow-Integrity-For-The-Linux-Kernel.pdf
A paper on KCFI:
http://sbseg2016.ic.uff.br/pt/files/anais/completos/ST8-1.pdf
A different paper on a different implementation of KCFI:
http://www.cse.psu.edu/~trj1/papers/eurosp16.pdf

PaX team has something similar, RAP; I haven't found much documentation on
it, this comparison is the best I've found so far:
https://github.com/kcfi/docs/blob/master/kcfi_vs_rap.txt

I suspect Brad looks at the reduced return on investment of KASLR compared
to normal ASLR and KCFI and figures it's not worth investing in KASRL
at all. But someone did invest in it, upstreamed it, and maintains it,
and it does raise the bar for writing kernel exploits.

Thanks
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: <https://lists.ubuntu.com/archives/ubuntu-hardened/attachments/20170724/2be7a2a5/attachment.pgp>