exploit the possibilities
Home Files News &[SERVICES_TAB]About Contact Add New

eCryptfs write_tag_3_packet Heap Buffer Overflow

eCryptfs write_tag_3_packet Heap Buffer Overflow
Posted Nov 4, 2013
Authored by x90c

eCryptfs in Linux kernel version 2.6.18 suffer from a write_tag_3_packet heap buffer overflow vulnerability.

tags | advisory, overflow, kernel
systems | linux
SHA-256 | 015570f2ec233897e40a39fd6d6b1250c0412b0d3c5a7f74de150f8212dc2cf0

eCryptfs write_tag_3_packet Heap Buffer Overflow

Change Mirror Download

+--------------------------------------------------------------------------------------------+
| XADV-2013003 Linux Kernel eCryptfs write_tag_3_packet Heap Buffer Overflow Vulnerability |
+--------------------------------------------------------------------------------------------+

Vulnerable versions:
- linux kernel 2.6.18

Testbed: linux kernel 2.6.18
Type: Local
Impact: kernel panic or potential local privelge escalation.
Vendor: http://www.kernel.org
Author: x90c <geinblues *nospam* gmail dot com>
Site: x90c.org


=========
ABSTRACT:
=========

The write_tag_3_packet() in Linux Kernel eCryptfs is vulnerable to heap buffer overflow.
It lead to kernel panic and potentialy privilege escalation. The vulnerability occured
with no checks to memory copy length variable in the vulnerable function.


=========
DETAILS:
=========

The ecryptfs_create() in ecryptfs/inode.c called when operation to create an directory
in the ecryptfs file system. When after ecryptfs_create() called finally to reach to
the vulnerable point of memcpy in the vulnerable function of write_tag_3_packet.



[write_tag_3_packet() in ecryptfs/keystore.c]:
----
..


} else /* no aes, no 0, 24 key size? */
auth_tok->session_key.encrypted_key_size = crypt_stat->key_size; /* (1) */

key_rec->enc_key_size = /* (2) */
auth_tok->session_key.encrypted_key_size;

/* vulnerable point (2, 3 arguments usercontrollable) */
memcpy(key_rec->enc_key, auth_tok->session_key.encrypted_key, key_rec->enc_key_size);

..
----



If see The vulnerable point, key_rec->enc_key_size is usercontrolable variable.
(1) Store the crypt_stat->key_size to authtok->session_key.encrypted_key_size and (2)
store the authtok->session_key.encrypted_key_size to key_rec->enc_key_size.
In other word, the crypt_stat->key_size to the key_rec->enc_key_size usercontrollable
variable at the vulnerable point.

The Enter to the vulnerable point, no aes and 0, 24 key size.

If can control crypt_stat->key_size variable, lead to the heap buffer overflow.
First see the call path from ecryptfs_create() in ecryptfs/inode.c to vulnerable point.



[call path to the vulnerable point]
----
ecryptfs/inode.c::ecryptfs_create()
+-> ecryptfs/inode.c::ecryptfs_initialize_file()
| -> ecryptfs/crypto.c::ecryptfs_new_file_context()
|
+-> ecryptfs/inode.c::ecryptfs_write_metadata()
-> ecryptfs/crypto.c::ecryptfs_write_headers_virt()
-> ecryptfs/keystore.c::ecryptfs_generate_key_packet_set()
-> ecryptfs/keystore.c::write_tag_3_packet() (vulnerable function)
-> memcpy(key_rec->enc_key, /* vulnerable point */
auth_tok->session_key.encrypted_key,
key_rec->enc_key_size); // XXX usercontrolable key_rec->enc_key_size!
----



The ecryptfs_initialize_file in ecryptfs/inode.c store the crypt_stat->key_size by
the variable passed to kernel (mount options). In ecryptfs_new_file_context
store mount_crypt_stat->global_default_cipher_key_size to crypt_stat->key_size.
the global*key_size is the variable can control at the parse mount options.



