CVE-2019-11328

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.

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.

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.

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.

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.

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.

This update for singularity fixes the following issues:

singularity was updated to version 3.4.1:

This point release addresses the following issues:

• Fixes an issue where a PID namespace was always being used
• Fixes compilation on non 64-bit architectures
• Allows fakeroot builds for zypper, pacstrap, and debootstrap
• Correctly detects seccomp on OpenSUSE
• Honors GO_MODFLAGS properly in the mconfig generated makefile
• Passes the Mac hostname to the VM in MacOS Singularity builds
• Handles temporary EAGAIN failures when setting up loop devices on recent kernels.

New version 3.4.0. Many changes since 3.2.1, for the full changelog please read CHANGELOG.md

Update to version 3.2.1:

This point release fixes the following bugs:

• Allows users to join instances with non-suid workflow
• Removes false warning when seccomp is disabled on the host
• Fixes an issue in the terminal when piping output to commands
• Binds NVIDIA persistenced socket when --nv is invoked

Improve integration with SUSE Products: add support to create Singularity images with SLE.

• Newer SUSE versions use a different path for the RPM database.

• When the installation succeeds by an installation scriptlet fails zypper returns error code 107. Don't treat this as an error.

• In order to specify a repository GPG key, add support for multi line variables.

• In order to specify a list of additional repos, add support to 'indexed' variables.

• Improve handling of SUSE repositires:

  • For SLE, use SUSEConnect to get all product repos.
  • Allow to specify a repository GPG key.
  • Allow to specify additional installation repositories.

• Add group 'singularity', fix ownerships.

Updated to singularity v3.2.0

• CVE-2019-11328: Instance files are now stored in user's home directory for privacy and many checks have been added to ensure that a user can't manipulate files to change starter-suid behavior when instances are joined (many thanks to Matthias Gerstner from the SUSE security team for finding and securely reporting this vulnerability) (boo#1128598)

• New features / functionalities

  • Introduced a new basic framework for creating and managing plugins
  • Added the ability to create containers through multi-stage builds
  • Created the concept of a Sylabs Cloud 'remote' endpoint and added the ability for users and admins to set them through CLI and conf files
  • Added caching for images from Singularity Hub
  • Made it possible to compile Singularity outside of $GOPATH
  • Added a json partition to SIF files for OCI configuration when building from an OCI source
  • Full integration with Singularity desktop for MacOS code base

• New Commands

  • Introduced the plugin command group for creating and managing plugins.

• Introduced the remote command group to support management of Singularity endpoints.

• Added to the key command group to improve PGP key management.

• Added the Stage: <name> keyword to the definition file header and the from <stage name> option/argument pair to the %files section to support multistage builds

• Deprecated / removed commands

  • The --token/-t option has been deprecated in favor of the singularity remote command group

• Changed defaults / behaviors

  • Ask to confirm password on a newly generated PGP key
  • Prompt to push a key to the KeyStore when generated
  • Refuse to push an unsigned container unless overridden with --allow-unauthenticated/-U option
  • Warn and prompt when pulling an unsigned container without the --allow-unauthenticated/-U option For more information check: https://github.com/sylabs/singularity/blob/release-3.2/CHANGELOG.md

Updated to singularity v3.1.1:

• New Commands

  • New hidden buildcfg command to display compile-time parameters
  • Added support for LDFLAGS, CFLAGS, CGO_ variables in build system
  • Added --nocolor flag to Singularity client to disable color in logging

• Removed Commands

  -…

This update for singularity fixes the following issues:

• New version 3.6.0. This version introduces a new signature format for SIF images, and changes to the signing / verification code to address the following security problems:

  • CVE-2020-13845, boo#1174150 In Singularity 3.x versions below 3.6.0, issues allow the ECL to be bypassed by a malicious user.
  • CVE-2020-13846, boo#1174148 In Singularity 3.5 the --all / -a option to singularity verify returns success even when some objects in a SIF container are not signed, or cannot be verified.
  • CVE-2020-13847, boo#1174152 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.

• New features / functionalities

  • A new '--legacy-insecure' flag to verify allows verification of SIF signatures in the old, insecure format.
  • A new '-l / --logs' flag for instance list that shows the paths to instance STDERR / STDOUT log files.
  • The --json output of instance list now include paths to STDERR / STDOUT log files.
  • Singularity now supports the execution of minimal Docker/OCI containers that do not contain /bin/sh, e.g. docker://hello-world.
  • A new cache structure is used that is concurrency safe on a filesystem that supports atomic rename. If you downgrade to Singularity 3.5 or older after using 3.6 you will need to run singularity cache clean.
  • A plugin system rework adds new hook points that will allow the development of plugins that modify behavior of the runtime. An image driver concept is introduced for plugins to support new ways of handling image and overlay mounts. Plugins built for <=3.5 are not compatible with 3.6.
  • The --bind flag can now bind directories from a SIF or ext3 image into a container.
  • The --fusemount feature to mount filesystems to a container via FUSE drivers is now a supported feature (previously an experimental hidden flag).
  • This permits users to mount e.g. sshfs and cvmfs filesystems to the container at runtime.
  • A new -c/--config flag allows an alternative singularity.conf to be specified by the root user, or all users in an unprivileged installation.
  • A new --env flag allows container environment variables to be set via the Singularity command line.
  • A new --env-file flag allows container environment variables to be set from a specified file.
  • A new --days flag for cache clean allows removal of items older than a specified number of days. Replaces the --name flag which is not generally useful as the cache entries are stored by hash, not a friendly name.

• Changed defaults / behaviours

• New signature format (see security fixes above).

• Fixed spacing of singularity instance list to be dynamically changing based off of input lengths instead of fixed number of spaces to account for long instance names.

• Environment variables prefixed with SINGULARITYENV_ always take precedence over variables without SINGULARITYENV_ prefix.

• The %post build section inherits environment variables from the base image.

• %files from ... will now follow symlinks for sources that are directly specified, or directly resolved from a glob pattern. It will not follow symlinks found through directory traversal. This mirrors Docker multi-stage COPY behaviour.

• Restored the CWD mount behaviour of v2, implying that CWD path is not recreated inside container and any symlinks in the CWD path are not resolved anymore to determine the destination path inside container.

• The %test build section is executed the same manner as singularity test image. --fusemount with the container: default directive will foreground the FUSE process. Use container-daemon: for previous…

These are all security issues fixed in the singularity-3.8.3-1.2 package on the GA media of openSUSE Tumbleweed.