Android KeyStore Service Stack Buffer Overflow - BestCyberNews: Online News Presenter in the present world

BestCyberNews: Online News Presenter in the present world

Start knowing

test banner

Breaking

Android KeyStore Service Stack Buffer Overflow

Android provides a secure storage service implemented by /system/bin/keystore. This service had accessible to other applications using a UNIX socket daemon found under /dev/socket/keystore. Now, it is accessible by the Binder interface.

Every Android user receives own secure storage area and 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.

Securityintelligence team found this stack-based buffer overflow in the Android KeyStore service and privately reported this issue to the Android Security Team

After that they are patched available KitKat version. Considering Android’s fragmented nature and the fact that this was a code-execution vulnerability.

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 on-dis. 

According to Securityintelligence, this stack buffer is created by the ‘KeyStore::getKeyForName’. This function has several callers, which are accessible by external applications using the Binder interface. 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
This vulnerability leads to a malicious code execution under the keystore process. 

  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.






Author Venkatesh Yalagandula Follow us Google + and Facebook and Twitter