Message-ID: <BANLkTi=D+VA9Tjodng_953BH_sfAmvxDxA@mail.gmail.com>
Date: Fri, 24 Jun 2011 12:27:32 +0900
From: アドリアンヘンドリック
	<unixfreaxjp22@...il.com>
To: full-disclosure@...ts.grok.org.uk
Subject: Re: From kernel memory disclosure to privilege
	escalation: when and how?

Well, first of all, this is the Dan Rosenberg's specialty. I just try
to comment so hope the snowball rolls.

AFAIK, most of linux kernel's memory disclosure vulnerability goes
with the same 'ol line similar to this "Some vulnerabilities have been
reported in the Linux Kernel, which potentially can be exploited by
malicious, local users to disclose kernel memory or gain escalated
privileges."

For your question number one, when kernel memory disclosure is found
what will be the threat?

Depends on the nature of the bug, but most of the impact of memory
disclosure may lead to gain escalated privileges in many ways, not
only the /etc/shadow. So the impact possibility is huge.

For first example, see the pktcdvd Memory Disclosure which disclosed a
year ago by Dan as reference:
http://jon.oberheide.org/blog/2010/10/23/linux-kernel-pktcdvd-memory-disclosure/
As you can see, in this case the threat vector is: "This can be
exploited by users with
permission to open /dev/pktcdvd/control (on many distributions, this is
readable by group "cdrom")."

Also please look at the second example: "Linux Kernel DCCP Memory Disclosure":
http://www.securityfocus.com/archive/1/archive/1/463934/100/0/threaded
credit: Przemyslaw Frasunek, Pawel Pisarczyk & Robert Swieck
In this bug, the privileges threat vector is susceptible to a locally
exploitable flaw
which may allow local users to steal data from the kernel memory.

There are many more example like this.., so like I said previously the
Linux Kernel Memory Disclosure may lead to many privilege escalation
cases, but not specifically the direct relation to /etc/shadow


So, the next question is: when and where /etc/shadow affected by
kernel memory disclosure?
When the kernel memory disclosure bug reproduced, most of the dump
data show the memory contents, that's WHEN the escalation privilege
data can be shown & stolen. HOW? depened the nature of the flaw
itself, for instance, please see the POC made by the above second
example above, if you build the POC correctly & run it to the correct
environment you will find cached disk blocks in the dump data which
you will see the /etc/shadow and others like tty buffers :-)
It's a straight answer idn't it?

Again, this topic is the Dan Rosenberg's expertise. I think he can
answer your questions deeper & better.
FYI, His vulnerability credits, as reference related to this questions
are in this page:
http://osvdb.org/creditees/4839-dan-rosenberg
List of his research for this topic can be viewed here, may you find
something in there beforehand..
http://vulnfactory.org/vulns/
Just in case, I sent him the cc for your questions to be answered by
him directly if he's willing to.

Best Regards,

---
Hendrik ADRIAN
Zero Day Japan Security Research http://www.0day.jp
Twitter: @unixfreaxjp
http://www.kljtech.com


----in reply to----
From: Kevin Johnson <kevjohnson71 () yahoo com>
Date: Thu, 23 Jun 2011 02:53:21 -0700 (PDT)

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!?
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?

So, besides /etc/shadow disclosure, are there any significant places,
where kernel memory disclosure could lead to very
likely privilege escalation?

Thank you.

_______________________________________________
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