O kernel Linux acaba de receber novos pacotes extras de segurança. O anúncio é de Kees Cook, um ex-administrador de sistemas chefe da kernel.org e líder da equipe de segurança Ubuntu. Kees agora trabalha no Google para Android e ChromeOS protect. Ele publicou um conjunto de patches para randomizar a pilha de compensação do kernel para lidar com as chamadas do sistema. Assim, os patches melhoram a segurança do kernel alterando a localização da pilha, o que torna os ataques muito mais difíceis e menos bem-sucedidos.
A ideia original para o patch pertence ao projeto PaX RANDKSTACK. Em 2019, Elena Reshetova, engenheira da Intel, tentou criar uma implementação dessa ideia, adequada para inclusão na composição principal do kernel Linux.
Novos patches melhoram a segurança do kernel Linux
Posteriormente, a iniciativa foi tomada por Kees Cook que apresentou uma implementação adequada para a versão principal do kernel e cujos patches estão planejados para a versão 5.13 do Linux.
O modo será desabilitado por padrão. Assim, para habilitá-lo, o parâmetro de linha de comando do kernel “randomize_kstack_offset = on/off” e a configuração CONFIG_RANDOMIZE_KSTACK_OFFSET_DEFAULT são oferecidos, além da sobrecarga de habilitar o modo é estimada em aproximadamente 1% de perda de desempenho .
A essência da proteção proposta é escolher um deslocamento de pilha aleatório em cada chamada do sistema. Isso complica a determinação do layout da pilha na memória mesmo se as informações de endereço forem recebidas, já que o endereço base da pilha mudará na próxima chamada.
Ao contrário da implementação PaX RANDKSTACK, nos patches propostos para inclusão no kernel, a randomização não é feita no estágio inicial, mas após definir a estrutura pt_regs, o que torna impossível usar métodos baseados em ptrace para determinar um deslocamento aleatório durante um chamada de sistema de longa duração.
Invasores precisam melhorar ataques
Como as proteções de pilha do kernel Linux têm melhorado constantemente (mapeamento de pilha baseado em vmap com páginas de proteção, remoção de thread_info, STACKLEAK), os invasores tiveram que encontrar novas maneiras de seus exploits funcionarem.
Eles têm, e continuam a contar com o determinismo da pilha do kernel, em situações em que VMAP_STACK e THREAD_INFO_IN_TASK_STRUCT não eram relevantes. Por exemplo, os seguintes ataques recentes teriam sido prejudicados se o deslocamento da pilha não fosse determinístico entre as chamadas do sistema
O objetivo da função randomize_kstack_offset é adicionar um deslocamento aleatório após pt_regs ter sido colocado e antes que o resto da pilha de threads seja usado durante o processamento da chamada e alterá-lo cada vez que um processo emitir uma chamada do sistema. A fonte de aleatoriedade é atualmente definida pela arquitetura (mas o x86 usa o byte baixo de rdtsc ()).
O que dizem
Melhorias futuras são possíveis para diferentes fontes de entropia, mas fora do escopo deste patch. Além disso, para adicionar mais imprevisibilidade, novos deslocamentos são escolhidos no final das chamadas do sistema (o tempo deve ser menos fácil de medir a partir do espaço do usuário do que no momento da entrada da chamada do sistema) e eles são armazenados em uma variável por CPU, para que o tempo de vida do valor não permaneça explicitamente vinculado a uma única tarefa.
Não há mudanças visíveis para isso no x86 porque o protetor de pilha já está incondicionalmente desabilitado para a unidade de compilação, mas a mudança é necessária em arm64. Infelizmente, não há nenhum atributo que possa ser usado para desabilitar o protetor de pilha para funções específicas. Comparação com a função PaX RANDKSTACK: A função RANDKSTACK randomiza a localização do início da pilha (cpu_current_top_of_stack), ou seja, inclui a localização da estrutura pt_regs na pilha.
Este patch seguiu inicialmente a mesma abordagem, mas durante discussões recentes foi determinado ser de pouco valor, pois se a funcionalidade ptrace estivesse disponível para um invasor, eles podem usar PTRACE_PEEKUSR para ler / gravar diferentes offsets na estrutura pt_regs. Observe o comportamento do cache de acesso pt_regs e descubra o deslocamento aleatório da pilha.
Finalmente, é mencionado que a implementação inicial suporta processadores ARM64 e x86/x86_64.
Via Linux Adictos