No cenário da computação moderna, as preocupações de segurança vão além das vulnerabilidades do sistema operacional (SO) e bugs de software. Abaixo das abstrações, nossos processadores evoluíram para microarquiteturas intrincadas—pipelines, caches, buffers e motores de execução—projetados para extrair o máximo de desempenho. Ironicamente, essas características introduzem novos e sutis riscos de segurança, dando origem ao que são conhecidos como ataques microarquiteturais. Esses ataques exploram o compartilhamento não intencional—e vazamento—do estado microarquitetural entre aplicativos executando simultaneamente, às vezes mesmo em software perfeitamente seguro.
Este post abrangente tem como objetivo desmistificar os ataques microarquiteturais, cobrindo:
Seja você um iniciante, pesquisador, desenvolvedor de software ou profissional de segurança cibernética, este guia equipará você para entender esses ataques modernos poderosos—e como se defender deles.
Ataques microarquiteturais são técnicas de exploração que tiram proveito de vazamentos de informações não intencionais no design de baixo nível do hardware de um processador.
Ao contrário dos exploits de software típicos, os ataques microarquiteturais não exigem bugs de programação na aplicação ou no SO. Em vez disso, exploram como CPUs modernas tentam maximizar o desempenho, como ao compartilhar caches ou reordenar instruções.
As CPUs modernas compartilham estruturas de hardware críticas entre aplicativos e até máquinas virtuais, como:
Como essas estruturas não são perfeitamente isoladas, um processo pode muitas vezes observar ou inferir os efeitos de outro. Os atacantes exploram esse compartilhamento implícito para extrair segredos observando efeitos físicos indiretos (como pequenas mudanças no tempo de acesso à memória).
Existem duas grandes categorias:
Canais encobertos criam um caminho de comunicação entre dois atores (emissor e receptor) não pretendido pelo design do sistema. Um aplicativo modula algum recurso compartilhado, enquanto outro observa essas modificações para reconstruir uma mensagem.
Exemplos:
Ataques de canal lateral vazam informações sensíveis sem comunicação direta. Em vez disso, eles exploram informações “derramadas” pela atividade da vítima.
Exemplos:
Ambos os canais permitem que um processo deduza informações sobre outro—às vezes através de contêineres, VMs ou limites de usuário.
Sistemas de computação heterogêneos compreendem vários tipos de processadores (CPUs de propósito geral, GPUs, FPGAs, aceleradores de IA, etc.) na mesma plataforma, muitas vezes compartilhando alguma memória e/ou estado microarquitetural.
Suponha que uma GPU e CPU compartilham uma região de cache. Um processo de baixo privilégio em execução na GPU poderia “preparar” o cache, e um processo de alto privilégio na CPU poderia revelar inadvertidamente segredos através de seus acessos à memória. Então, o processo de baixo privilégio poderia observar mudanças, inferindo informações protegidas.
RISC-V é um conjunto de instruções modular e open-source, rapidamente ganhando popularidade para sistemas embutidos e pesquisa. Enquanto ataques microarquiteturais são bem estudados em x86 e ARM, pesquisas recentes mostram que o RISC-V é igualmente suscetível.
Conclusão Chave: Nenhum conjunto de instruções ou hardware open-source é imune—todas as CPUs com microarquitetura compartilhada são vulneráveis a menos que especificamente fortificadas.
Uma área nova: ataques ao motor de pilha (Fonte)
Se o atacante e a vítima compartilham uma CPU, ao realizar operações de pilha cuidadosamente calibradas e observar o tempo resultante, o atacante pode inferir que tipo de atividade de pilha a vítima realizou recentemente.
Spectre e Meltdown (2018) fizeram o mundo entender que os ataques microarquiteturais são mais do que teoria—they afetam bilhões de computadores.
[Processo da Vítima] [Processo do Atacante]
Executa instrução Prepara cache, cronometra acessos
em dados secretos Decodifica mudanças devido à atividade da vítima
---[Cache fisicamente compartilhado]---
Prime+Probe é um ataque clássico que funciona da seguinte forma:
Como colocar moedas em todos os assentos de um teatro (preparar), ter alguém entrando (vítima) e depois verificar quais assentos estão vazios (sondar)—revelando onde a vítima se sentou, sem observá-la diretamente.
Ataques recentes têm como alvo a otimização do motor de pilha:
É importante enfatizar: ataques práticos em sistemas de produção são ilegais sem consentimento. No entanto, medidas de desempenho que revelam canais laterais de temporização podem ser realizadas em suas próprias máquinas de teste para pesquisa e defesa.
Sonda de temporização simples para verificar compartilhamento de cache (por exemplo, em máquinas virtuais).
#!/bin/bash
buffer=/tmp/testmem
size=1024000
# Alocar um buffer grande
dd if=/dev/urandom of="$buffer" bs=1K count=1000
# Acessar repetidamente a memória para "preparar" o cache
function prime_cache {
for i in $(seq 1 $size); do
tail -c +$i "$buffer" | head -c 1 >/dev/null
done
}
# Temporizar um acesso
function time_access {
/usr/bin/time -f "%e" dd if="$buffer" of=/dev/null bs=1K count=1000 2>&1
}
echo "Preparando cache..."
prime_cache
echo "Cronometrando acesso de leitura..."
time_access
# Agora peça a outro processo para executar uma carga de trabalho intensiva de memória e repita
# Compare para ver se os tempos mudam, indicando contenção de cache!
Interprete mudanças significativas como evidência de contenção de cache com outros processos—potencialmente permitindo ataques Prime+Probe.
Método mais preciso usa o módulo time do Python e arrays numpy para padrões de acesso à memória repetitivos.
import numpy as np
import time
# Alocar um grande array
arr = np.zeros((1024 * 1024 * 10,), dtype=np.uint8)
def probe_access():
ts = time.time()
# Acessar todos os elementos para forçar carregamento no cache
for i in range(0, len(arr), 64):
arr[i] += 1
te = time.time()
print(f"Tempo de acesso: {te - ts:.6f} segundos")
# Primeiro teste: deve estar frio (pode haver page fault)
probe_access()
# Segundo teste: cache provavelmente quente
probe_access()
Agora, em um segundo terminal (ou processo separado), execute um script devorador de memória (por exemplo, stress-ng ou similar), o qual removerá linhas de cache. Execute probe_access() novamente e observe o aumento do tempo.
Se você observar tempos de acesso maiores após outro processo ser executado, isso significa que o cache do seu sistema é suscetível a ataques de tempo.
Dada a persistência dos ataques microarquiteturais, o que os defensores de segurança podem fazer?
# Verificar recursos de CPU relacionados a flush
grep . /proc/cpuinfo | grep -E 'flush|clflush|clwb'
# Pode mostrar: clflush, indicando instruções disponíveis para software limpar caches
Muitos fornecedores de CPU estão introduzindo recursos como:
No entanto, a maioria das CPUs implantadas ainda são suscetíveis, especialmente em ambientes de nuvem ou com hardware complexo.
Os ataques microarquiteturais não são mais uma "curiosidade teórica." À medida que nossos processadores se tornam mais otimizados—e mais compartilhados—a sutileza dos seus designs internos se torna uma ferramenta poderosa nas mãos de atacantes habilidosos.
Especialmente em sistemas heterogêneos, onde CPUs, GPUs e aceleradores compartilham estado microarquitetural, canais encobertos e laterais não são apenas possíveis—they são comuns. Ataques recentes contra CPUs RISC-V e o motor de pilha demonstram a universalidade e relevância persistente desses riscos, mesmo para novas arquiteturas e otimizações.
Mantenha-se atualizado, teste seus próprios ambientes e exija melhor isolamento—tanto em software quanto hardware.
Este post é apenas para fins educacionais. Sempre teste em ambientes seguros e controlados.
Se você achou este conteúdo valioso, imagine o que você poderia alcançar com nosso programa de treinamento de elite abrangente de 47 semanas. Junte-se a mais de 1.200 alunos que transformaram suas carreiras com as técnicas da Unidade 8200.