5 ms·
Well, the exploit doesn't seem to work on my kernel 4.1.0 system, so that's good.
by mnw21cam 11y ago
Well, the exploit doesn't seem to work on my kernel 4.1.0 system, so that's good.
- 16 11y agoDid you update the addresses of commit_creds() and prepare_kernel_cred() to match your running kernel before you compiled/ran it?
- javanix 11y agoHow do you find those addresses?
- agwa 11y agoGrep for commit_creds and prepare_kernel_cred in /proc/kallsyms. The address is in the first column.
- fuuuuuuuuu 11y agohttps://gist.github.com/gcmurphy/1c91644718d28695da2d https://gist.github.com/gcmurphy/1c91644718d28695da2d ^-- this version should do that automatically
- wfn 11y agoBy 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;
- javanix 11y agoThanks, that worked.
- Maran 11y agoQuestion 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?
- baghira 11y agoThat 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).
- Maran 11y agoIt is indeed compiled with CONFIG_KEYS=y. Does this protect me against this issue? I'm not sure what this means.
- baghira 11y agoNo, the bug is in the kernel keyring facility, so if I'm not mistaken compiling with CONFIG_KEYS=n option should protect you (I haven't tested though). As for the /proc/kallsyms, I honestly don't know how come you only get zeroes. EDIT: The obvious question I should have asked is which distro you are running. Also, as others have pointed out, hoping that the attacker can't read kallsyms from the machine he's attacking is not really a good defense plan.
- Maran 11y agoI'm running Ubuntu 14.04 which should be affected. I just hoped it would be harder without having the correct kallsyms version. It seems I will have no options except to reboot my cluster :)
- altendo 11y agomake 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.
- juhanima 11y agoArch 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.
- 16 11y agoArch is not kosher. You need to do this: https://news.ycombinator.com/item?id=10931954 https://news.ycombinator.com/item?id=10931954
- juhanima 11y agoI did. I still maintain that the reason why the exploit doesn't work is this: include/asm-generic/atomic-long.h: #if BITS_PER_LONG == 64 typedef atomic64_t atomic_long_t; ... #else typedef atomic_t atomic_long_t; Just checking it with a 32-bit VM with the latest upstream kernel. EDIT: No, I was wrong. atomic_t is 32 bits also with 64 bit architecture. Must be something else then, let's see.