UPDATE  (Jun. 30, 2014):
The vulnerability affects Android 4.3 only. Thanks for the Android Security Team for correcting our advisory.

Nine months ago, my team came across a classic stack-based buffer overflow in the Android KeyStore service.

As always, we adhered to our responsible disclosure policy and privately reported this issue to the Android Security Team; the result is a patch that is now available in KitKat. Considering Android’s fragmented nature and the fact that this was a code-execution vulnerability, we decided to wait a bit with the public disclosure.

See the full advisory with more details here.

As an anecdote, the vulnerable source code file contains the following comment:

/* 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. */

Though things are simple, buffers are not always larger than the maximum space they needed.

The Android KeyStore Service

Android provides a secure storage service implemented by /system/bin/keystore. In the past, this service was accessible to other applications using a UNIX socket daemon found under /dev/socket/keystore; nowadays, however, it is accessible by the Binder interface. Each Android user receives his or her own secure storage area. A Blob is encrypted with AES using a master key, which is random, and is encrypted on-disk using a key that is derived from a password (the lock screen credentials) by the PKCS5_PBKDF2_HMAC_SHA1 function.

In recent Android versions, credentials such as RSA private keys can be hardware-backed. This basically means that the keystore keys only serve as identifiers for the real keys backed by the hardware. Despite the hardware support, some credentials, such as VPN PPTP credentials, are still stored (encrypted) on-disk.

The following diagram best illustrates the operation of the KeyStore service:

More internals of KeyStore are available on the excellent series of posts (1, 2, 3, 4, 5) by Nikolay Elenkov.

The Vulnerability

A stack buffer is created by the ‘KeyStore::getKeyForName’ method.

ResponseCode getKeyForName( Blob* keyBlob, 
                            const android::String8& keyName,
                            const uid_t uid,
                            const BlobType type)
  char filename[NAME_MAX];
  encode_key_for_uid(filename, uid, keyName);

This function has several callers, which are accessible by external applications using the Binder interface (e.g., ‘android::KeyStoreProxy::get’). Therefore, the ‘keyName’ variable can be controllable with an arbitrary size by a malicious application. As you can see, the ‘encode_key’ routine that is called by ‘encode_key_for_uid’ can overflow the ‘filename’ buffer, since bounds checking is absent:

static int encode_key_for_uid( char* out,
                               uid_t uid,
                               const android::String8& keyName)
  int n = snprintf(out, NAME_MAX, "%u_", uid);
  out += n; return n + encode_key(out, keyName);

static int encode_key( char* out, const android::String8& keyName)
  const uint8_t* in = reinterpret_cast(keyName.string());
  size_t length = keyName.length();
  for (int i = length; i > 0; --i, ++in, ++out)
     if (*in < '0' || *in > '~')
        *out = '+' + (*in >> 6);
        *++out = '0' + (*in & 0x3F);
        *out = *in;
  *out = '';
  return length;


Exploiting this vulnerability can theoretically be done by a malicious application; however, a working exploit needs to overcome a combination of obstacles:

  1. Data Execution Prevention (DEP). This can be bypassed by Return-Oriented Programming (ROP) payloads.
  2. Address Space Layout Randomization (ASLR)
  3. Stack Canaries
  4. Encoding. Characters below 0x30 (‘0’) or above 0x7e (‘~’) are encoded before being written on the buffer.

However, the Android KeyStore is respawned every time it terminates. This behavior enables a probabilistic approach; moreover, the attacker may even theoretically abuse ASLR to defeat the encoding.


Successfully exploiting this vulnerability leads to a malicious code execution under the keystore process. Such code can:

  1. Leak the device’s lock credentials. Since the master key is derived by the lock credentials, whenever the device is unlocked, ‘Android::KeyStoreProxy::password’ is called with the credentials.
  2. Leak decrypted master keys, data and hardware-backed key identifiers from the memory.
  3. Leak encrypted master keys, data and hardware-backed key identifiers from the disk for an offline attack.
  4. Interact with the hardware-backed storage and perform crypto operations (e.g., arbitrary data signing) on behalf of the user.

Vulnerable Versions

Android 4.3.

Non-vulnerable Versions

Android 4.4.

Disclosure Timeline

Jun. 23, 2014 Public disclosure.
Nov. 11, 2013 Fix confirmed by Android Security Team.
Oct. 22, 2013 Updates requested from Android Security Team.
Sept. 9, 2013 Vulnerability acknowledged by Android Security Team.
Sept. 9, 2013 Private disclosure to Android Security Team.




We would like to thank Android Security Team for the efficient way in which they handled this security vulnerability.

More from Software Vulnerabilities

X-Force releases detection & response framework for managed file transfer software

5 min read - How AI can help defenders scale detection guidance for enterprise software tools If we look back at mass exploitation events that shook the security industry like Log4j, Atlassian, and Microsoft Exchange when these solutions were actively being exploited by attackers, the exploits may have been associated with a different CVE, but the detection and response guidance being released by the various security vendors had many similarities (e.g., Log4shell vs. Log4j2 vs. MOVEit vs. Spring4Shell vs. Microsoft Exchange vs. ProxyShell vs.…

MSMQ QueueJumper (RCE Vulnerability): An in-depth technical analysis

13 min read - The security updates released by Microsoft on April 11, 2023, addressed over 90 individual vulnerabilities. Of particular note was CVE-2023-21554, dubbed QueueJumper, a remote code execution vulnerability affecting the Microsoft Message Queueing (MSMQ) service. MSMQ is an optional Windows component that enables applications to exchange messages via message queues that are reachable both locally and remotely. This analysis was performed in collaboration with the Randori and X-Force Adversary Services teams, by Valentina Palmiotti, Fabius Watson, and Aaron Portnoy. Research motivations…

X-Force prevents zero day from going anywhere

8 min read - This blog was made possible through contributions from Fred Chidsey and Joseph Lozowski. The 2023 X-Force Threat Intelligence Index shows that vulnerability discovery has rapidly increased year-over-year and according to X-Force’s cumulative vulnerability and exploit database, only 3% of vulnerabilities are associated with a zero day. X-Force often observes zero-day exploitation on Internet-facing systems as a vector for initial access however, X-Force has also observed zero-day attacks leveraged by attackers to accomplish their goals and objectives after initial access was…

Patch Tuesday -> exploit Wednesday: Pwning windows ancillary function driver for WinSock (afd.sys) in 24 hours

12 min read - ‘Patch Tuesday, Exploit Wednesday’ is an old hacker adage that refers to the weaponization of vulnerabilities the day after monthly security patches become publicly available. As security improves and exploit mitigations become more sophisticated, the amount of research and development required to craft a weaponized exploit has increased. This is especially relevant for memory corruption vulnerabilities. Figure 1 — Exploitation timeline However, with the addition of new features (and memory-unsafe C code) in the Windows 11 kernel, ripe new attack…