传送门：上篇https://www.anquanke.com/post/id/96730
概要
本文主要讲解了如何对三星的TrustZone进行逆向工程和漏洞利用。在下篇中，我主要将介绍我发现的漏洞，具体漏洞如下：
SVE-2017-8888：身份验证绕过和tlc_server缓冲区溢出
SVE-2017-8889：ESECOMM Trustlet栈缓冲区溢出
SVE-2017-8890：ESECOMM Trustlet越界读取内存
SVE-2017-8891：ESECOMM Trustlet栈缓冲区溢出
SVE-2017-8892：ESECOMM Trustlet栈缓冲区溢出
SVE-2017-8893：ESECOMM Trustlet任意写入
大家可以在我的Git中，找到我提交给三星的全部PoC：https://github.com/puppykitten/tbase 。
目标选择
最一开始，我就将目光聚焦在Trustlet上。我要强调的是：如果能事先通过某种方式获得系统级权限，那么将会打开大量Trustlet层级的攻击面。但是，我希望能找到一种方式，能够在无特权的情况下实现攻击。因此，我开始尝试寻找一些可以利用的进程。
我采取了最简单的方法，grep系统二进制文件、库和暴露Binder接口的字符串，并借助它们实现我想要的功能。在理解了如何在安卓系统中暴露T-Base接口的共享库（在上篇文章中已经详细讲解）的情况下，我实现了进一步的攻击：
shell@herolte:/ $ service list | grep com.sec
shell@herolte:/system/lib64 $ strings -f * | grep mcNotify
shell@herolte:/system/bin$ strings -f * | grep onTransact
root@herolte:/proc# strings -f /proc/*/maps | grep libtlc
由此，我确定tlc_server是一个通过Binder实际暴露对若干Trustlet访问的进程，并且能够在默认安装中运行。
从tlc_server的主要代码中我们可以看到，共支持5个不同的Trustlet：
v3 = argc;
v4 = argv;
__android_log_print(4LL, "TLC_SERVER", "tlc_cerver main starts");
if ( v3 == 1 )
{
__android_log_print(4LL, "TLC_SERVER", "service name was not provided: defaulting to CCM");
strncpy(&service_name, aCCM, 31LL);
}
else
{
if ( v3 != 2 )
{
v6 = -1;
__android_log_print(6LL, "TLC_SERVER", "usage: tlc_server <CCM|DCM|ESECOMM|TUI|PUF>");
goto LABEL_15;
}
v5 = v4[1];
if ( (unsigned __int64)strnlen(v4[1], 32LL) > 0x1F )
{
v6 = -1;
__android_log_print(6LL, "TLC_SERVER", "too long g_service_name");
goto LABEL_15;
}
strncpy(&service_name, v5, 31LL);
__android_log_print(4LL, "TLC_SERVER", "Service Name = %s", &service_name);
if ( (unsigned int)strcmp("CCM", &service_name)
&& (unsigned int)strcmp("DCM", &service_name)
&& (unsigned int)strcmp("ESECOMM", &service_name)
&& (unsigned int)strcmp("TUI", &service_name)
&& (unsigned int)strcmp("PUF", &service_name) )
{
v6 = -1;
__android_log_print(6LL, "TLC_SERVER", "Only 'CCM', 'DCM', 'ESECOMM', 'TUI', and 'PUF' are supported");
goto LABEL_15;
}
}
v28 = 0LL;
v29 = 0LL;
v30 = 0LL;
v31 = 0LL;
v32 = 0LL;
v33 = 0LL;
v34 = 0LL;
v35 = 0LL;
if ( (unsigned int)strcmp(&service_name, "CCM") )
{
if ( (unsigned int)strcmp(&service_name, "DCM") )
{
if ( (unsigned int)strcmp(&service_name, "ESECOMM") )
{
if ( (unsigned int)strcmp(&service_name, "TUI") )
{
if ( (unsigned int)strcmp(&service_name, "PUF") )
{
LABEL_14:
v6 = -1;
__android_log_print(6LL, "TLC_SERVER", "fill_comm_data failed!");
goto LABEL_15;
}
strncpy(&v28, "libtlc_tz_puf_km.so", 31LL);
strncpy(&v32, "puf_get_comm_data", 31LL);
}
else
{
strncpy(&v28, "libtlc_tima_tui.so", 31LL);
strncpy(&v32, "tui_get_comm_data", 31LL);
}
}
else
{
strncpy(&v28, "libtlc_tz_esecomm.so", 31LL);
strncpy(&v32, "esecomm_get_comm_data", 31LL);
}
}
else
{
strncpy(&v28, "libtlc_tz_dcm.so", 31LL);
strncpy(&v32, "dcm_get_comm_data", 31LL);
}
}
else
{
strncpy(&v28, "libtlc_tz_ccm.so", 31LL);
strncpy(&v32, "ccm_get_comm_data", 31LL);
}
更重要的是，我发现两个tlc_server实例也在默认运行：一个是用于ESECOMM（与设备上的eSE硬件元件进行通信的Trustlet，用于安全支付交易），另一个是用于CCM（客户端证书管理）。
所以，接下来，我们就要观察Binder接口，找到一个不借助特权的利用方式。
注：我针对这些漏洞进行了独立研究，但后来发现Gal Beniamini也发现了tlc_server的Binder接口中的漏洞，这些漏洞已经在2017年被修复。
SVE-2017-8888：身份验证绕过和tlc_server缓冲区溢出
我在tlc_server中发现了两个漏洞。一个是内存破坏漏洞，恐怕非常难以借助此漏洞来实现远程代码执行。另一个是身份验证绕过，看上去似乎也非常不起眼。
针对这两个漏洞，我们必须要阅读Binder接口的函数。我们可以使用tlc_server的logcat输出，并跟踪字符串引用。
__int64 __fastcall binder_handler(android::IPCThreadState *IPCThreadState, unsigned int cmd_, const android::Parcel *data, android::Parcel *reply_, unsigned int flags_)
{
// (...)
switch ( cmd )
{
case 0u:
__android_log_print(4LL, "TLC_SERVER", "OPENSWCONN");
if ( !(unsigned __int8)android::Parcel::checkInterface(parcel_data, (char *)IPCThreadState_ + 16) )
goto LABEL_93;
if ( !reply )
goto LABEL_90;
if ( *((_DWORD *)IPCThreadState_ + 20) > 0 )
goto LABEL_35;
tlc_comm_cxt_ptr = (comm_cxt_t **)malloc(8LL);
if ( !tlc_comm_cxt_ptr )
{
__android_log_print(6LL, "TLC_SERVER", "tlc_server_ctx_t malloc failed");
goto LABEL_126;
}
*tlc_comm_cxt_ptr = 0LL;
comm_cxt = create_comm_ctx( // TLC_COMM_TYPE:
// 0 - proxy
// 1 - direct
//
// ==> we create direct
//
//
// direct_comm_cxt()
// - instantiate directCommImpl with these parameters
// - includes root (== device id, switched out to 0) and process (==uuid)
// - call tlc_open
// - mcOpenDevice(0) and mcOpenSession to uuid,
// after it mmaps the TLC buffer, to sendmsglen+recvmsglen length
TLC_COMMUNICATION_TYPE_DIRECT,
comm_data_root,
comm_data_root_strlen,
comm_data_process,
comm_data_process_strlen,
comm_data_max_sendmsg_size,
comm_data_max_recvmsg_size);
*tlc_comm_cxt_ptr = comm_cxt;
if ( !comm_cxt )
{
__android_log_print(6LL, "TLC_SERVER", "Failed to establish secure world communication");
free(tlc_comm_cxt_ptr);
goto LABEL_126;
}
if ( !(unsigned int)strcmp(&service_name, "ESECOMM") )
{
__android_log_print(4LL, "TLC_SERVER", "ESECOMM tlc_server connecting to SPI");
if ( (unsigned __int16)secEseSPI_open() )
{
__android_log_print(6LL, "TLC_SERVER", "*** secEseSPI_open failed : %d ***");
free(tlc_comm_cxt_ptr);
LABEL_126:
v52 = "Ctx creation failed - TZ app not loaded";
tlc_comm_ctx_ptr_global = 0LL;
goto OPEN_HANDLED;
}
}
tlc_comm_ctx_ptr_global = tlc_comm_cxt_ptr;
//(...)
case 1u:
__android_log_print(4LL, "TLC_SERVER", "CLOSESWCONN");
//(...)
case 2u:
__android_log_print(4LL, "TLC_SERVER", "COMM");
//(...)
android::defaultServiceManager(v73); // sp<IServiceManager> sm = defaultServiceManager()
//(...)
if ( sm )
{
v78 = *(int (__fastcall **)(__int64, int *))(*sm + 32LL);
android::String16::String16((android::String16 *)&recv_msg_len, "SEAMService");
v78(v77, &recv_msg_len); // defaultServiceManager->addService()
//(...)
isAuthorized_fnptr = *(__int64 (__fastcall **)(__int64, _QWORD, signed __int64, int *, _QWORD **))(*sm__ + 32LL);
android::String16::String16((android::String16 *)&recv_msg_len, "knox_ccm_policy");
android::String16::String16((android::String16 *)&send_msg_len, "C_SignInit");
v83 = isAuthorized_fnptr(sm__, mCallingPid, 0xFFFFFFFFLL, &recv_msg_len, &send_msg_len);
// sm->isAuthorized(mCallingPid, -1, service_name, &sm (?))
// can the calling pid call to the knox_ccm_policy service?
//(...)
if ( v83 )
{
v84 = "isAuthorized() returns an error!";
}
else
{
v74 = (*((__int64 (__fastcall **)(comm_cxt_t *))(*tlc_comm_ctx_ptr_global)->vtable_ptr + 8))(*tlc_comm_ctx_ptr_global);
// tlc_communicate()
//(...)
case 3u:
__android_log_print(4LL, "TLC_SERVER", "COMM_VIA_ASHMEM");
if ( !(android::Parcel::checkInterface(parcel_data, (char *)IPCThreadState_ + 16) & 1) )
{
v30 = -1;
goto LABEL_119;
}
if ( !v6 )
goto LABEL_72;
v43 = 0LL;
v44 = (_DWORD *)((char *)IPCThreadState_ + 92);
do
{
if ( *(v44 - 2) == v13 || *v44 == v13 )
goto LABEL_53;
v43 += 2LL;
v44 += 4;
}
while ( v43 < 1024 );
if ( (_DWORD)v43 == 1024 )
goto LABEL_70;
LABEL_53:
if ( (unsigned int)android::Parcel::readInt32(parcel_data, &msglen.recv_len) )
从反编译的代码中，我们可以发现以下内容：
- OPENSWCONN / CLOSESWCONN不需要权限；
- 对于命令2（COMM），tlc_server将使用SEAMS来验证调用者的权限；
- 命令3（COMM_VIA_ASHMEM）不会进行验证。
由此，我们已经发现了一个身份验证绕过漏洞，通过使用命令3，而不是命令2，使费特权进程可以打开到某个Trustlet的会话，并发送任意命令。
除了这一利用方式之外，命令3的也被用于实现缓冲区溢出，原因在于其允许sendlen和recvlen为负值。在Gal Beniamini报告这一漏洞后，这一点已经得到解决，但修复是不完整的。问题在于，共享内存总会被映射为sendlen的大小，但在将命令发送到Trustlet之后，会使用recvlen将结果写入映射的区域。针对sendlen和recvlen，会验证是否符合0 < len < max_len，但不会检查sendlen是否严格大于recvlen。由于该区域被映射，所以必须要跨越页的边界才能导致缓冲区溢出。实际上这是可行的，因为最大允许长度为4416，会被映射2页，而在sendlen < 0x1000的情况下则为1页。
通常情况下，tlc_server不会直接执行其他任何映射操作，因此对这个漏洞的利用看起来非常具有挑战性。coax tlc_server分配这样的大小是可能的，分配器将会为它们进行映射。实际上，我还没有深入考虑这一种利用方式，因为我希望尝试一些其他的漏洞利用。
ESECOMM Trustlet介绍
接下来，我们看看ESECOMM Trustlet。这个Trustlet实现了一个eSE（嵌入式安全元件）的借口，这二者的通信基于ISO7816标准。Trustlet使用SEC_SPI安全驱动程序通过SPI与eSE通信。通过查看Linux内核源代码，我们发现还有一个Linux内核驱动程序（请查看/drivers/spi/spi-s3c64xx.c）。我认为，这是针对将接口直接暴露给安卓的设备版本。无论哪种情况，这段代码解释了内存映射的输入输出，并帮我们理解Trustlet的实际作用。
对我们来说，最重要的是，Trustlet实施“SCP03全平台安全通道协议”。它使用基于APDU的协议来设置密码信息（Diffie-Hellman密钥）以创建安全通道。请注意，在这种情况下，与Trustlet通信的不安全世界客户端使用主密钥，我们会直接提供私钥。
当对ESECOMM Trustlet进行逆向工程时，有一个“非常嫌疑犯”向我们提供了有力的帮助。
- 协助我们标记tlApi调用。
- 三星在日志消息中有使用原始函数名称的习惯。例如：
snprintf(logbuffer, 119, "Enter %s", "process_SCPHandleApduResponse"); logbuffer[119] = 0; tlApiLogPrintf_0("%sn", logbuffer); if ( !state_ ) { snprintf(logbuffer, 119, "%s:%d :: Error, %sn", "process_SCPHandleApduResponse"); logbuffer[119] = 0; tlApiLogPrintf_0("%sn", logbuffer); JUMPOUT(&locret_AD5E); } - 通过/proc/sec_log中的adb Shell读取这些日志。
SVE-2017-8889：ESECOMM Trustlet栈缓冲区溢出
所有与SCP有关的命令，都是TLV编码的APDU。有一个实用程序函数用于解析TLV：
int __fastcall parse_tlvs_from_APDU(parsed_tlvs_t *out_apdus, char *in_buf, int start_offset, int total_length)
{
parsed_tlvs_t *parsed_tlvs_t; // r4
char *in_buf_; // r8
int total_length_; // r7
int offset; // r5
int i; // r6
tlv_t *tlv_obj; // r0
int ret; // r0
parsed_tlvs_t = out_apdus;
in_buf_ = in_buf;
total_length_ = total_length;
offset = start_offset;
if ( out_apdus && out_apdus->num_slots_used ) //
// so this is basically an array of TLV
// objects that we parse out.
//
// a TLV instance always point to a tag object
// also, which is its kind basically.
{
for ( i = 0; parsed_tlvs_t->num_slots_used > i; ++i )
free_tlv_obj(parsed_tlvs_t->tlv_array[i]);
}
parsed_tlvs_t->num_slots_used = 0;
while ( 1 )
{
tlv_obj = create_TLV_obj_wrap(in_buf_, offset, total_length_);// checks apdu len, but nothing about destination length
if ( !tlv_obj )
break;
parsed_tlvs_t->tlv_array[parsed_tlvs_t->num_slots_used++] = tlv_obj;
offset += get_apdu_len(tlv_obj);
if ( offset == total_length_ ) //
// we have parsed everything, return.
{
ret = parsed_tlvs_t->num_slots_used;
JUMPOUT(&return_);
}
}
JUMPOUT(&return_);
}
函数自身会进行一些检查，来确保TLV是合法的：
- 解析会在到达total_length时停止；
- 每个解析的TLV会被验证，要求不能大于total_length的长度，也不能大于0x400。
然而，这里却存在一个问题：并没有对TLV的数量检查，假如TLV的数量过多，那么解析出来的结构就会完全覆盖数组out_apdus。
使用的结构定义如下：
00000000 tlv_t struc ; (sizeof=0x413, mappedto_34)
00000000 filled DCB ?
00000001 multiple_tlvs_for_tag DCB ?
00000002 fill_1 DCB ?
00000003 fill_2 DCB ?
00000004 tag_obj_ptr DCD ? ; offset
00000008 len_field_len DCB ?
00000009 fill_3 DCB ?
0000000A fill_4 DCB ?
0000000B fill_5 DCB ?
0000000C tlv_length DCD ?
00000010 tlv_value_OR_num_extra_tlvs DCB ?
00000011 fill_6 DCB ?
00000012 fill_7 DCB ?
00000013 fill_8 DCB ?
00000014 next_tlv_ptrs_array DCB 1023 dup(?)
00000413 tlv_t ends
00000413
00000000 ; ---------------------------------------------------------------------------
00000000
00000000 parsed_tlvs_t struc ; (sizeof=0x44, mappedto_33)
00000000 tlv_array DCD 16 dup(?) ; this is an array of 16 tlv objects
00000040 num_slots_used DCD
00000044 parsed_tlvs_t ends
换句话说，parsed_tlvs_t最多只能容纳16个TLV对象。如果APDU中有超过16个TLV，解析将会导致缓冲区溢出。
这个漏洞可以由多个调用者触发：
parse_ca_cert
parse_scp_param
process_SCPHandleApduResponse
process_SCP11bHandleApduResponse
process_SCP11bDhHandleApduResponse
除parse_scp_param以外，所有名称都是基于二进制文件中字符串的原始函数名称。对于parse_scp_param，这是首先从process_ConstructSecureChannel调用的解析函数。
所有的路径都会存在同样的问题。例如，对于parse_ca_cert()，输出结构parsed_tlvs_t被分配在栈上，这意味着可以触发栈缓冲区溢出。
SVE-2017-8890：ESECOMM Trustlet越界读取内存
parse_tlvs_from_APDU存在的另一个问题，是它对于TLV解析不会在输入缓冲区结束时运行的保证是不充分的。从上面的伪代码中可以看到，只会对偏移量是否等于总长度进行检查。然而，每个TLV的长度都可能会增加1或多个字节，这就意味着total_length的值可以一直增加下去，解析也不会终止，从而导致读取缓冲区不足。事实上，触发该漏洞是非常容易的，即使在发送内容只有一些0的情况下，也能够导致Trustlet崩溃。
SVE-2017-8891：ESECOMM Trustlet栈缓冲区溢出
之前的栈缓冲区溢出漏洞并不是最方便的利用方式，因为我们借助该漏洞并不能直接控制要写入的内容。幸运的是，还有一个更方便的漏洞。
这一漏洞位于函数parse_ca_cert()中。
漏洞原因非常简单：在处理process_ScpInstallCaCert命令时，首先在APDU中发送的CA会被解析。其中应该会有几个字段，首先是CA的ID（tag 0x42）。一旦TLV被解析，CA ID的值就会从TLV结构复制到32字节的本地栈变量中。
由于没有进行任何长度检查，APDU TLV解析自身包含的检查只会确保TLV不会大于0x400字节，所以就可以将有效载荷放在输入之中，从而导致栈BOF被利用。
signed int __fastcall parse_ca_cert(char *msg_payload, int total_req_payload_len, void *caid, int *caid_len, char *curveid, void *pubkey_buf, int *pubkey_buf_len)
{
//(…)
v7 = msg_payload;
total_req_payload_len_ = total_req_payload_len;
caid_ = caid;
v10 = caid_len;
v11 = -1;
memset_to_0(&out_buf, 0x44u);
if ( parse_tlvs_from_APDU(&out_buf, v7, 0, total_req_payload_len_) < 0 )
{
snprintf(logbuffer, 119, "%s:%d :: Error, %sn", "parse_ca_cert", 73, "failed to parse TLV");
logbuffer[119] = 0;
tlApiLogPrintf_0("%sn", logbuffer);
return 3;
}
tlv_caid = find_tlv_obj_in_parsed_tlvs(&out_buf, (char *)&caid_tag_value);
tlv_caid_ = tlv_caid;
if ( tlv_caid )
{
memcpy_w(caid_, &tlv_caid->tlv_value_OR_num_extra_tlvs, tlv_caid->tlv_length);
具有漏洞的目标缓冲区，位于parse_ca_cert调用者的栈上：
signed int __fastcall process_ScpInstallCaCert(tci_msg_add_ca_payload_t *reqmsg, tci_rsp_payload_t *rspmsg)
{
tci_msg_add_ca_payload_t *reqmsg_; // r4@1
tci_rsp_payload_t *rspmsg_; // r5@1
char *reqmsg_payload_; // r7@1
signed int result; // r0@2
char pubkey[512]; // [sp+Ch] [bp-244h]@2
char caid[32]; // [sp+20Ch] [bp-44h]@2
char curveid; // [sp+22Ch] [bp-24h]@2
int pubkey_len; // [sp+230h] [bp-20h]@2
unsigned int caid_len; // [sp+234h] [bp-1Ch]@2
reqmsg_ = reqmsg;
rspmsg_ = rspmsg;
reqmsg_payload_ = reqmsg->payload;
if ( validate_input_len(reqmsg->payload, reqmsg->total_len, reqmsg->payload, (char *)&reqmsg->total_len) )
//ONLY verifies the total input len, not related to TLV lengths
{
result = parse_ca_cert(reqmsg_payload_, reqmsg_->total_len, caid, (int *)&caid_len, &curveid, pubkey, &pubkey_len);
(…)
为了保证完整性，以下是非常易读的validate_input_len：
BOOL __fastcall validate_input_len(BOOL payload_start__, unsigned int len, char *payload_start_, char *payload_end)
{
if ( payload_start__ )
payload_start__ = payload_start_ <= payload_end
&& payload_start__ >= payload_start_
&& payload_end >= payload_start__
&& payload_end >= len
&& &payload_end[-len] >= payload_start__;
return payload_start__;
}
SVE-2017-8892：ESECOMM Trustlet栈缓冲区溢出
ESECOMM Trustlet的下一个漏洞出现在函数parse_scp_param中。该函数被process_ConstructSecureChannel()的CMD_TZ_SCP_ConstructSecureChannel命令的处理程序调用。
这一漏洞与CA ID漏洞非常相似：在处理CMD_TZ_SCP_ConstructSecureChannel命令时，包含着建立安全通道所需加密参数的APDU首先被解析。输出被解析成以下格式：
00000000 scp_t struc ; (sizeof=0x110, mappedto_36)
00000000 protocol DCB ?
00000001 key_id DCB ?
00000002 key_version DCB ?
00000003 key_usage DCB ?
00000004 key_length DCB ?
00000005 key_type DCB ?
00000007 field_7 DCB ?
00000008 dh_p DCB 252 dup(?)
00000104 field_104 DCD ?
00000108 dh_P_len DCD ?
0000010C dh_G DCB ?
0000010D field_10D DCB ?
0000010E field_10E DCB ?
0000010F field_10F DCB ?
00000110 scp_t ends
在process_ConstructSecureChannel，该结构在栈上被实例化：
signed int __fastcall process_ConstructSecureChannel(int unk_type, tci_msg_payload_t *reqmsg, tci_rsp_payload_t *respmsg)
{
tci_msg_payload_t *reqmsg_; // r6
tci_rsp_payload_t *respmsg_; // r7
int protocol_type; // r10
char *reqmsg_payload; // r11
int calling_uid; // r9
char *v8; // r3
state_t *v9; // r8
char *v10; // r3
state_t *state; // r8
signed int v13; // r0
signed int v14; // r4
scp_t parsed_scp; // [sp+8h] [bp-138h]
reqmsg_ = reqmsg;
respmsg_ = respmsg;
protocol_type = unk_type;
reqmsg_payload = reqmsg->payload;
if ( !validate_input_len(reqmsg_payload, reqmsg->total_len, reqmsg_payload, &reqmsg[1])//
|| !validate_input_len(respmsg_->payload, respmsg_->total_len, respmsg_->payload, &respmsg_[1]) )
{
goto LABEL_6;
}
scp_state_dump("construct secure channel");
calling_uid = reqmsg_->calling_uid;
v9 = get_current_state(reqmsg_->calling_uid);
if ( v9 )
{
snprintf(logbuffer, 119, "cleanup existing state", v8);
logbuffer[119] = 0;
tlApiLogPrintf_0("%sn", logbuffer);
free_scp_state(v9);
scp_state_dump("construct secure channel, cleaned ongoing channel for callinguid");
}
hex_print_value("parsing scp_param", reqmsg_payload, reqmsg_->total_len);
if ( parse_scp_param(reqmsg_payload, reqmsg_->total_len, &parsed_scp) )
为此，必须存在多个标签，如下面parse_scp_param反编译后的伪代码所示：
signed int __fastcall parse_scp_param(char *input_payload, int total_length, scp_t *parsed_scp)
{
char *input_payload_; // r8@1
int total_length_; // r9@1
scp_t *parsed_scp_; // r4@1
signed int v6; // r5@1
signed int v7; // r0@4
const char *v8; // r1@4
tlv_t *v10; // r0@8
tlv_t *v11; // r0@9
tlv_t *v12; // r0@10
tlv_t *v13; // r0@11
tlv_t *v14; // r0@12
tlv_t *v15; // r0@13
int v16; // r0@14
signed int v17; // r0@17
const char *v18; // r1@17
tlv_t *dh_tlv; // r0@23
tlv_t *dh_tlv_; // r8@23
tlv_t *v21; // r0@24
tlv_t *v22; // r0@16
int i; // r4@31
parsed_tlvs_t parsed_apdus; // [sp+8h] [bp-60h]@1
input_payload_ = input_payload;
total_length_ = total_length;
parsed_scp_ = parsed_scp;
memset_to_0(&parsed_apdus, 68u);
v6 = 0;
if ( !input_payload_ || !parsed_scp_ )
{
v7 = 43;
v8 = "invalid parameter";
goto LABEL_5;
}
memset_to_0(parsed_scp_, 272u);
if ( parse_tlvs_from_APDU(&parsed_apdus, input_payload_, 0, total_length_) < 0 )
{
v7 = 47;
v8 = "bad apdu";
LABEL_5:
snprintf(logbuffer, 119, "%s:%d :: Error, %sn", 325987, v7, v8);
logbuffer[119] = 0;
tlApiLogPrintf_0((const char *)&loc_10F20, logbuffer);
return 4;
}
v10 = find_tlv_obj_in_parsed_tlvs(&parsed_apdus, scp_param_tag_values);
if ( !v10 )
{
v17 = 50;
v18 = "can't find protocol";
goto FAIL;
}
parsed_scp_->protocol = v10->tlv_value_OR_num_extra_tlvs;
v11 = find_tlv_obj_in_parsed_tlvs(&parsed_apdus, &scp_param_tag_values[1]);
if ( !v11 )
{
v17 = 54;
v18 = "can't find key-id";
goto FAIL;
}
parsed_scp_->key_id = v11->tlv_value_OR_num_extra_tlvs;
v12 = find_tlv_obj_in_parsed_tlvs(&parsed_apdus, &scp_param_tag_values[2]);
if ( !v12 )
{
v17 = 58;
v18 = "can't find key-version";
goto FAIL;
}
parsed_scp_->key_version = v12->tlv_value_OR_num_extra_tlvs;
v13 = find_tlv_obj_in_parsed_tlvs(&parsed_apdus, &scp_param_tag_values[3]);
if ( !v13 )
{
v17 = 62;
v18 = "can't find key-usage";
goto FAIL;
}
parsed_scp_->key_usage = v13->tlv_value_OR_num_extra_tlvs;
v14 = find_tlv_obj_in_parsed_tlvs(&parsed_apdus, &scp_param_tag_values[9]);
if ( !v14 )
{
v17 = 66;
v18 = "can't find key-length";
goto FAIL;
}
parsed_scp_->key_length = v14->tlv_value_OR_num_extra_tlvs;
v15 = find_tlv_obj_in_parsed_tlvs(&parsed_apdus, &scp_param_tag_values[5]);
if ( !v15 )
{
v17 = 70;
v18 = "can't find key-type";
goto FAIL;
}
v16 = (unsigned __int8)v15->tlv_value_OR_num_extra_tlvs;
parsed_scp_->key_type = v16;
if ( v16 == 0x89 )
{
dh_tlv = find_tlv_obj_in_parsed_tlvs(&parsed_apdus, &scp_param_tag_values[7]);
dh_tlv_ = dh_tlv;
if ( !dh_tlv )
{
v17 = 76;
v18 = "can't find dh param (p)";
goto FAIL;
}
memcpy((_DWORD *)parsed_scp_->dh_p, (int *)&dh_tlv->tlv_value_OR_num_extra_tlvs, dh_tlv->tlv_length);
// so this is straight up copying the dh param TLV value,
// using the L from the TLV.
//
// there is a max length check on this, but it is not sufficient:
// - check against 1024 AND
// - check against input length (max 512)
//
// but the stack buffer copied into is less than 300 bytes long.
SVE-2017-8893：ESECOMM Trustlet任意写入
与之前的几个漏洞不同，该漏洞无法在不提权的情况下直接利用。其原因在于，tlc_server自身增加了一个格式化（Sanitization）步骤。
然而，只要攻击者能够使用/dev/mobicore接口（借助任何一个有权限的系统进程，例如@oldfresher曾尝试过的远程利用链）就可以触发内存损坏漏洞。
漏洞的产生原因在于，使用了TCI缓冲区来确定请求缓冲区和相应缓冲区的范围。通常情况下，TCI缓冲区会被如下格式的头部填充：
00000000 tcibuf_hdr struc ; (sizeof=0x219, mappedto_27)
00000000 id DCD ?
00000004 calling_uid DCD ?
00000008 envelope_len DCD ?
0000000C status DCD ?
00000010 tcimsg_payload tci_msg_payload_t ?
00000219 tcibuf_hdr ends
字段envelope_len用于确定响应消息部分开始的缓冲区内偏移量。在通过tlc_server进行通信后，我们实际上使用的是libtlc_direct_comm.so，并且正确设置了这个字段：
__int64 __fastcall direct_comm_ctx::comm_request(direct_comm_ctx *this)
{
direct_comm_impl_t *direct_comm_impl; // x8
unsigned int v2; // w19
__int64 TCI_buf_addr; // x9
__int64 v4; // x21
bool v5; // zf
const char *v6; // x2
unsigned int max_recvmsg_size; // w20
unsigned int v8; // w0
direct_comm_impl = (direct_comm_impl_t *)*((_QWORD *)this + 1);
v2 = 65542;
if ( !direct_comm_impl )
{
v6 = "direct comm_request: NULL implementation pointer";
goto LABEL_9;
}
TCI_buf_addr = direct_comm_impl->TCI_buf_addr;// ?????
v4 = direct_comm_impl->unk_must_be_zero;
if ( TCI_buf_addr )
v5 = v4 == 0;
else
v5 = 1;
if ( v5 )
{
v6 = "tlc_request: NULL pointer data";
LABEL_9:
__android_log_print(6LL, "TZ: mc_tlc_communication", v6);
return v2;
}
max_recvmsg_size = direct_comm_impl->max_recvmsg_size;
*(_DWORD *)(TCI_buf_addr + 8) = direct_comm_impl->max_sendmsg_size; // can't set to arbitrary when used via tlc_server
v8 = tlc_communicate((__int64)&direct_comm_impl->device_id);
然而，如果我们可以写入WSM，然后触发通知命令，而不通过tlc_server到达Trustlet，那么envelope_len就能被任意定义。
其中的问题在于，我见过的很多Trustlet代码直接就信任了这个字段。以下ESECOMM Trustlet入口点的代码片段展现了从不安全世界处理输入内容的起始过程：
void __fastcall Main(_DWORD *tciBuf, unsigned int tciBufLen)
{
tcibuf_hdr *tciBuf_; // r6@1
unsigned int tciBufLen_; // r9@1
char *logbuffer_; // r5@4
tcibuf_hdr *respmsg; // r7@5
_BYTE *logbuffer_end; // r5@5
int envelope_len; // ST00_4@5
int cmd_id; // r8@5
int ret_val; // r10@7
_BYTE *logbuffer_end_; // r5@7
tciBuf_ = (tcibuf_hdr *)tciBuf;
tciBufLen_ = tciBufLen;
if ( !tciBuf || tciBufLen < 4397 )
{
((void (__fastcall *)(signed int, signed int))stru_1000.lib_addr)(4, -1);// tlApiExit()
JUMPOUT(&stru_1000);
}
snprintf(logbuffer, 119, "TL_TZ_ESECOMM: tciBufferLen = %d = 0x%x", tciBufLen, tciBufLen);
logbuffer_ = logbuffer;
logbuffer[119] = 0;
tlApiLogPrintf_0((const char *)&off_7364, logbuffer);
snprintf(logbuffer, 119, "Trustlet TL_TZ_ESECOMM: Starting");
logbuffer[119] = 0;
tlApiLogPrintf_0((const char *)&off_7364, logbuffer);
while ( 1 )
{
tlApiWaitNotification(-1);
respmsg = (tcibuf_hdr *)((char *)tciBuf_ + tciBuf_->envelope_len);
// tciBuf__[2] is the max_sendmsg_size ... NORMALLY
// but, if the command header is malformed,
// respmsg can become an arbitrary pointer
snprintf(logbuffer, 119, "TL_TZ_ESECOMM: tciBufferLen = %d = 0x%x", tciBufLen_, tciBufLen_);
logbuffer_[119] = 0;
logbuffer_end = logbuffer_ + 119;
tlApiLogPrintf_0((const char *)&off_7364, logbuffer);
envelope_len = tciBuf_->envelope_len;
snprintf(logbuffer, 119, "TL_TZ_ESECOMM: sendmsg envelope length = %d = 0x%x");
*logbuffer_end = 0;
tlApiLogPrintf_0((const char *)&off_7364, logbuffer);
snprintf(logbuffer, 119, "TL_TZ_ESECOMM: sendmsg = %p, respmsg = %p", tciBuf_, respmsg);
*logbuffer_end = 0;
tlApiLogPrintf_0((const char *)&off_7364, logbuffer);
cmd_id = tciBuf_->id;
snprintf(logbuffer, 119, "Trustlet TL_TZ_ESECOMM: Got a message!");
*logbuffer_end = 0;
logbuffer_ = logbuffer_end - 119;
tlApiLogPrintf_0((const char *)&off_7364, logbuffer);
if ( cmd_id >= 0 )
{
snprintf(logbuffer, 119, "TZ_ESECOMM: we got a command");
logbuffer_[119] = 0;
tlApiLogPrintf_0((const char *)&off_7364, logbuffer);
ret_val = process_cmd((int)esecomm_cxt_something, cmd_id, tciBuf_, (char *)respmsg);
respmsg->id = cmd_id | 0x80000000;
// respmsg address is completely controlled!
在Main中存在一个问题，无论命令处理是成功还是失败，响应值都会被写入到respmsg指针，在envelope_len被控制时，该指针可以是任意地址。
但不巧的是，对respmsg的写入在process_cmd内部的逻辑中也是重复的。发现很多代码路径都包含对respmsg有效载荷长度的检查，但实际上这里也是存在问题的。这些检查，会验证由respmsg字段指示的有效载荷长度是否符合给定命令类型的respmsg的预期大小。然而，Main中的初始respmsg分配可能已经指向了某个任意地址，因此该检查是没有意义的。
其中的一些，将会被tciBufLen > envelope_len检查覆盖，但并不是完全覆盖，因为在大多数情况下，respmsg的起始部分都采用写入的方式。最经典的例子是在process_DECRYPT：
int __fastcall process_cmd_decrypt(void *esecomm_cxt, char *reqmsg, char *rspmsg)
{
(…)
reqmsg_ = reqmsg;
rspmsg_ = rspmsg;
(…)
snprintf(logbuffer, 119, "TL_TZ_ESECOMM: process_DECRYPT: entering");
logbuffer[119] = 0;
tlApiLogPrintf_0((const char *)&loc_89EC, logbuffer);
*(_DWORD *)rspmsg_ = 10;
*((_WORD *)rspmsg_ + 2) = 255;
*(_DWORD *)(rspmsg_ + 4362) = 0;
(...)
所以，假如在Main()中增加了一个检查，那么它必须要知道respmsg正确的最大偏移量，这个偏移量可以被任何命令处理写入，并且会确保envelope_len永远不会过大。
SVE-2017-8893：为什么没有竞争条件？
在研究过程中，我们可能会有这样的一个思路：即使没有提升权限，我们也可以按照自己的需要写入TCI缓冲区，将Binder调用到tlc_server，然后调用tlc_communicate()来触发到Trustlet的通知，并在Trustlet世纪获取到安全世界内的运行计划之前，重写（修正后的）envelope_len。
事实证明，这一思路是错误的。其原因在于，当使用COMM_VIA_ASHMEM时，tlc_server中的binder_handler()在我们的命令中实际上是mmap，然后会从映射的缓冲区复制到独立的TCI缓冲区。也就是说，我们从来没有真正地直接访问TCI缓冲区。这也就意味着，tlc_server无法满足它在多个客户端之间多路复用（Multiplexing）的基本目标，仍然是使用ESECOMM Trustlet的单个开放Session（也就是单个TCI WSM）。
接下来的计划
接下来，我将对其他一些漏洞进行详细分析，特别是：
SVE-2017-9008：CCM Trustlet整数溢出
SVE-2017-9009：CCM Trustlet整数溢出
SVE-2017-10638：CCM Trustlet会话劫持漏洞
SVE-2017-8973：TIMA驱动程序缓冲区溢出
SVE-2017-8974：TIMA驱动程序竞争条件漏洞
SVE-2017-8975：TIMA驱动程序竞争条件漏洞
TIMA驱动程序信息泄漏导致KASLR绕过
敬请期待！
还没有评论，来说两句吧...