BlackBerry Z 10 Buffer Overflow

`---------------------------------------------------------------------  
  
modzero Security Advisory:  
BlackBerry Z 10 - Buffer Overflow in qconnDoor [MZ-13-05]  
  
---------------------------------------------------------------------  
  
---------------------------------------------------------------------  
  
1. Timeline  
  
---------------------------------------------------------------------  
  
* 2013-06-23: Vendor has been contacted.  
* 2013-06-24: Vendor response.  
* 2013-06-27: Vendor meeting and information exchange.  
* 2013-08-20: Advisory and more details sent to the vendor.  
* 2013-10-15 or after patch-release: Advisory will be published.  
* 2013-12-05: Vendor requested delay of release, until a high level  
of carrier uptake has been achieved  
* 2014-01-14: Vendor announced release in March 2014  
* 2014-04-01: Vendor achieved sufficient customer availability for  
this issue and announced release on April 8th, 2014.  
* 2014-04-08: Release of security advisory in cooperation with  
vendor.  
  
---------------------------------------------------------------------  
  
2. Summary  
  
---------------------------------------------------------------------  
Vendor: BlackBerry  
Products known to be affected: Blackberry Z10  
(model STL100-2, Software release: 10.1.0.2312,  
OS version: 10.1.0.2354, Build ID: 524717)  
  
Severity: Medium  
Remote exploitable: Yes  
CVE: CVE-2014-2389  
  
qconndoor is a network service, running on the Blackberry Z10  
to allow developers to access the device using BlackBerry's SDK  
tool-chain. The qconndoor process is used to e. g. enable SSH access  
to the device; More functionality is not documented yet and may  
remain proprietary. Even though the service is intended for being  
used by software developers in the Blackberry developer-mode only,  
the service is still running, even if the developer-mode is not  
enabled. The qconndoor process is executed under super-user UID 0  
(root) privileges.  
  
modzero identified a stack-based buffer overflow in the qconnDoor  
service that can be triggered by an unauthenticated attacker. The  
buffer overflow issue can only be triggered, if the developer-mode  
has been activated once during runtime and can still be triggered  
when the developer-mode has been turned off. Since the developer  
service is exposed to the (wireless) network and the service is  
running with administrative privileges, the risk of a successful  
exploitation is considered high after the developer-mode has been  
turned on and off during runtime once.  
  
Even if exploit mitigations at first prevent a code execution, it is  
still possible to modify data variables in the affected services,  
which is a high risk, too.  
  
---------------------------------------------------------------------  
  
3. Details  
  
---------------------------------------------------------------------  
  
To overflow the stack-buffer in qconnDoor, an attacker has to send a  
single specially crafted packet with any command code that triggers  
AES-decryption of the data payload (for example, command code #7). By  
specifying an invalid combination of encrypted and decrypted payload  
lengths, the decryption routine will write past the end of the  
decrypted plaintext buffer. qconnDoor will terminate immediately,  
because processing the packet causes a modification of the stack  
cookie, which the process detects.  
  
$ perl -e 'print "\x00\x2a\x00\x02\x00\x07\x12\x00\x0c\x00" . "\x41" x 0xc00' |  
nc target.host 4455  
  
Analysis:  
  
To understand and estimate the impact and exploitability of the  
service, different executables were examined to obtain information  
about payload structure and program-flow. First of all, the  
blackberry-connect utility from the Blackberry Java SDK was analyzed  
to obtain information about the protocol format and data structure.  
Secondly, the qconnDoor executable of the x86 emulation environment  
has been analyzed, to gather information about internal code-flow  
and data-structures - assuming, that both executables are based  
on the same or similar source-code. The findings were used in  
a third, empirical test to reproduce the issue and the build  
a proof-of-concept procedure to verify the existance of the  
memory-corruption. These steps are described in more detail in the  
following sections.  
  
3.1 Static Analysis of blackberry-connect (Java, from BB SDK)  
  
The BB10 SDK was installed using  
installer-bbndk-bb10_1_x-linux-1020-201303191709-201303191501.bin  
(MD5: 6c295359827636f0425e8bff73baee52). The Eclipse workbench was  
updated to the most recent version of the pubic SDK for being  
in sync with the simulator (BlackBerry Native SDK 10.1.0.2354).  
The directory $HOME/bbndk/host_10_1_0_235/linux/x86/usr/lib contains  
multiple jar files, which implement the client-side of  
the qconnDoor network protocol. In particular, jqconnDoor.jar  
(MD5: d8c93abceeb84b6bf3858d00982efccd) was decompiled to gain  
understanding of the qconnDoor protocol. The following qconnDoor  
messages could be reverse-engineered:  
  
Definition of data types:  
short 16 bit integer in network byte order (big endian)  
long 32 bit integer in network byte order (big endian)  
bytes sequence of bytes with variable length  
IV 16 bytes AES initialization vector  
  
Message: hello  
short 6 packet length  
short 2 protocol version  
short 1 command code  
  
Message: feedback  
short ? packet length  
short 2 protocol version  
short 2 command code  
short ? feedback code  
short ? length of feedback message in bytes  
bytes ? feedback message  
  
Message: challenge request  
short ? packet length  
short 2 protocol version  
short 3 command code  
short ? length of rsapubkey  
bytes ? rsapubkey  
  
Message: encrypted challenge response  
short ? packet length  
short 2 protocol version  
short 4 command code  
bytes ? ? opaque challenge data, possibly encrypted to previously sent  
rsapubkey  
  
Message: decrypted challenge response  
short ? packet length  
short 2 protocol version  
short 5 command code  
short ? encrypted length  
short ? decrypted length  
IV ? initialization vector  
bytes ? encrypted data  
  
Message: plaintext of encrypted data (AES-CBC with PKCS5 padding):  
short ? 4 + decrypted blob length + signature length  
short ? decrypted blob length  
short ? signature length  
bytes ? decrypted blob  
bytes ? signature  
  
Message: keepalive  
short 6 packet length  
short 2 protocol version  
short 6 command code  
  
Message: send ssh key  
short ? packet length  
short 2 protocol version  
short 7 command code  
short ? encrypted length  
short ? decrypted length  
IV ? initialization vector  
bytes ? encrypted data  
  
Message: plaintext of encrypted data (AES-CBC with PKCS5 padding):  
short ? key length  
bytes ? key  
  
Message: authenticate challenge request  
short 6 packet length  
short 2 protocol version  
short 8 command code  
  
Message: authenticate challenge response  
short ? packet length  
short 2 protocol version  
short 9 command code  
long ? algorithm  
long ? iterations  
char ? salt length  
char ? challenge length  
bytes ? salt  
bytes ? challenge  
  
Message: authenticate  
short ? packet length  
short 2 protocol version  
short 10 command code  
short ? encrypted length  
short ? decrypted length  
IV ? initialization vector  
bytes ? encrypted data  
  
Message: plaintext of encrypted data (AES-CBC with PKCS5 padding):  
short ? hash length  
bytes ? hash  
  
Message: start service  
short 6 packet length  
short 2 protocol version  
short 11 command code  
  
Message: close  
short 6 packet length  
short 2 protocol version  
short 12 command code  
  
The qconnDoor protocol messages contain many redundant length-fields  
which need to be validated by the recipient of the packet. This type  
of protocol implementation is highly prone to length validation  
issues.  
  
For example, a very obvious flaw is that the qconnDoor server-side  
sometimes sends wrong packet length fields. These malformed  
data-packets however, are processed by the client correctly without  
ending in undefined states or termination of the process, due to  
side-effects of the network-client implementation.  
  
The fact that qconnDoor runs with root priviledges, makes the server  
process a worthwhile target.  
  
3.2 Static Analysis of qconnDoor (x86, simulator)  
  
Since binary x86 code is more convenient to reverse-engineer than ARM  
code and all qconnDoor binaries seem to be compiled from the same  
source-code-base, the one from the simulator was statically analyzed  
in the following step.  
  
Simulator VM:  
BlackBerry10Simulator-Installer-BB10_1_X-1483-Linux-201304131554.bin  
(MD5: db20e8151ece5a88f8b70d016e54df3f). The simulator was rooted by  
patching the VM disk image, resulting in a setuid 0 (root) binary  
(/tmp/setuidgid) that can be used to locally elevate privileges:  
  
# patch vmdk disk image  
perl -i.backup -0777 -pe  
's/\x69\x66\x20\x5b\x20\x22\x24\x7b\x42\x4f\x41\x52\x44\x5f\x43\x4f\x4e\x46\x49\x47\x7d\x22\x20\x21\x3d\x20\x22\x64\x65\x76\x65\x6c\x6f\x70\x65\x72\x22\x20\x5d\x3b\x20\x74\x68\x65\x6e\x0a\x20\x20\x20\x20\x20\x20\x20\x20\x72\x6d\x20\x2d\x72\x66\x20\x2f\x72\x6f\x6f\x74\x2f\x2e\x20\x3e\x20\x2f\x64\x65\x76\x2f\x6e\x75\x6c\x6c\x20\x32\x3e\x26\x31\x3b\x0a\x20\x20\x20\x20\x66\x69\x3b/\x63\x70\x20\x2f\x75\x73\x72\x2f\x62\x69\x6e\x2f\x73\x65\x74\x75\x69\x64\x67\x69\x64\x20\x2f\x74\x6d\x70\x20\x26\x26\x20\x63\x68\x6d\x6f\x64\x20\x36\x37\x35\x35\x20\x2f\x74\x6d\x70\x2f\x73\x65\x74\x75\x69\x64\x67\x69\x64\x3b\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20/g'  
BlackBerry10Simulator-s001.vmdk  
  
Using root access in the emulator, many binaries could be extracted  
from the simulator's file system, including qconnDoor (MD5:  
1dc6f998eaa4cd60653c1fe0df9a78b7). Afterwards, qconnDoor has been  
analyzed in IDA Pro with the intention to find bugs in message length  
validation checks.  
  
The binary did not contain symbols. Thus, function names are invented  
by the analyst. Notable functions are:  
  
.text:00003E4B get_byteswapped_enc_header  
[esp] char *raw_packet  
[esp+4] struct enc_header *decoded_packet  
  
The function expects encrypted/plaintext length fields, an  
initialization vector (IV) followed by encrypted data in the  
raw_packet buffer. The function copies all fields to the  
decoded_packet structure and performs endianess conversion where  
necessary. At addresses 0x3e87 and following, it contains arithmetic  
instructions operating on field lengths. This might be the remains of  
an optimized-out length validation check.  
  
.text:00003E9A recv_exact_and_decrypt  
eax connection_struct *conn  
edx char *plaintextbuf  
[esp] plaintextbuflen  
[esp+4] rawpayloadlen  
[esp+8] resultlenptr  
  
This function reads rawpayloadlen bytes (at least 24 bytes, but no  
more than 4090 bytes) from the network into a 4096 bytes long local  
buffer. The function calls get_byteswapped_enc_header to interpret  
the fixed header fields of the raw packet data. It validates that the  
length of decrypted data (as specified in the packet) is less or  
equal than plaintextbuflen (at address 0x3ff6). Furthermore, the  
function prepares an AES context (exact conditions when this may  
fail are not understood) and uses an unvalidated length of the  
encrypted data as specified in the packet as an argument to the AES  
decryption function _hu_AESDecrypt(), decrypting raw packet data into  
plaintextbuf (at address 0x3f7e). Thus, when length of encrypted data  
is larger than plaintextbuflen, the decrypted data will be written  
past the end of plaintextbuf, which results in a memory-corruption.  
  
.text:00004011 receive_command  
[esp] struct connection_struct *connection  
[esp+4] struct packet_header *headerbuf  
[esp+8] char *databuf  
[esp+12] int databuflen  
  
At the beginning, the function reads the common 6 byte long packet  
header from the network into databuf. When the command code is 6, 7  
or 10, recv_exact_and_decrypt is called with plaintextbuf = databuf  
and plaintextbuflen = databuflen (at addresses 0x4158 and 0x41c0).  
Thus, when receive_command encounters a packet with command code 6, 7  
or 10, decrypted data may be written past databuf + databuflen.  
  
.text:0000422D qconndoor_accept  
  
stack of function:  
-00001140 var_1140 dd ?  
-0000113C var_113C dd ?  
-00001138 headerbuf packet_header ?  
-00001120 len dd ?  
-0000111C buf db 4096 dup(?)  
-0000011C s db 256 dup(?)  
-0000001C canary dd ?  
-00000018 var_18 db 24 dup(?)  
+00000000 s db 4 dup(?)  
+00000004 r db 4 dup(?)  
+00000008 connection dd ? ; offset  
  
The function calls receive_command to acquire an initial hello packet  
with databuf = buf and databuflen = 4096. Thus, when a packet with  
command code 6, 7 or 10 is encountered (instead of hello packet) and  
the length of encrypted data in packet is larger than 4096 + 256 + 4  
+ 24 + 4 = 4384, a buffer overflow may occur and the code  
overwrites the return address. This overflow will be detected when  
the stack-canary is validated on function return. When the length of  
encrypted data in the packet is between 4096 and 4352 the variable s  
will be overwritten. This seems to have no malicous consequences,  
because the data written into s due to the buffer overflow is  
subsequently never used, but overwritten by a call to sprintf()).  
  
.text:00003284 big_receive_switch  
  
stack of function:  
-00001174 data_ptr dd ?  
-00001170 rtas_key_or_errmsg dd ?  
-0000116C _connection dd ? ; offset  
-00001168 algo_iter_salt algo_iter_salt ?  
-00001150 decoded_packet_header packet_header ?  
-00001138 challenge_length dd ?  
-00001134 buf db 4096 dup(?)  
-00000134 challenge db 280 dup(?)  
-0000001C canary dd ?  
-00000018 var_18 db 24 dup(?)  
+00000000 s db 4 dup(?)  
+00000004 r db 4 dup(?)  
+00000008 connection dd ? ; offset  
  
The main loop that receives packets after an initial hello message  
was processed in qconndoor_accept. The function calls receive_command  
to acquire packet data with databuf = buf and databuflen = 4096. When  
a packet with command code 6, 7 or 10 is encountered and the length  
of encrypted data in packet is larger than 4096 + 280 + 4 + 24 + 4 =  
4408, a buffer overflow may occur and overwrites the return address.  
This overflow will be detected when the canary is validated on  
function return. When the encrypted length is between 4096 and 4376  
the buffer "challenge" will be overwritten. How this may have  
malicous effects is not understood, because "challenge" is used in  
calls to undocumented external functions.  
  
Conclusion:  
  
All qconnDoor messages seem to be received via the receive_command  
function, which in turn calls the vulnarable recv_exact_and_decrypt  
whenever the command code is 6, 7 or 10. Depending on the exact code  
path, a stack-based buffer overflow overwriting the return address  
may occur when the length of encrypted data in the packet is larger  
than 4384 or 4408 bytes. AES encrypted messages are exchanged during  
normal operation of the qconnDoor protocol. Therefore, program states  
must exist where the vulnerable code path is traversed. The exact  
conditions where the vulnerable code path is not taken are unknown  
because external libraries are involved.  
  
To empirically verify the presence of this bug, the following "deadly  
packet" was conceived:  
  
Data Description  
00 2a packet length (42, completely bogus but large enough to  
contain all relevant header fields)  
00 02 protocol version  
00 07 command code  
12 00 encrypted length (4608, large enough to trigger the bug and  
overwrite return address)  
0c 00 decrypted length (3072, small enough to pass the check in  
recv_exact_and_decrypt)  
??...?? initialization vector  
??...?? data  
  
3.3 Empirical Testing Using the Deadly Packet  
  
3.3.1 Unmodified simulator (i.e. not rooted, no changes after installation):  
  
Step 1: Connect once with blackberry-connect and terminate connection again  
  
$ bbndk/host_10_1_0_235/linux/x86/usr/bin/blackberry-connect 192.168.149.128  
-sshPublicKey ~/.rim/bbt_id_rsa.pub  
Info: Connecting to target 192.168.149.128:4455  
Info: Authenticating with target 192.168.149.128:4455  
Info: Encryption parameters verified  
Info: Sending ssh key to target 192.168.149.128:4455  
Info: ssh key successfully transferred.  
Info: Successfully connected. This application must remain running in order to  
use debug tools. Exiting the application will terminate this connection.  
^C  
  
Step 2: Send deadly packet  
  
$ perl -e 'print "\x00\x2a\x00\x02\x00\x07\x12\x00\x0c\x00" . "\x41" x 0xc00' |  
nc 192.168.149.128 4455  
  
Result: qconnDoor stopped working  
  
$ nc -v 192.168.149.128 4455  
nc: connect to 192.168.149.128 port 4455 (tcp) failed: Connection refused  
  
3.3.2 Unmodified simulator, same as above but with device password set:  
  
Step 1: Connect with blackberry-connect, this will fail due to the unknown password  
  
$ bbndk/host_10_1_0_235/linux/x86/usr/bin/blackberry-connect 192.168.149.128  
-sshPublicKey ~/.rim/bbt_id_rsa.pub  
Info: Connecting to target 192.168.149.128:4455  
Info: Authenticating with target 192.168.149.128:4455  
Info: Encryption parameters verified  
Error: The device password is set on the device. You must provide the device  
password in order to authenticate, or clear the password on the device.  
  
Step 2: Send deadly packet  
  
$ perl -e 'print "\x00\x2a\x00\x02\x00\x07\x12\x00\x0c\x00" . "\x41" x 0xc00' |  
nc 192.168.149.128 4455  
  
Result: qconnDoor stopped working  
  
$ nc -v 192.168.149.128 4455  
nc: connect to 192.168.149.128 port 4455 (tcp) failed: Connection refused  
  
  
3.3.3 BlackBerry Z10 with developer-mode activated  
  
For this test, the Z10 is a client in a wireless network.  
The developer-mode was activated. According to the "Developer  
Mode" settings dialog, the "Developer IP Address" is 169.254.0.1.  
Nevertheless, the attacker's host is a wireless participant, too, and  
has a different IP address.  
  
Step 1: Check availability of the service:  
  
$ nc -v 10.0.0.121 4455  
Connection to 10.0.0.121 4455 port [tcp/*] succeeded!  
  
Step 2: Connect with blackberry-connect, this will fail due to the unknown password:  
  
$ /opt/bbndk/host_10_1_0_132/linux/x86/usr/bin/blackberry-connect 10.0.0.121  
-password 'wrong' -sshPublicKey id_rsa.pub  
Info: Connecting to target 10.0.0.121:4455  
Info: Authenticating with target 10.0.0.121:4455  
Info: Encryption parameters verified  
Info: Authenticating with target credentials.  
Error: Connection refused: The device password you provided is incorrect.  
  
Step 3: Disable developer-mode  
  
This step can be omitted.  
  
Step 4: Send deadly packet  
  
$ perl -e 'print "\x00\x2a\x00\x02\x00\x07\x12\x00\x0c\x00" . "\x41" x 0xc00' |  
nc 10.0.0.121 4455  
  
Step 5: Check availability  
  
$ nc -v 10.0.0.121 4455  
nc: connect to 10.0.0.121 port 4455 (tcp) failed: Connection refused  
  
Result:  
  
Running blackberry-connected even with an invalid password is  
required in order to initilize communication functionality in  
qconnDoor. Therefore, the developer-mode has to be enabled.  
Afterwards, the developer-mode is not necessary and may be disabled  
again. After sending the deadly packet, the qconnDoor service is not  
available anymore.  
  
The qconnDoor TCP port is even accessible from hosts other than the  
"Developer IP Address" and even if the developer-mode is disabled.  
  
  
---------------------------------------------------------------------  
  
4. Impact  
  
---------------------------------------------------------------------  
  
The stack-based buffer overflow results in a memory-corruption, which  
may result in remote code execution. Countermeasures against buffer  
overflows such as Address Space Layout Randomization and stack  
cookies mitigate an easy exploitation. Since there is another variable  
stored in the stack frame of the affected function, at least this  
variable can be modified, too. It is not known if the affected  
variable that can be overwritten is actually used afterwards.  
  
---------------------------------------------------------------------  
  
5. Workaround  
  
---------------------------------------------------------------------  
  
To defeat the above described attack, the developer-mode should be  
disabled. Other workarounds are not known.  
  
---------------------------------------------------------------------  
  
6. Fix  
  
---------------------------------------------------------------------  
  
Vendor provided bugfix.  
  
---------------------------------------------------------------------  
  
7. Credits  
  
---------------------------------------------------------------------  
  
* David Gullasch ([email protected])  
* Max Moser ([email protected])  
* Martin Schobert ([email protected])  
  
---------------------------------------------------------------------  
  
8. About modzero  
  
---------------------------------------------------------------------  
  
The independent Swiss company modzero AG assists clients with  
security analysis in the complex areas of computer technology. The  
focus lies on highly detailed technical analysis of concepts,  
software and hardware components as well as the development of  
individual solutions. Colleagues at modzero AG work exclusively in  
practical, highly technical computer-security areas and can draw on  
decades of experience in various platforms, system concepts, and  
designs.  
  
http://modzero.ch  
  
[email protected]  
  
---------------------------------------------------------------------  
  
9. Disclaimer  
  
---------------------------------------------------------------------  
  
The information in the advisory is believed to be accurate at the  
time of publishing based on currently available information. Use of  
the information constitutes acceptance for use in an AS IS condition.  
There are no warranties with regard to this information. Neither the  
author nor the publisher accepts any liability for any direct,  
indirect, or consequential loss or damage arising from use of, or  
reliance on, this information.  
  
---------------------------------------------------------------------  
  
See also:  
http://www.modzero.ch/advisories/MZ-13-05-Blackberry_Z10-qconnDoor.txt  
  
  
`