OpenBSD Will Get Unique Kernels on Each Reboot

https://www.bleepingcomputer.com/news/security/openbsd-will-get-unique-kernels-on-each-reboot-do-you-hear-that-linux-windows/

by SwellJoe • 9 years ago

409 111 9 years ago

bleepingcomputer.com

ConfucianNardin• 9 years ago

Previously: https://news.ycombinator.com/item?id=14542874

drdaeman• 9 years ago

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

dimman• 9 years ago

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• 9 years ago

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

gbrown_• 9 years ago

The re-link is recorded so if you needed can reproduce the same kernel. But as dimman has said you will have symbols.

brynet4• 9 years ago

The relative offsets within individual compilation units is the same, so debugging is unaffected by this.

cat1992• 9 years ago

Not entirely true -

e.g. if your stack is hosed, etc, things could be affected

Also, much of kernel debugging involves poking at core images, which wouldn't be coherent with the kernel binary.

That said, I'm fairly certain I recall reading that the logic saves your previous kernel for such a case, and otherwise someone could make scripts to save more copies if needed.

Others have pointed out reconstructing kernels for debug purposes.

wolfgke4• 9 years ago

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.

_asummers2• 9 years ago

Don't forget fonts!

wolfgke4• 9 years ago

Don't forget fonts!

It is today considered a design mistake that GDI was moved to kernel mode in Windows NT 4.0 for performance reasons (https://en.wikipedia.org/w/index.php?title=Architecture_of_W...). But with Windows 10 Anniversary Update font parsing is done in user mode within an AC ["AppContainer"] (source: https://blogs.technet.microsoft.com/mmpc/2017/01/13/hardenin...).

mtgx2• 9 years ago

Wasn't NotPetya spread via SMB?

noway421• 9 years ago

That was AFAIK WannaCry

pjmlp• 9 years ago

Also, at least for those of us on Windows 10 Professional and Enterprise, there is secure kernel.

https://channel9.msdn.com/Events/Ignite/2016/BRK4010

rsync2• 9 years ago

"This is surely true, but at least on Windows the central security holes do not lie in Windows itself"

They don't ? IIRC, stuxnet was an autorun exploit of some kind and the recent unpleasantness was all based on built-in SMB functionality ... right ?

jstarks• 9 years ago

Well, it's true that the initial vector is often third-party software. But once you're able to run arbitrary code in a user-mode process running in a limited security context, you still need to attack some high-privilege component to get full control of the machine. Usually this component is the kernel, so additional kernel mitigations do help protect you.

lawnchair_larry5• 9 years ago

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.

wolfgke4• 9 years ago

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).

andrew_ln• 9 years ago

And why would you ever reboot openbsd computer? :)

qubex• 9 years ago

To watch KARL do it's thing!

peedy• 9 years ago

To upgrade to a new snapshot :)

tzs2• 9 years ago

To verify that it still boots correctly after an update.

If an update does something that breaks your startup sequence it generally is much better to find out about it right away than it is to find out about years later in the middle of the night when you get a forced reboot due to hardware or power issues, and find that things are broken and you have no idea which of a dozen allegedly minor updates broke it.

nwmcsween3• 9 years ago

Then the package manager is broken on your OS of choice, the package manager (or another related utility) should ensure whatever it updates or installs actually works.

keithpeter• 9 years ago

Because you use it on a laptop with hard-drive encryption and tend to avoid suspend to RAM.

Liking the advocacy though

protomyth• 9 years ago

I tend to reboot after each patch, and of course, every six months for the new release.

I must admit that syspatch has saved me a ton of time.

elchief• 9 years ago

to quit Vim

busterarm• 9 years ago

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

Then I laughed some more.

w8rbt• 9 years ago

:q is not that hard ;) I upvoted you though because I liked the joke.

brynet4• 9 years ago

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=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

danesparza• 9 years ago

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

brynet4• 9 years ago

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

The full implementation is in the tree.

perlgeek• 9 years ago

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?

hobarrera• 9 years ago

You could generate a checksum each time you generate a new kernel. If you need some pre-kernel checksum validation, that might be a problem though.

clarry3• 9 years ago

In fact OpenBSD already generates a checksum for each kernel.

Ded7xSEoPKYNsDd• 9 years ago

You could just feed the individual kernel symbols in a canonical order (i.e. sorted) to the checksum algorithm. It's a bit more involved, but since boot loaders like Grub already have ELF parsers, it shouldn't be too hard.

clarry3• 9 years ago

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.

microtonal• 9 years ago

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://wiki.gentoo.org/wiki/Signed_kernel_module_support

lambdadmitry• 9 years ago

According to [1],

"At boot time, a unique kernel is built and installed for the next boot"

Therefore, if the building code is itself trusted it can make a checksum and sign it. So each boot can verify the next boot, in a blockchain-ish way.

[1] https://news.ycombinator.com/item?id=14711983

fooker2• 9 years ago

How does this help though?

If you are in a position to replace the kernel, can't you also replace the code that does this verification?

That is exactly how games are cracked, as I understand.

CGamesPlay• 9 years ago

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• 9 years ago

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• 9 years ago

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

lawnchair_larry5• 9 years ago

That's exactly it, more or less. KASLR is almost always useless in practice because there are so many ways to leak kernel pointers that most seasoned researchers are convinced that this will never be plugged. Even if they are, it's often the case that the same bug you are exploiting can also be used to leak enough information.

Here is a long anti-ASLR rant by the folks who invented the ASLR mitigation in the first place, explaining why attempts to repurpose the idea for kernel attacks are misguided:

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

I agree that it is probably not a meaningful improvement.

trelliscoded4• 9 years ago

There's this thing called return oriented programming that this is a hard counter to. Return oriented programming replaced shell code a while back when stacks became non executable across the board.

dobin• 9 years ago

KASLR just requires ONE leaked pointer to calculate base offset of the kernel, and from there is the standard ROPchain technique. The kernel is still one big identical blog, just mapped at a different starting address.

If i understand KARL correctly, they reorder the internal code (and data?) in the kernel. Therefore a single pointer-leak does not expose all the ROP gadgets anymore. More information leak is necessary, or a smaller amount of gadgets. Therefore imho this is a much better protection than KASLR.

rsync2• 9 years ago

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

quanticle• 9 years ago

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?

Crontab• 9 years ago

Per Theo de Raadt:

"At boot time, a unique kernel is built and installed for the next boot"

clarry3• 9 years ago

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

pklausler4• 9 years ago

Distinct, not unique, I believe.

dchest4• 9 years ago

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?

pklausler4• 9 years ago

Distinct enough, sure.

Unique means something else.

kbradero• 9 years ago

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

cat1992• 9 years ago

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.

ta34512• 9 years ago

I guess this is more of a quick start but along the lines:

https://www.freebsd.org/doc/en/articles/nanobsd/index.html

giovannibajo1• 9 years ago

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• 9 years ago

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.

Iv• 9 years ago

Doesn't this prevent using UEFI secure boot mechanisms?

trelliscoded4• 9 years ago

Yes.

idealpersona• 9 years ago

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.

warsharks• 9 years ago

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)

OpenBSD Will Get Unique Kernels on Each Reboot

Related Stories