A empresa Qualys identificou a terceira vulnerabilidade crítica deste ano (CVE-2022-3328) na ferramenta snap-confine, que é entregue com a flag SUID root e chamada pelo processo snapd para criar um ambiente de execução para aplicativos distribuídos em pacotes independentes no formato snap. A vulnerabilidade permite que um usuário local não privilegiado execute código com permissões de root na configuração padrão do Ubuntu. O problema foi corrigido na versão snapd 2.57.6. Atualizações de pacotes foram lançadas para todos os branches suportados do Ubuntu.
Curiosamente, a vulnerabilidade em questão foi introduzida durante a correção de uma vulnerabilidade semelhante de fevereiro no snap-confine. Os pesquisadores conseguiram preparar um exploit funcional que fornece acesso root no Ubuntu Server 22.04, onde, além da vulnerabilidade no snap-confine, duas vulnerabilidades no processo multipathd (CVE-2022-41974, CVE-2022-41973) também foram exploradas, relacionadas a uma falha na verificação de autorização ao transmitir comandos privilegiados e ao manuseio inseguro de links simbólicos.
A vulnerabilidade no snap-confine é causada por uma condição de corrida na função must_mkdir_and_open_with_perms(), que foi adicionada para proteger contra a substituição do diretório /tmp/snap.$SNAP_NAME por um link simbólico após a verificação do proprietário, mas antes de chamar a system call mount para fazer um bind mount nos diretórios do pacote no formato snap. A proteção adicionada envolvia renomear o diretório /tmp/snap.$SNAP_NAME para outro diretório em /tmp com um nome aleatório, se existisse e não pertencesse ao usuário root.
Durante a exploração da operação de renomeação do diretório /tmp/snap.$SNAP_NAME, os pesquisadores aproveitaram o fato de que o snap-confine também cria um diretório /tmp/snap.rootfs_XXXXXX para o conteúdo raiz do pacote snap. A parte "XXXXXX" no nome é escolhida aleatoriamente usando mkdtemp(), mas um pacote com o nome "rootfs_XXXXXX" pode passar na verificação na função sc_instance_name_validate (ou seja, a ideia é que o nome $SNAP_NAME assuma o valor "rootfs_XXXXXX" e, assim, a operação de renomeação levará à sobrescrição do diretório /tmp/snap.rootfs_XXXXXX com a raiz do snap).
Para que houvesse um uso simultâneo de /tmp/snap.rootfs_XXXXXX e a renomeação de /tmp/snap.$SNAP_NAME, duas instâncias do snap-confine foram iniciadas. Assim que a primeira instância criava /tmp/snap.rootfs_XXXXXX, o processo ficava bloqueado e a segunda instância com o nome do pacote rootfs_XXXXXX era iniciada, o que fazia com que o diretório temporário /tmp/snap.$SNAP_NAME da segunda instância se tornasse o diretório raiz /tmp/snap.rootfs_XXXXXX da primeira. Logo após a execução da renomeação, a segunda instância falhava, e /tmp/snap.rootfs_XXXXXX era substituído com a manipulação de estado de corrida, como na exploração da vulnerabilidade de fevereiro. Após a substituição, o bloqueio de execução da primeira instância era removido, e os atacantes obtinham controle total sobre o diretório raiz do snap.
Na última etapa, era criada uma ligação simbólica /tmp/snap.rootfs_XXXXXX/tmp, que era utilizada pela função sc_bootstrap_mount_namespace() para montar bind do diretório real gravável /tmp em qualquer diretório do sistema de arquivos, já que a chamada mount() segue as ligações simbólicas antes de montar. Tal montagem é bloqueada pelas restrições do AppArmor, mas para contornar esse bloqueio, o exploit utilizou duas vulnerabilidades auxiliares no multipathd.
Fonte: opennet.ru
