Vulnerabilidade raiz no kit de ferramentas de gerenciamento de pacotes Snap

Qualys identificou a terceira vulnerabilidade perigosa este ano (CVE-2022-3328) no utilitário snap-confine, que vem com o sinalizador de raiz SUID e é chamado pelo processo snapd para criar um ambiente executável para aplicativos distribuídos em pacotes independentes no formato instantâneo. A vulnerabilidade permite que um usuário local sem privilégios execute a execução de código como root na configuração padrão do Ubuntu. O problema foi corrigido na versão 2.57.6. Atualizações de pacotes foram lançadas para todos os ramos suportados do Ubuntu.

Curiosamente, a vulnerabilidade em questão foi introduzida durante o processo de correção de uma vulnerabilidade semelhante de fevereiro no snap-confine. Os pesquisadores conseguiram preparar uma exploração funcional que fornece acesso root ao Ubuntu Server 22.04, que, além da vulnerabilidade no snap-confine, também envolve duas vulnerabilidades no processo multipathd (CVE-2022-41974, CVE-2022-41973) , associado a ignorar a verificação de autoridade na transmissão de comandos privilegiados e trabalho inseguro com links simbólicos.

A vulnerabilidade no snap-confine é causada por uma condição de corrida na função must_mkdir_and_open_with_perms(), adicionada para proteger contra a substituição do diretório /tmp/snap.$SNAP_NAME por um link simbólico após verificar o proprietário, mas antes de chamar o sistema de montagem chamada para vincular e montar diretórios nele para um pacote em formato snap. A proteção adicional foi renomear o diretório /tmp/snap.$SNAP_NAME para outro diretório em /tmp com um nome aleatório se ele existir e não for de propriedade do root.

Ao explorar a 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 a raiz do conteúdo do pacote snap. A parte "XXXXXX" do nome é escolhida aleatoriamente por mkdtemp(), mas um pacote chamado "rootfs_XXXXXX" pode ser validado na função sc_instance_name_validate (ou seja, a ideia é que $SNAP_NAME seja definido como "rootfs_XXXXXX" e então a operação de renomeação resultará na substituição do diretório /tmp/snap.rootfs_XXXXXX pelo snap raiz).

Para obter o uso simultâneo de /tmp/snap.rootfs_XXXXXX e renomear /tmp/snap.$SNAP_NAME, duas instâncias de snap-confine foram iniciadas. Depois que a primeira instância criasse /tmp/snap.rootfs_XXXXXX, o processo seria bloqueado e uma segunda instância começaria com o nome do pacote rootfs_XXXXXX, fazendo com que o diretório temporário da segunda instância /tmp/snap.$SNAP_NAME se tornasse o diretório raiz /tmp/snap .rootfs_XXXXXX do primeiro. Imediatamente após a renomeação ser concluída, a segunda instância travou e /tmp/snap.rootfs_XXXXXX foi substituído pela manipulação de condições de corrida, como ao explorar a vulnerabilidade de fevereiro. Após a substituição, o bloqueio de execução foi removido da primeira instância e os invasores ganharam controle total sobre o diretório raiz do snap.

A última etapa foi criar um link simbólico /tmp/snap.rootfs_XXXXXX/tmp, que foi usado pela função sc_bootstrap_mount_namespace() para montar o diretório real gravável /tmp em qualquer diretório no sistema de arquivos, já que a chamada mount() segue links simbólicos antes da montagem. Tal montagem é bloqueada pelas restrições do AppArmor, mas para contornar esse bloqueio, o exploit utilizou duas vulnerabilidades auxiliares no multipathd.

Fonte: opennet.ru

Adicionar um comentário