Injeção de Privilégio em Branches: explorando condições de corrida no preditor de branches
(comsec.ethz.ch)- Branch Privilege Injection é uma vulnerabilidade que volta a contornar as defesas de hardware da família Spectre-BTI, mantidas por cerca de 6 anos, por meio de uma condição de corrida no preditor de branches de CPUs Intel
- O ponto central do ataque é que as atualizações do preditor de branches são processadas de forma assíncrona em relação ao fluxo de instruções e, em certas condições, podem ser aplicadas com atraso de dezenas a centenas de ciclos
- Se atualizações atrasadas permanecerem durante uma transição de privilégio ou durante a execução de IBPB, elas podem acabar associadas ao domínio de segurança errado depois, quebrando as garantias de segurança de eIBRS e IBPB
- Os pesquisadores demonstraram, no Ubuntu 24.04 com todas as mitigação padrão ativadas, um ataque ponta a ponta em um Intel Raptor Lake de 13ª geração que vaza memória arbitrária a 5.6KiB/s
- A atualização de microcódigo da Intel bloqueou o primitivo de detecção da vulnerabilidade na avaliação com Alder Lake, com overhead de até 2.7%
Condições para que o Branch Privilege Injection funcione
- Branch Privilege Injection é um ataque de injeção de alvo de branch, ou seja, um ataque que volta a viabilizar o poder do Spectre-BTI em ambientes Intel
- As mitigação de hardware da Intel vinham bloqueando esse tipo de ataque há cerca de 6 anos, mas esta pesquisa mostra que uma condição de corrida em CPUs Intel pode abalar essa defesa
- O ataque se baseia em duas observações
- O preditor de branches dos processadores Intel é atualizado de forma assíncrona em relação ao fluxo de instruções
- Em certas condições, a atualização pode atrasar dezenas ou centenas de ciclos
- A atualização assíncrona em si não é a vulnerabilidade, mas uma funcionalidade
- Não há sincronização suficiente entre o preditor de branches e o fluxo de instruções durante operações críticas para a segurança
- Durante a transição de modo usuário para kernel, ou de guest para hypervisor, atualizações ainda podem estar em andamento
- Mesmo durante a execução de IBPB, ainda podem restar atualizações em andamento
- Se essas atualizações chegarem depois da transição de privilégio, elas passam a ser associadas ao novo modo de privilégio, e não ao anterior
- O preditor de branches dos processadores Intel é atualizado de forma assíncrona em relação ao fluxo de instruções
- Esse tipo de vulnerabilidade é chamado de Branch Predictor Race Conditions
Mitigações quebradas e escopo do impacto
- eIBRS é a mitigação de Spectre-BTI que a Intel introduziu em todos os processadores a partir da 9ª geração Coffee Lake Refresh
- O objetivo é separar a predição de branches indiretos entre diferentes domínios de segurança
- Cada predição é associada ao domínio em que foi gerada, e o design determina que depois apenas as predições do domínio atual sejam usadas
- Se atualizações em andamento durante uma transição de privilégio forem associadas ao novo domínio de segurança, essa associação pode ser manipulada
- IBPB é o mecanismo usado para separar sandboxes ou máquinas virtuais que não confiam umas nas outras dentro do mesmo domínio de segurança de hardware
- Ele fornece a capacidade de invalidar todas as predições de branches indiretos
- Atualizações em andamento não são limpas pelo IBPB e podem ser gravadas no preditor de branches mesmo após a invalidação
- O escopo do impacto varia por geração e arquitetura
- Todos os processadores Intel a partir da 9ª geração Coffee Lake Refresh são afetados por Branch Privilege Injection
- Predições de bypass de IBPB foram observadas até a 7ª geração Kaby Lake
- Nenhum problema foi encontrado nos sistemas AMD e ARM avaliados
- O ataque de prova de conceito foi desenvolvido para Linux, mas como o problema é de hardware, sistemas operacionais executados em hardware afetado também sofrem impacto
Mitigações, custo de desempenho e materiais públicos
- Recomenda-se instalar as atualizações mais recentes do sistema operacional e da BIOS
- A Intel desenvolveu atualizações de microcódigo para os processadores afetados, e os pesquisadores as avaliaram em Alder Lake
- A mitigação por microcódigo bloqueou o primitivo de detecção da vulnerabilidade
- Em Alder Lake, mostrou overhead de até 2.7%
- Alternativas de mitigação por software também foram avaliadas
- Em Coffee Lake Refresh, houve overhead de 1.6%
- Em Rocket Lake, houve overhead de 8.3%
- Mais detalhes técnicos podem ser consultados no artigo
- O artigo sobre Branch Privilege Injection será apresentado na USENIX Security 2025, e também está prevista uma apresentação na Black Hat USA 2025
- O código-fonte do ataque e dos experimentos está disponível no github
1 comentários
Comentários no Hacker News
Post do blog dos pesquisadores: https://comsec.ethz.ch/research/microarch/branch-privilege-i...
Artigo: https://comsec.ethz.ch/wp-content/files/bprc_sec25.pdf
Em um cenário de ataque, no fim é só uma questão de tempo até que todas as informações da memória da CPU caiam em mãos erradas
Bom texto. Em resumo, a atualização do preditor de desvios pode ser adiada para muito depois de a instrução de desvio se aposentar (retire)
Faz sentido; caso contrário, a aposentadoria da instrução de desvio levaria mais tempo. Instruções de serialização de dispatch também não parecem parar o pipeline por causa de atualizações pendentes no estado do preditor, o que é natural, já que “commit do resultado da instrução de desvio” e “commit do resultado da predição” já foram separados
Instruções de mudança de privilégio também não param o pipeline por causa de atualizações pendentes, mas isso só é válido quando se pode garantir que o nível de privilégio ao criar a predição e ao fazer o commit seja consistente. Caso contrário, uma predição criada por código em um nível de privilégio pode ser comitada em um estado usado por outro nível de privilégio
Talvez seja um problema difícil porque, dentro do pipeline, o nível de privilégio atual não é um valor único e bem definido
É bom ver Kaveh Razavi. Ele lecionava na Vrije Universiteit de Amsterdã, e a disciplina de Hardware Security abordava esse tipo de conteúdo em profundidade; era muito legal
Fico curioso se existem gravações oficiais ou notas online
Alguém sabe qual é a relação disso com o ataque Training Solo, divulgado agora há pouco? https://www.vusec.net/projects/training-solo/
O Training Solo entra no kernel, muda o nível de privilégio e depois, por “autoaprendizado”, faz com que o desvio seja predito incorretamente na direção de um disclosure gadget para vazar memória
Branch predictor race conditions entra no kernel enquanto uma atualização treinada do preditor de desvios ainda está em processamento, fazendo com que essa atualização seja associada ao nível de privilégio errado. Depois usa isso novamente para redirecionar um desvio do kernel para um disclosure gadget e vazar memória
Se o preditor de desvios da CPU pudesse usar imediatamente informações para verificar limites de buffer e níveis de privilégio de código, problemas assim seriam muito mais fáceis de evitar
Mas isso provavelmente não vai acontecer até arrancarem
void*das mãos frias dos programadores C e enriquecerem ponteiros com informações importantesPara fazer o que você quer, seria necessária uma arquitetura de hardware em que todo load/store passasse por algum tipo de “endereço aumentado” que armazenasse informações de limites
Ou seja, você está basicamente pedindo a segmentação do 80286, que já existiu e não fazia o que você queria. O motivo é que esses descritores de segmento também precisam ser carregados corretamente pelo software. Do ponto de vista do software, no fim das contas ainda é “só um ponteiro”, vulnerável aos mesmos erros
No caso de execução especulativa, para realmente usar essa vulnerabilidade para algo é preciso uma preparação absurdamente grande. Quase a única forma prática de usá-la é ter acesso direto ao computador e executar código de baixo nível. Não é o tipo de coisa em que apenas código JS rodando no navegador vaza segredos arbitrários
Se um sistema é valioso o bastante para que uma organização privada dedicada ou uma organização patrocinada por Estado faça a pesquisa e o direcionamento necessários, ele deveria, para começo de conversa, ter mecanismos que impeçam a execução de código arbitrário não autorizado
Pessoalmente, como o ganho de desempenho é realmente perceptível, deixo todas as mitigações desligadas
Aviso de segurança da Intel: https://www.intel.com/content/www/us/en/security-center/advi...
Fico curioso se há uma brecha semelhante no hardware da AMD. Execução especulativa parece uma vulnerabilidade muito difícil de corrigir em espaços de processador compartilhados, então fico me perguntando como a AMD conseguiu escapar disso
Eles dizem que não encontraram o problema nos sistemas AMD e ARM avaliados
Fonte: https://comsec.ethz.ch/research/microarch/branch-privilege-i...
Esta vulnerabilidade específica parece ser exclusiva da Intel, como o Meltdown, mas a AMD também era vulnerável ao Spectre original
Só que o motor de execução especulativa é complexo, então bugs e vulnerabilidades são muito disseminados
É bem provável que AMD e ARM também tenham bugs semelhantes. Basta pensar em quanto tempo esses bugs ficaram sem ser descobertos na Intel
Infelizmente, a solução real é admitir que não é possível isolar o código executado em sistemas modernos, o que poderia ser fatal para o modelo de negócios de algumas empresas muito ricas
Não é o mesmo tipo de problema que apareceria em software, com a mesma solução?
Dizem que “para fechar essas brechas, é necessária uma atualização especial do microcódigo do processador. Como isso pode ser feito por atualização de BIOS ou do sistema operacional, ela deve ser instalada no PC por meio de uma das atualizações cumulativas mais recentes do Windows”; por que mencionam só o Windows? E os usuários de Linux?
As distribuições são configuradas para pegar dali e distribuir automaticamente
Mas não sei exatamente o que verificar para confirmar se esta mitigação específica já foi incluída
CONFIG_MICROCODE/CONFIG_MICROCODE_INTEL)Mas a Intel precisa publicar os arquivos de microcódigo necessários para que os mantenedores das distribuições possam atualizar os pacotes, e então isso será incluído nas atualizações do sistema
Fico me perguntando se há um caminho de recuperação para a Intel. Ela não tem produtos convincentes no mercado, P&D leva muito tempo, e a fundição está atrás das concorrentes e continua sendo fonte de prejuízo
Além disso, o x86 está sendo cada vez mais pressionado por hardware ARM, e agora o RISC-V vindo da China também está crescendo. Claro, há também o ponto de vista dos semicondutores nos EUA. Especialmente depois dos problemas durante a Covid, será que os EUA deixariam um fabricante essencial como a Intel desmoronar?
A situação não é boa, mas o sensacionalismo chega a ser ridículo
Gamers são apenas uma pequena porcentagem dos usuários de produtos Intel, mas é desse lado que mais se ouve falar. Um ou dois pedidos de data center são maiores do que todos os CPUs gamer que a Intel vende em um ano. A Intel ainda se mantém bem no mercado de data centers
Além disso, a Intel ainda domina o mercado de notebooks corporativos, que também é consideravelmente maior que o mercado gamer
A Arm tinha apenas 15% de participação no mercado de data centers no ano passado e ainda não avançou muito no mercado Windows
Separando isso dos produtos, do ponto de vista de acionistas/negócios, acho que o desempenho financeiro hoje reflete cada vez menos o produto final, então tento pensar nisso à parte; mas vejo a Intel como perto de grande demais para quebrar
Quero confirmar se entendi direito: neste momento, todos os principais sistemas operacionais já têm patches que mitigam esse problema ou aplicam o microcódigo relacionado?