Contributed by pitrh on from the all tomorrows random gaps dept.
5 weeks ago at d2k17 I started work on randomized kernels. I've been having conversations with other developers for nearly 5 years on the topic... but never got off to a good start, probably because I was trying to pawn the work off on others.
Having done this, I really had no idea we'd end up where we are today.Here are the behaviours:
- The base set has grown, it now includes a link-kit
- At install time, a unique kernel is built from this link-kit
- At upgrade time, a unique kernel is built
- At boot time, a unique kernel is built and installed for the next boot
- If someone compiles their own kernel and uses 'make install', the link-kit is also updated, so that the next boot can do the work
- If a developer cp's a kernel to /, the mechanism dis-engages until a 'make install" or upgrade is performed in the future. That may help debugging.
A unique kernel is linked such that the startup assembly code is kept in the same place, followed by randomly-sized gapping, followed by all the other .o files randomly re-organized. As a result the distances between functions and variables are entirely new. An info leak of a pointer will not disclose other pointers or objects. This may also help reduce gadgets on variable-sized architectures, because polymorphism in the instruction stream is damaged by nested offsets changing.
At runtime, the kernel can unmap it's startup code. On architectures where an unmap isn't possible due to large-PTE use, the code can be trashed instead.
I did most of the kernel work on amd64 first, then i386. I explained what needed to be done to visa and patrick, who handled the arm and mips platforms. Then I completed all the rest of the architectures. Some architecture are missing the unmap/trashing of startup code, that's a step we need to get back to.
The next part was tricky and I received assistance from tb and rpe. We had to script the behaviours at build time, snapshot time, relink time, boot time, and later on install/upgrade time also.
While they helped, I also worked to create the "gap.o" file without use of a C compiler so that relinks can occur without the "comp" set installed. This uses the linkscript feature of ld. I don't think anyone has done this before. It is little bit fragile, and the various linkers may need to receive some fixes due to what I've encountered.
To ensure this security feature works great in the 6.2 release, please test snapshots. By working well, I mean it should work invisibly, without any glitch such as a broken kernel or anything. If there are ugly glitches we would like to know before the release.
You heard the man, now is the time to test and get a preview of the new awsomeness that will be in OpenBSD 6.2.
(Comments are closed)
By Renzo Fabriek (94.210.194.44) on
I have only one question. I know if a hacker can adjust the "source" files for rebuilding (relinking) the kernel he is already to far to need it. The same as not installing "comp.tgz" to not provide compiling tools. Does not make a difference if a hacker can modify or add crucial files to gain acces to a system.
Is there any worst case scenario with this which was not present before?
By Anonymous Coward (45.76.92.69) on
Comments
By Theo (199.185.136.55) deraadt@openbsd.org on de Raadt
If your kernel is trojaned, how can you run userland code upon it to check if it is trojaned?
If you are holed, you are holed. Don't get holed.
Comments
By Anonymous Coward (185.170.42.4) on
>
> If you are holed, you are holed. Don't get holed.
I agree, but the checks can be done offline via a trusted OS booted from read-only media (CD-ROM, write-protected USB or floppy), or it can be done by the boot loader if it can be trusted.
Comments
By Anonymous Coward (199.185.136.55) on
> >
> > If you are holed, you are holed. Don't get holed.
>
> I agree, but the checks can be done offline via a trusted OS booted from read-only media (CD-ROM, write-protected USB or floppy), or it can be done by the boot loader if it can be trusted.
And you do that with a CD-ROM every time?
As to the second point, our bootloader doesn't do that.
You can disable this security subsystem if you prefer your kernel to have the same address space everytime it runs. Go for it. You can disable this security mechanism, and keep checking with your CD-ROM procedure. Noone is stopping you from using your CD-ROM.
By Anonymous Coward (107.182.226.250) on
> >
> > If you are holed, you are holed. Don't get holed.
>
> I agree, but the checks can be done offline via a trusted OS booted from read-only media (CD-ROM, write-protected USB or floppy), or it can be done by the boot loader if it can be trusted.
It would be neat if another stage was added to the boot loader so it could verify signatures of the kernel object files and then does the re-linking before the new kernel boots. Best of both worlds.
Comments
By Anonymous Coward (81.148.134.38) on
> > >
> > > If you are holed, you are holed. Don't get holed.
> >
> > I agree, but the checks can be done offline via a trusted OS booted from read-only media (CD-ROM, write-protected USB or floppy), or it can be done by the boot loader if it can be trusted.
>
> It would be neat if another stage was added to the boot loader so it could verify signatures of the kernel object files and then does the re-linking before the new kernel boots. Best of both worlds.
Verify against what? a hacked list of signatures?
Remember, before booting, there is no OS to help you access remote websites (or even other local storage), so the only source of data is the same place you got the object files.
By Anonymous Coward (88.150.87.179) on
By Lima (200.126.211.43) on
how intensive is this relinking thing and at what stage is it done? will be this an optional feature? Thanks.
Comments
By Billy Larlad (69.178.115.138) on
> how intensive is this relinking thing and at what stage is it done? will be this an optional feature? Thanks.
Don't know how it compares to what's in an Alix, but I've got an Intel Atom D525 (1.8 GHz). The relinking took maybe 45-90 seconds when I updated to the latest snapshot.