Date: Mon, 17 Feb 2025 08:03:28 -0800
On Monday, 17 February 2025 02:02:26 Pacific Standard Time Jan Schultke via
Std-Discussion wrote:
> Any bit of code that runs in the address space of your process is able
> to overwrite any memory that's not write-protected.
And it can also make a system call to change from write-protected to writable.
You can even do this with code and make it read-only + executable later again
(q.v. JIT).
There are some OS security mechanisms that will only allow executable pages to
be unmodified from the disk copy, which itself must have some type of
verification. But those are the exception, not the rule, for applications (see
SELinux). But as I noted above, JIT exists and an application that uses JIT
couldn't use this technique. And you don't have to go very far to find JIT
uses, just look at libpcre2.
Std-Discussion wrote:
> Any bit of code that runs in the address space of your process is able
> to overwrite any memory that's not write-protected.
And it can also make a system call to change from write-protected to writable.
You can even do this with code and make it read-only + executable later again
(q.v. JIT).
There are some OS security mechanisms that will only allow executable pages to
be unmodified from the disk copy, which itself must have some type of
verification. But those are the exception, not the rule, for applications (see
SELinux). But as I noted above, JIT exists and an application that uses JIT
couldn't use this technique. And you don't have to go very far to find JIT
uses, just look at libpcre2.
-- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Principal Engineer - Intel DCAI Platform & System Engineering
Received on 2025-02-17 16:03:33