mm: protect suid binaries against rowhammer with copy-on-read mappings

From: Konstantin Khlebnikov <[email protected]>

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.

Quoted 5 lines · Konstantin Khlebnikov

From: Konstantin Khlebnikov <[email protected]>

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.

Quoted 4 lines · Kirill A. Shutemov

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.

Quoted 7 lines · Konstantin Khlebnikov

Quoted 4 lines · Kirill A. Shutemov

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.

mm/mmap.c unsigned long do_mmap_pgoff(struct file *file, unsigned long addr, · line 1367

Quoted 10 lines · Konstantin Khlebnikov

mm/mmap.c +10 -0

+             /*
+              * 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.

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.