Re: [RFC PATCH v1 1/2] mm/memfd: Add support for F_SEAL_FUTURE_EXEC to memfd

[Isaac Manjarres <isaacmanjarres@google.com>]

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