EGI SVG Advisories

Advisory-SVG-CVE-2019-19724

Title:   EGI SVG 'ADVISORY'  Singularity File Permission Vulnerability
         [EGI-SVG-CVE-2019-19724]

Date:    2019-12-19
Updated:


Affected software and risk
==========================

Vulnerability concerning Singularity

Package : Singularity
CVE     : CVE-2019-19724

A file permission issue has been found in Singularity, in which
$HOME/.singularity is created mode 777 in some circumstances. [R 1] This may
allow anyone with login access to the host to modify container images and have
malicious container images executed on behalf of affected users.

Actions required/recommended
============================

Sites running Singularity should check the current installation of Singularity.

Ideally all sites should update to release 3.5.2.

If this is not practical in the short term, the checks/actions below may be
sufficient.

Check/actions on current installation
=====================================

Check which version of Singularity is currently installed, if any.

If the version is NOT between 3.3.0 and 3.5.1 then the system is not
vulnerable.

Check the permission on .singularity directories, for example like this:

    find /home/*/.singularity -maxdepth 0 -perm -777 -ls

If any are mode 777 then further checks should be carried out.

See whether there are any entries below them owned by another user.

If so, the directory would have been tampered with. In such a case, besides a
cleanup of the given directory, any copies of potentially affected images might
have to be removed.

Set the permission to 700 on all affected '.singularity' directories.

As new users could still run any affected Singularity version later (in
unprivileged mode), this recipe will only catch existing cases, if any.

For more information see the OSG information below.

Component installation information
==================================

The latest release may be installed from GitHub [R 1]

The fixed version of Singularity is NOT yet in EPEL [R 2]

Affected software details
=========================

This is fixed in singularity version 3.5.2.

Singularity Versions from 3.3.0 to 3.5.1 contain this vulnerability.

Other information
=================

While some LHC experiments and possibly other VOs prefer using Singularity from
CVMFS in their grid jobs, there may still be many sites with local installation
for various reasons.  Here we are less concerned with Worker Nodes, but more
with shared login hosts on which users can build their own images.

For more information see the OSG information below.

OSG information
===============

A publicly announced vulnerability in singularity can leave the
$HOME/.singularity directory open to tampering by other people with login
access.  For people who build container images this can result in the
possibility of a malicious person modifying the contents of those container
images.
The OSG security team judges this vulnerability to be of moderate impact.

IMPACTED VERSIONS:

singularity-3.3.0 through 3.5.1

WHAT ARE THE VULNERABILITIES:

When creating the $HOME/.singularity directory, singularity-3.3.0 through 3.5.1
sets the permissions on the directory to mode 777.  Singularity keeps caches of
docker layers and other things in subdirectories of that directory, so it is
possible for someone with login access to the same system to modify those
caches and for the modified contents to make it into another container image
the owner of the directory makes later.
 People who used an older version of singularity earlier are not affected
 because $HOME/.singularity would have been created with correct permissions.
 People whose home directories are not searchable by others (e.g. mode 700) are
 also not vulnerable.

WHAT YOU SHOULD DO:

System administrators that have a vulnerable version of singularity installed,
have users that build singularity images, and have open home directory
permissions should remove any group and other write permission from the users'
$HOME/.singularity directories, and upgrade to singularity-3.5.2 when it
becomes available.  Since subdirectories and files are created with correct
permissions, if any tampering had been done it should be evident because there
would be directories and files owned by someone else. For example, someone
could rename the cache subdirectory and create a new one.

RELATED LINKS

https://github.com/sylabs/singularity/releases/tag/v3.5.2


TLP and URL
===========

** WHITE information - Limited distribution
  - see https://go.egi.eu/tlp for distribution restrictions **

URL:   https://advisories.egi.eu/Advisory-SVG-CVE-2019-19724

Minor updates may be made without re-distribution to the sites

Comments
========

Comments or questions should be sent to svg-rat  at  mailman.egi.eu

If you find or become aware of another vulnerability which is relevant to EGI
you may report it by e-mail to

report-vulnerability at egi.eu

the EGI Software Vulnerability Group will take a look according to the
procedure defined in [R 3]

Note that this is undergoing revision to fully handle vulnerabilities in the
EOSC-hub era.


References
==========

[R 1] https://github.com/sylabs/singularity/releases/tag/v3.5.2

[R 2] https://dl.fedoraproject.org/pub/epel/7/x86_64/Packages/s/

[R 3] https://documents.egi.eu/public/ShowDocument?docid=3145

Credit
======

SVG was alerted to this vulnerability by Dave Dykstra (FNAL & OSG)

Timeline
========

Yyyy-mm-dd  [EGI-SVG-2019-CVE-2019-19724]

2019-12-17 SVG alerted to this issue by Dave Dykstra
2019-12-17 Acknowledgement from the EGI SVG to the reporter
2019-12-17 Issue fixed in GitHub by Singularity team
2019-12-19 Advisory sent to sites

Context
=======

This advisory has been prepared as part of the effort to fulfil EGI SVG's
purpose "To minimize the risk to the EGI infrastructure arising from software
vulnerabilities"

The risk is that assessed by the group, according to the EGI SVG issue handling
procedure [R 3]  in the context of how the software is used in the EGI
infrastructure. It is the opinion of the group, we do not guarantee it to be
correct. The risk may also be higher or lower in other deployments depending on
how the software is used.

Others may re-use this information provided they:-

1) Respect the provided TLP classification

2) Credit the EGI https://www.egi.eu/ Software Vulnerability Group

Note that the SVG issue handling procedure is currently under review, to take
account of the increasing inhomogeneity of the EGI infrastructure and the
services in the EOSC-hub catalogue.

On behalf of the EGI SVG,