Hi everyone,
     Recently I saw a vulnerability - Android KeyStore Stack Buffer
Overflow  CVE-2014-3100
<http://securityintelligence.com/android-keystore-stack-buffer-overflow-to-keep-things-simple-buffers-are-always-larger-than-needed/#.U6h2NPmSxCh>.
It's about Android keystore daemon.
/* KeyStore is a secured storage for key-value pairs. In this
implementation,
* each file stores one key-value pair. Keys are encoded in file names, and
* values are encrypted with checksums. The encryption key is protected by a
* user-defined password. To keep things simple, buffers are always larger
than
* the maximum space we needed, so boundary checks on buffers are omitted. */
*The threat model*: One vulnerability exists in keystore and attackers can
exploit this vulnerability to execute arbitrary codes after bypassing the
DEP, ASLR and stack cookie protection. Let's see this legitimate app
(uid:10053), which sends a request to keystore for generating a key pair
(alias: a). The keys are stored in the path
"/data/misc/keystore/user_0/10053_USRCERT_a"
and "/data/misc/keystore/user_0/10053_USRPKEY_a" (the permission are
"-rw------- keystore keystore" ).  Now, attackers can easily write a
malicious app, which can send a malformed or overflowed request message to
keystore to trigger that vulnerability and execute malicious codes. Then,
the malicious app can read the 10053_USRCERT_a key file. In fact, this
malicious app is not allowed to read this key file according to the current
data isolation mechanism in keystore daemon. But, this mechanism will be
nothing once attackers can trigger keystore's  vulnerabilities.

      *Even though SEAndroid is applied into Android after version 4.4, the
above attack can still not be prevented by SEAndroid. In SEAndroid,  each
file and process are labeled, and the file operation is restricted by
policies. Obviously, the keystore process is allowed to create/read/write
all key files in the "/data/misc/keystore/" directory for each app in
SEAndroid policies, even when keystore process has been compromised. The
SEAndroid cannot dynamically adjust policies to restrict file operations on
different files according to different requested apps. So, this attack can
bypass the defense of SEAndroid. *

KeyStore daemon can access all the keys which applications store in its
folder. So If there is vulnerability in this daemon, malicious app can
trigger this vulnerability to compromise this daemon and let the daemon to
work for it. Malicious app can get all the keys on behalf of Keystore
daemon.

*I have a doubt about Daemon in Linux is vulnerable to this kind of attack.
There are many daemon in Linux, such as init,sshd,httpd,ftpd,syslogd...... *
* First, w**hat's the difference between with Linux daemon and Android
daemon?*
* Second, i**s there a possibility to attack daemon in Linux by this kind
of attack? If there is, as shown in the paragraph with underline, this kind
of attack is not prevented by SEAndroid. Can SELinux prevent this kind of
attack?*

    *P.S.CC <http://P.S.CC> me because I don't subscribe debian-security
mailing list.*
    Thanks in advance.

-- 
My best regards to you.

     No System Is Safe!
     mudongliang

Reply via email to