Esta semana, discutiremos três vulnerabilidades de alta severidade que poderiam permitir aos atacantes aumentar os privilégios se tivessem acesso local ao sistema.
Linux Kernel eBPF - Vulnerabilidade de Validação de Entrada Imprópria
CVE-2022-23222 descreve uma vulnerabilidade decorrente da manipulação dos programas eBPF pelo kernel. Um atacante que possa executar BPF pode travar o sistema ou executar código arbitrário no contexto do kernel.
Causa Raiz - O verificador BPF não restringe adequadamente vários tipos de ponteiro *_OU_NULL, o que permite que estes tipos façam aritmética de ponteiro. Isto pode ser alavancado para executar código arbitrário ou crashar o sistema.
Nota importante: A BPF sem privilégios é desactivada por defeito na maioria das distros. O bug foi introduzido na versão 5.8.0 do kernel e corrigido na versão 5.14.17 do kernel. A disponibilidade de explorações públicas é outra razão pela qual o CVE-2022-23222 representa um risco significativo.
Manter-se actualizado com o mais recente kernel oferecido pela sua distribuição Linux é uma forma fácil de se proteger desta vulnerabilidade. Se o seu Linode arranca um kernel fornecido por nós, pode verificar se o seu Perfil de Configuração Linode está configurado para arrancar o kernel mais recente e depois reiniciar o seu Linode.
Se não puder actualizar imediatamente para um kernel corrigido, pode também mitigar esta vulnerabilidade, assegurando que o não-privilegiado_bpf_disabled seja definido para 1. O exemplo seguinte aplicará a mitigação temporária até que o seu Linode reinicie. Certifique-se de escrever esta configuração num ficheiro de configuração sysctl e arrancar com segurança o seu Linode para persistir na mitigação.
# sysctl -w kernel.unprivileged_bpf_disabled=1Fonte: Tr3e wang do SecCoder Security Lab
Fuga de contentores usando Excesso de pilha no Kernel do Linux
CVE-2022-0185 é um bug de transbordamento de pilha que permite a um atacante com acesso a um utilizador sem privilégios escalar os seus privilégios para enraizar. Para o fazer, o atacante deve ter uma capacidade específica de Linux, CAP_SYS_ADMIN. É importante notar que quando o Docker (ou outros CRIs) são utilizados num cluster Kubernetes, o filtro seccomp fica desactivado por defeito, pelo que esta vulnerabilidade poderia ser explorada nesses casos.
Causa Raiz - O insecto é causado por um subfluxo inteiro presente em fs/fs_context.c:legacy_parse_param, resultando num erro de cálculo válido de comprimento máximo. Isto leva a um subfluxo inteiro no componente "Contexto do Sistema de Ficheiros".
O subfluxo ocorre quando uma operação de subtracção reduz um número inteiro não assinado a um valor abaixo de zero. Uma vez que os números inteiros não assinados não podem representar números negativos, o cálculo resultante envolve antes o valor máximo do número inteiro. Quando este subfluxo ocorre dentro da função legacy_parse_param, uma verificação de tamanho falha, e o atacante pode escrever para além dos limites da memória de 4kb alocada no espaço do kernel. Usando esta "escrita sem limites", o atacante pode alterar valores na memória do kernel e, por exemplo, adicionar acesso a si próprio a qualquer outro processo em execução no mesmo nó.
O comando "capsh -print" pode ser utilizado no contexto do utilizador actual para listar as capacidades activadas. A exploração depende da capacidade CAP_SYS_ADMIN; contudo, a permissão só precisa de ser concedida no espaço de nomes actual. Um utilizador sem privilégios pode usar o unshare (CLONE_NEWNS | CLONE_NEWUSER) para entrar num namespace com a permissão CAP_SYS_ADMIN e depois proceder à exploração para enraizar o sistema. Contudo, a utilização do seccomp impedirá o atacante de entrar no espaço de nomes com essa capacidade.
A vulnerabilidade foi introduzida no kernel 5.1 e remendada em 5.16.2. O código de exploração já está a emergir em linha. Aqui está a redacção original para mais detalhes técnicos sobre os resultados.
Manter-se actualizado com o mais recente kernel oferecido pela sua distribuição Linux é uma forma fácil de se proteger desta vulnerabilidade. Se o seu Linode inicia um kernel fornecido por nós, pode também verificar se o seu Perfil de Configuração do Linode está configurado para iniciar o último kernel e depois reiniciar o seu Linode. Se não for capaz de actualizar imediatamente um kernel corrigido, pode aplicar estas atenuações:
- Minimizar a utilização de recipientes privilegiados que tenham acesso à capacidade CAP_SYS_ADMIN.
- Para contentores não privilegiados, assegurar-se de que existe um filtro seccomp que bloqueia a chamada não compartilhada irá reduzir o risco.
- Mitigar a exploração a partir de contentores não privilegiados, desactivando a capacidade do utilizador de utilizar espaços com nomes de utilizador a nível de anfitrião. O exemplo seguinte aplicará a mitigação temporária até o seu Linode reiniciar. Certifique-se de escrever esta configuração num ficheiro de configuração sysctl e arrancar com segurança o seu Linode para persistir na mitigação.
# sysctl -w kernel.unprivileged_userns_clone=0PwnKit - Vulnerabilidade à Escalada de Privilégios Local em Polkit
O Polkit é um componente para controlar privilégios de todo o sistema em SOs do tipo Unix. Fornece uma metodologia sistemática para processos não-privilegiados para comunicar com processos privilegiados. Além disso, alguém pode também usar o polkit para executar comandos com privilégios elevados usando o comando pkexec (geralmente com raiz).
CVE-2021-4034 é uma vulnerabilidade de corrupção de memória no pkexec do polkit, um programa SUID-root instalado por defeito na maioria das principais distribuições Linux. A exploração bem sucedida permite a qualquer utilizador sem privilégios de raiz ganhar facilmente privilégios na configuração padrão.
Causa Raiz - O programa pkexec não valida devidamente o número de argumentos que lhe são transmitidos, permitindo que alguém execute código arbitrário como utilizador privilegiado.
Todas as versões Polkit a partir de 2009 são vulneráveis e exploráveis mesmo que o próprio daemon Polkit não esteja a funcionar.
Manter-se actualizado com o mais recente kernel oferecido pela sua distribuição Linux é uma forma fácil de se proteger desta vulnerabilidade. Se o seu Linode arranca um kernel fornecido por nós, pode verificar se o seu Perfil de Configuração Linode está configurado para arrancar o kernel mais recente e depois reiniciar o seu Linode. Se não for capaz de actualizar imediatamente para um kernel corrigido, pode atenuar temporariamente o problema removendo o SUID-bit do pkexec:
# chmod 0755 /usr/bin/pkexec
Comentários