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.
Microsoft Azure Sphere 20.06
8.1 - CVSS:3.0/AV:L/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:H
CWE-20 - Improper Input Validation
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
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
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
11223344-1234-1234-1234-aabbccddeeff is the one being compromised , and that was previously used in TALOS-2020-1132 to access 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.
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  1004,a65f3686-e50a-4fff-b25d-415c206537af 1005,89ecd022-0bdd-4767-a527-d756dd784a19 1003,11223344-1234-1234-1234-aabbccddeeff 
48a22e96-d078-4e34-9d7a-91b3404031da component ID  corresponds to the
azured system app. Notice that we set the same UID (1003) to the attacker-controlled app . After the system relaunches the attacker’s application (e.g. after a reboot), that application will have the same UID as the
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.
2020-08-04 - Vendor Disclosure
2020-08-24 - Public Release
Discovered by Claudio Bozzato, Lilith >_> and Dave McDaniel of Cisco Talos.