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); ... }
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:
C
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); ++length; } else { *out = *in; } } *out = ''; return length; }
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);
++length;
}
else
{
*out = *in;
}
}
*out = '';
return length;
}
Exploitation
Exploiting this vulnerability can theoretically be done by a malicious application; however, a working exploit needs to overcome a combination of obstacles:
Data Execution Prevention (DEP). This can be bypassed by Return-Oriented Programming (ROP) payloads.
Address Space Layout Randomization (ASLR)
Stack Canaries
Encoding. Characters below 030 (’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.
Impact
Successfully exploiting this vulnerability leads to a malicious code execution under the keystore process. Such code can:
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.
Leak decrypted master keys, data and hardware-backed key identifiers from the memory.
Leak encrypted master keys, data and hardware-backed key identifiers from the disk for an offline attack.
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.
