ZDI-CAN-23157: New Vulnerability Report (ZDI-24-1077)

The attachment could not be scanned for viruses because it is a password protected file.
Per the request to share information for ZDI-24-1077, please see the below report and attachment, and let us know if there are any issues.

--

ZDI-CAN-23157: oFono QMI SMS Handling Out-Of-Bounds Read Information Disclosure Vulnerability

-- CVSS -----------------------------------------

3.7: AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N

-- ABSTRACT -------------------------------------

Trend Micro's Zero Day Initiative has identified a vulnerability affecting the following products:
oFono - oFono

-- VULNERABILITY DETAILS ------------------------
* Version tested:  16.0.3
* Installer file:  agl-demo-platform-crosssdk-raspberrypi4-64.wic.xz
* Platform tested: Raspberry Pi

---

### Analysis
please note: the first bug used in the exploit chain is an nday (dupe of ZDI-CAN-20971). The following is analysis of the second bug used in the chain.
When the SMS service is being initialized through QMI in sms.c get msg list cb(), the soft- ware requests a message list from the modem. The following code is an excerpt from this code (with added comments).

```
/* save list and get 1st msg */
 if (cnt) {
         // Msg_size can be made to anything, as cnt is controlled
         int msg_size = cnt * sizeof(list->msg[0]);
         data->msg_list = g_try_malloc0(sizeof(list->cnt) + msg_size);
         if (data->msg_list == NULL)
goto done;
         data->msg_list->cnt = cnt;
         // This can read a lot out of bounds!
         memcpy(data->msg_list->msg, list->msg, msg_size);
         data->rd_msg_num = 0;
         raw_read(sms, data->msg_list->msg[0].type,
         GUINT32_FROM_LE(data->msg_list->msg[0].ndx));
         return;
}
```

Here, ���cnt��� is a controlled integer pulled from a type-length value provided by the reply to a get msg list request. The vulnerability here is a missing bounds check on the ���cnt��� value. What���s happening is that the WMS service of QMI is asking the ���device��� how many SMS messages there are to read in and pass into the higher Ofono SMS code layers. It will trust the INT count of messages provided by the TLV, allocate an array of message types and indexes, then copy these from the original TLV into this allocated array. The following is the type definition for these msg���s being copied.

```

 struct qmi_wms_result_msg_list {
         uint32_t cnt;
         struct {
                 uint32_t ndx;
                 uint8_t  type;
         } __attribute__((__packed__)) msg[0];
 } __attribute__((__packed__));
```

What this indicates is that 5 bytes times ���cnt��� will be allocated, and this data will be copied there from the list-��msg object which lives on the stack. This provides an out of bounds read of stack data that may help exploit the overflow identified previously, but how can this be leaked remote to the attacker? Keep in mind, ���remote��� in this attack is actually over USB.
When looking further into how this array of SMS identifiers is used, it can be observed that they are actually used to request the SMS data for each identifier from the modem one-by-one. The following function, raw read() is called for each of these 5-byte identifiers:

```
 static void raw_read(struct ofono_sms *sms, uint8_t type, uint32_t ndx)
 {
         struct sms_data *data = ofono_sms_get_data(sms);
         struct qmi_param *param;
DBG("");
         param = qmi_param_new();
         if (param == NULL)
         goto done;
         data->rd_msg_id.type = type;
         data->rd_msg_id.ndx = ndx;
         DBG("read type %d ndx %d", data->rd_msg_id.type, data->rd_msg_id.ndx);
         qmi_param_append(param, QMI_WMS_PARAM_READ_MSG,
         sizeof(data->rd_msg_id), &data->rd_msg_id);
         qmi_param_append_uint8(param, QMI_WMS_PARAM_READ_MODE, data->msg_mode);
         printf("raw_read service send\n");
         if (qmi_service_send(data->wms, QMI_WMS_RAW_READ, param,
         raw_read_cb, sms, NULL) > 0)
         return;
         qmi_param_free(param);
         done:
         data->msg_list_chk = false;
}
```

Looking backwards now, the buffer that is copied from is found in the snippet below. It is reading right from the 20480-byte buffer on the stack reserved for the incoming QMI message.

```
static gboolean received_data(GIOChannel *channel, GIOCondition cond,
 gpointer user_data)
 {
         struct qmi_device *device = user_data;
         struct qmi_mux_hdr *hdr;
         unsigned char buf[2048];
         ssize_t bytes_read;
         uint16_t offset;

```

If these 5-byte identifiers are going to be sent back one-by-one, and much of the array of them may be comprised of out-of-bounds stack data when ���cnt��� is tampered, then this becomes a useful remote stack leak!
Since both of these primitives take place in the same thread for QMI, the stack canary in use is captured. Return addresses can now be captured for defeating PIE, and LibC addresses may be captured for defeating ASLR.



-- CREDIT ---------------------------------------
This vulnerability was discovered by:
Rob Blakely working with Trend Micro Zero Day Initiative

-- FURTHER DETAILS ------------------------------

Supporting files:


If supporting files were contained with this report they are provided within a password protected ZIP file. The password is the ZDI candidate number in the form: ZDI-CAN-XXXX where XXXX is the ID number.

Please confirm receipt of this report. We expect all vendors to remediate ZDI vulnerabilities within 90 days of the reported date. If you are ready to release a patch at any point leading up to the deadline, please coordinate with us so that we may release our advisory detailing the issue. If the 90-day deadline is reached and no patch has been made available we will release a limited public advisory with our own mitigations, so that the public can protect themselves in the absence of a patch. Please keep us updated regarding the status of this issue and feel free to contact us at any time:

Zero Day Initiative
[email protected]

The PGP key used for all ZDI vendor communications is available from:

  http://www.zerodayinitiative.com/documents/disclosures-pgp-key.asc

-- INFORMATION ABOUT THE ZDI --------------------
Established by TippingPoint and acquired by Trend Micro, the Zero Day Initiative (ZDI) neither re-sells vulnerability details nor exploit code. Instead, upon notifying the affected product vendor, the ZDI provides its Trend Micro TippingPoint customers with zero day protection through its intrusion prevention technology. Explicit details regarding the specifics of the vulnerability are not exposed to any parties until an official vendor patch is publicly available.

Please contact us for further details or refer to:

  http://www.zerodayinitiative.com

-- DISCLOSURE POLICY ----------------------------

Our vulnerability disclosure policy is available online at:

  http://www.zerodayinitiative.com/advisories/disclosure_policy/
TREND MICRO EMAIL NOTICE

The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system.

For details about what personal information we collect and why, please see our Privacy Notice on our website at: Read privacy policy<http://www.trendmicro.com/privacy>