Sylabs Singularity 3.1.0 to 3.2.0-rc2 Remote Code Execution Vulnerability


An issue was discovered in Singularity 3.1.0 to 3.2.0-rc2, 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 behaviour of the starter-suid program when instances are joined resulting in a potential privilege escalation on the host.


The information has been provided by Matthias Gerstner
The original article can be found at:


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

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.

I couldn’t work out a full local root exploit from these defects yet but all of the findings are very close to getting root and if putting in enough energy there’s probably some way to achieve it.

The issue has been fixed by usptream by moving the instance
configuration file into the user’s home directory, fixing the
permissions of the directory in /run and not trusting certain parameters found in the instance’s JSON configuration.

Vulnerable Systems:

  • Sylabs Singularity 3.2.0
  • Sylabs Singularity 3.2.0
  • Sylabs Singularity 3.2.0

CVE Information:

Disclosure Timeline:
Publish Date:05/14/2019