On Tue, Jan 14, 2025 at 01:29:44PM -0800, Kees Cook wrote: > On Tue, Jan 14, 2025 at 12:02:28PM -0800, Isaac Manjarres wrote: > > I think the main issue in the threat model that I described is that > > an attacking process can gain control of a more priveleged process. > > I understood it to be about an attacker gaining execution control through > a rewritten function pointer, not that they already have arbitrary > execution control. (i.e. taking a "jump anywhere" primitive and > upgrading it to "execute anything".) Is the expectation that existing > ROP/JOP techniques make protecting memfd irrelevant? > Is arbitrary execution control necessary? Suppose the attacker overwrites the function pointer that the victim process is supposed to return to. The attacker makes it that the victim process ends up executing code that maps the buffer with PROT_EXEC and then jumps to the buffer to execute the code that was injected. I don't think having the ability to seal memfds against execution on a per-buffer basis entirely addresses that attack. Can't the attacker craft a different type of attack where they instead copy the code they wrote to an executable memfd? I think a way to avoid that would be if the original memfd was write-only to avoid the copy scenario but that is not reasonable. Alternatively, MFD_NOEXEC_SEAL could be extended to prevent executable mappings, and MEMFD_NOEXEC_SCOPE_NOEXEC_ENFORCED could be enabled, but that type of system would prevent memfd buffers from being used for execution for legitimate usecases (e.g. JIT), which may not be desirable. --Isaac
