On Wed, Jun 28, 2017 at 08:15:20AM +0100, Cory Benfield wrote: > When you say “the linked article”, do you mean the PCWorld one? > Because that article doesn’t provide any suggestion that > /dev/urandom has anything to do with it. It is at least as likely > that the SSH key is hard-coded into the machine image. The flaw here > is not “using /dev/urandom”, it’s “exposing your router’s SSH access > on the external side of the router”, plus the standard level of poor > configuration done by shovelware router manufacturers.
The PC World article was clearly caused by hard-coding the RSA private key in the flashed firmware and sharing it across fast numbers of routers. The reference which I believe Paul Dale was looking for dates back to five years ago, in the "Minding your P's and Q's paper", published in Usenix Security: https://factorable.net/ The researchers gave me early access to the paper in early July and I spent most of July 4th on the rooftop of the Museum of Science rooftop, reworking Linux's random driver during the day (so we could watch the fireworks from an advantageous position that evening). We had patches released before the P's and Q's paper was published, and these fixes are in 3.6 and newer kernels. There may still be issues with silly programs which initialize symmetric keys the first time the system boots, instead of doing it on an on-demand basis the first time someone tries connecting to the SSH port (when there would be plenty of entropy mixed in). And of course, things have gotten more challenging because systemd starts the sshd service much more quickly, and if you are on an embedded system which does not have a high resolution clock, and very little entropy when the box is first booted (for example, if the user plugs in the router without having first attached any of the LAN or WAN cables), it may still be a problem on some systems. Unfortunately, though, this ends up being a system design problem. There only so much you can do just at the kernel level, or just at the openssl level. My recommendation, again, is to use getrandom(2) if it is available, and if it isn't (on kernels older than 3.17) fall back to using /dev/urandom. On kernels older than 3.17, you're probably totally screwed because the kernel is very likely going to be missing large numbers of security fixes, so if someone is unfortunate enough to be using a kernel which is older than 3.17, they're probably totally screwed anyway. (The only exception to this rule is if you're getting monthly security updates from your cell phone provider, but if you're not using an Google-supported android releases, and you're using a ARM SOC with a 3.10 BSP kernel, you might as well give up now. And if the leader of the free world, is using such a device to tweet messages in lieu of press conferences --- again, you've got bigger problems. :-) If you are using a system which is 3.17 or newer, but your libc doesn't have support for getrandom(2), I would recommend trying to call getrandom(2) directly using the syscall(2) interface. This will mean hardcoding Linux's syscall number for different architectures, which is painful and ugly, but that's going to be the best way to block until you are sure the CRNG has been initialized, in case you do have silly programs trying to generate long-term secrets a second or so after the box is first powered on. Cheers, - Ted P.S. Short summry of kernel versions from an upstream perspective 3.17 -- first kernel version with getrandom(2) 3.18 -- Long Term Stable kernel 4.1 -- Long Term Stable kernel 4.4 -- Long Term Stable kernel 4.8 -- first kernel version using a ChaCha20 CRNG 4.9 -- Long Term Stable kernel 4.12 -- Next Long Term Stable kernel (to be released in a week or two) (Long Term Stable kernels are ones which get upstream security fixes backported by Greg K-H and his team. Just because your kernel has a LTS version may not mean you are getting the latest bug fixes. SOC vendors are notorious for not bothering to update their kernels with the latest bug fixes, and many embedded and mobile device vendors aren't bothering to keep up as well.) -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev