2013-09-24 17:35:18 +08:00
|
|
|
/* Large capacity key type
|
|
|
|
*
|
security/keys: rewrite all of big_key crypto
This started out as just replacing the use of crypto/rng with
get_random_bytes_wait, so that we wouldn't use bad randomness at boot
time. But, upon looking further, it appears that there were even deeper
underlying cryptographic problems, and that this seems to have been
committed with very little crypto review. So, I rewrote the whole thing,
trying to keep to the conventions introduced by the previous author, to
fix these cryptographic flaws.
It makes no sense to seed crypto/rng at boot time and then keep
using it like this, when in fact there's already get_random_bytes_wait,
which can ensure there's enough entropy and be a much more standard way
of generating keys. Since this sensitive material is being stored
untrusted, using ECB and no authentication is simply not okay at all. I
find it surprising and a bit horrifying that this code even made it past
basic crypto review, which perhaps points to some larger issues. This
patch moves from using AES-ECB to using AES-GCM. Since keys are uniquely
generated each time, we can set the nonce to zero. There was also a race
condition in which the same key would be reused at the same time in
different threads. A mutex fixes this issue now.
So, to summarize, this commit fixes the following vulnerabilities:
* Low entropy key generation, allowing an attacker to potentially
guess or predict keys.
* Unauthenticated encryption, allowing an attacker to modify the
cipher text in particular ways in order to manipulate the plaintext,
which is is even more frightening considering the next point.
* Use of ECB mode, allowing an attacker to trivially swap blocks or
compare identical plaintext blocks.
* Key re-use.
* Faulty memory zeroing.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
Reviewed-by: Eric Biggers <ebiggers3@gmail.com>
Signed-off-by: David Howells <dhowells@redhat.com>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Cc: Kirill Marinushkin <k.marinushkin@gmail.com>
Cc: security@kernel.org
Cc: stable@vger.kernel.org
2017-09-20 22:58:39 +08:00
|
|
|
* Copyright (C) 2017 Jason A. Donenfeld <Jason@zx2c4.com>. All Rights Reserved.
|
2013-09-24 17:35:18 +08:00
|
|
|
* Copyright (C) 2013 Red Hat, Inc. All Rights Reserved.
|
|
|
|
* Written by David Howells (dhowells@redhat.com)
|
|
|
|
*
|
|
|
|
* This program is free software; you can redistribute it and/or
|
|
|
|
* modify it under the terms of the GNU General Public Licence
|
|
|
|
* as published by the Free Software Foundation; either version
|
|
|
|
* 2 of the Licence, or (at your option) any later version.
|
|
|
|
*/
|
|
|
|
|
2016-10-26 22:02:01 +08:00
|
|
|
#define pr_fmt(fmt) "big_key: "fmt
|
2013-09-24 17:35:18 +08:00
|
|
|
#include <linux/init.h>
|
|
|
|
#include <linux/seq_file.h>
|
|
|
|
#include <linux/file.h>
|
|
|
|
#include <linux/shmem_fs.h>
|
|
|
|
#include <linux/err.h>
|
2016-04-13 02:54:58 +08:00
|
|
|
#include <linux/scatterlist.h>
|
security/keys: rewrite all of big_key crypto
This started out as just replacing the use of crypto/rng with
get_random_bytes_wait, so that we wouldn't use bad randomness at boot
time. But, upon looking further, it appears that there were even deeper
underlying cryptographic problems, and that this seems to have been
committed with very little crypto review. So, I rewrote the whole thing,
trying to keep to the conventions introduced by the previous author, to
fix these cryptographic flaws.
It makes no sense to seed crypto/rng at boot time and then keep
using it like this, when in fact there's already get_random_bytes_wait,
which can ensure there's enough entropy and be a much more standard way
of generating keys. Since this sensitive material is being stored
untrusted, using ECB and no authentication is simply not okay at all. I
find it surprising and a bit horrifying that this code even made it past
basic crypto review, which perhaps points to some larger issues. This
patch moves from using AES-ECB to using AES-GCM. Since keys are uniquely
generated each time, we can set the nonce to zero. There was also a race
condition in which the same key would be reused at the same time in
different threads. A mutex fixes this issue now.
So, to summarize, this commit fixes the following vulnerabilities:
* Low entropy key generation, allowing an attacker to potentially
guess or predict keys.
* Unauthenticated encryption, allowing an attacker to modify the
cipher text in particular ways in order to manipulate the plaintext,
which is is even more frightening considering the next point.
* Use of ECB mode, allowing an attacker to trivially swap blocks or
compare identical plaintext blocks.
* Key re-use.
* Faulty memory zeroing.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
Reviewed-by: Eric Biggers <ebiggers3@gmail.com>
Signed-off-by: David Howells <dhowells@redhat.com>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Cc: Kirill Marinushkin <k.marinushkin@gmail.com>
Cc: security@kernel.org
Cc: stable@vger.kernel.org
2017-09-20 22:58:39 +08:00
|
|
|
#include <linux/random.h>
|
2018-04-06 07:25:34 +08:00
|
|
|
#include <linux/vmalloc.h>
|
2013-09-24 17:35:18 +08:00
|
|
|
#include <keys/user-type.h>
|
|
|
|
#include <keys/big_key-type.h>
|
security/keys: rewrite all of big_key crypto
This started out as just replacing the use of crypto/rng with
get_random_bytes_wait, so that we wouldn't use bad randomness at boot
time. But, upon looking further, it appears that there were even deeper
underlying cryptographic problems, and that this seems to have been
committed with very little crypto review. So, I rewrote the whole thing,
trying to keep to the conventions introduced by the previous author, to
fix these cryptographic flaws.
It makes no sense to seed crypto/rng at boot time and then keep
using it like this, when in fact there's already get_random_bytes_wait,
which can ensure there's enough entropy and be a much more standard way
of generating keys. Since this sensitive material is being stored
untrusted, using ECB and no authentication is simply not okay at all. I
find it surprising and a bit horrifying that this code even made it past
basic crypto review, which perhaps points to some larger issues. This
patch moves from using AES-ECB to using AES-GCM. Since keys are uniquely
generated each time, we can set the nonce to zero. There was also a race
condition in which the same key would be reused at the same time in
different threads. A mutex fixes this issue now.
So, to summarize, this commit fixes the following vulnerabilities:
* Low entropy key generation, allowing an attacker to potentially
guess or predict keys.
* Unauthenticated encryption, allowing an attacker to modify the
cipher text in particular ways in order to manipulate the plaintext,
which is is even more frightening considering the next point.
* Use of ECB mode, allowing an attacker to trivially swap blocks or
compare identical plaintext blocks.
* Key re-use.
* Faulty memory zeroing.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
Reviewed-by: Eric Biggers <ebiggers3@gmail.com>
Signed-off-by: David Howells <dhowells@redhat.com>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Cc: Kirill Marinushkin <k.marinushkin@gmail.com>
Cc: security@kernel.org
Cc: stable@vger.kernel.org
2017-09-20 22:58:39 +08:00
|
|
|
#include <crypto/aead.h>
|
2018-04-25 04:26:37 +08:00
|
|
|
#include <crypto/gcm.h>
|
2013-09-24 17:35:18 +08:00
|
|
|
|
2018-02-22 22:38:34 +08:00
|
|
|
struct big_key_buf {
|
|
|
|
unsigned int nr_pages;
|
|
|
|
void *virt;
|
|
|
|
struct scatterlist *sg;
|
|
|
|
struct page *pages[];
|
|
|
|
};
|
|
|
|
|
2015-10-21 21:04:48 +08:00
|
|
|
/*
|
|
|
|
* Layout of key payload words.
|
|
|
|
*/
|
|
|
|
enum {
|
|
|
|
big_key_data,
|
|
|
|
big_key_path,
|
|
|
|
big_key_path_2nd_part,
|
|
|
|
big_key_len,
|
|
|
|
};
|
|
|
|
|
2016-04-13 02:54:58 +08:00
|
|
|
/*
|
|
|
|
* Crypto operation with big_key data
|
|
|
|
*/
|
|
|
|
enum big_key_op {
|
|
|
|
BIG_KEY_ENC,
|
|
|
|
BIG_KEY_DEC,
|
|
|
|
};
|
|
|
|
|
2013-09-24 17:35:18 +08:00
|
|
|
/*
|
|
|
|
* If the data is under this limit, there's no point creating a shm file to
|
|
|
|
* hold it as the permanently resident metadata for the shmem fs will be at
|
|
|
|
* least as large as the data.
|
|
|
|
*/
|
|
|
|
#define BIG_KEY_FILE_THRESHOLD (sizeof(struct inode) + sizeof(struct dentry))
|
|
|
|
|
2016-04-13 02:54:58 +08:00
|
|
|
/*
|
|
|
|
* Key size for big_key data encryption
|
|
|
|
*/
|
security/keys: rewrite all of big_key crypto
This started out as just replacing the use of crypto/rng with
get_random_bytes_wait, so that we wouldn't use bad randomness at boot
time. But, upon looking further, it appears that there were even deeper
underlying cryptographic problems, and that this seems to have been
committed with very little crypto review. So, I rewrote the whole thing,
trying to keep to the conventions introduced by the previous author, to
fix these cryptographic flaws.
It makes no sense to seed crypto/rng at boot time and then keep
using it like this, when in fact there's already get_random_bytes_wait,
which can ensure there's enough entropy and be a much more standard way
of generating keys. Since this sensitive material is being stored
untrusted, using ECB and no authentication is simply not okay at all. I
find it surprising and a bit horrifying that this code even made it past
basic crypto review, which perhaps points to some larger issues. This
patch moves from using AES-ECB to using AES-GCM. Since keys are uniquely
generated each time, we can set the nonce to zero. There was also a race
condition in which the same key would be reused at the same time in
different threads. A mutex fixes this issue now.
So, to summarize, this commit fixes the following vulnerabilities:
* Low entropy key generation, allowing an attacker to potentially
guess or predict keys.
* Unauthenticated encryption, allowing an attacker to modify the
cipher text in particular ways in order to manipulate the plaintext,
which is is even more frightening considering the next point.
* Use of ECB mode, allowing an attacker to trivially swap blocks or
compare identical plaintext blocks.
* Key re-use.
* Faulty memory zeroing.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
Reviewed-by: Eric Biggers <ebiggers3@gmail.com>
Signed-off-by: David Howells <dhowells@redhat.com>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Cc: Kirill Marinushkin <k.marinushkin@gmail.com>
Cc: security@kernel.org
Cc: stable@vger.kernel.org
2017-09-20 22:58:39 +08:00
|
|
|
#define ENC_KEY_SIZE 32
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Authentication tag length
|
|
|
|
*/
|
|
|
|
#define ENC_AUTHTAG_SIZE 16
|
2016-04-13 02:54:58 +08:00
|
|
|
|
2013-09-24 17:35:18 +08:00
|
|
|
/*
|
|
|
|
* big_key defined keys take an arbitrary string as the description and an
|
|
|
|
* arbitrary blob of data as the payload
|
|
|
|
*/
|
|
|
|
struct key_type key_type_big_key = {
|
|
|
|
.name = "big_key",
|
2014-07-19 01:56:36 +08:00
|
|
|
.preparse = big_key_preparse,
|
|
|
|
.free_preparse = big_key_free_preparse,
|
|
|
|
.instantiate = generic_key_instantiate,
|
2013-09-24 17:35:18 +08:00
|
|
|
.revoke = big_key_revoke,
|
|
|
|
.destroy = big_key_destroy,
|
|
|
|
.describe = big_key_describe,
|
|
|
|
.read = big_key_read,
|
security/keys: rewrite all of big_key crypto
This started out as just replacing the use of crypto/rng with
get_random_bytes_wait, so that we wouldn't use bad randomness at boot
time. But, upon looking further, it appears that there were even deeper
underlying cryptographic problems, and that this seems to have been
committed with very little crypto review. So, I rewrote the whole thing,
trying to keep to the conventions introduced by the previous author, to
fix these cryptographic flaws.
It makes no sense to seed crypto/rng at boot time and then keep
using it like this, when in fact there's already get_random_bytes_wait,
which can ensure there's enough entropy and be a much more standard way
of generating keys. Since this sensitive material is being stored
untrusted, using ECB and no authentication is simply not okay at all. I
find it surprising and a bit horrifying that this code even made it past
basic crypto review, which perhaps points to some larger issues. This
patch moves from using AES-ECB to using AES-GCM. Since keys are uniquely
generated each time, we can set the nonce to zero. There was also a race
condition in which the same key would be reused at the same time in
different threads. A mutex fixes this issue now.
So, to summarize, this commit fixes the following vulnerabilities:
* Low entropy key generation, allowing an attacker to potentially
guess or predict keys.
* Unauthenticated encryption, allowing an attacker to modify the
cipher text in particular ways in order to manipulate the plaintext,
which is is even more frightening considering the next point.
* Use of ECB mode, allowing an attacker to trivially swap blocks or
compare identical plaintext blocks.
* Key re-use.
* Faulty memory zeroing.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
Reviewed-by: Eric Biggers <ebiggers3@gmail.com>
Signed-off-by: David Howells <dhowells@redhat.com>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Cc: Kirill Marinushkin <k.marinushkin@gmail.com>
Cc: security@kernel.org
Cc: stable@vger.kernel.org
2017-09-20 22:58:39 +08:00
|
|
|
/* no ->update(); don't add it without changing big_key_crypt() nonce */
|
2013-09-24 17:35:18 +08:00
|
|
|
};
|
|
|
|
|
2016-04-13 02:54:58 +08:00
|
|
|
/*
|
security/keys: rewrite all of big_key crypto
This started out as just replacing the use of crypto/rng with
get_random_bytes_wait, so that we wouldn't use bad randomness at boot
time. But, upon looking further, it appears that there were even deeper
underlying cryptographic problems, and that this seems to have been
committed with very little crypto review. So, I rewrote the whole thing,
trying to keep to the conventions introduced by the previous author, to
fix these cryptographic flaws.
It makes no sense to seed crypto/rng at boot time and then keep
using it like this, when in fact there's already get_random_bytes_wait,
which can ensure there's enough entropy and be a much more standard way
of generating keys. Since this sensitive material is being stored
untrusted, using ECB and no authentication is simply not okay at all. I
find it surprising and a bit horrifying that this code even made it past
basic crypto review, which perhaps points to some larger issues. This
patch moves from using AES-ECB to using AES-GCM. Since keys are uniquely
generated each time, we can set the nonce to zero. There was also a race
condition in which the same key would be reused at the same time in
different threads. A mutex fixes this issue now.
So, to summarize, this commit fixes the following vulnerabilities:
* Low entropy key generation, allowing an attacker to potentially
guess or predict keys.
* Unauthenticated encryption, allowing an attacker to modify the
cipher text in particular ways in order to manipulate the plaintext,
which is is even more frightening considering the next point.
* Use of ECB mode, allowing an attacker to trivially swap blocks or
compare identical plaintext blocks.
* Key re-use.
* Faulty memory zeroing.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
Reviewed-by: Eric Biggers <ebiggers3@gmail.com>
Signed-off-by: David Howells <dhowells@redhat.com>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Cc: Kirill Marinushkin <k.marinushkin@gmail.com>
Cc: security@kernel.org
Cc: stable@vger.kernel.org
2017-09-20 22:58:39 +08:00
|
|
|
* Crypto names for big_key data authenticated encryption
|
2016-04-13 02:54:58 +08:00
|
|
|
*/
|
security/keys: rewrite all of big_key crypto
This started out as just replacing the use of crypto/rng with
get_random_bytes_wait, so that we wouldn't use bad randomness at boot
time. But, upon looking further, it appears that there were even deeper
underlying cryptographic problems, and that this seems to have been
committed with very little crypto review. So, I rewrote the whole thing,
trying to keep to the conventions introduced by the previous author, to
fix these cryptographic flaws.
It makes no sense to seed crypto/rng at boot time and then keep
using it like this, when in fact there's already get_random_bytes_wait,
which can ensure there's enough entropy and be a much more standard way
of generating keys. Since this sensitive material is being stored
untrusted, using ECB and no authentication is simply not okay at all. I
find it surprising and a bit horrifying that this code even made it past
basic crypto review, which perhaps points to some larger issues. This
patch moves from using AES-ECB to using AES-GCM. Since keys are uniquely
generated each time, we can set the nonce to zero. There was also a race
condition in which the same key would be reused at the same time in
different threads. A mutex fixes this issue now.
So, to summarize, this commit fixes the following vulnerabilities:
* Low entropy key generation, allowing an attacker to potentially
guess or predict keys.
* Unauthenticated encryption, allowing an attacker to modify the
cipher text in particular ways in order to manipulate the plaintext,
which is is even more frightening considering the next point.
* Use of ECB mode, allowing an attacker to trivially swap blocks or
compare identical plaintext blocks.
* Key re-use.
* Faulty memory zeroing.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
Reviewed-by: Eric Biggers <ebiggers3@gmail.com>
Signed-off-by: David Howells <dhowells@redhat.com>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Cc: Kirill Marinushkin <k.marinushkin@gmail.com>
Cc: security@kernel.org
Cc: stable@vger.kernel.org
2017-09-20 22:58:39 +08:00
|
|
|
static const char big_key_alg_name[] = "gcm(aes)";
|
2018-04-25 04:26:37 +08:00
|
|
|
#define BIG_KEY_IV_SIZE GCM_AES_IV_SIZE
|
2016-04-13 02:54:58 +08:00
|
|
|
|
|
|
|
/*
|
security/keys: rewrite all of big_key crypto
This started out as just replacing the use of crypto/rng with
get_random_bytes_wait, so that we wouldn't use bad randomness at boot
time. But, upon looking further, it appears that there were even deeper
underlying cryptographic problems, and that this seems to have been
committed with very little crypto review. So, I rewrote the whole thing,
trying to keep to the conventions introduced by the previous author, to
fix these cryptographic flaws.
It makes no sense to seed crypto/rng at boot time and then keep
using it like this, when in fact there's already get_random_bytes_wait,
which can ensure there's enough entropy and be a much more standard way
of generating keys. Since this sensitive material is being stored
untrusted, using ECB and no authentication is simply not okay at all. I
find it surprising and a bit horrifying that this code even made it past
basic crypto review, which perhaps points to some larger issues. This
patch moves from using AES-ECB to using AES-GCM. Since keys are uniquely
generated each time, we can set the nonce to zero. There was also a race
condition in which the same key would be reused at the same time in
different threads. A mutex fixes this issue now.
So, to summarize, this commit fixes the following vulnerabilities:
* Low entropy key generation, allowing an attacker to potentially
guess or predict keys.
* Unauthenticated encryption, allowing an attacker to modify the
cipher text in particular ways in order to manipulate the plaintext,
which is is even more frightening considering the next point.
* Use of ECB mode, allowing an attacker to trivially swap blocks or
compare identical plaintext blocks.
* Key re-use.
* Faulty memory zeroing.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
Reviewed-by: Eric Biggers <ebiggers3@gmail.com>
Signed-off-by: David Howells <dhowells@redhat.com>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Cc: Kirill Marinushkin <k.marinushkin@gmail.com>
Cc: security@kernel.org
Cc: stable@vger.kernel.org
2017-09-20 22:58:39 +08:00
|
|
|
* Crypto algorithms for big_key data authenticated encryption
|
2016-04-13 02:54:58 +08:00
|
|
|
*/
|
security/keys: rewrite all of big_key crypto
This started out as just replacing the use of crypto/rng with
get_random_bytes_wait, so that we wouldn't use bad randomness at boot
time. But, upon looking further, it appears that there were even deeper
underlying cryptographic problems, and that this seems to have been
committed with very little crypto review. So, I rewrote the whole thing,
trying to keep to the conventions introduced by the previous author, to
fix these cryptographic flaws.
It makes no sense to seed crypto/rng at boot time and then keep
using it like this, when in fact there's already get_random_bytes_wait,
which can ensure there's enough entropy and be a much more standard way
of generating keys. Since this sensitive material is being stored
untrusted, using ECB and no authentication is simply not okay at all. I
find it surprising and a bit horrifying that this code even made it past
basic crypto review, which perhaps points to some larger issues. This
patch moves from using AES-ECB to using AES-GCM. Since keys are uniquely
generated each time, we can set the nonce to zero. There was also a race
condition in which the same key would be reused at the same time in
different threads. A mutex fixes this issue now.
So, to summarize, this commit fixes the following vulnerabilities:
* Low entropy key generation, allowing an attacker to potentially
guess or predict keys.
* Unauthenticated encryption, allowing an attacker to modify the
cipher text in particular ways in order to manipulate the plaintext,
which is is even more frightening considering the next point.
* Use of ECB mode, allowing an attacker to trivially swap blocks or
compare identical plaintext blocks.
* Key re-use.
* Faulty memory zeroing.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
Reviewed-by: Eric Biggers <ebiggers3@gmail.com>
Signed-off-by: David Howells <dhowells@redhat.com>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Cc: Kirill Marinushkin <k.marinushkin@gmail.com>
Cc: security@kernel.org
Cc: stable@vger.kernel.org
2017-09-20 22:58:39 +08:00
|
|
|
static struct crypto_aead *big_key_aead;
|
2016-04-13 02:54:58 +08:00
|
|
|
|
|
|
|
/*
|
security/keys: rewrite all of big_key crypto
This started out as just replacing the use of crypto/rng with
get_random_bytes_wait, so that we wouldn't use bad randomness at boot
time. But, upon looking further, it appears that there were even deeper
underlying cryptographic problems, and that this seems to have been
committed with very little crypto review. So, I rewrote the whole thing,
trying to keep to the conventions introduced by the previous author, to
fix these cryptographic flaws.
It makes no sense to seed crypto/rng at boot time and then keep
using it like this, when in fact there's already get_random_bytes_wait,
which can ensure there's enough entropy and be a much more standard way
of generating keys. Since this sensitive material is being stored
untrusted, using ECB and no authentication is simply not okay at all. I
find it surprising and a bit horrifying that this code even made it past
basic crypto review, which perhaps points to some larger issues. This
patch moves from using AES-ECB to using AES-GCM. Since keys are uniquely
generated each time, we can set the nonce to zero. There was also a race
condition in which the same key would be reused at the same time in
different threads. A mutex fixes this issue now.
So, to summarize, this commit fixes the following vulnerabilities:
* Low entropy key generation, allowing an attacker to potentially
guess or predict keys.
* Unauthenticated encryption, allowing an attacker to modify the
cipher text in particular ways in order to manipulate the plaintext,
which is is even more frightening considering the next point.
* Use of ECB mode, allowing an attacker to trivially swap blocks or
compare identical plaintext blocks.
* Key re-use.
* Faulty memory zeroing.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
Reviewed-by: Eric Biggers <ebiggers3@gmail.com>
Signed-off-by: David Howells <dhowells@redhat.com>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Cc: Kirill Marinushkin <k.marinushkin@gmail.com>
Cc: security@kernel.org
Cc: stable@vger.kernel.org
2017-09-20 22:58:39 +08:00
|
|
|
* Since changing the key affects the entire object, we need a mutex.
|
2016-04-13 02:54:58 +08:00
|
|
|
*/
|
security/keys: rewrite all of big_key crypto
This started out as just replacing the use of crypto/rng with
get_random_bytes_wait, so that we wouldn't use bad randomness at boot
time. But, upon looking further, it appears that there were even deeper
underlying cryptographic problems, and that this seems to have been
committed with very little crypto review. So, I rewrote the whole thing,
trying to keep to the conventions introduced by the previous author, to
fix these cryptographic flaws.
It makes no sense to seed crypto/rng at boot time and then keep
using it like this, when in fact there's already get_random_bytes_wait,
which can ensure there's enough entropy and be a much more standard way
of generating keys. Since this sensitive material is being stored
untrusted, using ECB and no authentication is simply not okay at all. I
find it surprising and a bit horrifying that this code even made it past
basic crypto review, which perhaps points to some larger issues. This
patch moves from using AES-ECB to using AES-GCM. Since keys are uniquely
generated each time, we can set the nonce to zero. There was also a race
condition in which the same key would be reused at the same time in
different threads. A mutex fixes this issue now.
So, to summarize, this commit fixes the following vulnerabilities:
* Low entropy key generation, allowing an attacker to potentially
guess or predict keys.
* Unauthenticated encryption, allowing an attacker to modify the
cipher text in particular ways in order to manipulate the plaintext,
which is is even more frightening considering the next point.
* Use of ECB mode, allowing an attacker to trivially swap blocks or
compare identical plaintext blocks.
* Key re-use.
* Faulty memory zeroing.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
Reviewed-by: Eric Biggers <ebiggers3@gmail.com>
Signed-off-by: David Howells <dhowells@redhat.com>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Cc: Kirill Marinushkin <k.marinushkin@gmail.com>
Cc: security@kernel.org
Cc: stable@vger.kernel.org
2017-09-20 22:58:39 +08:00
|
|
|
static DEFINE_MUTEX(big_key_aead_lock);
|
2016-04-13 02:54:58 +08:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Encrypt/decrypt big_key data
|
|
|
|
*/
|
2018-02-22 22:38:34 +08:00
|
|
|
static int big_key_crypt(enum big_key_op op, struct big_key_buf *buf, size_t datalen, u8 *key)
|
2016-04-13 02:54:58 +08:00
|
|
|
{
|
security/keys: rewrite all of big_key crypto
This started out as just replacing the use of crypto/rng with
get_random_bytes_wait, so that we wouldn't use bad randomness at boot
time. But, upon looking further, it appears that there were even deeper
underlying cryptographic problems, and that this seems to have been
committed with very little crypto review. So, I rewrote the whole thing,
trying to keep to the conventions introduced by the previous author, to
fix these cryptographic flaws.
It makes no sense to seed crypto/rng at boot time and then keep
using it like this, when in fact there's already get_random_bytes_wait,
which can ensure there's enough entropy and be a much more standard way
of generating keys. Since this sensitive material is being stored
untrusted, using ECB and no authentication is simply not okay at all. I
find it surprising and a bit horrifying that this code even made it past
basic crypto review, which perhaps points to some larger issues. This
patch moves from using AES-ECB to using AES-GCM. Since keys are uniquely
generated each time, we can set the nonce to zero. There was also a race
condition in which the same key would be reused at the same time in
different threads. A mutex fixes this issue now.
So, to summarize, this commit fixes the following vulnerabilities:
* Low entropy key generation, allowing an attacker to potentially
guess or predict keys.
* Unauthenticated encryption, allowing an attacker to modify the
cipher text in particular ways in order to manipulate the plaintext,
which is is even more frightening considering the next point.
* Use of ECB mode, allowing an attacker to trivially swap blocks or
compare identical plaintext blocks.
* Key re-use.
* Faulty memory zeroing.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
Reviewed-by: Eric Biggers <ebiggers3@gmail.com>
Signed-off-by: David Howells <dhowells@redhat.com>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Cc: Kirill Marinushkin <k.marinushkin@gmail.com>
Cc: security@kernel.org
Cc: stable@vger.kernel.org
2017-09-20 22:58:39 +08:00
|
|
|
int ret;
|
|
|
|
struct aead_request *aead_req;
|
|
|
|
/* We always use a zero nonce. The reason we can get away with this is
|
|
|
|
* because we're using a different randomly generated key for every
|
|
|
|
* different encryption. Notably, too, key_type_big_key doesn't define
|
|
|
|
* an .update function, so there's no chance we'll wind up reusing the
|
|
|
|
* key to encrypt updated data. Simply put: one key, one encryption.
|
|
|
|
*/
|
2018-04-25 04:26:37 +08:00
|
|
|
u8 zero_nonce[BIG_KEY_IV_SIZE];
|
security/keys: rewrite all of big_key crypto
This started out as just replacing the use of crypto/rng with
get_random_bytes_wait, so that we wouldn't use bad randomness at boot
time. But, upon looking further, it appears that there were even deeper
underlying cryptographic problems, and that this seems to have been
committed with very little crypto review. So, I rewrote the whole thing,
trying to keep to the conventions introduced by the previous author, to
fix these cryptographic flaws.
It makes no sense to seed crypto/rng at boot time and then keep
using it like this, when in fact there's already get_random_bytes_wait,
which can ensure there's enough entropy and be a much more standard way
of generating keys. Since this sensitive material is being stored
untrusted, using ECB and no authentication is simply not okay at all. I
find it surprising and a bit horrifying that this code even made it past
basic crypto review, which perhaps points to some larger issues. This
patch moves from using AES-ECB to using AES-GCM. Since keys are uniquely
generated each time, we can set the nonce to zero. There was also a race
condition in which the same key would be reused at the same time in
different threads. A mutex fixes this issue now.
So, to summarize, this commit fixes the following vulnerabilities:
* Low entropy key generation, allowing an attacker to potentially
guess or predict keys.
* Unauthenticated encryption, allowing an attacker to modify the
cipher text in particular ways in order to manipulate the plaintext,
which is is even more frightening considering the next point.
* Use of ECB mode, allowing an attacker to trivially swap blocks or
compare identical plaintext blocks.
* Key re-use.
* Faulty memory zeroing.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
Reviewed-by: Eric Biggers <ebiggers3@gmail.com>
Signed-off-by: David Howells <dhowells@redhat.com>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Cc: Kirill Marinushkin <k.marinushkin@gmail.com>
Cc: security@kernel.org
Cc: stable@vger.kernel.org
2017-09-20 22:58:39 +08:00
|
|
|
|
|
|
|
aead_req = aead_request_alloc(big_key_aead, GFP_KERNEL);
|
|
|
|
if (!aead_req)
|
|
|
|
return -ENOMEM;
|
|
|
|
|
|
|
|
memset(zero_nonce, 0, sizeof(zero_nonce));
|
2018-02-22 22:38:34 +08:00
|
|
|
aead_request_set_crypt(aead_req, buf->sg, buf->sg, datalen, zero_nonce);
|
security/keys: rewrite all of big_key crypto
This started out as just replacing the use of crypto/rng with
get_random_bytes_wait, so that we wouldn't use bad randomness at boot
time. But, upon looking further, it appears that there were even deeper
underlying cryptographic problems, and that this seems to have been
committed with very little crypto review. So, I rewrote the whole thing,
trying to keep to the conventions introduced by the previous author, to
fix these cryptographic flaws.
It makes no sense to seed crypto/rng at boot time and then keep
using it like this, when in fact there's already get_random_bytes_wait,
which can ensure there's enough entropy and be a much more standard way
of generating keys. Since this sensitive material is being stored
untrusted, using ECB and no authentication is simply not okay at all. I
find it surprising and a bit horrifying that this code even made it past
basic crypto review, which perhaps points to some larger issues. This
patch moves from using AES-ECB to using AES-GCM. Since keys are uniquely
generated each time, we can set the nonce to zero. There was also a race
condition in which the same key would be reused at the same time in
different threads. A mutex fixes this issue now.
So, to summarize, this commit fixes the following vulnerabilities:
* Low entropy key generation, allowing an attacker to potentially
guess or predict keys.
* Unauthenticated encryption, allowing an attacker to modify the
cipher text in particular ways in order to manipulate the plaintext,
which is is even more frightening considering the next point.
* Use of ECB mode, allowing an attacker to trivially swap blocks or
compare identical plaintext blocks.
* Key re-use.
* Faulty memory zeroing.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
Reviewed-by: Eric Biggers <ebiggers3@gmail.com>
Signed-off-by: David Howells <dhowells@redhat.com>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Cc: Kirill Marinushkin <k.marinushkin@gmail.com>
Cc: security@kernel.org
Cc: stable@vger.kernel.org
2017-09-20 22:58:39 +08:00
|
|
|
aead_request_set_callback(aead_req, CRYPTO_TFM_REQ_MAY_SLEEP, NULL, NULL);
|
|
|
|
aead_request_set_ad(aead_req, 0);
|
|
|
|
|
|
|
|
mutex_lock(&big_key_aead_lock);
|
|
|
|
if (crypto_aead_setkey(big_key_aead, key, ENC_KEY_SIZE)) {
|
2016-04-13 02:54:58 +08:00
|
|
|
ret = -EAGAIN;
|
|
|
|
goto error;
|
|
|
|
}
|
|
|
|
if (op == BIG_KEY_ENC)
|
security/keys: rewrite all of big_key crypto
This started out as just replacing the use of crypto/rng with
get_random_bytes_wait, so that we wouldn't use bad randomness at boot
time. But, upon looking further, it appears that there were even deeper
underlying cryptographic problems, and that this seems to have been
committed with very little crypto review. So, I rewrote the whole thing,
trying to keep to the conventions introduced by the previous author, to
fix these cryptographic flaws.
It makes no sense to seed crypto/rng at boot time and then keep
using it like this, when in fact there's already get_random_bytes_wait,
which can ensure there's enough entropy and be a much more standard way
of generating keys. Since this sensitive material is being stored
untrusted, using ECB and no authentication is simply not okay at all. I
find it surprising and a bit horrifying that this code even made it past
basic crypto review, which perhaps points to some larger issues. This
patch moves from using AES-ECB to using AES-GCM. Since keys are uniquely
generated each time, we can set the nonce to zero. There was also a race
condition in which the same key would be reused at the same time in
different threads. A mutex fixes this issue now.
So, to summarize, this commit fixes the following vulnerabilities:
* Low entropy key generation, allowing an attacker to potentially
guess or predict keys.
* Unauthenticated encryption, allowing an attacker to modify the
cipher text in particular ways in order to manipulate the plaintext,
which is is even more frightening considering the next point.
* Use of ECB mode, allowing an attacker to trivially swap blocks or
compare identical plaintext blocks.
* Key re-use.
* Faulty memory zeroing.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
Reviewed-by: Eric Biggers <ebiggers3@gmail.com>
Signed-off-by: David Howells <dhowells@redhat.com>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Cc: Kirill Marinushkin <k.marinushkin@gmail.com>
Cc: security@kernel.org
Cc: stable@vger.kernel.org
2017-09-20 22:58:39 +08:00
|
|
|
ret = crypto_aead_encrypt(aead_req);
|
2016-04-13 02:54:58 +08:00
|
|
|
else
|
security/keys: rewrite all of big_key crypto
This started out as just replacing the use of crypto/rng with
get_random_bytes_wait, so that we wouldn't use bad randomness at boot
time. But, upon looking further, it appears that there were even deeper
underlying cryptographic problems, and that this seems to have been
committed with very little crypto review. So, I rewrote the whole thing,
trying to keep to the conventions introduced by the previous author, to
fix these cryptographic flaws.
It makes no sense to seed crypto/rng at boot time and then keep
using it like this, when in fact there's already get_random_bytes_wait,
which can ensure there's enough entropy and be a much more standard way
of generating keys. Since this sensitive material is being stored
untrusted, using ECB and no authentication is simply not okay at all. I
find it surprising and a bit horrifying that this code even made it past
basic crypto review, which perhaps points to some larger issues. This
patch moves from using AES-ECB to using AES-GCM. Since keys are uniquely
generated each time, we can set the nonce to zero. There was also a race
condition in which the same key would be reused at the same time in
different threads. A mutex fixes this issue now.
So, to summarize, this commit fixes the following vulnerabilities:
* Low entropy key generation, allowing an attacker to potentially
guess or predict keys.
* Unauthenticated encryption, allowing an attacker to modify the
cipher text in particular ways in order to manipulate the plaintext,
which is is even more frightening considering the next point.
* Use of ECB mode, allowing an attacker to trivially swap blocks or
compare identical plaintext blocks.
* Key re-use.
* Faulty memory zeroing.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
Reviewed-by: Eric Biggers <ebiggers3@gmail.com>
Signed-off-by: David Howells <dhowells@redhat.com>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Cc: Kirill Marinushkin <k.marinushkin@gmail.com>
Cc: security@kernel.org
Cc: stable@vger.kernel.org
2017-09-20 22:58:39 +08:00
|
|
|
ret = crypto_aead_decrypt(aead_req);
|
2016-04-13 02:54:58 +08:00
|
|
|
error:
|
security/keys: rewrite all of big_key crypto
This started out as just replacing the use of crypto/rng with
get_random_bytes_wait, so that we wouldn't use bad randomness at boot
time. But, upon looking further, it appears that there were even deeper
underlying cryptographic problems, and that this seems to have been
committed with very little crypto review. So, I rewrote the whole thing,
trying to keep to the conventions introduced by the previous author, to
fix these cryptographic flaws.
It makes no sense to seed crypto/rng at boot time and then keep
using it like this, when in fact there's already get_random_bytes_wait,
which can ensure there's enough entropy and be a much more standard way
of generating keys. Since this sensitive material is being stored
untrusted, using ECB and no authentication is simply not okay at all. I
find it surprising and a bit horrifying that this code even made it past
basic crypto review, which perhaps points to some larger issues. This
patch moves from using AES-ECB to using AES-GCM. Since keys are uniquely
generated each time, we can set the nonce to zero. There was also a race
condition in which the same key would be reused at the same time in
different threads. A mutex fixes this issue now.
So, to summarize, this commit fixes the following vulnerabilities:
* Low entropy key generation, allowing an attacker to potentially
guess or predict keys.
* Unauthenticated encryption, allowing an attacker to modify the
cipher text in particular ways in order to manipulate the plaintext,
which is is even more frightening considering the next point.
* Use of ECB mode, allowing an attacker to trivially swap blocks or
compare identical plaintext blocks.
* Key re-use.
* Faulty memory zeroing.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
Reviewed-by: Eric Biggers <ebiggers3@gmail.com>
Signed-off-by: David Howells <dhowells@redhat.com>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Cc: Kirill Marinushkin <k.marinushkin@gmail.com>
Cc: security@kernel.org
Cc: stable@vger.kernel.org
2017-09-20 22:58:39 +08:00
|
|
|
mutex_unlock(&big_key_aead_lock);
|
|
|
|
aead_request_free(aead_req);
|
2016-04-13 02:54:58 +08:00
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2018-02-22 22:38:34 +08:00
|
|
|
/*
|
|
|
|
* Free up the buffer.
|
|
|
|
*/
|
|
|
|
static void big_key_free_buffer(struct big_key_buf *buf)
|
|
|
|
{
|
|
|
|
unsigned int i;
|
|
|
|
|
|
|
|
if (buf->virt) {
|
|
|
|
memset(buf->virt, 0, buf->nr_pages * PAGE_SIZE);
|
|
|
|
vunmap(buf->virt);
|
|
|
|
}
|
|
|
|
|
|
|
|
for (i = 0; i < buf->nr_pages; i++)
|
|
|
|
if (buf->pages[i])
|
|
|
|
__free_page(buf->pages[i]);
|
|
|
|
|
|
|
|
kfree(buf);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Allocate a buffer consisting of a set of pages with a virtual mapping
|
|
|
|
* applied over them.
|
|
|
|
*/
|
|
|
|
static void *big_key_alloc_buffer(size_t len)
|
|
|
|
{
|
|
|
|
struct big_key_buf *buf;
|
|
|
|
unsigned int npg = (len + PAGE_SIZE - 1) >> PAGE_SHIFT;
|
|
|
|
unsigned int i, l;
|
|
|
|
|
|
|
|
buf = kzalloc(sizeof(struct big_key_buf) +
|
|
|
|
sizeof(struct page) * npg +
|
|
|
|
sizeof(struct scatterlist) * npg,
|
|
|
|
GFP_KERNEL);
|
|
|
|
if (!buf)
|
|
|
|
return NULL;
|
|
|
|
|
|
|
|
buf->nr_pages = npg;
|
|
|
|
buf->sg = (void *)(buf->pages + npg);
|
|
|
|
sg_init_table(buf->sg, npg);
|
|
|
|
|
|
|
|
for (i = 0; i < buf->nr_pages; i++) {
|
|
|
|
buf->pages[i] = alloc_page(GFP_KERNEL);
|
|
|
|
if (!buf->pages[i])
|
|
|
|
goto nomem;
|
|
|
|
|
|
|
|
l = min_t(size_t, len, PAGE_SIZE);
|
|
|
|
sg_set_page(&buf->sg[i], buf->pages[i], l, 0);
|
|
|
|
len -= l;
|
|
|
|
}
|
|
|
|
|
|
|
|
buf->virt = vmap(buf->pages, buf->nr_pages, VM_MAP, PAGE_KERNEL);
|
|
|
|
if (!buf->virt)
|
|
|
|
goto nomem;
|
|
|
|
|
|
|
|
return buf;
|
|
|
|
|
|
|
|
nomem:
|
|
|
|
big_key_free_buffer(buf);
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
2013-09-24 17:35:18 +08:00
|
|
|
/*
|
2014-07-19 01:56:36 +08:00
|
|
|
* Preparse a big key
|
2013-09-24 17:35:18 +08:00
|
|
|
*/
|
2014-07-19 01:56:36 +08:00
|
|
|
int big_key_preparse(struct key_preparsed_payload *prep)
|
2013-09-24 17:35:18 +08:00
|
|
|
{
|
2018-02-22 22:38:34 +08:00
|
|
|
struct big_key_buf *buf;
|
2015-10-21 21:04:48 +08:00
|
|
|
struct path *path = (struct path *)&prep->payload.data[big_key_path];
|
2013-09-24 17:35:18 +08:00
|
|
|
struct file *file;
|
2016-04-13 02:54:58 +08:00
|
|
|
u8 *enckey;
|
2013-09-24 17:35:18 +08:00
|
|
|
ssize_t written;
|
2018-02-22 22:38:34 +08:00
|
|
|
size_t datalen = prep->datalen, enclen = datalen + ENC_AUTHTAG_SIZE;
|
2013-09-24 17:35:18 +08:00
|
|
|
int ret;
|
|
|
|
|
|
|
|
if (datalen <= 0 || datalen > 1024 * 1024 || !prep->data)
|
2018-02-22 22:38:34 +08:00
|
|
|
return -EINVAL;
|
2013-09-24 17:35:18 +08:00
|
|
|
|
|
|
|
/* Set an arbitrary quota */
|
2014-07-19 01:56:36 +08:00
|
|
|
prep->quotalen = 16;
|
2013-09-24 17:35:18 +08:00
|
|
|
|
2015-10-21 21:04:48 +08:00
|
|
|
prep->payload.data[big_key_len] = (void *)(unsigned long)datalen;
|
2013-09-24 17:35:18 +08:00
|
|
|
|
|
|
|
if (datalen > BIG_KEY_FILE_THRESHOLD) {
|
|
|
|
/* Create a shmem file to store the data in. This will permit the data
|
|
|
|
* to be swapped out if needed.
|
|
|
|
*
|
2016-04-13 02:54:58 +08:00
|
|
|
* File content is stored encrypted with randomly generated key.
|
2013-09-24 17:35:18 +08:00
|
|
|
*/
|
2017-09-01 23:39:14 +08:00
|
|
|
loff_t pos = 0;
|
2016-04-13 02:54:58 +08:00
|
|
|
|
2018-02-22 22:38:34 +08:00
|
|
|
buf = big_key_alloc_buffer(enclen);
|
|
|
|
if (!buf)
|
2016-04-13 02:54:58 +08:00
|
|
|
return -ENOMEM;
|
2018-02-22 22:38:34 +08:00
|
|
|
memcpy(buf->virt, prep->data, datalen);
|
2016-04-13 02:54:58 +08:00
|
|
|
|
|
|
|
/* generate random key */
|
|
|
|
enckey = kmalloc(ENC_KEY_SIZE, GFP_KERNEL);
|
|
|
|
if (!enckey) {
|
|
|
|
ret = -ENOMEM;
|
|
|
|
goto error;
|
|
|
|
}
|
security/keys: rewrite all of big_key crypto
This started out as just replacing the use of crypto/rng with
get_random_bytes_wait, so that we wouldn't use bad randomness at boot
time. But, upon looking further, it appears that there were even deeper
underlying cryptographic problems, and that this seems to have been
committed with very little crypto review. So, I rewrote the whole thing,
trying to keep to the conventions introduced by the previous author, to
fix these cryptographic flaws.
It makes no sense to seed crypto/rng at boot time and then keep
using it like this, when in fact there's already get_random_bytes_wait,
which can ensure there's enough entropy and be a much more standard way
of generating keys. Since this sensitive material is being stored
untrusted, using ECB and no authentication is simply not okay at all. I
find it surprising and a bit horrifying that this code even made it past
basic crypto review, which perhaps points to some larger issues. This
patch moves from using AES-ECB to using AES-GCM. Since keys are uniquely
generated each time, we can set the nonce to zero. There was also a race
condition in which the same key would be reused at the same time in
different threads. A mutex fixes this issue now.
So, to summarize, this commit fixes the following vulnerabilities:
* Low entropy key generation, allowing an attacker to potentially
guess or predict keys.
* Unauthenticated encryption, allowing an attacker to modify the
cipher text in particular ways in order to manipulate the plaintext,
which is is even more frightening considering the next point.
* Use of ECB mode, allowing an attacker to trivially swap blocks or
compare identical plaintext blocks.
* Key re-use.
* Faulty memory zeroing.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
Reviewed-by: Eric Biggers <ebiggers3@gmail.com>
Signed-off-by: David Howells <dhowells@redhat.com>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Cc: Kirill Marinushkin <k.marinushkin@gmail.com>
Cc: security@kernel.org
Cc: stable@vger.kernel.org
2017-09-20 22:58:39 +08:00
|
|
|
ret = get_random_bytes_wait(enckey, ENC_KEY_SIZE);
|
|
|
|
if (unlikely(ret))
|
2016-04-13 02:54:58 +08:00
|
|
|
goto err_enckey;
|
|
|
|
|
|
|
|
/* encrypt aligned data */
|
2018-02-22 22:38:34 +08:00
|
|
|
ret = big_key_crypt(BIG_KEY_ENC, buf, datalen, enckey);
|
2016-04-13 02:54:58 +08:00
|
|
|
if (ret)
|
|
|
|
goto err_enckey;
|
|
|
|
|
|
|
|
/* save aligned data to file */
|
|
|
|
file = shmem_kernel_file_setup("", enclen, 0);
|
2013-10-30 11:23:02 +08:00
|
|
|
if (IS_ERR(file)) {
|
|
|
|
ret = PTR_ERR(file);
|
2016-04-13 02:54:58 +08:00
|
|
|
goto err_enckey;
|
2013-10-30 11:23:02 +08:00
|
|
|
}
|
2013-09-24 17:35:18 +08:00
|
|
|
|
2018-02-22 22:38:34 +08:00
|
|
|
written = kernel_write(file, buf->virt, enclen, &pos);
|
2016-04-13 02:54:58 +08:00
|
|
|
if (written != enclen) {
|
2013-11-14 00:51:06 +08:00
|
|
|
ret = written;
|
2013-09-24 17:35:18 +08:00
|
|
|
if (written >= 0)
|
|
|
|
ret = -ENOMEM;
|
|
|
|
goto err_fput;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Pin the mount and dentry to the key so that we can open it again
|
|
|
|
* later
|
|
|
|
*/
|
2016-04-13 02:54:58 +08:00
|
|
|
prep->payload.data[big_key_data] = enckey;
|
2013-09-24 17:35:18 +08:00
|
|
|
*path = file->f_path;
|
|
|
|
path_get(path);
|
|
|
|
fput(file);
|
2018-02-22 22:38:34 +08:00
|
|
|
big_key_free_buffer(buf);
|
2013-09-24 17:35:18 +08:00
|
|
|
} else {
|
|
|
|
/* Just store the data in a buffer */
|
|
|
|
void *data = kmalloc(datalen, GFP_KERNEL);
|
2016-04-13 02:54:58 +08:00
|
|
|
|
2014-07-19 01:56:36 +08:00
|
|
|
if (!data)
|
|
|
|
return -ENOMEM;
|
2013-09-24 17:35:18 +08:00
|
|
|
|
2015-10-21 21:04:48 +08:00
|
|
|
prep->payload.data[big_key_data] = data;
|
|
|
|
memcpy(data, prep->data, prep->datalen);
|
2013-09-24 17:35:18 +08:00
|
|
|
}
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
err_fput:
|
|
|
|
fput(file);
|
2016-04-13 02:54:58 +08:00
|
|
|
err_enckey:
|
2017-09-20 22:58:38 +08:00
|
|
|
kzfree(enckey);
|
2013-09-24 17:35:18 +08:00
|
|
|
error:
|
2018-02-22 22:38:34 +08:00
|
|
|
big_key_free_buffer(buf);
|
2013-09-24 17:35:18 +08:00
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2014-07-19 01:56:36 +08:00
|
|
|
/*
|
|
|
|
* Clear preparsement.
|
|
|
|
*/
|
|
|
|
void big_key_free_preparse(struct key_preparsed_payload *prep)
|
|
|
|
{
|
|
|
|
if (prep->datalen > BIG_KEY_FILE_THRESHOLD) {
|
2015-10-21 21:04:48 +08:00
|
|
|
struct path *path = (struct path *)&prep->payload.data[big_key_path];
|
2016-04-13 02:54:58 +08:00
|
|
|
|
2014-07-19 01:56:36 +08:00
|
|
|
path_put(path);
|
|
|
|
}
|
2017-09-20 22:58:38 +08:00
|
|
|
kzfree(prep->payload.data[big_key_data]);
|
2014-07-19 01:56:36 +08:00
|
|
|
}
|
|
|
|
|
2013-09-24 17:35:18 +08:00
|
|
|
/*
|
|
|
|
* dispose of the links from a revoked keyring
|
|
|
|
* - called with the key sem write-locked
|
|
|
|
*/
|
|
|
|
void big_key_revoke(struct key *key)
|
|
|
|
{
|
2015-10-21 21:04:48 +08:00
|
|
|
struct path *path = (struct path *)&key->payload.data[big_key_path];
|
2013-09-24 17:35:18 +08:00
|
|
|
|
|
|
|
/* clear the quota */
|
|
|
|
key_payload_reserve(key, 0);
|
2017-10-04 23:43:25 +08:00
|
|
|
if (key_is_positive(key) &&
|
2015-10-21 21:04:48 +08:00
|
|
|
(size_t)key->payload.data[big_key_len] > BIG_KEY_FILE_THRESHOLD)
|
2013-09-24 17:35:18 +08:00
|
|
|
vfs_truncate(path, 0);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* dispose of the data dangling from the corpse of a big_key key
|
|
|
|
*/
|
|
|
|
void big_key_destroy(struct key *key)
|
|
|
|
{
|
2015-10-21 21:04:48 +08:00
|
|
|
size_t datalen = (size_t)key->payload.data[big_key_len];
|
|
|
|
|
2016-04-13 02:54:58 +08:00
|
|
|
if (datalen > BIG_KEY_FILE_THRESHOLD) {
|
2015-10-21 21:04:48 +08:00
|
|
|
struct path *path = (struct path *)&key->payload.data[big_key_path];
|
2016-04-13 02:54:58 +08:00
|
|
|
|
2013-09-24 17:35:18 +08:00
|
|
|
path_put(path);
|
|
|
|
path->mnt = NULL;
|
|
|
|
path->dentry = NULL;
|
|
|
|
}
|
2017-09-20 22:58:38 +08:00
|
|
|
kzfree(key->payload.data[big_key_data]);
|
2016-04-13 02:54:58 +08:00
|
|
|
key->payload.data[big_key_data] = NULL;
|
2013-09-24 17:35:18 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* describe the big_key key
|
|
|
|
*/
|
|
|
|
void big_key_describe(const struct key *key, struct seq_file *m)
|
|
|
|
{
|
2015-10-21 21:04:48 +08:00
|
|
|
size_t datalen = (size_t)key->payload.data[big_key_len];
|
2013-09-24 17:35:18 +08:00
|
|
|
|
|
|
|
seq_puts(m, key->description);
|
|
|
|
|
2017-10-04 23:43:25 +08:00
|
|
|
if (key_is_positive(key))
|
2015-10-21 21:04:48 +08:00
|
|
|
seq_printf(m, ": %zu [%s]",
|
2013-09-24 17:35:18 +08:00
|
|
|
datalen,
|
|
|
|
datalen > BIG_KEY_FILE_THRESHOLD ? "file" : "buff");
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* read the key data
|
|
|
|
* - the key's semaphore is read-locked
|
|
|
|
*/
|
|
|
|
long big_key_read(const struct key *key, char __user *buffer, size_t buflen)
|
|
|
|
{
|
2015-10-21 21:04:48 +08:00
|
|
|
size_t datalen = (size_t)key->payload.data[big_key_len];
|
2013-09-24 17:35:18 +08:00
|
|
|
long ret;
|
|
|
|
|
|
|
|
if (!buffer || buflen < datalen)
|
|
|
|
return datalen;
|
|
|
|
|
|
|
|
if (datalen > BIG_KEY_FILE_THRESHOLD) {
|
2018-02-22 22:38:34 +08:00
|
|
|
struct big_key_buf *buf;
|
2015-10-21 21:04:48 +08:00
|
|
|
struct path *path = (struct path *)&key->payload.data[big_key_path];
|
2013-09-24 17:35:18 +08:00
|
|
|
struct file *file;
|
2016-04-13 02:54:58 +08:00
|
|
|
u8 *enckey = (u8 *)key->payload.data[big_key_data];
|
security/keys: rewrite all of big_key crypto
This started out as just replacing the use of crypto/rng with
get_random_bytes_wait, so that we wouldn't use bad randomness at boot
time. But, upon looking further, it appears that there were even deeper
underlying cryptographic problems, and that this seems to have been
committed with very little crypto review. So, I rewrote the whole thing,
trying to keep to the conventions introduced by the previous author, to
fix these cryptographic flaws.
It makes no sense to seed crypto/rng at boot time and then keep
using it like this, when in fact there's already get_random_bytes_wait,
which can ensure there's enough entropy and be a much more standard way
of generating keys. Since this sensitive material is being stored
untrusted, using ECB and no authentication is simply not okay at all. I
find it surprising and a bit horrifying that this code even made it past
basic crypto review, which perhaps points to some larger issues. This
patch moves from using AES-ECB to using AES-GCM. Since keys are uniquely
generated each time, we can set the nonce to zero. There was also a race
condition in which the same key would be reused at the same time in
different threads. A mutex fixes this issue now.
So, to summarize, this commit fixes the following vulnerabilities:
* Low entropy key generation, allowing an attacker to potentially
guess or predict keys.
* Unauthenticated encryption, allowing an attacker to modify the
cipher text in particular ways in order to manipulate the plaintext,
which is is even more frightening considering the next point.
* Use of ECB mode, allowing an attacker to trivially swap blocks or
compare identical plaintext blocks.
* Key re-use.
* Faulty memory zeroing.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
Reviewed-by: Eric Biggers <ebiggers3@gmail.com>
Signed-off-by: David Howells <dhowells@redhat.com>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Cc: Kirill Marinushkin <k.marinushkin@gmail.com>
Cc: security@kernel.org
Cc: stable@vger.kernel.org
2017-09-20 22:58:39 +08:00
|
|
|
size_t enclen = datalen + ENC_AUTHTAG_SIZE;
|
2017-09-01 23:39:13 +08:00
|
|
|
loff_t pos = 0;
|
2016-04-13 02:54:58 +08:00
|
|
|
|
2018-02-22 22:38:34 +08:00
|
|
|
buf = big_key_alloc_buffer(enclen);
|
|
|
|
if (!buf)
|
2016-04-13 02:54:58 +08:00
|
|
|
return -ENOMEM;
|
2013-09-24 17:35:18 +08:00
|
|
|
|
|
|
|
file = dentry_open(path, O_RDONLY, current_cred());
|
2016-04-13 02:54:58 +08:00
|
|
|
if (IS_ERR(file)) {
|
|
|
|
ret = PTR_ERR(file);
|
|
|
|
goto error;
|
|
|
|
}
|
2013-09-24 17:35:18 +08:00
|
|
|
|
2016-04-13 02:54:58 +08:00
|
|
|
/* read file to kernel and decrypt */
|
2018-02-22 22:38:34 +08:00
|
|
|
ret = kernel_read(file, buf->virt, enclen, &pos);
|
2016-04-13 02:54:58 +08:00
|
|
|
if (ret >= 0 && ret != enclen) {
|
2013-09-24 17:35:18 +08:00
|
|
|
ret = -EIO;
|
2016-04-13 02:54:58 +08:00
|
|
|
goto err_fput;
|
|
|
|
}
|
|
|
|
|
2018-02-22 22:38:34 +08:00
|
|
|
ret = big_key_crypt(BIG_KEY_DEC, buf, enclen, enckey);
|
2016-04-13 02:54:58 +08:00
|
|
|
if (ret)
|
|
|
|
goto err_fput;
|
|
|
|
|
|
|
|
ret = datalen;
|
|
|
|
|
|
|
|
/* copy decrypted data to user */
|
2018-02-22 22:38:34 +08:00
|
|
|
if (copy_to_user(buffer, buf->virt, datalen) != 0)
|
2016-04-13 02:54:58 +08:00
|
|
|
ret = -EFAULT;
|
|
|
|
|
|
|
|
err_fput:
|
|
|
|
fput(file);
|
|
|
|
error:
|
2018-02-22 22:38:34 +08:00
|
|
|
big_key_free_buffer(buf);
|
2013-09-24 17:35:18 +08:00
|
|
|
} else {
|
|
|
|
ret = datalen;
|
2015-10-21 21:04:48 +08:00
|
|
|
if (copy_to_user(buffer, key->payload.data[big_key_data],
|
|
|
|
datalen) != 0)
|
2013-09-24 17:35:18 +08:00
|
|
|
ret = -EFAULT;
|
|
|
|
}
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2016-04-13 02:54:58 +08:00
|
|
|
/*
|
|
|
|
* Register key type
|
|
|
|
*/
|
2013-09-24 17:35:18 +08:00
|
|
|
static int __init big_key_init(void)
|
|
|
|
{
|
2016-10-26 22:02:01 +08:00
|
|
|
int ret;
|
2016-04-13 02:54:58 +08:00
|
|
|
|
|
|
|
/* init block cipher */
|
security/keys: rewrite all of big_key crypto
This started out as just replacing the use of crypto/rng with
get_random_bytes_wait, so that we wouldn't use bad randomness at boot
time. But, upon looking further, it appears that there were even deeper
underlying cryptographic problems, and that this seems to have been
committed with very little crypto review. So, I rewrote the whole thing,
trying to keep to the conventions introduced by the previous author, to
fix these cryptographic flaws.
It makes no sense to seed crypto/rng at boot time and then keep
using it like this, when in fact there's already get_random_bytes_wait,
which can ensure there's enough entropy and be a much more standard way
of generating keys. Since this sensitive material is being stored
untrusted, using ECB and no authentication is simply not okay at all. I
find it surprising and a bit horrifying that this code even made it past
basic crypto review, which perhaps points to some larger issues. This
patch moves from using AES-ECB to using AES-GCM. Since keys are uniquely
generated each time, we can set the nonce to zero. There was also a race
condition in which the same key would be reused at the same time in
different threads. A mutex fixes this issue now.
So, to summarize, this commit fixes the following vulnerabilities:
* Low entropy key generation, allowing an attacker to potentially
guess or predict keys.
* Unauthenticated encryption, allowing an attacker to modify the
cipher text in particular ways in order to manipulate the plaintext,
which is is even more frightening considering the next point.
* Use of ECB mode, allowing an attacker to trivially swap blocks or
compare identical plaintext blocks.
* Key re-use.
* Faulty memory zeroing.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
Reviewed-by: Eric Biggers <ebiggers3@gmail.com>
Signed-off-by: David Howells <dhowells@redhat.com>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Cc: Kirill Marinushkin <k.marinushkin@gmail.com>
Cc: security@kernel.org
Cc: stable@vger.kernel.org
2017-09-20 22:58:39 +08:00
|
|
|
big_key_aead = crypto_alloc_aead(big_key_alg_name, 0, CRYPTO_ALG_ASYNC);
|
|
|
|
if (IS_ERR(big_key_aead)) {
|
|
|
|
ret = PTR_ERR(big_key_aead);
|
2016-10-26 22:02:01 +08:00
|
|
|
pr_err("Can't alloc crypto: %d\n", ret);
|
security/keys: rewrite all of big_key crypto
This started out as just replacing the use of crypto/rng with
get_random_bytes_wait, so that we wouldn't use bad randomness at boot
time. But, upon looking further, it appears that there were even deeper
underlying cryptographic problems, and that this seems to have been
committed with very little crypto review. So, I rewrote the whole thing,
trying to keep to the conventions introduced by the previous author, to
fix these cryptographic flaws.
It makes no sense to seed crypto/rng at boot time and then keep
using it like this, when in fact there's already get_random_bytes_wait,
which can ensure there's enough entropy and be a much more standard way
of generating keys. Since this sensitive material is being stored
untrusted, using ECB and no authentication is simply not okay at all. I
find it surprising and a bit horrifying that this code even made it past
basic crypto review, which perhaps points to some larger issues. This
patch moves from using AES-ECB to using AES-GCM. Since keys are uniquely
generated each time, we can set the nonce to zero. There was also a race
condition in which the same key would be reused at the same time in
different threads. A mutex fixes this issue now.
So, to summarize, this commit fixes the following vulnerabilities:
* Low entropy key generation, allowing an attacker to potentially
guess or predict keys.
* Unauthenticated encryption, allowing an attacker to modify the
cipher text in particular ways in order to manipulate the plaintext,
which is is even more frightening considering the next point.
* Use of ECB mode, allowing an attacker to trivially swap blocks or
compare identical plaintext blocks.
* Key re-use.
* Faulty memory zeroing.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
Reviewed-by: Eric Biggers <ebiggers3@gmail.com>
Signed-off-by: David Howells <dhowells@redhat.com>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Cc: Kirill Marinushkin <k.marinushkin@gmail.com>
Cc: security@kernel.org
Cc: stable@vger.kernel.org
2017-09-20 22:58:39 +08:00
|
|
|
return ret;
|
|
|
|
}
|
2018-04-25 04:26:37 +08:00
|
|
|
|
|
|
|
if (unlikely(crypto_aead_ivsize(big_key_aead) != BIG_KEY_IV_SIZE)) {
|
|
|
|
WARN(1, "big key algorithm changed?");
|
|
|
|
ret = -EINVAL;
|
|
|
|
goto free_aead;
|
|
|
|
}
|
|
|
|
|
security/keys: rewrite all of big_key crypto
This started out as just replacing the use of crypto/rng with
get_random_bytes_wait, so that we wouldn't use bad randomness at boot
time. But, upon looking further, it appears that there were even deeper
underlying cryptographic problems, and that this seems to have been
committed with very little crypto review. So, I rewrote the whole thing,
trying to keep to the conventions introduced by the previous author, to
fix these cryptographic flaws.
It makes no sense to seed crypto/rng at boot time and then keep
using it like this, when in fact there's already get_random_bytes_wait,
which can ensure there's enough entropy and be a much more standard way
of generating keys. Since this sensitive material is being stored
untrusted, using ECB and no authentication is simply not okay at all. I
find it surprising and a bit horrifying that this code even made it past
basic crypto review, which perhaps points to some larger issues. This
patch moves from using AES-ECB to using AES-GCM. Since keys are uniquely
generated each time, we can set the nonce to zero. There was also a race
condition in which the same key would be reused at the same time in
different threads. A mutex fixes this issue now.
So, to summarize, this commit fixes the following vulnerabilities:
* Low entropy key generation, allowing an attacker to potentially
guess or predict keys.
* Unauthenticated encryption, allowing an attacker to modify the
cipher text in particular ways in order to manipulate the plaintext,
which is is even more frightening considering the next point.
* Use of ECB mode, allowing an attacker to trivially swap blocks or
compare identical plaintext blocks.
* Key re-use.
* Faulty memory zeroing.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
Reviewed-by: Eric Biggers <ebiggers3@gmail.com>
Signed-off-by: David Howells <dhowells@redhat.com>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Cc: Kirill Marinushkin <k.marinushkin@gmail.com>
Cc: security@kernel.org
Cc: stable@vger.kernel.org
2017-09-20 22:58:39 +08:00
|
|
|
ret = crypto_aead_setauthsize(big_key_aead, ENC_AUTHTAG_SIZE);
|
|
|
|
if (ret < 0) {
|
|
|
|
pr_err("Can't set crypto auth tag len: %d\n", ret);
|
|
|
|
goto free_aead;
|
2016-10-26 22:02:01 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
ret = register_key_type(&key_type_big_key);
|
|
|
|
if (ret < 0) {
|
|
|
|
pr_err("Can't register type: %d\n", ret);
|
security/keys: rewrite all of big_key crypto
This started out as just replacing the use of crypto/rng with
get_random_bytes_wait, so that we wouldn't use bad randomness at boot
time. But, upon looking further, it appears that there were even deeper
underlying cryptographic problems, and that this seems to have been
committed with very little crypto review. So, I rewrote the whole thing,
trying to keep to the conventions introduced by the previous author, to
fix these cryptographic flaws.
It makes no sense to seed crypto/rng at boot time and then keep
using it like this, when in fact there's already get_random_bytes_wait,
which can ensure there's enough entropy and be a much more standard way
of generating keys. Since this sensitive material is being stored
untrusted, using ECB and no authentication is simply not okay at all. I
find it surprising and a bit horrifying that this code even made it past
basic crypto review, which perhaps points to some larger issues. This
patch moves from using AES-ECB to using AES-GCM. Since keys are uniquely
generated each time, we can set the nonce to zero. There was also a race
condition in which the same key would be reused at the same time in
different threads. A mutex fixes this issue now.
So, to summarize, this commit fixes the following vulnerabilities:
* Low entropy key generation, allowing an attacker to potentially
guess or predict keys.
* Unauthenticated encryption, allowing an attacker to modify the
cipher text in particular ways in order to manipulate the plaintext,
which is is even more frightening considering the next point.
* Use of ECB mode, allowing an attacker to trivially swap blocks or
compare identical plaintext blocks.
* Key re-use.
* Faulty memory zeroing.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
Reviewed-by: Eric Biggers <ebiggers3@gmail.com>
Signed-off-by: David Howells <dhowells@redhat.com>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Cc: Kirill Marinushkin <k.marinushkin@gmail.com>
Cc: security@kernel.org
Cc: stable@vger.kernel.org
2017-09-20 22:58:39 +08:00
|
|
|
goto free_aead;
|
2016-04-13 02:54:58 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
|
security/keys: rewrite all of big_key crypto
This started out as just replacing the use of crypto/rng with
get_random_bytes_wait, so that we wouldn't use bad randomness at boot
time. But, upon looking further, it appears that there were even deeper
underlying cryptographic problems, and that this seems to have been
committed with very little crypto review. So, I rewrote the whole thing,
trying to keep to the conventions introduced by the previous author, to
fix these cryptographic flaws.
It makes no sense to seed crypto/rng at boot time and then keep
using it like this, when in fact there's already get_random_bytes_wait,
which can ensure there's enough entropy and be a much more standard way
of generating keys. Since this sensitive material is being stored
untrusted, using ECB and no authentication is simply not okay at all. I
find it surprising and a bit horrifying that this code even made it past
basic crypto review, which perhaps points to some larger issues. This
patch moves from using AES-ECB to using AES-GCM. Since keys are uniquely
generated each time, we can set the nonce to zero. There was also a race
condition in which the same key would be reused at the same time in
different threads. A mutex fixes this issue now.
So, to summarize, this commit fixes the following vulnerabilities:
* Low entropy key generation, allowing an attacker to potentially
guess or predict keys.
* Unauthenticated encryption, allowing an attacker to modify the
cipher text in particular ways in order to manipulate the plaintext,
which is is even more frightening considering the next point.
* Use of ECB mode, allowing an attacker to trivially swap blocks or
compare identical plaintext blocks.
* Key re-use.
* Faulty memory zeroing.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
Reviewed-by: Eric Biggers <ebiggers3@gmail.com>
Signed-off-by: David Howells <dhowells@redhat.com>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Cc: Kirill Marinushkin <k.marinushkin@gmail.com>
Cc: security@kernel.org
Cc: stable@vger.kernel.org
2017-09-20 22:58:39 +08:00
|
|
|
free_aead:
|
|
|
|
crypto_free_aead(big_key_aead);
|
2016-04-13 02:54:58 +08:00
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2016-10-26 22:02:01 +08:00
|
|
|
late_initcall(big_key_init);
|