Package Instance

"Verify All" Returns Success Despite Validation Failures in Singularity
### 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.

```
$ singularity verify -a image.sif 
WARNING: Missing signature for SIF descriptor 2 (JSON.Generic)
WARNING: Missing signature for SIF descriptor 3 (FS)
Container is signed by 1 key(s):

Verifying partition: Def.FILE:
12045C8C0B1004D058DE4BEDA20C27EE7FF7BA84
[LOCAL]   Unit Test <unit@test.com>
[OK]      Data integrity verified

INFO:    Container verified: image.sif

$ echo $?
0
```


### 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 signatures for compatibility with existing containers. This does not guarantee that containers have not been modified since signing, due to other issues in the legacy signature format.

### Workarounds

If you are unable to update to 3.6.0 ensure that you do not rely on the return code of `singularity verify --all / -a` as an indicator of trust in a container.

Note that other issues in the sign/verify implementation in Singularity < 3.6.0 allow additional means to introduce malicious behavior to a signed container.


### For more information

General questions about the impact of the advisory / changes made in the 3.6.0 release can be asked in the:

* [Singularity Slack Channel](https://bit.ly/2m0g3lX)
* [Singularity Mailing List](https://groups.google.com/a/lbl.gov/forum/??sdf%7Csort:date#!forum/singularity)

Any sensitive security concerns should be directed to: security@sylabs.io

See our Security Policy here: https://sylabs.io/security-policy

Insecure permissions on user namespace / fakeroot temporary rootfs in Singularity
### 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 questions about the impact of the advisory / changes made in the 3.6.0 release can be asked in the:

* [Singularity Slack Channel](https://bit.ly/2m0g3lX)
* [Singularity Mailing List](https://groups.google.com/a/lbl.gov/forum/??sdf%7Csort:date#!forum/singularity)

Any sensitive security concerns should be directed to: security@sylabs.io

See our Security Policy here: https://sylabs.io/security-policy

Insecure permissions on build temporary rootfs in Singularity
### 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 impact of the advisory / changes made in the 3.6.0 release can be asked in the:

* [Singularity Slack Channel](https://bit.ly/2m0g3lX)
* [Singularity Mailing List](https://groups.google.com/a/lbl.gov/forum/??sdf%7Csort:date#!forum/singularity)

Any sensitive security concerns should be directed to: security@sylabs.io

See our Security Policy here: https://sylabs.io/security-policy

Path traversal and files overwrite with unsquashfs in singularity
### 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 building image as root user.

### Workarounds

There is no solid workaround except to temporarily avoid use of unprivileged mode with single file images, in favor of sandbox images instead. Regarding image build, temporarily avoid building from `library` and `shub` sources, and as much as possible use `--fakeroot` or a VM to limit potential impact.

### For more information

General questions about the impact of the advisory / changes made in the 3.6.0 release can be asked in the:

* [Singularity Slack Channel](https://bit.ly/2m0g3lX)
* [Singularity Mailing List](https://groups.google.com/a/lbl.gov/forum/??sdf%7Csort:date#!forum/singularity)

Any sensitive security concerns should be directed to: security@sylabs.io

See our Security Policy here: https://sylabs.io/security-policy

Execution Control List (ECL) Is Insecure in Singularity
### 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. Singularity 3.5.3 cannot verify containers signed by 3.6.0.

Version 3.6.0 includes a `legacyinsecure` option that can be set to `legacyinsecure = true` in `ecl.toml` to allow the ECL to perform verification of the older, and insecure, legacy signatures for compatibility with existing containers. This does not guarantee that containers have not been modified since signing, due to other issues in the legacy signature format. The option should be used only to temporarily ease the transition to containers signed with the new 3.6.0 signature format.

### Workarounds

This issue affects any installation of Singularity configured to use the Execution Control List (ECL) functionality. There is no workaround if ECL is required.

### For more information

General questions about the impact of the advisory / changes made in the 3.6.0 release can be asked in the:

* [Singularity Slack Channel](https://bit.ly/2m0g3lX)
* [Singularity Mailing List](https://groups.google.com/a/lbl.gov/forum/??sdf%7Csort:date#!forum/singularity)

Any sensitive security concerns should be directed to: security@sylabs.io

See our Security Policy here: https://sylabs.io/security-policy