On 23.01.23 21:46, Edgecombe, Rick P wrote:
On Mon, 2023-01-23 at 11:45 +0100, Florian Weimer wrote:
* David Hildenbrand:
On 19.01.23 22:23, Rick Edgecombe wrote:
The x86 Control-flow Enforcement Technology (CET) feature
includes a new
type of memory called shadow stack. This shadow stack memory has
some
unusual properties, which requires some core mm changes to
function
properly.
Shadow stack memory is writable only in very specific, controlled
ways.
However, since it is writable, the kernel treats it as such. As a
result
there remain many ways for userspace to trigger the kernel to
write to
shadow stack's via get_user_pages(, FOLL_WRITE) operations. To
make this a
little less exposed, block writable GUPs for shadow stack VMAs.
Still allow FOLL_FORCE to write through shadow stack protections,
as
it
does for read-only protections.
So an app can simply modify the shadow stack itself by writing to
/proc/self/mem ?
Is that really intended? Looks like security hole to me at first
sight, but maybe I am missing something important.
Isn't it possible to overwrite GOT pointers using the same vector?
So I think it's merely reflecting the status quo.
There was some debate on this. /proc/self/mem can currently write
through read-only memory which protects executable code. So should
shadow stack get separate rules? Is ROP a worry when you can overwrite
executable code?
The question is, if there is reasonable debugging reason to keep it. I
assume if a debugger would adjust the ordinary stack, it would have to
adjust the shadow stack as well (oh my ...). So it sounds reasonable to
have it in theory at least ... not sure when debugger would support
that, but maybe they already do.
The consensus seemed to lean towards not making special rules for this
case, and there was some discussion that /proc/self/mem should maybe be
hardened generally.
I agree with that. It's a debugging mechanism that a process can abuse
to do nasty stuff to its memory that it maybe shouldn't be able to do ...
--
Thanks,
David / dhildenb
