We're sitting on a bunch of Hurd-specific bug reports that concern the
interaction with file system translators across trust boundaries. 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?
On Linux, we would have this very issue with FUSE and specifically its
ioctl implementation (yes, you can emulate ioctls that have pointers in
the payload with FUSE), which is why FUSE blocks cross-user access to
these special file systems. For example, a process running as root
cannot accidentally descend into a FUSE file system implemented by
another user.
I've been instructed to mention this: Found by AISLE in partnership with
Red Hat.
Thanks,
Florian
