[PATCH RFC] mm: protect suid binaries against rowhammer with copy-on-read mappings

[PATCH RFC] mm: protect suid binaries against rowhammer with copy-on-read mappings

[Konstantin Khlebnikov]

From: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>

Each user gets private copy of the code thus nobody will be able to exploit
pages in the page cache. This works for statically-linked binaries. Shared
libraries are still vulnerable, but setting suid bit will protect them too.

[1] http://googleprojectzero.blogspot.com/2015/03/exploiting-dram-rowhammer-bug-to-gain.html

Signed-off-by: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
---
 include/linux/mm.h |    1 +
 mm/memory.c        |    4 ++--
 mm/mmap.c          |   11 +++++++++++
 3 files changed, 14 insertions(+), 2 deletions(-)

diff --git a/include/linux/mm.h b/include/linux/mm.h
index 47a9392..25edb4a 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -123,6 +123,7 @@ extern unsigned int kobjsize(const void *objp);
 #define VM_MAYSHARE	0x00000080
 
 #define VM_GROWSDOWN	0x00000100	/* general info on the segment */
+#define VM_COR		0x00000200	/* copy-on-read */
 #define VM_PFNMAP	0x00000400	/* Page-ranges managed without "struct page", just pure PFN */
 #define VM_DENYWRITE	0x00000800	/* ETXTBSY on write attempts.. */
 
diff --git a/mm/memory.c b/mm/memory.c
index 411144f..a3c1064 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -2904,7 +2904,7 @@ static int do_cow_fault(struct mm_struct *mm, struct vm_area_struct *vma,
 		}
 		goto uncharge_out;
 	}
-	do_set_pte(vma, address, new_page, pte, true, true);
+	do_set_pte(vma, address, new_page, pte, vma->vm_flags & VM_WRITE, true);
 	mem_cgroup_commit_charge(new_page, memcg, false);
 	lru_cache_add_active_or_unevictable(new_page, vma);
 	pte_unmap_unlock(pte, ptl);
@@ -3002,7 +3002,7 @@ static int do_fault(struct mm_struct *mm, struct vm_area_struct *vma,
 			- vma->vm_start) >> PAGE_SHIFT) + vma->vm_pgoff;
 
 	pte_unmap(page_table);
-	if (!(flags & FAULT_FLAG_WRITE))
+	if (!(flags & FAULT_FLAG_WRITE) && !(vma->vm_flags & VM_COR))
 		return do_read_fault(mm, vma, address, pmd, pgoff, flags,
 				orig_pte);
 	if (!(vma->vm_flags & VM_SHARED))
diff --git a/mm/mmap.c b/mm/mmap.c
index da9990a..a91dd2b 100644
--- a/mm/mmap.c
+++ b/mm/mmap.c
@@ -1354,6 +1354,17 @@ unsigned long do_mmap_pgoff(struct file *file, unsigned long addr,
 		default:
 			return -EINVAL;
 		}
+
+		/*
+		 * Read-only SUID/SGID binares are mapped as copy-on-read
+		 * this protects them against exploiting with Rowhammer.
+		 */
+		if (!(file->f_mode & FMODE_WRITE) &&
+		    ((inode->i_mode & S_ISUID) || ((inode->i_mode & S_ISGID) &&
+			    (inode->i_mode & S_IXGRP)))) {
+			vm_flags &= ~(VM_SHARED | VM_MAYSHARE);
+			vm_flags |= VM_COR;
+		}
 	} else {
 		switch (flags & MAP_TYPE) {
 		case MAP_SHARED:

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH RFC] mm: protect suid binaries against rowhammer with copy-on-read mappings

[Kirill A. Shutemov]

On Wed, Mar 18, 2015 at 11:30:40AM +0300, Konstantin Khlebnikov wrote:
> From: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
> 
> Each user gets private copy of the code thus nobody will be able to exploit
> pages in the page cache. This works for statically-linked binaries. Shared
> libraries are still vulnerable, but setting suid bit will protect them too.

Hm. Do we have suid/sgid semantic defiend for non-executables?

To me we should do this for all file private mappings of the suid process
or don't do it at all.

And what about forked suid process which dropped privilages. We still have
code pages shared.

I don't think it worth it. The only right way to fix the problem is ECC
memory.

-- 
 Kirill A. Shutemov

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH RFC] mm: protect suid binaries against rowhammer with copy-on-read mappings

[Konstantin Khlebnikov]

On 18.03.2015 12:57, Kirill A. Shutemov wrote:
> On Wed, Mar 18, 2015 at 11:30:40AM +0300, Konstantin Khlebnikov wrote:
>> From: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
>>
>> Each user gets private copy of the code thus nobody will be able to exploit
>> pages in the page cache. This works for statically-linked binaries. Shared
>> libraries are still vulnerable, but setting suid bit will protect them too.
>
> Hm. Do we have suid/sgid semantic defiend for non-executables?
>
> To me we should do this for all file private mappings of the suid process
> or don't do it at all.

Yeah, this patch doesn't provide full protection.
That's just a proof-of-concept.

>
> And what about forked suid process which dropped privilages. We still have
> code pages shared.

User can get access to that private copy later but new suid
applications will get their own copy at exec.
Original page-cache pages are never exposed in pte.

