Re: Hurd and trust relationship with file system translators
Samuel Thibault <[email protected]>
| Newsgroups | gmane.os.hurd.cvs,gmane.comp.lib.glibc.alpha |
|---|---|
| Organization | I am not organized |
| Message-ID | <apXwootOMkl3Vuiy@end> |
Hello, Florian Weimer, le ven. 07 août 2026 18:40:00 +0200, a ecrit: > We're sitting on a bunch of Hurd-specific bug reports that concern the > interaction with file system translators across trust boundaries. Thanks for this! > One specific example (RHEL-216329) is in > sysdeps/mach/hurd/readdir64.c, where a comment says: > > /* We trust the filesystem to return correct data and so we > ignore NENTRIES. */ > > In contrast, the report claims we have to validate the data because we > can't trust the translator: > > | Summary: OOB Read in GNU/Hurd `readdir64` / `readdir64_r` due to missing > | per-record bounds checks: malformed directory records returned by a > | GNU/Hurd filesystem server or translator can be consumed without validating > | record boundaries, leading to out-of-bounds reads and likely client-process > | crashes. > | Requirements to exploit: An attacker must be able to control or influence a > | GNU/Hurd filesystem server/translator that returns malformed `dir_readdir` > | data, and must cause a target process to enumerate a directory backed by > | that service via `opendir()` and `readdir64()` or `readdir64_r()`. > > Is this accurate, or is this just a misunderstanding of how translators > work and where the trust boundaries are located? In general, we do trust translators, and we do not plan to let users discuss with other users' translators. Checking for incoherencies can still be useful to report errors rather than get odd segfaults. Samuel