Jump to navigation Jump to search
The printable version is no longer supported and may have rendering errors. Please update your browser bookmarks and please use the default browser print function instead.
|Main page||Software Security Checklist||Issue Handling||Advisories||Notes On Risk||Advisory Template||More|
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://wiki.egi.eu/wiki/EGI_CSIRT:TLP for distribution restrictions ** URL: https://wiki.egi.eu/wiki/SVG: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,