linux-kernel - Re: [PATCH 05/12] usb: feed USB device information to the /dev/random driver

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20120706232659.GA28978@thunk.org>
Date:	Fri, 6 Jul 2012 19:26:59 -0400
From:	Theodore Ts'o <tytso@....edu>
To:	Jonathan Nieder <jrnieder@...il.com>
Cc:	Linux Kernel Developers List <linux-kernel@...r.kernel.org>,
	ewust@...ch.edu, zakir@...ch.edu, nadiah@...ucsd.edu,
	jhalderm@...ch.edu, Linus Torvalds <torvalds@...ux-foundation.org>,
	stable@...r.kernel.org
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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/