Allele Security Alert
ASA-2019-00273
Identifier(s)
ASA-2019-00273, CVE-2019-11328
Title
Namespace privilege escalation and arbitrary file corruption
Vendor(s)
Sylabs
Product(s)
Singularity
Affected version(s)
Singularity versions >= 3.1.0
Fixed version(s)
Singularity version 3.2.0
Proof of concept
Unknown
Description
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.
Credits
Unknown
Reference(s)
Singularity 3.2.0
https://github.com/sylabs/singularity/releases/tag/v3.2.0
Singularity 3.1.0: CVE-2019-11328: namespace privilege escalation and arbitrary file corruption
https://seclists.org/oss-sec/2019/q2/112
Fix instance directory permission for privacy and exit when container instance doesn’t contain processes
https://github.com/sylabs/singularity/commit/b4dcb0e4d77baa1c7647a4a5705ea824bb4e0dca
CVE-2019-11328.diff
https://repo.sylabs.io/security/2019/CVE-2019-11328.diff
CVE-2019-11328
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-11328
CVE-2019-11328
https://nvd.nist.gov/vuln/detail/CVE-2019-11328
If there is any error in this alert or you wish a comprehensive analysis, let us know.
Last modified: May 16, 2019