EGI SVG Advisories


Title:   EGI SVG 'ADVISORY'  Singularity File Permission Vulnerability

Date:    2019-12-19

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

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

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
The OSG security team judges this vulnerability to be of moderate impact.


singularity-3.3.0 through 3.5.1


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.


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.



** WHITE information - Limited distribution
  - see for distribution restrictions **


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


Comments or questions should be sent to svg-rat  at

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

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.


[R 1]

[R 2]

[R 3]


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


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


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

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 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,