| Message ID | 20170606174804.31124-9-Jason@zx2c4.com (mailing list archive) |
|---|---|
| State | Not Applicable |
| Delegated to: | Herbert Xu |
| Headers | show |
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
On Thu, Jun 8, 2017 at 2:25 AM, Theodore Ts'o <tytso@mit.edu> wrote: > 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. :-) High five for taking the deep dive and actually reading how this all works. Nice bug! > Not waiting > for the CRNG to be fully initialized is the *least* of its problems. The kernel is vast and filled with tons of bugs of many sorts. On this reasoning, maybe I should spend my time auditing web apps instead, which are usually the "front door" of bugs? I like the puzzles of random.c. I also had a real world need for wait_for_random_bytes() in a module I'm writing. But anyway, your general point is a really good one. Tons of callers of the random functions are doing it wrong in one way or another. Spending time looking at those is probably a good idea... > Anyway, I'll include this commit in the dev branch of the random tree, > since it's not going to make things worse. Great, thanks.
On Thu, Jun 8, 2017 at 2:25 AM, Theodore Ts'o <tytso@mit.edu> wrote: > 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. :-) High five for taking the deep dive and actually reading how this all works. Nice bug! > Not waiting > for the CRNG to be fully initialized is the *least* of its problems. The kernel is vast and filled with tons of bugs of many sorts. On this reasoning, maybe I should spend my time auditing web apps instead, which are usually the "front door" of bugs? I like the puzzles of random.c. I also had a real world need for wait_for_random_bytes() in a module I'm writing. But anyway, your general point is a really good one. Tons of callers of the random functions are doing it wrong in one way or another. Spending time looking at those is probably a good idea... > Anyway, I'll include this commit in the dev branch of the random tree, > since it's not going to make things worse. Great, thanks.
diff --git a/fs/cifs/cifsfs.c b/fs/cifs/cifsfs.c index 9a1667e0e8d6..fe0c8dcc7dc7 100644 --- a/fs/cifs/cifsfs.c +++ b/fs/cifs/cifsfs.c @@ -1359,7 +1359,7 @@ init_cifs(void) spin_lock_init(&cifs_tcp_ses_lock); spin_lock_init(&GlobalMid_Lock); - get_random_bytes(&cifs_lock_secret, sizeof(cifs_lock_secret)); + cifs_lock_secret = get_random_u32(); if (cifs_max_pending < 2) { cifs_max_pending = 2;
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> --- fs/cifs/cifsfs.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)