Duas novas vulnerabilidades foram descobertas no subsistema eBPF, que permite executar manipuladores dentro do núcleo do Linux em uma máquina virtual especial com JIT. Ambas as vulnerabilidades possibilitam a execução de código com privilégios de kernel, fora da máquina virtual isolada eBPF. A equipe da Zero Day Initiative, que realiza as competições Pwn2Own, publicou informações sobre os problemas, tendo demonstrado este ano três ataques ao Ubuntu Linux que utilizaram vulnerabilidades anteriormente desconhecidas (não está claro se as vulnerabilidades no eBPF estão relacionadas a esses ataques).
- CVE-2021-3490 — a vulnerabilidade é causada pela falta de verificação da saída do limite de valores de 32 bits durante a execução de operações bit-a-bit AND, OR e XOR no eBPF ALU32. Um atacante pode explorar este erro para ler e gravar dados fora dos limites do buffer alocado. O problema na operação XOR se manifesta a partir da versão do núcleo 5.7-rc1, enquanto AND e OR causam problemas a partir da versão 5.10-rc1.
- CVE-2021-3489 — a vulnerabilidade é causada por um erro na implementação do buffer circular e está relacionada ao fato de que a função bpf_ringbuf_reserve não verificava se o tamanho da área de memória alocada poderia ser menor que o tamanho real do buffer circular ringbuf. O problema se manifesta a partir da versão 5.8-rc1.
O status da correção das vulnerabilidades nas distribuições pode ser acompanhado nas seguintes páginas: Ubuntu, Debian, RHEL, Fedora, SUSE, Arch. As correções também estão disponíveis na forma de patches (CVE-2021-3489, CVE-2021-3490). A possibilidade de exploração do problema depende da disponibilidade do sistema de chamada eBPF para o usuário. Por exemplo, na configuração padrão no RHEL, para explorar a vulnerabilidade, o usuário precisa ter privilégios de CAP_SYS_ADMIN.
Adicionalmente, pode-se destacar uma outra vulnerabilidade no núcleo do Linux — CVE-2021-32606, que permite que um usuário local eleve suas permissões ao nível root. O problema se manifesta a partir do núcleo Linux 5.11 e é causado por uma condição de corrida na implementação do protocolo CAN ISOTP, que permite alterar os parâmetros de vinculação do socket devido à falta de bloqueios adequados na função isotp_setsockopt() ao processar a flag CAN_ISOTP_SF_BROADCAST.
Após o fechamento do socket, o ISOTP continua a manter a ligação ao socket receptor, que pode continuar a usar estruturas associadas ao socket após a liberação da memória relacionada (use-after-free devido à referência em isotp_rcv() a uma estrutura isotp_sock já liberada). Através de manipulações de dados, pode-se conseguir a substituição do ponteiro para a função sk_error_report() e executar seu próprio código a nível de kernel.
Fonte: opennet.ru
