Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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



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


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.


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


OpenBSD's bootloader seeds the kernel, mixing in other entropy sources. High quality random numbers are available very early compared to other operating systems.

See Theo's talk from Hackfest 2014, an updated talk originally given at EuroBSDcon 2014:

https://www.openbsd.org/papers/hackfest2014-arc4random/index...

Page 19 and beyond explain this in detail: https://www.openbsd.org/papers/hackfest2014-arc4random/mgp00...


Does it actually do the randomisation at boot time? It's unclear from the article, but OpenBSD could be randomising the next kernel to boot after the current one has been loaded. This could be performed some time after the boot process, allowing more randomness, and minimising the boot-time workload/code complexity.


No. After boot time. As you said.


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


Yep, there's a stored seed (/etc/random.seed) that gets added to the mix at boot.


> Many

^[which?] ^[citation needed]


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/

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.


TPM has one too.


Recent AMD and Intel systems with AES-NI provide a hardware RNG. Although as far as I was aware this is not used on OpenBSD for fear of hardware backdoors.


See https://en.wikipedia.org/wiki/RdRand and (same page) https://en.wikipedia.org/wiki/RdRand#Reception for info on concerns about backdrops.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: