From: Theodore Ts'o <tytso@mit.edu>
To: Jonathan Nieder <jrnieder@gmail.com>
Cc: Linux Kernel Developers List <linux-kernel@vger.kernel.org>,
ewust@umich.edu, zakir@umich.edu, nadiah@cs.ucsd.edu,
jhalderm@umich.edu,
Linus Torvalds <torvalds@linux-foundation.org>,
stable@vger.kernel.org
Subject: Re: [PATCH 05/12] usb: feed USB device information to the /dev/random driver
Date: Fri, 6 Jul 2012 19:26:59 -0400 [thread overview]
Message-ID: <20120706232659.GA28978@thunk.org> (raw)
In-Reply-To: <20120706230218.GD3728@burratino>
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.
next prev parent reply other threads:[~2012-07-06 23:26 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1341614704-24965-1-git-send-email-tytso@mit.edu>
2012-07-06 22:44 ` [PATCH 02/12] random: make 'add_interrupt_randomness()' do something sane Theodore Ts'o
2012-07-08 2:01 ` Ben Hutchings
2012-07-06 22:44 ` [PATCH 03/12] random: use lockless techniques in the interrupt path Theodore Ts'o
2012-07-06 22:44 ` [PATCH 04/12] random: create add_device_randomness() interface Theodore Ts'o
2012-07-06 22:44 ` [PATCH 05/12] usb: feed USB device information to the /dev/random driver Theodore Ts'o
2012-07-06 23:02 ` Jonathan Nieder
2012-07-06 23:18 ` Greg KH
2012-07-06 23:26 ` Theodore Ts'o [this message]
2012-07-07 1:08 ` Jonathan Nieder
2012-07-06 22:44 ` [PATCH 06/12] net: feed /dev/random with the MAC address when registering a device Theodore Ts'o
2012-07-06 22:44 ` [PATCH 07/12] random: use the arch-specific rng in xfer_secondary_pool Theodore Ts'o
2012-07-07 17:11 ` [PATCH] random: only use gathered bytes from arch_get_random_long Kees Cook
2012-07-07 18:23 ` Theodore Ts'o
2012-07-07 23:20 ` Kees Cook
2012-07-08 1:06 ` [PATCH 07/12] random: use the arch-specific rng in xfer_secondary_pool Ben Hutchings
2012-07-08 1:41 ` Theodore Ts'o
2012-07-08 2:06 ` Ben Hutchings
2012-07-06 22:45 ` [PATCH 08/12] random: add new get_random_bytes_arch() function Theodore Ts'o
2012-07-06 22:45 ` [PATCH 11/12] rtc: wm831x: Feed the write counter into device_add_randomness() Theodore Ts'o
2012-07-06 22:45 ` [PATCH 12/12] mfd: wm831x: Feed the device UUID " Theodore Ts'o
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20120706232659.GA28978@thunk.org \
--to=tytso@mit.edu \
--cc=ewust@umich.edu \
--cc=jhalderm@umich.edu \
--cc=jrnieder@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=nadiah@cs.ucsd.edu \
--cc=stable@vger.kernel.org \
--cc=torvalds@linux-foundation.org \
--cc=zakir@umich.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).