And I don't see how looking for two instructions is enough to prevent bypassing of the security, since it seems to assume they have control over mprotect etc, but yet they're not scanning the rw-but-soon-rx maps for mmap/mprotect syscalls that they wouldn't intercept
-
-
Replying to @grsecurity @dwizzzleMSFT
Small correction, we do. In the paper we describe and the sources offer two alternative runtime monitors. One is based on a few kernel changes (lsm hooks) + an LSM module, the other combines p-trace and seccomp to filter for certian syscalls. Or am I missing something?
1 reply 0 retweets 2 likes -
Replying to @ovahldy @dwizzzleMSFT
You're right, missed that part. I still don't think you can get away with avoiding CFI though -- what stops me from having a write() or send() syscall point at a buffer unreadable by the userland thread only by virtue of PKU and just leaking 'protected' memory that way?
2 replies 0 retweets 0 likes -
BTW monitoring mmap/mprotect isn't enough ;) I can mmap a file, have you inspect it and allow it to be made executable, then i can extend it with mremap() to include additional code from the file that you don't inspect. Fill blahdata with a page of As and a page of Bspic.twitter.com/FFQOe4BBfa
1 reply 2 retweets 6 likes -
Replying to @grsecurity @dwizzzleMSFT
Thanks for taking the time. Good catch! You're right that certain system calls like mmap/mprotect/pkey_mprotect/mremap have to be monitored. I'm not sure that we have a complete list in the paper. For instance, we also monitor signal to prevent installing new handlers.
1 reply 0 retweets 1 like -
by the way, I don't think I've seen your paper (or anyone else) mention that you also have to check whether the CS register contains the correct segment selector in code that is equivalent in 32-bit-mode - AFAIK otherwise something like IRET or long jumps can be abused?
1 reply 0 retweets 4 likes -
Greatly appreciate your feedback! I'm not familiar with this style of attack, please elaborate? Do you expect existing 32-bit compatibility libraries in application? I was under the impression that the CS register is preserved across syscalls (=0 for x86-64). Feel free to DM.
1 reply 0 retweets 0 likes -
at least on Linux, the GDT that is used across all processes on the system contains an entry for a 32-bit code segment. so you can abuse an instruction like IRET (which is a single-byte instruction) to switch to 32-bit mode from normal 64-bit code.
1 reply 0 retweets 0 likes -
and afaik WRPKRU is also valid in 32-bit mode. so if you switch to 32-bit with IRET, then jump to WRPKRU, you can get the CPU to reinterpret the following trusted 64-bit code as 32-bit code
1 reply 0 retweets 2 likes -
which I think means that e.g. offsets used for RIP-relative addressing will instead be interpreted as absolute addresses, which is probably not great for the integrity of the trusted code
1 reply 0 retweets 0 likes
so I think you need to either put a guard behind WRPKRU that ensures CS holds the correct selector (0x33) using bitness-invariant code, or ensure that WRPKRU is located above 4GiB (so that it can't be reached in 32-bit mode)
-
-
(IIRC both Xen PV and Virtualbox used the "hide stuff above 4GiB trick" for running paravirtualized 32-bit guests, with the guest kernel in ring 1 - they ensured that the GDT/LDT contained no 32-bit code segments, so it couldn't reach the hypervisor mappings above 4GiB)
2 replies 0 retweets 0 likes -
and I think macOS had a bug where it didn't initialize r8-r15 for 32-bit processes because it assumed that those couldn't access the 64-bit-only registers; so you could leak data by letting a 32-bit task switch to 64-bit with IRET
1 reply 1 retweet 4 likes - 1 more reply
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.