isec-tugraz/meltdownDemos de prova de conceito e biblioteca libkdump que demonstram o ataque microarquitetural Meltdown, vazando memória do kernel e memória física em CPUs Intel vulneráveis.
Este repositório contém várias aplicações que demonstram o bug Meltdown. Para informações técnicas sobre o bug, consulte o artigo:
As aplicações neste repositório são construídas com libkdump, uma biblioteca que desenvolvemos para o artigo. Esta biblioteca simplifica a exploração do bug ao adaptar-se automaticamente a certas propriedades do ambiente.
Este repositório contém vários vídeos que demonstram o Meltdown
Este repositório contém cinco demos para demonstrar diferentes casos de uso. Todos os demos são testados no Ubuntu 16.04 com um Intel Core i7-6700K, mas devem funcionar em qualquer sistema Linux com qualquer CPU Intel moderna desde 2010.
Para melhores resultados, recomendamos uma CPU rápida que suporte Intel TSX (por exemplo, qualquer Intel Core i7-5xxx, i7-6xxx ou i7-7xxx). Além disso, cada demo deve ser fixado a um núcleo de CPU, por exemplo, com taskset.
Como pré-requisito, você precisa instalar o glibc-static na sua máquina.
Para sistemas baseados em RPM:
sudo yum install -y glibc-static
test)Este é o demo mais básico. Ele usa o Meltdown para ler endereços acessíveis do próprio espaço de endereçamento, sem quebrar nenhum mecanismo de isolamento.
Se este demo não funcionar para você, os demos restantes provavelmente também não funcionarão. As razões são várias, por exemplo, a CPU pode ser muito lenta, não suportar execução fora de ordem, o temporizador de alta resolução não ser preciso o suficiente (especialmente em VMs), o sistema operacional não suportar manipuladores de sinais personalizados, etc.
make
taskset 0x1 ./test
Se você vir uma saída semelhante a esta
Expect: Welcome to the wonderful world of microarchitectural attacks
Got: Welcome to the wonderful world of microarchitectural attacks
então o demo básico funciona.
kaslr)A partir do kernel Linux 4.12, o KASLR (Kernel Address Space Layout Randomizaton) está ativo por padrão. Isso significa que a localização do kernel (e também o mapa físico direto que mapeia toda a memória física) muda a cada reinicialização.
Este demo usa o Meltdown para vazar a randomização (secreta) do mapa físico direto. Este demo requer privilégios de root para acelerar o processo. O artigo descreve uma variante que não requer privilégios de root.
make
sudo taskset 0x1 ./kaslr
Após alguns segundos, você deverá ver algo semelhante a isto
[+] Direct physical map offset: 0xffff880000000000
reliability)Este demo testa quão confiavelmente a memória física pode ser lida. Para este demo, você precisa do deslocamento do mapa físico direto (por exemplo, do demo #2) ou precisa desabilitar o KASLR especificando nokaslr na linha de comando do kernel.
Compile e inicie reliability. Se você tiver o KASLR habilitado, o primeiro parâmetro é o deslocamento do mapa físico direto. Caso contrário, o programa não requer parâmetro.
make
sudo taskset 0x1 ./reliability 0xffff880000000000
Após alguns segundos, você deverá obter uma saída semelhante a esta:
[-] Success rate: 99.93% (read 1354 values)
physical_reader)Este demo lê memória de um processo diferente lendo diretamente a memória física. Para este demo, você precisa do deslocamento do mapa físico direto (por exemplo, do demo #2) ou precisa desabilitar o KASLR especificando nokaslr na linha de comando do kernel.
Em princípio, este programa pode ler endereços físicos arbitrários. No entanto, como a memória física contém muitos dados não legíveis por humanos, fornecemos uma ferramenta de teste (secret), que coloca uma string legível por humanos na memória e fornece diretamente o endereço físico desta string.
Para o demo, primeiro execute secret (como root) para obter o endereço físico de uma string legível por humanos:
make
sudo ./secret
Ele deverá exibir algo como isto:
[+] 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
Enquanto o programa secret estiver em execução, inicie physical_reader. O primeiro parâmetro é o endereço físico impresso por secret. Se você não tiver o KASLR desabilitado, o segundo parâmetro é o deslocamento do mapa físico direto.
taskset 0x1 ./physical_reader 0x390fff400 0xffff880000000000
Após alguns segundos, você deverá obter uma saída semelhante a esta:
[+] Physical address : 0x390fff400
[+] Physical offset : 0xffff880000000000
[+] Reading virtual address: 0xffff880390fff400
If you can read this, this is really bad
memdump)Este demo despeja o conteúdo da memória. Como os demos #3 e #4, ele usa o mapa físico direto para despejar o conteúdo da memória física em um formato semelhante a um hexdump.
Novamente, como a memória física contém muito conteúdo não legível por humanos, fornecemos uma ferramenta de teste para preencher grandes quantidades da memória física com strings legíveis por humanos.
Para o demo, primeiro execute memory_filler para preencher a memória com strings legíveis por humanos. O primeiro argumento é a quantidade de memória (em gigabytes) a preencher.
make
./memory_filler 9
Em seguida, execute a ferramenta memdump para despejar o conteúdo da memória. Se você executou memory_filler antes, deverá ver alguns fragmentos de string.
Se você tiver o Firefox ou Chrome com várias abas abertas, também poderá ver partes dos sites que estão abertos ou foram fechados recentemente.
O primeiro parâmetro é o endereço físico no qual o despejo deve começar (deixe vazio para começar no primeiro gigabyte). O segundo parâmetro é a quantidade de bytes que você deseja que sejam lidos; para ler tudo, forneça -1. Se você não tiver o KASLR desabilitado, o terceiro parâmetro é o deslocamento do mapa físico direto.
taskset 0x1 ./memdump 0x240000000 -1 0xffff880000000000 # start at 9 GB
Você deverá obter um hexdump de partes da memória (potencialmente contendo até segredos como senhas, veja o exemplo no artigo), por exemplo: