Lol your a savage spender
-
-
Replying to @dwizzzleMSFT
Not trying to be, I looked at the paper and didn't see what all the hype was about. The press coverage was misleading, trying to make it sound like it was MPK that nobody could use in a performant way, but the paper was talking about alternative methods (hypervisors etc)
2 replies 0 retweets 1 like -
Replying to @grsecurity @dwizzzleMSFT
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
2 replies 0 retweets 2 likes -
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
-
-
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)
1 reply 0 retweets 1 like - 3 more replies
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.