Messages in this thread | | | Date | Fri, 6 Jul 2012 19:26:59 -0400 | From | Theodore Ts'o <> | Subject | Re: [PATCH 05/12] usb: feed USB device information to the /dev/random driver |
| |
On Fri, Jul 06, 2012 at 06:02:18PM -0500, Jonathan Nieder wrote: > > Why cc: stable@? Does this fix a build error, oops, hang, data > corruption, real security issue, or other critical "oh, that's not > good" bug?
All of the /dev/random patches in this patch series that were marked for the stable backports are to address a security issue. See: https://factorable.net/
The main hope is that we can get the embedded device manufacturers to grab these patches sooner rather than later, so getting them into the stable backport trees is just as important, if not more so, than getting them into v3.5.
While these patches are designed to do as much as we can without assuming any fixes in userspace, and the weak kea vulnerabilities are much more obviously detectable in embedded devices with close to zero available entropy, ideally there are improvements that can and should be done in upstream userspace packages as well as in the packaging and installation scripts for more general-purpose server and workstation distributions.
For example, ssh key generation should happen as late as possible; ideally, some time *after* the networking has been brought up. If the ssh keys get generated while the installer is running, before the kernel has a chance to collect entropy --- especially if the user chooses to do this with the machine off the network --- well, that's unfortunate. The same is true for the generation of remote administration keys for ntpd and bind.
See the extended version of the research paper for more discussion on remediation possibilities up and down the OS stack.
Regards,
- Ted
P.S. This vulnerability was blogged about a few months ago, and it's about to be presented at the upcoming Usenix Security Symposium next month. Hence, nothing discussed here or in the patch set is a secret. Please feel free to forward this to any distribution security teams you think appropriate.
| |