CVE-2021-32635

Singularity is an open source container platform. In verions 3.7.2 and 3.7.3, Dde 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. The vulnerability is patched in Singularity version 3.7.4. Two possible workarounds exist: Users can only interact with the default remote endpoint, or an installation can have an execution control list configured to restrict execution to containers signed with specific secure keys.

Singularity is an open source container platform. In verions 3.7.2 and 3.7.3, Dde 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. The vulnerability is patched in Singularity version 3.7.4. Two possible workarounds exist: Users can only interact with the default remote endpoint, or an installation can have an execution control list configured to restrict execution to containers signed with specific secure keys.

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 containers signed with specific secure keys are not affected.

For more information

General questions about the impact of the advisory can be asked in the:

• SingularityCE Slack Channel
• SingularityCE Mailing List

Any sensitive security concerns should be directed to: [email protected]

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

Singularity is an open source container platform. In verions 3.7.2 and 3.7.3, Dde 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. The vulnerability is patched in Singularity version 3.7.4. Two possible workarounds exist: Users can only interact with the default remote endpoint, or an installation can have an execution control list configured to restrict execution to containers signed with specific secure keys.

Singularity is an open source container platform. In verions 3.7.2 and 3.7.3, Dde 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. The vulnerability is patched in Singularity version 3.7.4. Two possible workarounds exist: Users can only interact with the default remote endpoint, or an installation can have an execution control list configured to restrict execution to containers signed with specific secure keys.

Singularity is an open source container platform. In verions 3.7.2 and 3.7.3, Dde 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. The vulnerability is patched in Singularity version 3.7.4. Two possible workarounds exist: Users can only interact with the default remote endpoint, or an installation can have an execution control list configured to restrict execution to containers signed with specific secure keys.