[ecryptfs/crypto.c]:
----
int ecryptfs_new_file_context(struct dentry *ecryptfs_dentry)
{
..

crypt_stat->key_size =
mount_crypt_stat->global_default_cipher_key_size;

..

----



The mount_crypt_stat->global_default_cipher_key_size can be set by parse
option 'ecryptfs_opt_ecryptfs_key_bytes'. (usercontrollable variable)




[ecryptfs/main.c]:
----
static int ecryptfs_parse_options(struct super_block *sb, char *options)
{
..


case ecryptfs_opt_ecryptfs_key_bytes:
cipher_key_bytes_src = args[0].from;
cipher_key_bytes =
(int)simple_strtol(cipher_key_bytes_src,
&cipher_key_bytes_src, 0);
mount_crypt_stat->global_default_cipher_key_size =
cipher_key_bytes;
ecryptfs_printk(KERN_DEBUG,
"The mount_crypt_stat "
"global_default_cipher_key_size "
"set to: [%d]\n", mount_crypt_stat->
global_default_cipher_key_size);
cipher_key_bytes_set = 1;
break;
----



The memcpy copy size at vulnerable point can be set by usercontrolable variable
via the 'ecryptfs_opt_ecryptfs_key_bytes' mount option.



----

/* vulnerable point */
memcpy(key_rec->enc_key, auth_tok->session_key.encrypted_key, key_rec->enc_key_size);

----



The second argument also can user controllable, in this advisory just commented on it.

heap buffer overflow!



===============
EXPLOIT CODES:
===============

-


=============
PATCH CODES:
=============

-


===============
VENDOR STATUS:
===============
2013/11/04 - The vulnerability discovered.
2013/11/04 - Advisory released on full-disclosure, bugtraq, packetstorm, exploit-db


============
DISCLAIMER:
============

The authors reserve the right not to be responsible for the topicality,
correctness, completeness or quality of the information provided in this
document. Liability claims regarding damage caused by the use of any information
provided, including any kind of information which is incomplete or incorrect,
will therefore be rejected.
Login or Register to add favorites

File Archive:

April 2024

  • Su
  • Mo
  • Tu
  • We
  • Th
  • Fr
  • Sa
  • 1
    Apr 1st
    10 Files
  • 2
    Apr 2nd
    26 Files
  • 3
    Apr 3rd
    40 Files
  • 4
    Apr 4th
    6 Files
  • 5
    Apr 5th
    26 Files
  • 6
    Apr 6th
    0 Files
  • 7
    Apr 7th
    0 Files
  • 8
    Apr 8th
    22 Files
  • 9
    Apr 9th
    14 Files
  • 10
    Apr 10th
    10 Files
  • 11
    Apr 11th
    13 Files
  • 12
    Apr 12th
    14 Files
  • 13
    Apr 13th
    0 Files
  • 14
    Apr 14th
    0 Files
  • 15
    Apr 15th
    30 Files
  • 16
    Apr 16th
    10 Files
  • 17
    Apr 17th
    22 Files
  • 18
    Apr 18th
    45 Files
  • 19
    Apr 19th
    0 Files
  • 20
    Apr 20th
    0 Files
  • 21
    Apr 21st
    0 Files
  • 22
    Apr 22nd
    0 Files
  • 23
    Apr 23rd
    0 Files
  • 24
    Apr 24th
    0 Files
  • 25
    Apr 25th
    0 Files
  • 26
    Apr 26th
    0 Files
  • 27
    Apr 27th
    0 Files
  • 28
    Apr 28th
    0 Files
  • 29
    Apr 29th
    0 Files
  • 30
    Apr 30th
    0 Files

Top Authors In Last 30 Days

File Tags

Systems

packet storm

© 2022 Packet Storm. All rights reserved.

Services
Security Services
Hosting By
Rokasec
close