OpenBSD Journal
Home : : Add Story : : Archives : : About : : Create Account : : Login :
KARL - kernel address randomized link
Contributed by rueda on Tue Jun 13 02:52:37 2017 (GMT)
from the Charlemagne dept.

In a message to the tech@ mailing list, Theo de Raadt (deraadt@) has announced a new randomization feature for kernel protection:

Over the last three weeks I've been working on a new randomization
feature which will protect the kernel.
[...]
Recently I moved all our kernels to a new mapping model, with patrick
and visa taking care of two platforms.
[...]
As a result, every new kernel is unique.  The relative offsets between
functions and data are unique.
[...]
However, snapshots of -current contain a futher change, which I
worked on with Robert Peichaer (rpe@):

That change is scaffolding to ensure you boot a newly-linked kernel
upon every reboot.[...]

Read the full message for the juicy details.

Note that, because of the new mechanisms, unhibernate does not work on -current (for now).

[topicsecurity]

<< OpenBSD Daily, code review, and you | Reply | Flattened | Expanded | OpenBSD now has Trapsleds to make life harder for ROPers >>

Threshold: Help

Related Links
more by rueda


  Re: KARL - kernel address randomized link (mod 7/13)
by Anonymous (185.104.120.4) on Wed Jun 14 05:30:03 2017 (GMT)
  There really needs to be a better way to do this, rather than using GCC to relink the files every time the OS boots up. There is a huge potential for failure here if it goes wrong, all for little benefit (especially with the kernel, since userland applications cannot access kernel memory anyway, and if it can, they can do a colossal amount of damage).

Being security-minded is great, but not if it leads to a false sense of security. If there is any attacks which can be prevented by this kind of tweakery (particularly when applied to the kernel) please let me know.

Before I get ragey fanboys saying how "oh openbsd is for the DEVELOPERS not the USERS" and "How dare you defer from OpenBSD developer opinion you HERETIC!", let me make it clear that this just seems like a waste of energy to me.
  [ Show thread ] [ Reply to this comment ] [ Mod Up ] [ Mod Down ]

  Re: KARL - kernel address randomized link (mod 2/12)
by Anonymous Coward (109.163.234.4) on Thu Jun 15 13:41:10 2017 (GMT)
  I would like to point out that maybe there should be some modification to this patch to support read-only /usr partition, like it was done for the reordening of the libraries, before some user start reporting errors at the boot sequence. Or is has already be taken care?
  [ Show thread ] [ Reply to this comment ] [ Mod Up ] [ Mod Down ]

  Re: KARL - kernel address randomized link (mod 1/7)
by ED Fochler (131.92.14.154) (undead@liquidbinary.com) on Thu Jun 22 16:51:11 2017 (GMT)
  This implementation seems mutually exclusive with signed executables like iPhone and Win8 and the TPM are employing. The concept of a trusted / signed boot chain seems useful, even if its current use case is to lock down hardware by companies to prevent users from installing legitimate operating systems.

Can this implementation occur in memory only? This would afford a signed kernel on disk to be loaded after checking legitimacy, and then morph to protect itself at runtime so that threats would not have a homogenous target base to attack.

I don't want to protect against a real-time attack only to be left vulnerable to an evil-maid on-disk kernel-swap attack.
  [ Show thread ] [ Reply to this comment ] [ Mod Up ] [ Mod Down ]

  Re: KARL - kernel address randomized link (mod 1/1)
by Anonymous Coward (112.215.172.239) on Sat Jun 24 00:34:16 2017 (GMT)
 
  [ Show thread ] [ Reply to this comment ] [ Mod Up ] [ Mod Down ]

[ Home | Add Story | Archives | Polls | About ]

Copyright © 2004-2008 Daniel Hartmeier. All rights reserved. Articles and comments are copyright their respective authors, submission implies license to publish on this web site. Contents of the archive prior to April 2nd 2004 as well as images and HTML templates were copied from the fabulous original deadly.org with Jose's and Jim's kind permission. Some icons from slashdot.org used with permission from Kathleen. This journal runs as CGI with httpd(8) on OpenBSD, the source code is BSD licensed. Search engine is ht://Dig. undeadly \Un*dead"ly\, a. Not subject to death; immortal. [Obs.]