User impersonation for lib9p based 9p fileservers
- 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
- Fix or patch referenced
- 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: yes
- Technical impact: partial
Summary
A bug in the 9p authentication implementation within lib9p allows an attacker with an existing valid user within the configured auth server to impersonate any other valid filesystem user. This is due to lib9p not properly verifying that the uname given in the Tauth and Tattach 9p messages matches the client UID returned from the factotum authentication handshake. The only filesystem making use of these functions within the base 9front systems is the experimental hjfs disk filesystem, other disk filesystems (cwfs and gefs) are not affected by this bug. This bug was inherited from Plan 9 and is present in all versions of 9front and is remedied fully in commit 9645ae07eb66a59015e3e118d0024790c37400da.
Timeline
- CVE published
- CISA SSVC assessment
Exploitation: none · Automatable: yes · Technical impact: partial
- Record last updated
Affected versions
- 9front 9front
Version range not reported