Message-ID: <BANLkTinmoWPHAkkRhYur7pkHz+EoLNgrgw@mail.gmail.com>
Date: Fri, 24 Jun 2011 00:10:59 -0400
From: Dan Rosenberg <dan.j.rosenberg@...il.com>
To: アドリアンヘンドリック
	<unixfreaxjp22@...il.com>
Cc: full-disclosure@...ts.grok.org.uk
Subject: Re: From kernel memory disclosure to privilege
	escalation: when and how?

2011/6/23 アドリアンヘンドリック <unixfreaxjp22@...il.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/

Powered by blists - more mailing lists