what you don't know can hurt you
Home Files News &[SERVICES_TAB]About Contact Add New

Android ssp_batch_ioctl Out-Of-Bounds Write

Android ssp_batch_ioctl Out-Of-Bounds Write
Posted Jan 17, 2017
Authored by Google Security Research, laginimaineb

Android suffers from an out-of-bounds write in ssp_batch_ioctl.

tags | advisory
SHA-256 | d8251df417f20cd57db8bb9ace2de1104fca9ec41f56cbe14574daaf5e879d27

Android ssp_batch_ioctl Out-Of-Bounds Write

Change Mirror Download
Android: OOB write in ssp_batch_ioctl 




SensorHub exposes a character device under /dev/batch_io which can be used in order to send instructions to batches of running sensors.

The IOCTL handler from this device has the following high-level logic:

1. static long ssp_batch_ioctl(struct file *file, unsigned int cmd, unsigned long arg) {
2. struct ssp_data *data = container_of(file->private_data, struct ssp_data, batch_io_device);
3. <...SNIP...>
4. sensor_type = (cmd & 0xFF);
5. if ((cmd >> 8 & 0xFF) != BATCH_IOCTL_MAGIC) {
6. pr_err("[SSP] Invalid BATCH CMD %x", cmd);
7. return -EINVAL;
8. }
9. <...SNIP...>
10. if (ret > 0) {
11. data->batchOptBuf[sensor_type] = (u8)batch.flag;
12. data->batchLatencyBuf[sensor_type] = timeout_ms;
13. data->adDelayBuf[sensor_type] = batch.delay;
14. } else {
15. ret = send_instruction_sync(data, CHANGE_DELAY, sensor_type, uBuf, 9);
16. if (ret > 0) {
17. data->batchOptBuf[sensor_type] = (u8)batch.flag;
18. data->batchLatencyBuf[sensor_type] = timeout_ms;
19. data->adDelayBuf[sensor_type] = batch.delay;
20. }
21. ...

As seen in the code above, the "sensor_type" field is taken from the least-significant byte of the user-supplied "cmd" argument. The range of the sensor_type is not validated in any way before using it (lines 11-19) as an index into a number of arrays defined under the "ssp_data" structure.

Looking at the definition of the "ssp_data" structure shows that the underlying arrays are defined as follows:

struct ssp_data {
...
int64_t adDelayBuf[SENSOR_MAX];
u64 lastTimestamp[SENSOR_MAX];
s32 batchLatencyBuf[SENSOR_MAX];
s8 batchOptBuf[SENSOR_MAX];
...
int (*wakeup_mcu)(void);
int (*set_mcu_reset)(int);
void (*get_sensor_data[SENSOR_MAX])(char *, int *, struct sensor_value *);
void (*report_sensor_data[SENSOR_MAX])(struct ssp_data *, struct sensor_value *);
...
}

The value of SENSOR_MAX varies according to the sensor vendor. For Broadcom, SENSOR_MAX is defined as 30, for Atmel 21, and for STM 25. Regardless, as the user-supplied "sensor_type" argument is not validated in any way, its range is 0x00-0xFF, thus exceeding the dimensions of the arrays above.

An attacker may use this vulnerability in order to overwrite values in the "ssp_data" structure which reside after the aforementioned arrays. For example, there are a few function pointers (see above) which the attacker could hijack. Moreover, note that the flow leading to the memory corruption is fully attacker-controlled, as is some of the data written (e.g., batch.flag or batch.delay).

This issue can be addressed by verifying the range of the "sensor_type" field to make sure it doesn't exceed SENSOR_MAX.

I've statically verified this issue on an SM-G935F device. The open-source kernel package I analysed was "SM-G935F_MM_Opensource".

The device entry mentioned above is owned by UID/GID "system". The SELinux context for this device is: "u:object_r:io_device:s0".

According to the default SELinux rules as present on the SM-G935F (version XXS1APG3), the following contexts may access this device file:

allow system_server io_device : chr_file { ioctl read open } ;

This bug is subject to a 90 day disclosure deadline. If 90 days elapse
without a broadly available patch, then the bug report will automatically
become visible to the public.



Found by: laginimaineb

Login or Register to add favorites

File Archive:

September 2024

  • Su
  • Mo
  • Tu
  • We
  • Th
  • Fr
  • Sa
  • 1
    Sep 1st
    261 Files
  • 2
    Sep 2nd
    17 Files
  • 3
    Sep 3rd
    38 Files
  • 4
    Sep 4th
    52 Files
  • 5
    Sep 5th
    23 Files
  • 6
    Sep 6th
    27 Files
  • 7
    Sep 7th
    0 Files
  • 8
    Sep 8th
    1 Files
  • 9
    Sep 9th
    16 Files
  • 10
    Sep 10th
    38 Files
  • 11
    Sep 11th
    21 Files
  • 12
    Sep 12th
    40 Files
  • 13
    Sep 13th
    18 Files
  • 14
    Sep 14th
    0 Files
  • 15
    Sep 15th
    0 Files
  • 16
    Sep 16th
    21 Files
  • 17
    Sep 17th
    51 Files
  • 18
    Sep 18th
    23 Files
  • 19
    Sep 19th
    0 Files
  • 20
    Sep 20th
    0 Files
  • 21
    Sep 21st
    0 Files
  • 22
    Sep 22nd
    0 Files
  • 23
    Sep 23rd
    0 Files
  • 24
    Sep 24th
    0 Files
  • 25
    Sep 25th
    0 Files
  • 26
    Sep 26th
    0 Files
  • 27
    Sep 27th
    0 Files
  • 28
    Sep 28th
    0 Files
  • 29
    Sep 29th
    0 Files
  • 30
    Sep 30th
    0 Files

Top Authors In Last 30 Days

File Tags

Systems

packet storm

© 2024 Packet Storm. All rights reserved.

Services
Security Services
Hosting By
Rokasec
close