Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
9 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
Go github.com/sylabs/singularity >= 3.3.0, <= 3.5.1
Fixed in
3.5.2· Vendor fix available
Issue
Insecure permissions (777) are set on $HOME/.singularity when it is newly created by Singularity (version from 3.3.0 to 3.5.1), which could lead to an information leak, and malicious redirection of operations performed against Sylabs cloud services.
Recommended action: Upgrade to 3.5.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go github.com/sylabs/singularity >= 2.4.0, < 2.6.1
Fixed in
2.6.1· Vendor fix available
Issue
Sylabs Singularity 2.4 to 2.6 allows local users to conduct Improper Input Validation attacks.
Recommended action: Upgrade to 2.6.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go github.com/sylabs/singularity >= 3.2.0, < 3.6.3
Fixed in
3.6.3· Vendor fix available
Issue
Impact Insecure permissions on temporary directories used in fakeroot or user namespace container execution. When a Singularity action command (run, shell, exec) is run with the fakeroot or user namespace option, Singularity will extract a container image to a temporary sandbox directory. Due to insecure permissions on the temporary directory it is possible for any user with access to the system to read the contents of the image. Additionally, if the image contains a world-writable file or directory, it is possible for a user to inject arbitrary content into the running container. Patches This issue is addressed in Singularity 3.6.3. All users are advised to upgrade to 3.6.3. Workarounds The issue is mitigated if TMPDIR is set to a location that is only accessible to the user, as any subdirectories directly under TMPDIR cannot then be accessed by others. However, this is difficult to enforce so it is not recommended to rely on this as a mitigation. For more information General…
Recommended action: Upgrade to 3.6.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go github.com/sylabs/singularity >= 3.1.0, < 3.2.0
Fixed in
3.2.0· Vendor fix available
Issue
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 behavior of the starter-suid program when instances are joined resulting in potential privilege escalation on the host.
Recommended action: Upgrade to 3.2.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go github.com/sylabs/singularity >= 3.5.0, < 3.6.0
Fixed in
3.6.0· Vendor fix available
Issue
Impact The --all / -a option to singularity verify returns success even when some objects in a SIF container are not signed, or cannot be verified. The SIF objects that are not verified are reported in WARNING log messages, but a Container Verified message and exit code of 0 are returned. Workflows that verify a container using --all / -a and use the exit code as an indicator of success are vulnerable to running SIF containers that have unsigned, or modified, objects that may be exploited to introduce malicious behavior. Patches Singularity 3.6.0 has a new implementation of sign/verify that fixes this issue. All users are advised to upgrade to 3.6.0. Note that Singularity 3.6.0 uses a new signature format that is necessarily incompatible with Singularity < 3.6.0 - e.g. Singularity 3.5.3 cannot verify containers signed by 3.6.0. Version 3.6.0 includes a --legacy-insecure flag for the singularity verify command, that will perform verification of the older, and insecure, legacy…
Recommended action: Upgrade to 3.6.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go github.com/sylabs/singularity >= 3.0.0, < 3.6.0
Fixed in
3.6.0· Vendor fix available
Issue
Impact The Singularity Execution Control List (ECL) allows system administrators to set up a policy that defines rules about what signature(s) must be (or must not be) present on a SIF container image for it to be permitted to run. In Singularity 3.x versions below 3.6.0, the following issues allow the ECL to be bypassed by a malicious user: Image integrity is not validated when an ECL policy is enforced. The fingerprint required by the ECL is compared against the signature object descriptor(s) in the SIF file, rather than to a cryptographically validated signature. Thus, it is trivial to craft an arbitrary payload which will be permitted to run, even if the attacker does not have access to the private key associated with the fingerprint(s) configured in the ECL. Patches These issues are addressed in Singularity 3.6.0. All users are advised to upgrade to 3.6.0. Note that Singularity 3.6.0 uses a new signature format that is necessarily incompatible with Singularity < 3.6.0 - e.g.…
Recommended action: Upgrade to 3.6.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go github.com/sylabs/singularity >= 3.7.2, < 3.7.4
Fixed in
3.7.4· Vendor fix available
Issue
Impact Due to incorrect use of a default URL, singularity action commands (run/shell/exec) specifying a container using a library:// URI will always attempt to retrieve the container from the default remote endpoint (cloud.sylabs.io) rather than the configured remote endpoint. An attacker may be able to push a malicious container to the default remote endpoint with a URI that is identical to the URI used by a victim with a non-default remote endpoint, thus executing the malicious container. Only action commands (run/shell/exec) against library:// URIs are affected. Other commands such as pull / push respect the configured remote endpoint. Patches All users should upgrade to Singularity 3.7.4 or later. A patch was applied at: https://github.com/sylabs/singularity/commit/d52ae9d13979733c5e987a566fae59ed6f1bf796 Workarounds Users who only interact with the default remote endpoint are not affected. Installations with an execution control list configured to restrict execution to…
Recommended action: Upgrade to 3.7.4 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go github.com/sylabs/singularity >= 3.1.1, < 3.6.4
Fixed in
3.6.4· Vendor fix available
Issue
Impact Due to insecure handling of path traversal and the lack of path sanitization within unsquashfs (a distribution provided utility used by Singularity), it is possible to overwrite/create any files on the host filesystem during the extraction of a crafted squashfs filesystem. Squashfs extraction occurs automatically for unprivileged execution of Singularity (either --without-suid installation or with allow setuid = no) when a user attempts to run an image which: - is a local SIF image or a single file containing a squashfs filesystem - is pulled from remote sources library:// or shub:// Image build is also impacted in a more serious way as it is often performed by the root user, allowing an attacker to overwrite/create files leading to a system compromise. Bootstrap methods library, shub and localimage trigger a squashfs extraction. Patches This issue is addressed in Singularity 3.6.4. All users are advised to upgrade to 3.6.4 especially if they use Singularity mainly for…
Recommended action: Upgrade to 3.6.4 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Insecure permissions on temporary directories used in explicit and implicit container build operations. When a Singularity command that results in a container build operation is executed, it is possible for a user with access to the system to read the contents of the image during the build. Additionally, if the image contains a world-writable file or directory, it is possible for a user to inject arbitrary content into the running build, which in certain circumstances may enable arbitrary code execution during the build and/or when the built container is run. Patches This issue is addressed in Singularity 3.6.3. All users are advised to upgrade to 3.6.3. Workarounds The issue is mitigated if TMPDIR is set to a location that is only accessible to the user, as any subdirectories directly under TMPDIR cannot then be accessed by others. However, this is difficult to enforce so it is not recommended to rely on this as a mitigation. For more information General questions about the…
Recommended action: Upgrade to 3.6.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.