41–50 of 70 posts
Earlier quoted context omitted.
Unfortunately no major distributions ship those patches by default.
Copperhead-os is an open-source android ROM that includes the security features of grsecurity. It runs on nexus-5 and Galaxy-S4. https://copperhead.co/android/ Which of course ,raises the question: Why doesn't Google integrate this into android, or at the very least for a secure/business version of android ?
Earlier quoted context omitted.
By looking at /proc/kallsyms : grep commit_creds /proc/kallsyms grep prepare_kernel_cred /proc/kallsyms Then update addresses as shown in one of the code snippets: _commit_creds commit_creds = 0xffffffff81094250; _prepare_kernel_cred prepare_kernel_cred = 0xffffffff81094550;
Question for you. As a normal user, grepping these values I actually get 0000000000000000. I can't imagine these being the actual values. Is it possible that because I remount my /proc with the hidepid=2 option the values are not visible for normal non-root accounts?
Earlier quoted context omitted.
By looking at /proc/kallsyms : grep commit_creds /proc/kallsyms grep prepare_kernel_cred /proc/kallsyms Then update addresses as shown in one of the code snippets: _commit_creds commit_creds = 0xffffffff81094250; _prepare_kernel_cred prepare_kernel_cred = 0xffffffff81094550;
Question for you. As a normal user, grepping these values I actually get 0000000000000000. I can't imagine these being the actual values. Is it possible that because I remount my /proc with the hidepid=2 option the values are not visible for normal non-root accounts?
Earlier quoted context omitted.
Question for you. As a normal user, grepping these values I actually get 0000000000000000. I can't imagine these being the actual values. Is it possible that because I remount my /proc with the hidepid=2 option the values are not visible for normal non-root accounts?
That only hides the pid directories of others users, and indeed on my system remounting /proc with hidepid=2 I'm still able to see the same values for kallsyms. Maybe your kernel is compiled without the CONFIG_KEYS=y option? (I'm spitballing here).
Earlier quoted context omitted.
Question for you. As a normal user, grepping these values I actually get 0000000000000000. I can't imagine these being the actual values. Is it possible that because I remount my /proc with the hidepid=2 option the values are not visible for normal non-root accounts?
make sure you have privileges to read that file. I ran grep without sudo and got that address on Ubuntu 15.10, but with sudo it will display an actual address.
Exploiting from root to root doesn't make a lot of sense. If the values are not retrievable as normal user this exploit can't be used.. Right?
Is there a reason that there's no overflow check on these refcounts? I suppose it's something like, these are hot paths in general and there's no good hardware support for atomic-increment-if-not-overflow?
Earlier quoted context omitted.
Arch seems to be kosher $ uname -r 4.3.3-2-ARCH No root: $ ./cve_2016_0728 PP_KEY uid=1000, euid=1000 Increfing... finished increfing forking... finished forking caling revoke... uid=1000, euid=1000 Only took about 25 minutes on a Lenovo core i7. That's kind of scary. EDIT: Actually it seems that atomic_t is 64 bits long with x86_64 these days, so no hope of overflowing.
Arch is not kosher. You need to do this: https://news.ycombinator.com/item?id=10931954
include/asm-generic/atomic-long.h:
#if BITS_PER_LONG == 64
typedef atomic64_t atomic_long_t;
...
#else
typedef atomic_t atomic_long_t;
EDIT: No, I was wrong. atomic_t is 32 bits also with 64 bit architecture. Must be something else then, let's see.
Earlier quoted context omitted.
Is SMAP required for mitigation, or is SMEP enough? IIUC SMEP is on Sandy Bridge processors too.
According the lwn comments it should be sufficient (and the post by perception-point suggests that it would at least make things more difficult), but I haven't the hardware to test for myself.
EDIT:
[chris@f23m cve20160728]$ ./cve_2016_0728 PP_KEY
uid=1000, euid=1000
Increfing...
finished increfing
forking...
finished forking
caling revoke...
uid=1000, euid=1000
sh-4.3$Earlier quoted context omitted.
Arch Linux does: https://www.archlinux.org/packages/?name=linux-grsec
> by default Arch don't even have coreutils "by default". Yes, I know, you're supposed to install them anyway, but if you follow the standard install guide, there is no GRsec.