5 ms·

How do you find those addresses?

by javanix 11y ago

agwa 11y ago
Grep for commit_creds and prepare_kernel_cred in /proc/kallsyms. The address is in the first column.
- fuuuuuuuuu 11y ago
  https://gist.github.com/gcmurphy/1c91644718d28695da2d https://gist.github.com/gcmurphy/1c91644718d28695da2d ^-- this version should do that automatically
wfn 11y ago
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;
- javanix 11y ago
  Thanks, that worked.
- Maran 11y ago
  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?
  - baghira 11y ago
    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).
    - Maran 11y ago
      It is indeed compiled with CONFIG_KEYS=y. Does this protect me against this issue? I'm not sure what this means.
      - baghira 11y ago
        No, 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 ago
        I'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 ago
    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.
    - Maran 11y ago
      As I understand it the whole idea of this exploit is getting sudo access from a normal user. 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?
      - geofft 11y ago
        The file /proc/kallsyms contains the addresses of various kernel functions: it's useful when you've already exploited a vulnerability in the kernel, and you want to do something useful with it, e.g. escalate your userspace process to root. In theory, since you're running code in kernelspace, you can do whatever; in practice it's much easier to start with known functions that can manipulate the data structures for you. Think of it like the manual of a nuclear missile launcher. Obviously they don't want to give that out to everyone. But if you can break into the room with the launcher's control panel, you've still caused a major security breach even if you have no idea what to do next. Having the manual just makes your job easier, but the attack was that you broke in in the first place; they can't count on you being unable to figure out how to work the panel. Also, if you're running a binary kernel (for instance, a kernel built by your Linux distro), the addresses in kallsyms are going to be constant for everyone running that distro. Hiding kallsyms for non-root users is primarily useful for people who build custom kernels. Production-level malware often also has code that doesn't depend on having access to kallsyms and is more advanced (e.g., starting from the system call interrupt vector and disassembling it and seeing what addresses are jumped to). Using kallsyms is good for keeping a simple proof-of-concept exploit readable.
      - javanix 11y ago
        The /proc/kallsyms values are identical across identical kernel compilations. Suppose you have a vulnerable CentOS 7 system that you want to exploit - you could get the proper addresses from your own CentOS 7 VM running the same kernel, apply those to a modified exploit compilation, and run that compilation on your target host.
  - wfn 11y ago
    No, it would seem (I'm not sure though) that this happens for you because your distro is smart enough to have a nice security setting be on by default. The setting / sysctl can be changed at: /proc/sys/kernel/kptr_restrict For me, this gave me 0, but if you cat this it should give you 1. So essentially it's a setting but I'd wager it's not related to you remounting /proc. Just for curiosity's sake, from searching around it seems that this particular security feature (hide kernel pointers for unprivileged users) seems to have originated from this commit (which in itself implements a broader and more general security feature): http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=455cd5ab305c90ffc422dd2e0fb634730942b257 http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.g... - but it's often not enabled. So it's not ASLR or anything to do with filesystem options (per se), but rather a custom "kptr_restrict" kernel vs. userspace security feature provided by the kernel: "[...] The %pK format specifier is designed to hide exposed kernel pointers, specifically via /proc interfaces. Exposing these pointers provides an easy target for kernel write vulnerabilities, since they reveal the locations of writable structures containing easily triggerable function pointers." (Dan Rosenberg, 2011-01-13 - nice.) (Of course if there's no ASLR and one knows which distro is being targeted, it's possible to find those values on another machine and to just bake them into the exploit, as others have pointed out. Also, other channels exist for finding these addresses, etc.)

How do you find those addresses?

by javanix 11y ago

How do you find those addresses?

agwa 11y ago

Grep for commit_creds and prepare_kernel_cred in /proc/kallsyms. The address is in the first column.

fuuuuuuuuu 11y ago
https://gist.github.com/gcmurphy/1c91644718d28695da2d https://gist.github.com/gcmurphy/1c91644718d28695da2d ^-- this version should do that automatically

wfn 11y ago

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;

javanix 11y ago
Thanks, that worked.
Maran 11y ago
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?
- baghira 11y ago
  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).
  - Maran 11y ago
    It is indeed compiled with CONFIG_KEYS=y. Does this protect me against this issue? I'm not sure what this means.
    - baghira 11y ago
      No, 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 ago
        I'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 ago
  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.
  - Maran 11y ago
    As I understand it the whole idea of this exploit is getting sudo access from a normal user. 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?
    - geofft 11y ago
      The file /proc/kallsyms contains the addresses of various kernel functions: it's useful when you've already exploited a vulnerability in the kernel, and you want to do something useful with it, e.g. escalate your userspace process to root. In theory, since you're running code in kernelspace, you can do whatever; in practice it's much easier to start with known functions that can manipulate the data structures for you. Think of it like the manual of a nuclear missile launcher. Obviously they don't want to give that out to everyone. But if you can break into the room with the launcher's control panel, you've still caused a major security breach even if you have no idea what to do next. Having the manual just makes your job easier, but the attack was that you broke in in the first place; they can't count on you being unable to figure out how to work the panel. Also, if you're running a binary kernel (for instance, a kernel built by your Linux distro), the addresses in kallsyms are going to be constant for everyone running that distro. Hiding kallsyms for non-root users is primarily useful for people who build custom kernels. Production-level malware often also has code that doesn't depend on having access to kallsyms and is more advanced (e.g., starting from the system call interrupt vector and disassembling it and seeing what addresses are jumped to). Using kallsyms is good for keeping a simple proof-of-concept exploit readable.
    - javanix 11y ago
      The /proc/kallsyms values are identical across identical kernel compilations. Suppose you have a vulnerable CentOS 7 system that you want to exploit - you could get the proper addresses from your own CentOS 7 VM running the same kernel, apply those to a modified exploit compilation, and run that compilation on your target host.
- wfn 11y ago
  No, it would seem (I'm not sure though) that this happens for you because your distro is smart enough to have a nice security setting be on by default. The setting / sysctl can be changed at: /proc/sys/kernel/kptr_restrict For me, this gave me 0, but if you cat this it should give you 1. So essentially it's a setting but I'd wager it's not related to you remounting /proc. Just for curiosity's sake, from searching around it seems that this particular security feature (hide kernel pointers for unprivileged users) seems to have originated from this commit (which in itself implements a broader and more general security feature): http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=455cd5ab305c90ffc422dd2e0fb634730942b257 http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.g... - but it's often not enabled. So it's not ASLR or anything to do with filesystem options (per se), but rather a custom "kptr_restrict" kernel vs. userspace security feature provided by the kernel: "[...] The %pK format specifier is designed to hide exposed kernel pointers, specifically via /proc interfaces. Exposing these pointers provides an easy target for kernel write vulnerabilities, since they reveal the locations of writable structures containing easily triggerable function pointers." (Dan Rosenberg, 2011-01-13 - nice.) (Of course if there's no ASLR and one knows which distro is being targeted, it's possible to find those values on another machine and to just bake them into the exploit, as others have pointed out. Also, other channels exist for finding these addresses, etc.)