We have identified a new heap buffer overflow vulnerability in Samsung’s Android Radio Interface Layer implementation. The vulnerability can be exploited by a malicious (compromised) baseband runtime to achieve arbitrary code execution in Android in the radio context.
The vulnerability we are disclosing in this advisory affected a wide range of Samsung devices, including phones on the newest Exynos chipsets. The July 2023 issue of the Samsung Mobile Security Bulletin contains this vulnerability as CVE-2023-30645.
Vulnerability Details
The Exynos vendor RIL implementation, provided by the libsec-ril.so
library, exposes an Inter Process Call (IPC) interface to the baseband processor.
The baseband processor can use this API through dedicated IPC messages.
When the IpcProtocol41Sms::IpcRxIncomingCBMsg
IPC handler is triggered it allocates a heap object and copies the content of the IPC message into it.
The vulnerability is in this IpcProtocol41Sms::IpcRxIncomingCBMsg
as it fails to verify the provided length field and overflows the allocated buffer.
The length is stored on two bytes, the maximum value is 0xffff bytes while the heap buffer size is 0x9e8 bytes.
CBMessage * __thiscall
IpcProtocol41Sms::IpcRxIncomingCBMsg
(IpcProtocol41Sms *this,sipc_ipc_msg *param_1,int IpcLen,int *param_3,
RegistrantType *param_4)
{
[...]
// [1] The CBMessage Object is allocated
this_00 = (CBMessage *)operator.new(0x9e8);
CBMessage::CBMessage(this_00);
DVar1 = param_1->data[1];
cbLen = param_1->data[2];
cbLen_ = (ulong)(byte)cbLen;
*(undefined4 *)(this_00 + 0x500) = 0;
uVar5 = 1;
if (DVar1 == (Data)0x2) {
uVar5 = 2;
}
*(undefined4 *)(this_00 + 0xc) = uVar5;
*(uint *)(this_00 + 0x10) = (uint)(byte)cbLen;
if ((byte)cbLen != 0) {
memcpy(this_00 + 0x14,param_1->data + 3,cbLen_);
}
if ((int)(uint)(byte)cbLen < IpcLen + -0xb) {
iVar4 = *(int *)puVar2;
// [2] The 2 byte length field is retrieved here
wacLen = CONCAT11(param_1->data[cbLen_ + 4],param_1->data[cbLen_ + 3]);
if (1 < iVar4) {
uVar3 = GetLogTag();
__android_log_buf_print(1,3,uVar3,"wacLen = %d",(ulong)wacLen);
}
wacLen_ = (uint)wacLen;
if ((int)(wacLen_ + (byte)cbLen) <= IpcLen + -0xb) {
if (1 < *(int *)puVar2) {
uVar3 = GetLogTag();
__android_log_buf_print(1,3,uVar3,"[WEAGEO] including wac");
}
*(uint *)(this_00 + 0x500) = wacLen_;
if (wacLen_ != 0) {
// [3] Data is copied into the heap buffer without length check
memcpy(this_00 + 0x504,param_1->data + cbLen_ + 5,(ulong)wacLen);
}
}
}
*param_4 = 0x4b;
return this_00;
}
The function allocates the heap object at [1] then retrieves the two byte length field at [2] and does the copy without further checks at [3].
The baseband firmware has dedicated API functions for sending and receiving IPC messages.
These functions serialize the IPC content into the dedicated shared memory ring-buffers and signal the kernel through an interrupt.
On the AP processor side the CPIF Android kernel driver retrieves the IPC message content from the shared memory and exposes it to the user-space
through the /dev/umts_ipc0
and/or /dev/umts_ipc1
character devices.
Within the vendor rild implementation (libsec-ril.so
) there are dedicated threads for continuously polling these devices.
The entry point of the threads is IoChannelReader::Run
and they block on the device read in the IoChannel::Read
function.
Once an IPC message is read from the character device it is passed to IpcModem::ReceiveMessage
and subsequently to the IpcModem::DoIoChannelRouting
and IpcModem::DoIoChannelRoutingRx
functions.
The IpcModem::DoIoChannelRoutingRx
function receives the pointer to the appropriate IoChannel
object where the IPC message was retrieved.
IPC messages are passed to IpcModem::GetIpcMessage
and then forwarded to IpcModem::ProcessSingleIpcMessageReceived
where the appropriate IpcProtocol41*
implementation is retrieved based on the IPC command value.
Finally, the IpcProtocol41*::GetRxData
function is called which is responsible for calling the requested IPC API endpoint, based on the subcommand of the IPC message.
Affected Devices
All Samsung chipsets containing Samsung’s baseband implementation, including all Exynos chipsets.
Fix
Samsung OTA images, released after July 2023, contain the fix for the vulnerability.
Timeline
- 2023.04.01. Bug reported to Samsung PSIRT
- 2023.05.12. Samsung confirms vulnerability
- 2023.06.26. Samsung confirms fix will be released in the July security bulletin
- 2023.07.11. Samsung releases security bulletin
- 2023.09.26. TASZK informs Samsung of disclosure plan, Samsung confirms
- 2023.11.03. Vulnerability released at Hardwear.io
- 2023.11.26. Advisory release