linux-kernel - Re: [RFC PATCH v1 1/2] mm/memfd: Add support for F_SEAL_FUTURE

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <Z4boRqW9Gv57GDzu@google.com>
Date: Tue, 14 Jan 2025 14:42:14 -0800
From: Isaac Manjarres <isaacmanjarres@...gle.com>
To: Kees Cook <kees@...nel.org>
Cc: Jeff Xu <jeffxu@...omium.org>,
	Lorenzo Stoakes <lorenzo.stoakes@...cle.com>,
	Jann Horn <jannh@...gle.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Jeff Layton <jlayton@...nel.org>,
	Chuck Lever <chuck.lever@...cle.com>,
	Alexander Aring <alex.aring@...il.com>,
	"Liam R. Howlett" <Liam.Howlett@...cle.com>,
	Vlastimil Babka <vbabka@...e.cz>, Shuah Khan <shuah@...nel.org>,
	kernel-team@...roid.com, linux-mm@...ck.org,
	linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org,
	linux-kselftest@...r.kernel.org,
	Suren Baghdasaryan <surenb@...gle.com>,
	Kalesh Singh <kaleshsingh@...gle.com>,
	John Stultz <jstultz@...gle.com>
Subject: Re: [RFC PATCH v1 1/2] mm/memfd: Add support for F_SEAL_FUTURE_EXEC
 to memfd

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