Block access to huge pages in sandboxed processes
Categories
(Core :: Security: Process Sandboxing, enhancement)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox143 | --- | fixed |
People
(Reporter: jld, Assigned: jld)
References
Details
Attachments
(1 file)
Suggested elsewhere by Jann Horn from Project Zero: we could block use of huge pages (as in the 2MB/1GB superpages on amd64) to reduce attack surface: reportedly there's a lot of huge-page-specific code that's not heavily used and there have previously been security issues. Concretely, this is MAP_HUGETLB for mmap and MFD_HUGETLB for memfd_create; I don't see any uses in our code using searchfox, and we probably don't have any indirectly via third-party libraries although it's not impossible.
The mmap and memfd_create man pages incorrectly state that group membership (sysctl vm.hugetlb_shm_group) or the CAP_IPC_LOCK capability (in the initial namespace) is required in order to create a hugetlbfs file this way. In fact, that limitation applies only to shmget. However, it's not possible to actually allocate space in a hugetlbfs file unless the relevant nr_*hugepages* limits are increased from 0 (which seems to be the default), so most users probably aren't exposed. But, more importantly, this means that anything that hypothetically tries to use huge pages will need to handle errors gracefully, which reduces the already-small risk here.
The other thing in this area (thanks to Bugzilla for suggesting bug 770612 as possibly related to this) is transparent huge pages, which seem to have had at least one security bug, but we can't really do anything about that as far as I can tell.
|
Assignee | |
Comment 1•1 year ago
|
||
This blocks the use of MAP_HUGETLB and MFD_HUGETLB for mmap and
memfd_create, respectively. (SHM_HUGETLB for shmget isn't blocked
because we normally block that entire syscall.) This does not affect
transparent hugepages created by the kernel.
|
||
Comment 3•1 year ago
|
||
| bugherder | ||
|
||
Updated•11 months ago
|
Description
•