>
> I don't think it worth it. The only right way to fix the problem is ECC
> memory.
>

ECC seems good protection until somebody figure out how to break it too.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH RFC] mm: protect suid binaries against rowhammer with copy-on-read mappings

[Dave Hansen]

On 03/18/2015 01:30 AM, Konstantin Khlebnikov wrote:
> +		/*
> +		 * Read-only SUID/SGID binares are mapped as copy-on-read
> +		 * this protects them against exploiting with Rowhammer.
> +		 */
> +		if (!(file->f_mode & FMODE_WRITE) &&
> +		    ((inode->i_mode & S_ISUID) || ((inode->i_mode & S_ISGID) &&
> +			    (inode->i_mode & S_IXGRP)))) {
> +			vm_flags &= ~(VM_SHARED | VM_MAYSHARE);
> +			vm_flags |= VM_COR;
> +		}

I think we probably need to come to _some_ sort of understanding in the
kernel of how much we are willing to do to thwart these kinds of
attacks.  I suspect it's a very deep rabbit hole.

For this particular case, I don't see how this would be effective.  The
existing exploit which you reference attacks PTE pages which are
unmapped in to the user address space.  I'm confused how avoiding
mapping a page in to an attacker's process can keep it from being exploited.

Right now, there's a relatively small number of pages that will get
COW'd for a SUID binary.  This greatly increases the number which could
allow spraying of these (valuable) copy-on-read pages.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH RFC] mm: protect suid binaries against rowhammer with copy-on-read mappings

[Konstantin Khlebnikov]

On Wed, Mar 18, 2015 at 5:11 PM, Dave Hansen <dave.hansen@intel.com> wrote:
> On 03/18/2015 01:30 AM, Konstantin Khlebnikov wrote:
>> +             /*
>> +              * Read-only SUID/SGID binares are mapped as copy-on-read
>> +              * this protects them against exploiting with Rowhammer.
>> +              */
>> +             if (!(file->f_mode & FMODE_WRITE) &&
>> +                 ((inode->i_mode & S_ISUID) || ((inode->i_mode & S_ISGID) &&
>> +                         (inode->i_mode & S_IXGRP)))) {
>> +                     vm_flags &= ~(VM_SHARED | VM_MAYSHARE);
>> +                     vm_flags |= VM_COR;
>> +             }
>
> I think we probably need to come to _some_ sort of understanding in the
> kernel of how much we are willing to do to thwart these kinds of
> attacks.  I suspect it's a very deep rabbit hole.
>
> For this particular case, I don't see how this would be effective.  The
> existing exploit which you reference attacks PTE pages which are
> unmapped in to the user address space.  I'm confused how avoiding
> mapping a page in to an attacker's process can keep it from being exploited.
>
> Right now, there's a relatively small number of pages that will get
> COW'd for a SUID binary.  This greatly increases the number which could
> allow spraying of these (valuable) copy-on-read pages.

Yeah, on second thought that copy-on-read gives the same security
level as hiding pfns from userspace. Sorry for the noise.

It seems the only option is memory zoning: kernel should allocate all
normal memory for userspace from isolated area which is kept far far
away from important data.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH RFC] mm: protect suid binaries against rowhammer with copy-on-read mappings

[Dave Hansen]

On 03/18/2015 08:08 AM, Konstantin Khlebnikov wrote:
> It seems the only option is memory zoning: kernel should allocate all
> normal memory for userspace from isolated area which is kept far far
> away from important data.

Yeah, except that the kernel has a pretty hard time telling which data
is important.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH RFC] mm: protect suid binaries against rowhammer with copy-on-read mappings

[Vlastimil Babka]

On 03/18/2015 12:41 PM, Konstantin Khlebnikov wrote:
> On 18.03.2015 12:57, Kirill A. Shutemov wrote:
>>
>> I don't think it worth it. The only right way to fix the problem is ECC
>> memory.
>>
> 
> ECC seems good protection until somebody figure out how to break it too.

I doubt that kind of attitude can get us very far. If we can't trust the
hardware, we lose sooner or later.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH RFC] mm: protect suid binaries against rowhammer with copy-on-read mappings

[Konstantin Khlebnikov]

On 19.03.2015 16:04, Vlastimil Babka wrote:
> On 03/18/2015 12:41 PM, Konstantin Khlebnikov wrote:
>> On 18.03.2015 12:57, Kirill A. Shutemov wrote:
>>>
>>> I don't think it worth it. The only right way to fix the problem is ECC
>>> memory.
>>>
>>
>> ECC seems good protection until somebody figure out how to break it too.
>
> I doubt that kind of attitude can get us very far. If we can't trust the
> hardware, we lose sooner or later.
>

Obviously ECC was designed for protecting against cosmic rays which 
flips several bits. If attacker modifies whole cacheline he can chose
value which have the same ECC. I hope next generation of DRAM (or PRAM)
wouldn't be affected.

Software solution is possible: we can put untrusted applications into
special ghetto memory zone. This is relatively easy for virtual 
machines. And it seems might work for normal tasks too (page-cache
pages should be doubled or handled in the way similar to copy-on-read
from that patch).

-- 
Konstantin

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>