Detalhes técnicos sobre integridade do fluxo de controle
“A disponibilidade de um grande número de ponteiros de função no kernel auxilia na popularidade desse padrão de ataque. Mesmo que os invasores não consigam injetar seu próprio código executável, partes arbitrárias do código do kernel existente podem ser executadas para completar sua exploração.
LLVMO CFI do CFI tenta mitigar esses ataques restringindo alvos de chamadas válidos e forçando um kernel panic ao detectar uma violação de CFI. Uma verificação é adicionada antes de cada ramificação indireta para confirmar se o endereço de destino aponta para uma função válida com uma assinatura correta. Isso evita que uma ramificação indireta salte para um local de código arbitrário e até limita as funções que podem ser chamadas. Um invasor ainda poderá alterar um ponteiro de função, se um bug permitir o acesso. Mas o CFI do LLVM limita 55% das chamadas indiretas a no máximo 5 alvos possíveis e 80% a no máximo 20 alvos. Para determinar todos os destinos de chamada válidos para cada ramificação indireta, o compilador precisa ver todo o código do kernel de uma só vez.
O uso de LTO (Otimização do tempo de link) torna isso possível. O CFI do LLVM requer o uso de LTO, onde o compilador produz bitcode específico do LLVM para todos os C unidades de compilação, e um vinculador compatível com LTO usa o backend LLVM para combinar o bitcode e compilá-lo em Código nativo.
Além de permitir o uso de CFI, o LTO alcança melhor desempenho de tempo de execução por meio de análise de todo o programa e otimização entre módulos.
ThinLTO quase alcançou a melhoria de desempenho dos LTOs. No modo ThinLTO, como no LTO normal, Clang emite bitcode LLVM após a fase de compilação. O bitcode ThinLTO é aumentado com um resumo compacto do módulo. Durante a etapa de link, apenas os resumos são lidos e mesclados em um índice de resumo combinado, que inclui um índice de locais de função para importação posterior de funções entre módulos. Posteriormente, é realizada uma análise rápida e eficiente de todo o programa no índice de resumo combinado. ThinLTO permite um processo de vinculação multithread, o que resulta em tempo de compilação reduzido.
Devido ao CFI interromper a execução do programa ao atingir certas classes de bugs, ele também é classificado como uma ferramenta de localização de bugs, conforme mencionado anteriormente, quando usado no modo permissivo. O CFI permissivo mostrará violações de CFI no log do kernel, sem forçar um kernel panic. Os núcleos 4.9 (dispositivos de geração Pixel 3) e 4.14 (dispositivos de geração Pixel 4) tinham vários tipos de função incompatibilidades resultando em violações de CFI, que foram abordadas pelo Google em conjuntos de patches disponíveis no kernel/common repositórios.
No entanto, devido à natureza do ecossistema Android, essas incompatibilidades provavelmente também serão encontradas no código específico do fabricante do SoC (neste caso, Qualcomm) ou do OEM (OnePlus). Várias violações CFI no código Qualcomm distintas do kernel 4.19 foram corrigidas no kernel Kirisakura do OnePlus 8 Pro (exemplo: 1, 2, 3).
A execução do kernel em CFI permissiva também revelou violações de CFI no código relacionado aos drivers OnePlus (commits relevantes podem ser encontrados aqui e aqui). O kernel Kirisakura para o OnePlus 8 Pro é executado com CFI aplicada, protegendo seus usuários contra esse tipo de ataque de reutilização de código.”
consulte Mais informação
Entusiasta do faça você mesmo (ou seja, salvador de peças antigas de PC). Usuário ávido do Android desde a época do Eclair, Skanda também gosta de acompanhar as tendências recentes de desenvolvimento no mundo da computação de placa única.