[PATCH v2 0/4] [RFC] Implement Trampoline File Descriptor
Madhavan T. Venkataraman
madvenka at linux.microsoft.com
Wed Sep 23 18:32:38 UTC 2020
...
>> The W^X implementation today is not complete. There exist many user level
>> tricks that can be used to load and execute dynamic code. E.g.,
>>
>> - Load the code into a file and map the file with R-X.
>>
>> - Load the code in an RW- page. Change the permissions to R--. Then,
>> change the permissions to R-X.
>>
>> - Load the code in an RW- page. Remap the page with R-X to get a separate
>> mapping to the same underlying physical page.
>>
>> IMO, these are all security holes as an attacker can exploit them to inject
>> his own code.
>
> IMO, you are smoking crack^H^H very seriously misunderstanding what
> W^X is supposed to protect from.
>
> W^X is not supposed to protect you from attackers that can already do
> system calls. So loading code into a file then mapping the file as R-X
> is in no way security hole in W^X.
>
> If you want to provide protection from attackers that _can_ do system
> calls, fine, but please don't talk about W^X and please specify what
> types of attacks you want to prevent and why that's good thing.
>
There are two things here - the idea behind W^X and the current realization
of that idea in actual implementation. The idea behind W^X, as I understand,
is to prevent a user from loading arbitrary code into a page and getting it
to execute. If the user code contains a vulnerability, an attacker can
exploit it to potentially inject his own code and get it to execute. This
cannot be denied.
>From that perspective, all of the above tricks I have mentioned are tricks
that user code can use to load arbitrary code into a page and get it to
execute.
Now, I don't want the discussion to be stuck in a mere name. If what I am
suggesting needs a name other than "W^X" in the opinion of the reviewers,
that is fine with me. But I don't believe there is any disagreement that
the above user tricks are security holes.
Madhavan
More information about the Linux-security-module-archive
mailing list