Singularity: Incorrect path matching for 'limit container paths' directive
- Published
- Last modified
- Where the record stands: published, rejected by its publisher, or superseded by another id.What do these mean? →
- published
- Whether CISA lists it in its Known Exploited Vulnerabilities catalog: proof that attackers are using it.What do these mean? →
- Not listed in CISA KEV
- Fix
- Fixed in 4.4.2, 4.1.14, 4.3.9
- Whether working attack code is public (Exploit-DB, Metasploit, Nuclei or GitHub). Public code makes attacks easier.What do these mean? →
- None on Exploit-DB, Metasploit or GitHub
- Exploitation: none
- Automatable: no
- Technical impact: partial
Summary
SingularityCE and SingularityPRO are open source container platforms. Prior to SingularityCE 4.4.2 and SingularityPRO 4.3.9 and 4.1.14, incorrect path-string matching in the singularity.conf limit container paths directive allows a container in a sibling directory such as /data/safe-but-unsafe to be run when /data/safe is allowed under setuid mode. This permits a user to run a container from outside the administrator's configured path allowlist. Installations that do not use limit container paths are not affected. This issue is fixed in SingularityCE 4.4.2 and SingularityPRO 4.3.9 and 4.1.14.
Timeline
- CVE published
- CISA SSVC assessment
Exploitation: none · Automatable: no · Technical impact: partial
- Record last updated
Affected versions
- sylabs singularity
fixed in 4.4.2
- sylabs SingularityPRO
fixed in 4.1.14; From 4.2.0 · fixed in 4.3.9
- github.com/sylabs/singularityGo
All versions
- github.com/sylabs/singularity/v4Go
fixed in 4.4.2
- github.com/sylabs/singularityGo
through 3.1.1