Full Disclosure mailing list archives
Re: From kernel memory disclosure to privilege escalation: when and how?
From: Dan Rosenberg <dan.j.rosenberg () gmail com>
Date: Fri, 24 Jun 2011 00:10:59 -0400
2011/6/23 アドリアンヘンドリック <unixfreaxjp22 () gmail com>:
Well, first of all, this is the Dan Rosenberg's specialty. I just try to comment so hope the snowball rolls.
Ok, you got my attention.
Hello! Could somebody write what threats there are when kernel memory disclosure is found? I mean not along with another bug (since kmem disclosure could lead to some interesting pointers addresses and values, etc), but only itself!?
As with userland exploitation, many kernel memory disclosure vulnerabilities don't have much inherent value on their own, but become useful when used in conjunction with other vulnerabilities. These types of leaks, including leakage of data via uninitialized structure members, for example, may be necessary in order to exploit more hardened kernel environments that don't expose as much information about kernel internals via public interfaces. On most vanilla (upstream) kernels, this isn't really necessary, because of the amount of useful targeting information is exported via e.g. the proc filesystem.
I guess it could lead to /etc/shadow disclosure, if some suid programs accessing it would be running in the background (chsh, for example). Is it correct? BTW, when chsh and other programs-accessing-shadow-file are running, where do they store the /etc/shadow content? On the kernel stack in it's thread_union, or somewhere else?
Sure, this is definitely possible - it really depends on the nature of the memory disclosure. If you've got a leak of uninitialized stack bytes, it's very unlikely you'll be able to get any immediately useful information (besides what can be used to target other vulnerabilities). If you've got a leak of a few bytes past the end of a structure allocated in a slab cache (via kmalloc), then you're going to be limited in what you can retrieve based on what other allocations are placed in that same slab cache. Assuming you have a somewhat targeted or large leak, however, disclosing file contents is definitely possible and is probably your best bet for privilege escalation. Where file contents actually touch kernel memory will depend on the implementation of the specific filesystem you're using - the actual read() system call doesn't do anything in the VFS layer that would cause kernel memory to contain file data, but most filesystem-specific implementation of the read file operation will cause that file data to touch kernel memory in some way, typically either in smaller blocks on the kernel heap or in filesystem cache layers. So you could run a program like chsh and dump the entire kernel address space, and you're likely to find /etc/shadow in there somewhere. Your mileage may vary with smaller leaks.
So, besides /etc/shadow disclosure, are there any significant places, where kernel memory disclosure could lead to very likely privilege escalation?
I think it's mostly up to your imagination and depends on what information is available on the system could potentially compromise it. Are there SSH keys? Can you cause any processes on the machine to read private keys and dump kernel memory immediately after those keys are read? If it's on disk and you can cause something to read it, and if you have a sufficiently flexible kernel memory disclosure, you can generally get at it. -Dan _______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Current thread:
- From kernel memory disclosure to privilege escalation: when and how? Kevin Johnson (Jun 23)
- <Possible follow-ups>
- Re: From kernel memory disclosure to privilege escalation: when and how? アドリアンヘンドリック (Jun 23)
- Re: From kernel memory disclosure to privilege escalation: when and how? Dan Rosenberg (Jun 23)