diff options
| author | Tyler Hicks <tyhicks@canonical.com> | 2011-11-23 11:31:24 -0600 |
|---|---|---|
| committer | Tyler Hicks <tyhicks@canonical.com> | 2011-11-23 15:43:53 -0600 |
| commit | 0f751e641a71157aa584c2a2e22fda52b52b8a56 (patch) | |
| tree | 53bc2e3edf25f4564376d2dac79a5bfbd1e16bf5 /fs/ecryptfs | |
| parent | 32001d6fe9ac6b0423e674a3093aa56740849f3b (diff) | |
| download | linux-0f751e641a71157aa584c2a2e22fda52b52b8a56.tar.gz linux-0f751e641a71157aa584c2a2e22fda52b52b8a56.tar.bz2 linux-0f751e641a71157aa584c2a2e22fda52b52b8a56.zip | |
eCryptfs: Extend array bounds for all filename chars
From mhalcrow's original commit message:
Characters with ASCII values greater than the size of
filename_rev_map[] are valid filename characters.
ecryptfs_decode_from_filename() will access kernel memory beyond
that array, and ecryptfs_parse_tag_70_packet() will then decrypt
those characters. The attacker, using the FNEK of the crafted file,
can then re-encrypt the characters to reveal the kernel memory past
the end of the filename_rev_map[] array. I expect low security
impact since this array is statically allocated in the text area,
and the amount of memory past the array that is accessible is
limited by the largest possible ASCII filename character.
This patch solves the issue reported by mhalcrow but with an
implementation suggested by Linus to simply extend the length of
filename_rev_map[] to 256. Characters greater than 0x7A are mapped to
0x00, which is how invalid characters less than 0x7A were previously
being handled.
Signed-off-by: Tyler Hicks <tyhicks@canonical.com>
Reported-by: Michael Halcrow <mhalcrow@google.com>
Cc: stable@kernel.org
Diffstat (limited to 'fs/ecryptfs')
| -rw-r--r-- | fs/ecryptfs/crypto.c | 4 |
1 files changed, 2 insertions, 2 deletions
diff --git a/fs/ecryptfs/crypto.c b/fs/ecryptfs/crypto.c index 203a1fdff666..2a834255c75d 100644 --- a/fs/ecryptfs/crypto.c +++ b/fs/ecryptfs/crypto.c @@ -1945,7 +1945,7 @@ static unsigned char *portable_filename_chars = ("-.0123456789ABCD" /* We could either offset on every reverse map or just pad some 0x00's * at the front here */ -static const unsigned char filename_rev_map[] = { +static const unsigned char filename_rev_map[256] = { 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, /* 7 */ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, /* 15 */ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, /* 23 */ @@ -1961,7 +1961,7 @@ static const unsigned char filename_rev_map[] = { 0x00, 0x26, 0x27, 0x28, 0x29, 0x2A, 0x2B, 0x2C, /* 103 */ 0x2D, 0x2E, 0x2F, 0x30, 0x31, 0x32, 0x33, 0x34, /* 111 */ 0x35, 0x36, 0x37, 0x38, 0x39, 0x3A, 0x3B, 0x3C, /* 119 */ - 0x3D, 0x3E, 0x3F + 0x3D, 0x3E, 0x3F /* 123 - 255 initialized to 0x00 */ }; /** |