Google Nexus Synaptics Touchscreen Firmware Injection

Due to lenient SELinux and DAC policy, vulnerable Synaptics DSX (touchscreen driver) sysfs file entires are exposed to an attacker that executes code within the mediaserver context on Android M 6.0.1 and system_server, bluetooth, nfc contexts on Android N 7.0 (or any other SELinux domain that has target type sysfs with the open and write permissions on file class). These vulnerable sysfs entries allows an attacker to inject a flawed firmware image, through user-space, onto the Synaptics touchscreen controller.

Synaptic’s Touchscreen controllers are built on top of a proprietary 16-bit microcontroller. So no datasheets to help us reverse engineer it. Nevertheless, we could still infer the firmware image layout by peeking into Synaptic’s touchscreen firmware update mechanism inside the kernel. A high level representation:

+----------+--------------------+----------+
|          |                    |          |
| FIRMWARE | ENCRYPTED FIRMWARE | FIRMWARE |
|  HEADER  |         BLOB       |  CONFIG  |
|          |                    |          |
+----------+--------------------+----------+

When provided with a firmware image, the update mechanism carves out its “firmware_id” ( a field within the header) and queries the touchscreen controller for its current “firmware_id”. If the former is greater than the latter the firmware is flashed to the controller.

We crafted a flawed firmware image that consists of a higher “firmware_id” and a messed up encrypted firmware blob (we zeroed some bytes within it) and were able to flash it successfully to the controller.

The Synaptic’s controller does not defend against Ciphertext Malleability attacks by using Digital Signatures or Message Authentication Codes.