
OpenBSD Will Get Unique Kernels on Each Reboot - SwellJoe
https://www.bleepingcomputer.com/news/security/openbsd-will-get-unique-kernels-on-each-reboot-do-you-hear-that-linux-windows/
======
brynet
In addition to a new kernel at boot, several libraries in base are also
randomly re-linked, including libc and libcrypto, which are prime targets.

[https://marc.info/?l=openbsd-
cvs&m=149605105003964&w=2](https://marc.info/?l=openbsd-
cvs&m=149605105003964&w=2)

[https://marc.info/?l=openbsd-
cvs&m=146168291000757&w=2](https://marc.info/?l=openbsd-
cvs&m=146168291000757&w=2)

This means that in addition to the dynamic linker loading libraries at random
addresses, in a random order, the offsets inside the library itself are
different on each boot, and on each system.

Robert Peichaer (rpe@) added the kernel re-linking at install/upgrade:
[https://marc.info/?l=openbsd-
cvs&m=149884116824098](https://marc.info/?l=openbsd-cvs&m=149884116824098)

~~~
danesparza
Any ideas how these are randomized? Just wondering if these are still
vulnerable to a timing attack...

~~~
brynet
What part? At least for the library randomization, a special libc.so.X.Y.a is
part of the base install, objects are extracted with ar(1), and then re-linked
in a random order (sort -R/arc4random(3)) to create a working shared library.

The kernel has a similar reordering stage, best explained by Theo de Raadt:
[https://marc.info/?l=openbsd-
tech&m=149887978201230&w=2](https://marc.info/?l=openbsd-
tech&m=149887978201230&w=2)

The full implementation is in the tree.

~~~
wlesieutre
Isn't secure random number generation a problem immediately after boot?
Curious what arc4random is using as an entropy source.

~~~
problems
Many modern systems have hardware RNGs, but they may also be using stored
seeds.

~~~
excaliboor
> Many

^[which?] ^[citation needed]

~~~
problems
On desktops, Intel Ivy Bridge and newer and everything AMD since June 2015.

On mobile, most mobile SoCs include security stuff, Qualcomm seems to have had
them since at least the Snapdragon 805. See here for the addition of the RNG
to the linux kernel in 2013:
[https://lwn.net/Articles/570158/](https://lwn.net/Articles/570158/)

Even common embedded SoCs like those used in the ESP8266 include hardware
RNGs.

Really, there's no excuse for not using it as at least one factor. If you're
concerned about possible backdoors, xor it with your own CSPRNG in software
like the Linux kernel does.

~~~
zurn
TPM has one too.

------
wolfgke
> Having KARL on other OS platforms would greatly improve the security of both
> Windows and Linux users.

This is surely true, but at least on Windows the central security holes do not
lie in Windows itself (these kinds of holes exist - but exploits are very
expensive, which shows that they are typically rare and not easy to exploit),
but in third-party applications.

For example the current 2017 version of the Petya ransomware was spreaded via
a security hole in the software update mechanism in the Ukrainian tax
preparation software M.E.Doc. Other well-known attack vectors that are
commonly used to attack Windows PCs are Flash Player and the Java browser
plugin.

~~~
lawnchair_larry
This is so wrong that I have no idea why anyone would make such an assertion.
Win32k.sys alone is a bottomless pit of EoP vulnerabilities. They are a dime a
dozen and not particularly difficult to exploit. Also, in the context of
_kernel_ security, tax software, flash, and java browser plugins have no
relevance.

~~~
wolfgke
> They are a dime a dozen and not particularly difficult to exploit. Also, in
> the context of _kernel_ security, tax software, flash, and java browser
> plugins have no relevance.

Indeed, but I wanted to illustrate that while kernel security is important,
there exist much more dangerous "open barn doors" (I don't know whether this
English translation of the German phrase "offene Scheunentore" is proper
English).

~~~
lawnchair_larry
Oh, that is fair. Kernel security is indeed largely inconsequential in the
real world. My initial read of that has it sounding like saying Windows
(kernel) doesn't have exploitable vulnerabilities, third party software does.

I still disagree, but less strongly :) Flash has always been a weak point, and
Java was (but has not really been hit for a few years). But not only have
there been exploits hitting MSIE/Edge/Office, they deserve much of the fault
for the poor security architecture that facilitates exploitation of plugins in
my opinion. Like untrusted fonts in the kernel, they seem to agree in so far
as Edge no longer supports ActiveX at all.

The number of exploits overall has gone way down, but there are still a ton of
security patches rated as Critical RCE coming out monthly in all the usual
Windows targets. And now that Tavis shone some light on their AV engine, it
has been revealed that is a gaping hole both in design as well as in
implementation.

Regardless, there are far more practical realities that make Windows a
security liability. If you survey 100 random penetration testers, you might
find one that uses RCE exploits regularly (before shadowbrokers gave everyone
new toys anyway). The playbook for everybody else largely consists of spear
phishing to get a "beachhead" and then moving laterally with Pass-the-hash and
similar things that are technically possible to defend if you read the
documentation and set the right group policies, but that nobody in the real
world does.

------
perlgeek
If the kernel image is different each time, you can't verify its integrity
through a checksum.

I'm curious to hear from people working in infosec: is that real problem? How
do you see the tradeoff?

~~~
clarry
I haven't noticed any boot time checksum verification on Linux or OpenBSD in
the past 15 years. If it's there, I've missed it. But it doesn't seem like
this change introduces a new problem. Secure boot springs to mind, but that's
something you probably have to disable anyway to run OpenBSD...

Think about this angle: if you're concerned about infosec, and there is a
malicious actor with the capability to replace your kernel (which you don't do
unless you're root), you _do_ have a real problem. Even if the kernel were
verified at boot time, that same actor should have countless other attack
vectors.

But it's something worth considering if a tursted chain from machine firmware
all the way to the application level is established. It's not there yet.

What is the solution when you need to upgrade some kernel or program and the
new version has a different cheksum? I don't see why that same solution,
whatever it is, wouldn't work in the relinking case.

~~~
danieldk
_I haven 't noticed any boot time checksum verification on Linux or OpenBSD in
the past 15 years._

Some Linux distributions support kernel and kernel module signature
verification in combination with secure boot. As far as I understand, RHEL
does this automatically when secure boot is enabled:

[https://access.redhat.com/documentation/en-
US/Red_Hat_Enterp...](https://access.redhat.com/documentation/en-
US/Red_Hat_Enterprise_Linux/7/html/System_Administrators_Guide/sect-signing-
kernel-modules-for-secure-boot.html)

[https://wiki.gentoo.org/wiki/Signed_kernel_module_support](https://wiki.gentoo.org/wiki/Signed_kernel_module_support)

~~~
snuxoll
AFAIK _ANY_ distribution that supports secure boot does this, it's entirely
pointless to sign the bootloader and kernel but then allow arbitrary kmod's to
load in and harm your trusted system.

~~~
jopsen
I disabled secure boot on ubuntu because I couldn't get the virtualbox kernel
module... So pretty sure the modules have to be signed.

Anyways, with Lenovo who is to say they didn't leak their private key out
shear incompetence :)

~~~
prashast
I faced the same issue. Though disabling secure boot just to get the vbox
driver running isn't the best idea. There are quite many detailed tutorials
that list how you can sign the vbox modules and it won't take that much time,
I promise. If the kernel devs are providing us with a security mechanism,
might as well use it. :)

------
CGamesPlay
What is the attack vector on KASLR that KARL prevents?

My best guess: A leaked kernel pointer could be used to find an offset for the
KASLR kernel, and that offset could produce a working payload for some other
unrelated kernel shell code exploit.

If that's correct, KARL seems like a pretty fringe improvement over KASLR. Can
anyone educate me?

~~~
module0000
I don't think it's meant to be a massive improvement - just another one of the
many barriers you want to put in front of an attacker. Assume they will get
through, but make it as difficult as possible in the hopes that reduces the
people who attempt it.

~~~
brian_herman
Or make it as difficult as possible so it will eat up the attacker's time.

------
ConfucianNardin
Previously:
[https://news.ycombinator.com/item?id=14542874](https://news.ycombinator.com/item?id=14542874)

------
andrew_ln
And why would you ever reboot openbsd computer? :)

~~~
elchief
to quit Vim

~~~
busterarm
I laughed and then remembered I did this once as a teen.

Then I laughed some more.

------
drdaeman
Just curious - how would they deal with kernel crash dumps?

~~~
dimman
It was the first thing that popped into my mind at first too but then I
started thinking about it and out of the top of my head the only issue I could
think of would be if symbols are stripped (you can't "load them from another
kernel"). But as long as they're in there I think there shouldn't be any
problems? But please elaborate on what you mean with the "deal with" part.

~~~
rbanffy
Wouldn't the symbols being there defeat the purpose of the whole randomization
thing?

~~~
vbernat
The purpose is to defeat a generic exploit.

For example, with ASLR, it's easy to retrieve the current layout of the
processus and therefore to debug it (if you have the appropriate symbols)
despite the randomization. But an exploit has to be built for the specific
instance of the application running. If you share the same privileges as the
process, you can get the current mapping but an exploit is useless. If you
don't, you don't have access to the mapping either and it's difficult to get
it while you are executing code inside the process as you can't easily access
the functions you would need for that.

------
quanticle
What's the performance impact of this? Are OpenBSD reboots suddenly going to
take 5-10 minutes because the kernel has to be re-linked?

~~~
clarry
The relinking is done in a background job fired off at the very end of the rc
script.

------
idealpersona
I am grateful that OpenBSD exists, but I find it sad that the most novel
advances employed in systems security are layers of security/obscurity over
vulnerable systems, instead of advances in intrinsically secure systems. Type-
safety would eliminate a large class of vulnerabilities in systems software.
We enjoy such benefits at the application layer, but systems software is far
behind.

------
rsync
I have not followed these features - are they proposed in any way for adoption
in FreeBSD ?

------
giovannibajo1
Nice technique but it cannot be used in a secure boot chain. Maybe that's not
an issue in most contexts OpenBSD is used into, but if I were to choose I
wouldn't turn off secure boot to activate this feature.

~~~
jethro_tell
why can't it be used in a secure boot? The image and checksum are created at
the end of last boot, so it could be signed then. If the bootloader is signed
it should be able check the kernel.

------
warsharks
the more i hear about OpenBSD the more i like it, i really should do more with
it as my current experience begins and ends at using pfsense (well and a PS4
which i believe runs a BSD based OS if you count that)

------
Iv
Doesn't this prevent using UEFI secure boot mechanisms?

~~~
trelliscoded
Yes.

------
kbradero
is there any book/document about building embedded systems with
openbsd/netbsd/freebsd ?

~~~
cat199
Embedded, not so sure.

Depending on your definition of 'embedded', you might look at the various
wireless router repackagings and scripts that are available.. Also, the NetBSD
'rump' kernel might be an interesting thing to review.

Generally speaking, the projects overall have excellent documentation,
including manual pages or HTML docs on kernel, c library interfaces, building
the system and packages from source, etc. Also, the whole system is in the
source tree, which can be downloaded as a set.

Otherwise:

OpenBSD in general: There's "Absolute OpenBSD', kind of more 'user/admin'
level.

For lower-level stuff like API's, kernel organization, etc, the McCusick books
(Design and implementation of the {4.3BSD,4.4BSD, FreeBSD} Operating System),
though either dated, or more specific to FreeBSD, respectively, still cover
quite a bit of stuff that still applies to OpenBSD (most changes have been
incremental, and can be tracked through the source tree history back to the
original USG sources if needed)

I'd suggest running an install 'from source' on a spare machine/vm/etc for a
while and reading docs and the source tree this will get you familiar enough
with the system to have an idea where to go next.

------
pklausler
Distinct, not unique, I believe.

~~~
dchest
Random linking of at least 160 files will give more combinations than there
are atoms on Earth. I counted 1206 *.o files in OpenBSD kernel. Unique enough?

~~~
pklausler
Distinct enough, sure.

Unique means something else.

~~~
dchest
Oh, I'm sorry, unique in the current Universe from its birth many many
trillions of trillions of years until after the death of all currently known
galaxies. Still not unique?

No other OpenBSD installation had or will _ever_ have the same kernel, so each
kernel is unique.

~~~
pklausler
You seem to think that I'm arguing that collisions might be a problem. I'm
not. I'm raising a point of English usage. "Unique" is not the right word to
use in this context; "distinct" is correct.

If a set has a single member, that member is unique; e.g., 2 is the unique
even prime number.

If a thing is different from all other things, it's distinct.

~~~
dchest
Huh? From the set of all possible linked OpenBSD kernels
(2^number_of_dot_o_files), the kernel you re-link is unique. And distinct,
too.

~~~
jwilk
It's n!, which is much bigger than 2^n.

~~~
dchest
Thanks for correction.

