lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [day] [month] [year] [list]
Message-ID: <CAHbG5q-Lw5C70sx0=VDvNSU=ZvN_9UtTbZhL4g9=yrb4rfZ7UA@mail.gmail.com>
Date: Mon, 4 Nov 2013 14:21:40 +0900
From: x90c <geinblues@...il.com>
To: full-disclosure@...ts.grok.org.uk
Subject: XADV-2013003 Linux Kernel eCryptfs
 write_tag_3_packet Heap Buffer Overflow Vulnerability

+--------------------------------------------------------------------------------------------+
| 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


========
GREETS:
========

my stuffs are more favorite than rebel's stuffs.


============
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.

Content of type "text/html" skipped

View attachment "xadv-2013003.txt" of type "text/plain" (5554 bytes)

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