From: Theodore Ts'o <tytso@mit.edu>
To: "Jason A. Donenfeld" <Jason@zx2c4.com>
Cc: Linux Crypto Mailing List <linux-crypto@vger.kernel.org>,
LKML <linux-kernel@vger.kernel.org>,
kernel-hardening@lists.openwall.com,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
David Miller <davem@davemloft.net>,
Eric Biggers <ebiggers3@gmail.com>,
Steve French <sfrench@samba.org>
Subject: Re: [PATCH v4 08/13] cifs: use get_random_u32 for 32-bit lock random
Date: Wed, 7 Jun 2017 20:25:23 -0400 [thread overview]
Message-ID: <20170608002523.m3h3jin4poav5xy2@thunk.org> (raw)
In-Reply-To: <20170606174804.31124-9-Jason@zx2c4.com>
On Tue, Jun 06, 2017 at 07:47:59PM +0200, Jason A. Donenfeld wrote:
> Using get_random_u32 here is faster, more fitting of the use case, and
> just as cryptographically secure. It also has the benefit of providing
> better randomness at early boot, which is sometimes when this is used.
>
> Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
> Cc: Steve French <sfrench@samba.org>
There's a bigger problem here, which is that cifs_lock_secret is a
32-bit value which is being used to obscure flock->fl_owner before it
is sent across the wire. But flock->fl_owner is a pointer to the
struct file *, so 64-bit architecture, the high 64-bits of a kernel
pointer is being exposed to anyone using tcpdump. (Oops, I'm showing
my age; I guess all the cool kids are using Wireshark these days.)
Worse, the obscuring is being done using XOR. How an active attacker
might be able to trivially reverse engineer the 32-bit "secret" is
left as an exercise to the reader. The bottom line is if the goal is
to hide the memory location of a struct file from an attacker,
cifs_lock_secret is about as useful as a TSA agent doing security
theatre at an airport. Which is to say, it makes the civilians feel
good. :-)
BTW, Jason, this is why it's *good* to audit all of the uses of
get_random_bytes(). It only took me about 30 seconds in the first
patch in your series that changes a caller of get_random_bytes(), and
look what I was able to find by just taking a quick look. Not waiting
for the CRNG to be fully initialized is the *least* of its problems.
Anyway, I'll include this commit in the dev branch of the random tree,
since it's not going to make things worse.
- Ted
WARNING: multiple messages have this Message-ID (diff)
From: "Theodore Ts'o" <tytso@mit.edu>
To: "Jason A. Donenfeld" <Jason@zx2c4.com>
Cc: Linux Crypto Mailing List <linux-crypto@vger.kernel.org>,
LKML <linux-kernel@vger.kernel.org>,
kernel-hardening@lists.openwall.com,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
David Miller <davem@davemloft.net>,
Eric Biggers <ebiggers3@gmail.com>,
Steve French <sfrench@samba.org>
Subject: Re: [kernel-hardening] [PATCH v4 08/13] cifs: use get_random_u32 for 32-bit lock random
Date: Wed, 7 Jun 2017 20:25:23 -0400 [thread overview]
Message-ID: <20170608002523.m3h3jin4poav5xy2@thunk.org> (raw)
In-Reply-To: <20170606174804.31124-9-Jason@zx2c4.com>
On Tue, Jun 06, 2017 at 07:47:59PM +0200, Jason A. Donenfeld wrote:
> Using get_random_u32 here is faster, more fitting of the use case, and
> just as cryptographically secure. It also has the benefit of providing
> better randomness at early boot, which is sometimes when this is used.
>
> Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
> Cc: Steve French <sfrench@samba.org>
There's a bigger problem here, which is that cifs_lock_secret is a
32-bit value which is being used to obscure flock->fl_owner before it
is sent across the wire. But flock->fl_owner is a pointer to the
struct file *, so 64-bit architecture, the high 64-bits of a kernel
pointer is being exposed to anyone using tcpdump. (Oops, I'm showing
my age; I guess all the cool kids are using Wireshark these days.)
Worse, the obscuring is being done using XOR. How an active attacker
might be able to trivially reverse engineer the 32-bit "secret" is
left as an exercise to the reader. The bottom line is if the goal is
to hide the memory location of a struct file from an attacker,
cifs_lock_secret is about as useful as a TSA agent doing security
theatre at an airport. Which is to say, it makes the civilians feel
good. :-)
BTW, Jason, this is why it's *good* to audit all of the uses of
get_random_bytes(). It only took me about 30 seconds in the first
patch in your series that changes a caller of get_random_bytes(), and
look what I was able to find by just taking a quick look. Not waiting
for the CRNG to be fully initialized is the *least* of its problems.
Anyway, I'll include this commit in the dev branch of the random tree,
since it's not going to make things worse.
- Ted
next prev parent reply other threads:[~2017-06-08 0:25 UTC|newest]
Thread overview: 109+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-06-06 17:47 [PATCH v4 00/13] Unseeded In-Kernel Randomness Fixes Jason A. Donenfeld
2017-06-06 17:47 ` [kernel-hardening] " Jason A. Donenfeld
2017-06-06 17:47 ` [PATCH v4 01/13] random: invalidate batched entropy after crng init Jason A. Donenfeld
2017-06-06 17:47 ` [kernel-hardening] " Jason A. Donenfeld
2017-06-07 23:58 ` Theodore Ts'o
2017-06-07 23:58 ` [kernel-hardening] " Theodore Ts'o
2017-06-08 0:52 ` Jason A. Donenfeld
2017-06-08 0:52 ` [kernel-hardening] " Jason A. Donenfeld
2017-06-06 17:47 ` [PATCH v4 02/13] random: add synchronous API for the urandom pool Jason A. Donenfeld
2017-06-06 17:47 ` [kernel-hardening] " Jason A. Donenfeld
2017-06-08 0:00 ` Theodore Ts'o
2017-06-08 0:00 ` [kernel-hardening] " Theodore Ts'o
2017-06-06 17:47 ` [PATCH v4 03/13] random: add get_random_{bytes,u32,u64,int,long,once}_wait family Jason A. Donenfeld
2017-06-06 17:47 ` [kernel-hardening] " Jason A. Donenfeld
2017-06-08 0:05 ` Theodore Ts'o
2017-06-06 17:47 ` [PATCH v4 04/13] security/keys: ensure RNG is seeded before use Jason A. Donenfeld
2017-06-06 17:47 ` [kernel-hardening] " Jason A. Donenfeld
2017-06-08 0:31 ` Theodore Ts'o
2017-06-08 0:31 ` [kernel-hardening] " Theodore Ts'o
2017-06-08 0:50 ` Jason A. Donenfeld
2017-06-08 0:50 ` [kernel-hardening] " Jason A. Donenfeld
2017-06-08 1:03 ` Jason A. Donenfeld
2017-06-08 1:03 ` [kernel-hardening] " Jason A. Donenfeld
2017-06-06 17:47 ` [PATCH v4 05/13] crypto/rng: ensure that the RNG is ready before using Jason A. Donenfeld
2017-06-06 17:47 ` [kernel-hardening] " Jason A. Donenfeld
2017-06-08 0:41 ` Theodore Ts'o
2017-06-08 0:47 ` Jason A. Donenfeld
2017-06-06 17:47 ` [PATCH v4 06/13] iscsi: ensure RNG is seeded before use Jason A. Donenfeld
2017-06-06 17:47 ` [kernel-hardening] " Jason A. Donenfeld
2017-06-08 2:43 ` Theodore Ts'o
2017-06-08 2:43 ` [kernel-hardening] " Theodore Ts'o
2017-06-08 12:09 ` Jason A. Donenfeld
2017-06-16 21:58 ` Lee Duncan
2017-06-17 0:41 ` Jason A. Donenfeld
2017-06-17 3:45 ` Lee Duncan
2017-06-17 14:23 ` Jeffrey Walton
[not found] ` <CAH8yC8nHX2r9cfQ0gNeJAUrgSfAS8V16dVHv35BRnLn-YprZCg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2017-06-17 18:50 ` [kernel-hardening] " Paul Koning
2017-06-17 18:50 ` Paul Koning
2017-07-05 7:08 ` Antw: Re: [kernel-hardening] " Ulrich Windl
2017-07-05 7:08 ` Ulrich Windl
2017-07-05 7:08 ` Ulrich Windl
2017-07-05 13:16 ` Paul Koning
2017-07-05 13:16 ` Paul Koning
2017-07-05 17:34 ` Antw: " Theodore Ts'o
2017-07-05 17:34 ` Antw: Re: [kernel-hardening] " Theodore Ts'o
2017-07-05 17:34 ` Theodore Ts'o
2017-06-18 8:04 ` Stephan Müller
[not found] ` <2639082.PtrrGWOPPL-jJGQKZiSfeo1haGO/jJMPxvVK+yQ3ZXh@public.gmane.org>
2017-06-26 1:23 ` Nicholas A. Bellinger
2017-06-26 1:23 ` Nicholas A. Bellinger
[not found] ` <1498440189.26123.85.camel-XoQW25Eq2zviZyQQd+hFbcojREIfoBdhmpATvIKMPHk@public.gmane.org>
2017-06-26 17:38 ` Stephan Müller
2017-06-26 17:38 ` Stephan Müller
2017-06-30 6:02 ` Nicholas A. Bellinger
[not found] ` <1678474.GnYBdSlWgs-b2PLbiJbNv8ftSvlWXw0+g@public.gmane.org>
2017-07-05 7:03 ` Antw: " Ulrich Windl
2017-07-05 7:03 ` Ulrich Windl
2017-07-05 7:03 ` Ulrich Windl
2017-07-05 12:35 ` Theodore Ts'o
2017-07-05 12:35 ` Theodore Ts'o
2017-06-06 17:47 ` [PATCH v4 07/13] ceph: ensure RNG is seeded before using Jason A. Donenfeld
2017-06-06 17:47 ` [kernel-hardening] " Jason A. Donenfeld
2017-06-08 2:45 ` Theodore Ts'o
2017-06-06 17:47 ` [PATCH v4 08/13] cifs: use get_random_u32 for 32-bit lock random Jason A. Donenfeld
2017-06-06 17:47 ` [kernel-hardening] " Jason A. Donenfeld
2017-06-08 0:25 ` Theodore Ts'o [this message]
2017-06-08 0:25 ` Theodore Ts'o
2017-06-08 0:31 ` Jason A. Donenfeld
2017-06-08 0:34 ` Jason A. Donenfeld
2017-06-06 17:48 ` [PATCH v4 09/13] rhashtable: use get_random_u32 for hash_rnd Jason A. Donenfeld
2017-06-06 17:48 ` [kernel-hardening] " Jason A. Donenfeld
2017-06-08 2:47 ` Theodore Ts'o
2017-06-08 2:47 ` [kernel-hardening] " Theodore Ts'o
2017-06-06 17:48 ` [PATCH v4 10/13] net/neighbor: use get_random_u32 for 32-bit hash random Jason A. Donenfeld
2017-06-06 17:48 ` [kernel-hardening] " Jason A. Donenfeld
2017-06-08 3:00 ` Theodore Ts'o
2017-06-08 3:00 ` [kernel-hardening] " Theodore Ts'o
2017-06-06 17:48 ` [PATCH v4 11/13] net/route: use get_random_int for random counter Jason A. Donenfeld
2017-06-06 17:48 ` [kernel-hardening] " Jason A. Donenfeld
2017-06-08 3:01 ` Theodore Ts'o
2017-06-08 3:01 ` [kernel-hardening] " Theodore Ts'o
2017-06-06 17:48 ` [PATCH v4 12/13] bluetooth/smp: ensure RNG is properly seeded before ECDH use Jason A. Donenfeld
2017-06-06 17:48 ` [kernel-hardening] " Jason A. Donenfeld
2017-06-08 3:06 ` Theodore Ts'o
2017-06-08 3:06 ` [kernel-hardening] " Theodore Ts'o
2017-06-08 5:04 ` Marcel Holtmann
2017-06-08 5:04 ` [kernel-hardening] " Marcel Holtmann
2017-06-08 12:03 ` Jason A. Donenfeld
2017-06-08 12:03 ` [kernel-hardening] " Jason A. Donenfeld
2017-06-08 12:05 ` Jason A. Donenfeld
2017-06-08 12:05 ` [kernel-hardening] " Jason A. Donenfeld
2017-06-08 17:05 ` Marcel Holtmann
2017-06-08 17:05 ` [kernel-hardening] " Marcel Holtmann
2017-06-08 17:34 ` Jason A. Donenfeld
2017-06-08 17:34 ` [kernel-hardening] " Jason A. Donenfeld
2017-06-09 1:16 ` [PATCH] bluetooth: ensure RNG is properly seeded before powerup Jason A. Donenfeld
2017-06-06 17:48 ` [PATCH v4 13/13] random: warn when kernel uses unseeded randomness Jason A. Donenfeld
2017-06-06 17:48 ` [kernel-hardening] " Jason A. Donenfeld
2017-06-08 8:19 ` Theodore Ts'o
2017-06-08 8:19 ` [kernel-hardening] " Theodore Ts'o
2017-06-08 12:01 ` Jason A. Donenfeld
2017-06-08 12:01 ` [kernel-hardening] " Jason A. Donenfeld
2017-06-15 11:03 ` Michael Ellerman
2017-06-15 11:59 ` Stephan Müller
2017-06-18 15:46 ` Theodore Ts'o
2017-06-18 17:55 ` Stephan Müller
2017-06-18 19:12 ` Jason A. Donenfeld
2017-06-18 19:11 ` Jason A. Donenfeld
2017-06-08 8:43 ` Jeffrey Walton
2017-06-08 8:43 ` [kernel-hardening] " Jeffrey Walton
2017-06-07 12:33 ` [PATCH v4 00/13] Unseeded In-Kernel Randomness Fixes Jason A. Donenfeld
2017-06-07 12:33 ` [kernel-hardening] " Jason A. Donenfeld
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=20170608002523.m3h3jin4poav5xy2@thunk.org \
--to=tytso@mit.edu \
--cc=Jason@zx2c4.com \
--cc=davem@davemloft.net \
--cc=ebiggers3@gmail.com \
--cc=gregkh@linuxfoundation.org \
--cc=kernel-hardening@lists.openwall.com \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=sfrench@samba.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.