search

v4ng3l1s / google-security-research

Automatically exported from code.google.com/p/google-security-research
0 stars 0 forks source link

Rowhammer: Linux kernel privilege escalation PoC #283

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
The issue is a placeholder for the PoC for a working Linux privilege escalation 
for the "rowhammer" DRAM vulnerability.

Original issue reported on code.google.com by cev...@google.com on 9 Mar 2015 at 3:23

Attachments:

GoogleCodeExporter commented 9 years ago

Original comment by cev...@google.com on 9 Mar 2015 at 4:02

GoogleCodeExporter commented 9 years ago 
hey guys. Is there guy success this test?
I failed compile.

Original comment by william....@gmail.com on 11 Mar 2015 at 9:13

GoogleCodeExporter commented 9 years ago 
[deleted comment]
GoogleCodeExporter commented 9 years ago 
[deleted comment]
GoogleCodeExporter commented 9 years ago 
I tried running the full demo "run.sh" ( have to run it "sudo" to use KVM), but 
it hangs in "qemu_runner.py", waiting for input to the ReadLines() function.

When I get bored and break out of it, it reports this:
----%>< snip----
...
pte_pages=913408, pte_size=3568 MB, rate=44.5 MB/sec
Running target executable...
Hello world -- in innocent program
Test mode: Flipping bit at address b0702100...
  before:  val=0x8000000057b32027
  after:   val=0x8000000057a32027
  Changed bit 20 to 0
Searching for modified PTE...
  Found at index 0xdf23e20
  In page table 15 (out of 16 per mmap())
  Entry 0 contains 0x0
  Entry 32 contains 0x800000005c329027
Modifying PTE...
Searching for page that uses this PTE...
  Found at index 0xbdc7601
  Points to 0xf000ff53f000ff53
Running target executable...
Escape!

Test mode: Cleaning up: Undoing bit flip
Test mode: Flipping bit at address b0702100...
  before:  val=0x8000000057a32067
  after:   val=0x8000000057b32067
  Changed bit 20 to 1
** exited with status 0 (0x0)
^Cqemu: terminating on signal 2
Traceback (most recent call last):
  File "qemu_runner.py", line 57, in <module>
    Main()
  File "qemu_runner.py", line 45, in Main
    for line in ReadLines(os.fdopen(read_fd, 'r')):
  File "qemu_runner.py", line 11, in ReadLines
    ch = stream.read(1)
KeyboardInterrupt

Original comment by prof.mon...@gmail.com on 14 Mar 2015 at 3:37

GoogleCodeExporter commented 9 years ago 
Hey, prof,mon...
What is your machine(OS, RAM)?

Original comment by william....@gmail.com on 16 Mar 2015 at 3:15

GoogleCodeExporter commented 9 years ago 
> #6 william....@gmail.com
> Hey, prof,mon...
> What is your machine(OS, RAM)?

I built a Linux kernel, 3.19.1, with pretty much stock options except for 
disabling CONFIG_STRICT_DEVMEM (also turned off Bluetooth).  Ran it in a VM on 
a Ubuntu 14.04 physical host w/ 6GB of RAM.  If I understand the 
"qemu_runner.py" script correctly, it gave the VM 4000 megabytes of memory.

Original comment by bloomu.p...@gmail.com on 16 Mar 2015 at 8:41

GoogleCodeExporter commented 9 years ago 
> Running target executable...
> Escape!

That shows that the exploit worked -- the test passed.

Original comment by mseaborn@chromium.org on 16 Mar 2015 at 3:41

GoogleCodeExporter commented 9 years ago 
This doesn't have payload, right?

Original comment by rehiz...@gmail.com on 16 Mar 2015 at 10:27

GoogleCodeExporter commented 9 years ago 
@comment #9: The proof-of-concept code linked above just overwrites a test 
executable with code that calls write() and then _exit().  It's a trivial 
payload, for test purposes, but it wouldn't be difficult to modify it to call 
execve() instead.

Original comment by mseaborn@chromium.org on 16 Mar 2015 at 10:35

GoogleCodeExporter commented 9 years ago 
in privesc.cc:565, I'm confused what does target_pt_size mean?

target_pt_size = memory_size - file_size

what does "memory_size - file_size" mean?

in my test, the final file_size is 32M, and the iterations is 57088, and the 
reverse_size is 1784G!!!!

Is there something wrong? How can it be that large?

Original comment by Mctrain...@gmail.com on 24 Mar 2015 at 6:00

GoogleCodeExporter commented 9 years ago 
target_pt_size is the amount of physical memory we're aiming to fill with page 
tables, in bytes.

reserve_size is the amount of virtual address space we're mmap()'ing, in bytes. 
 It's fine for this to be 1784 GB, because it's not all backed by unique pages 
of physical memory.  1784 GB of virtual address space requires 1784 / 512 = 
3.48 GB of page tables to map.

Original comment by mseaborn@chromium.org on 24 Mar 2015 at 6:59