Impact
In Singularity 3.x versions below 3.6.0, Singularity's sign and verify commands do not sign metadata found in the global header or data object descriptors of a SIF file, allowing an attacker to cause unexpected behavior. A signed container may verify successfully, even when it has been modified in ways that could be exploited to cause malicious behavior.
A container will still verify successfully if:
- Partition types are changed after signing, e.g. swapping a
PartPrimSys and PartOverlay to modify runtime behavior
- The global hash-bang header used for direct execution (e.g.
./image.sif) is changed to something else (e.g. rm -fr $HOME)
Other potentially exploitable ways in which a container can be modified, but would still verify successfully include:
- Re-labelling object data types to change how Singularity uses them. For example, re-labelling DataSignature to avoid the object being considered by singularity verify, DataEnvVar to avoid environment variables being applied, etc.
- Re-labelling partition types, in addition to the example above to change the primary system partition, change data partition to system partition, etc.
- Modifying filesystem types, FsSquash->FsExt3, causing mount to attempt to mount the wrong type of filesystem.
- Modifying the UID/GID of the image or its data objects.
- Modifying the creation time of the image or its data objects.
- Modifying the name of data objects.
- Modifying the UUID of an image.
Patches
A new signature format that addresses this issue by signing over security critical portions of the global header and object descriptors is introduced in Singularity 3.6.0.
All users are advised to upgrade to 3.6.0. Note that the new format 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. Verification with the --legacy-insecure flag does not indicate a container is unmodified from the time of signing. You should migrate to the new signature format as soon as possible.
Workarounds
If you do not use SIF images (i.e. only use sandbox containers), you are not affected by this advisory as sign/verify functionality applies to SIF images only.
If you cannot update to 3.6.0 at this time you should avoid using singularity sign, singularity verify or the execution control list functionality (ecl.toml), and should consider these features unsafe.
For more information
General questions about the impact of the advisory / changes made in the 3.6.0 release can be asked in the:
Any sensitive security concerns should be directed to: security@sylabs.io
See our Security Policy here: https://sylabs.io/security-policy
tri-adam Analyst
Impact
In Singularity 3.x versions below 3.6.0, Singularity's sign and verify commands do not sign metadata found in the global header or data object descriptors of a SIF file, allowing an attacker to cause unexpected behavior. A signed container may verify successfully, even when it has been modified in ways that could be exploited to cause malicious behavior.
A container will still verify successfully if:
PartPrimSysandPartOverlayto modify runtime behavior./image.sif) is changed to something else (e.g.rm -fr $HOME)Other potentially exploitable ways in which a container can be modified, but would still verify successfully include:
Patches
A new signature format that addresses this issue by signing over security critical portions of the global header and object descriptors is introduced in Singularity 3.6.0.
All users are advised to upgrade to 3.6.0. Note that the new format 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-insecureflag for thesingularity verifycommand, that will perform verification of the older, and insecure, legacy signatures for compatibility with existing containers. Verification with the--legacy-insecureflag does not indicate a container is unmodified from the time of signing. You should migrate to the new signature format as soon as possible.Workarounds
If you do not use SIF images (i.e. only use sandbox containers), you are not affected by this advisory as sign/verify functionality applies to SIF images only.
If you cannot update to 3.6.0 at this time you should avoid using
singularity sign,singularity verifyor the execution control list functionality (ecl.toml), and should consider these features unsafe.For more information
General questions about the impact of the advisory / changes made in the 3.6.0 release can be asked in the:
Any sensitive security concerns should be directed to: security@sylabs.io
See our Security Policy here: https://sylabs.io/security-policy