OpenBSD will get unique kernels on each reboot

Steve · 2017-07-07 13:17:26

This i think is an interesting concept.

https://www.bleepingcomputer.com/news/s … x-windows/

Snip..

A new feature added in test snapshots for OpenBSD releases will create a unique kernel every time an OpenBSD user reboots or upgrades his computer.
This feature is named KARL — Kernel Address Randomized Link — and works by relinking internal kernel files in a random order so that it generates a unique kernel binary blob every time.
Currently, for stable releases, the OpenBSD kernel uses a predefined order to link and load internal files inside the kernel binary, resulting in the same kernel for all users.

DeepDayze · 2017-07-07 14:54:16

Would that help improve security posture for even the Linux kernel?

Horizon_Brave · 2017-07-07 17:19:58

Pretty neat! Also a snippet:

Developed by Theo de Raadt, KARL will work by generating a new kernel binary at install, upgrade, and boot time. If the user boots up, upgrades, or reboots his machine, the most recently generated kernel will replace the existing kernel binary, and the OS will generate a new kernel binary that will be used on the next boot/upgrade/reboot, constantly rotating kernels on reboots or upgrades.

I'm glad they referrenced ASLR, as that was my first thought when I began reading...

My only thought to this is will this be completely transparent to the user? Atleast to the developer? I would suspect that vital things like .ko files and other kernel 'hooked in' files would be links then to the various random locations?

Head_on_a_Stick · 2017-07-07 20:52:36

Horizon_Brave wrote:

My only thought to this is will this be completely transparent to the user? Atleast to the developer? I would suspect that vital things like .ko files and other kernel 'hooked in' files would be links then to the various random locations?

But then an attacker could just read the links and find the order for the kernel, surely?

Anyway `find / -name *.ko` doesn't produce any output on my OpenBSD-current box and that's been using KARL for a while now:

https://forums.bunsenlabs.org/viewtopic … 756#p53756

The implementation is completely invisible, just a brief message after upgrading the sets when the unique kernel is generated and that's it.

Re: ASLR

It's always worth noting that address space layout randomisation (which was first introduced by OpenBSD) is only really effective if the system binaries are compiled as position independent executables and this is not the case for Debian jessie (or Arch for that matter); stretch does have full PIE however.

Also, ASLR isn't really that effective at all [1][2], especially for Intel chips [3], but it seems to be a useful selling point for distributions with a mercantile bent so the details are usually glossed over somewhat.

DeepDayze wrote:

Would that help improve security posture for even the Linux kernel?

Not really, Linux is a bit behind in respect of security although things are improving now that grsec have weaned the community off their teat [4] and the Kernel Self Protection Project [5] is gaining traction.

[1] https://benpfaff.org/papers/asrandom.pdf
[2] https://cybersecurity.upv.es/attacks/of … -paper.pdf
[3] http://www.cs.ucr.edu/~nael/pubs/micro16.pdf
[4] https://grsecurity.net/passing_the_baton.php
[5] https://kernsec.org/wiki/index.php/Kern … on_Project

Head_on_a_Stick · 2017-07-07 22:27:25

Also, the KASLR mentioned in the article linked in the OP is a castrated version of the original grsec patch and doesn't provide as much protection as is commonly assumed:

https://forums.grsecurity.net/viewtopic.php?f=7&t=3367

#1 2017-07-07 13:17:26

OpenBSD will get unique kernels on each reboot

#2 2017-07-07 14:54:16

Re: OpenBSD will get unique kernels on each reboot

#3 2017-07-07 17:19:58

Re: OpenBSD will get unique kernels on each reboot

#4 2017-07-07 20:52:36

Re: OpenBSD will get unique kernels on each reboot

#5 2017-07-07 22:27:25

Re: OpenBSD will get unique kernels on each reboot

Board footer