linux-kernel - Re: [RFC, PATCH] pagemap: do not leak physical addresses to non-privileged userspace

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 16 Mar 2015 18:21:44 -0700
From:	Andy Lutomirski <luto@...capital.net>
To:	Mark Seaborn <mseaborn@...omium.org>
Cc:	Pavel Machek <pavel@....cz>,
	"Kirill A. Shutemov" <kirill@...temov.name>,
	"linux-mm@...ck.org" <linux-mm@...ck.org>,
	kernel list <linux-kernel@...r.kernel.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	"Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>,
	Pavel Emelyanov <xemul@...allels.com>,
	Konstantin Khlebnikov <khlebnikov@...nvz.org>
Subject: Re: [RFC, PATCH] pagemap: do not leak physical addresses to
 non-privileged userspace

On Mon, Mar 16, 2015 at 5:49 PM, Mark Seaborn <mseaborn@...omium.org> wrote:
> On 16 March 2015 at 14:11, Pavel Machek <pavel@....cz> wrote:
>> On Mon 2015-03-09 23:11:12, Kirill A. Shutemov wrote:
>> > From: "Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>
>> >
>> > As pointed by recent post[1] on exploiting DRAM physical imperfection,
>> > /proc/PID/pagemap exposes sensitive information which can be used to do
>> > attacks.
>> >
>> > This is RFC patch which disallow anybody without CAP_SYS_ADMIN to read
>> > the pagemap.
>> >
>> > Any comments?
>> >
>> > [1] http://googleprojectzero.blogspot.com/2015/03/exploiting-dram-rowhammer-bug-to-gain.html
>>
>> Note that this kind of attack still works without pagemap, it just
>> takes longer. Actually the first demo program is not using pagemap.
>
> That depends on the machine -- it depends on how bad the machine's
> DRAM is, and whether the machine has the 2x refresh rate mitigation
> enabled.
>
> Machines with less-bad DRAM or with a 2x refresh rate might still be
> vulnerable to rowhammer, but only if the attacker has access to huge
> pages or to /proc/PID/pagemap.
>
> /proc/PID/pagemap also gives an attacker the ability to scan for bad
> DRAM locations, save a list of their addresses, and exploit them in
> the future.
>
> Given that, I think it would still be worthwhile to disable /proc/PID/pagemap.

Having slept on this further, I think that unprivileged pagemap access
is awful and we should disable it with no option to re-enable.  If we
absolutely must, we could allow programs to read all zeros or to read
addresses that are severely scrambled (e.g. ECB-encrypted by a key
generated once per open of pagemap).

Pagemap is awful because:

 - Rowhammer.

 - It exposes internals that users have no business knowing.

 - It could easily leak direct-map addresses, and there's a nice paper
detailing a SMAP bypass using that technique.

Can we just try getting rid of it except with global CAP_SYS_ADMIN.

(Hmm.  Rowhammer attacks targeting SMRAM could be interesting.)

>
>
>> Can we do anything about that? Disabling cache flushes from userland
>> should make it no longer exploitable.
>
> Unfortunately there's no way to disable userland code's use of
> CLFLUSH, as far as I know.
>
> Maybe Intel or AMD could disable CLFLUSH via a microcode update, but
> they have not said whether that would be possible.

The Intel people I asked last week weren't confident.  For one thing,
I fully expect that rowhammer can be exploited using only reads and
writes with some clever tricks involving cache associativity.  I don't
think there are any fully-associative caches, although the cache
replacement algorithm could make the attacks interesting.

--Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/