Talos Vulnerability Report

Summary

A privilege escalation vulnerability exists in the uid_map functionality of Microsoft Azure Sphere 20.06. A specially crafted uid_map file can cause multiple applications to get the same UID assigned, thus broadening the attack surface. An attacker can modify the uid_map file to trigger this vulnerability.

Tested Versions

Microsoft Azure Sphere 20.06

Product URLs

https://azure.microsoft.com/en-us/services/azure-sphere/

CVSSv3 Score

8.1 - CVSS:3.0/AV:L/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:H

CWE

CWE-20 - Improper Input Validation

Details

Microsoft’s Azure Sphere is a platform for the development of internet-of-things applications. It features a custom SoC that consists of a set of cores that run both high-level and real-time applications, enforces security and manages encryption (among other functions). The high-level applications execute on a custom Linux-based OS, with several modifications to make it smaller and more secure, specifically for IoT applications.

As previously shown in TALOS-2020-1131 and TALOS-2020-1132, in version 20.06 of Azure Sphere an attacker could manage to change the contents of /mnt/config/uid_map arbitrarily.

To recap, this is an example of its contents:

# cat uid_map
1008
1001,7ba05ff7-7835-4b26-9eda-29af0c635280
1002,641f94d9-7600-4c5b-9955-5163cb7f1d75
1003,48a22e96-d078-4e34-9d7a-91b3404031da
1004,a65f3686-e50a-4fff-b25d-415c206537af
1005,89ecd022-0bdd-4767-a527-d756dd784a19
1007,11223344-1234-1234-1234-aabbccddeeff

The file contains a map of Linux user ids and their corresponding Azure Sphere component_id. This file is used by application-manager (the init process) in order to set unique user IDs for each application when it is started.
In the example above, the UIDs from 1001 to 1005 are system applications, while the line with UID 1007 is a user application. For the purposes of this advisory, we assume that the user application with component_id of 11223344-1234-1234-1234-aabbccddeeff is the one being compromised [1], and that was previously used in TALOS-2020-1132 to access the mtd1 device.

The application-manager logic parses the uid_map file and makes sure that all UIDs specified are larger than 999, thus an attacker cannot simply set the UID for its compromised application to 0 (the root user). While it is possible to simply corrupt this file by modifying the system apps UIDs to invalid numbers, and thus force the system to crash, more interesting possibilities exist.
In fact, application-manager does not make any uniqueness tests among all the UIDs specified in the list, meaning that multiple component IDs can be set to the same UID, breaking the assumption that each application has a unique UID assigned.
This allows an attacker to force a system application to have the same UID as the attacker, creating more potential for attacking a target system application.

For example, an attacker could modify the file above to look like the following:

1001,7ba05ff7-7835-4b26-9eda-29af0c635280
1002,641f94d9-7600-4c5b-9955-5163cb7f1d75
1003,48a22e96-d078-4e34-9d7a-91b3404031da  [2]
1004,a65f3686-e50a-4fff-b25d-415c206537af
1005,89ecd022-0bdd-4767-a527-d756dd784a19
1003,11223344-1234-1234-1234-aabbccddeeff  [3]

The 48a22e96-d078-4e34-9d7a-91b3404031da component ID [2] corresponds to the azured system app. Notice that we set the same UID (1003) to the attacker-controlled app [3]. After the system relaunches the attacker’s application (e.g. after a reboot), that application will have the same UID as the azured process.

Some interesting things are gained from this UID sharing, for instance the attacker now gains access to the /mnt/config/<uuid> folder of targeted system app. And, via procfs, we can also see the process running:

> id
uid=1003 gid=1003 groups=5(gpio)
> ps aux | grep azure
PID   USER     TIME  COMMAND
   30 1003      0:00 /mnt/sys/azured/bin/azured --update --daemonize

Forcing a system app to share the UID with another app opens a larger attack surface, since system apps have higher capabilities and the possibilities of interaction with the targeted system app become larger. In TALOS-2020-1133 we will show how to exploit this further and gain elevated privileges.

Timeline

2020-08-04 - Vendor Disclosure
2020-08-24 - Public Release
2020-11-12 - CVE assigned