ASA-2019-00273 – Singularity: Namespace privilege escalation and arbitrary file corruption

Allele Security Alert



ASA-2019-00273, CVE-2019-11328


Namespace privilege escalation and arbitrary file corruption





Affected version(s)

Singularity versions >= 3.1.0

Fixed version(s)

Singularity version 3.2.0

Proof of concept



A malicious user with local/network access to the host system (e.g. ssh) could exploit this vulnerability due to insecure permissions allowing a user to edit files within /run/singularity/instances/sing/<user>/<instance>. The manipulation of those files can change the behavior of the starter-suid program when instances are joined resulting in potential privilege escalation on the host.

Technical details

Singularity 3 uses a setuid root program called `starter-suid` for setting up Singularity containers. The issue is that containers run as background instances get bad directory permissions in path `/run/singularity/instances/sing/<user>/<instance>`. The permission of these directories is set to “<user>:root” with mode 0550. Since the unprivileged user is the owner of the directory it may change the mode to arbitrary values and therefore also the content of the directory to arbitrary content.

A result of this is that symlinks can be placed in the `ns` sub-directory that will be followed when joining the container instance and thus allow unprivileged users to enter arbitrary mnt, pid, net, cgroup, uts and ipc namespaces. Only user namespaces cannot be joined, because the `starter-suid` binary refuses to use user namespaces when running in the setuid context. (`starter-suid` also contains logic that is only intended for use when the program doesn’t carry a setuid root bit).

Furthermore, because the `starter-suid` program trusts the content of the JSON config file found in the instance directory, an attacker can modify this content to change the behaviour of the `starter-suid` program when joining a container. This way all desired namespaces can be configured or even the `noNewPrivileges` field can be set to false,
allowing a user to join the container without the `PR_SET_NO_NEW_PRIVS` bit set (see `prctl()`).

Even further, during creation of a background instance, the unprivileged user can try to win a race condition and place a symlink in path `/run/singularity/instances/sing/<user>/<instance>/<instance>.json`. The `starter-suid` program will follow this symlink and create and truncate an existing file in the target location. This allows to create or overwrite arbitrary files in the system with root privileges. The content written to the file is only partially attacker controlled, because the beginning of the JSON has a fixed structure.




Singularity 3.2.0

Singularity 3.1.0: CVE-2019-11328: namespace privilege escalation and arbitrary file corruption

Fix instance directory permission for privacy and exit when container instance doesn’t contain processes




If there is any error in this alert or you wish a comprehensive analysis, let us know.

Last modified: May 16, 2019

We are not responsible for any data loss, device corruption or any other type of issue due to the use of any information mentioned in our security alerts.