Qubes OS corrige falha crítica que dá execução de código no dom0 via qvm-copy-to-vm

A QSB-118 descreve como um qube comprometido pode injetar comandos arbitrários no domínio privilegiado durante o relatório de erro de uma cópia de arquivo. Todas as versões do Qubes OS são afetadas.

O time do Qubes OS publicou em 29 de agosto de 2026 o Qubes Security Bulletin 118 (QSB-118), que descreve uma vulnerabilidade de execução de código arbitrário no dom0, o domínio administrativo privilegiado do sistema. Segundo o boletim, a falha está no caminho de relatório de erro da ferramenta qvm-copy-to-vm quando um arquivo é copiado do dom0 para um qube. Todas as versões do Qubes OS são afetadas.

Para quem usa Qubes como estação de trabalho isolada (jornalistas, pesquisadores de segurança, advogados, gente que lida com dados sensíveis), o dom0 é justamente a peça que nunca deveria ser comprometida: é dele que parte todo o controle das máquinas virtuais. Uma execução de código ali significa, nas palavras do próprio bulletin, que o atacante "pode assumir o controle do Qubes OS".

O que precisa acontecer para a falha ser explorada

A vulnerabilidade não é acionável remotamente do nada. O boletim é explícito sobre a cadeia de pré-condições:

• Um qube já precisa estar comprometido pelo atacante.
• O usuário precisa iniciar, a partir do dom0, uma chamada qvm-copy-to-vm copiando um arquivo para esse qube comprometido.

Se essas duas condições se combinam, o qube malicioso consegue injetar um comando arbitrário no dom0. Ou seja: é um cenário de escalonamento a partir de um qube já sob controle do adversário, não um ataque de primeiro acesso. Ainda assim, o impacto é o pior possível, porque quebra exatamente a fronteira de isolamento que justifica o uso do Qubes.

Onde está o bug: sanitização incompleta e system()

O qvm-copy-to-vm usa o protocolo "qfile", um formato de arquivo simplificado que inclui, ao final da transferência, uma confirmação enviada pelo destino de volta à origem. Essa confirmação carrega um checksum, um código de erro e o nome do último arquivo recebido, todos controláveis pelo qube de destino. Em caso de erro, o dom0 exibe um diálogo gráfico com essa informação, incluindo o nome do arquivo reportado pelo qube.

O problema está no tratamento desse nome. A função sanitize_remote_filename() percorre a string e substitui por _ apenas caracteres fora do intervalo ASCII imprimível e aspas duplas:

static void sanitize_remote_filename(char *untrusted_filename)
{
    for (; *untrusted_filename; ++untrusted_filename) {
        if (*untrusted_filename < ' ' ||
            *untrusted_filename > '~' ||
            *untrusted_filename == '"')
            *untrusted_filename = '_';
    }
}

Como o próprio boletim resume, essa sanitização deixa passar metacaracteres de shell. O nome, ainda contaminado, chega à função de erro display_error(), que monta o comando do diálogo (kdialog ou zenity) e o executa via system():

ret = stat("/usr/bin/kdialog", &st_buf);
if (asprintf(&dialog_cmd, "%s '%s: %s (error type: %s)'", ...) < 0) {
    ...
}
system(dialog_cmd);

Como system() passa a string pelo shell, o nome de arquivo escolhido pelo atacante é interpretado como comando. É um clássico command injection, agravado por rodar no contexto mais privilegiado do sistema.

O boletim registra que a variante do lado da VM não é afetada, porque sua função de relatório de erro não usa system(): ela faz fork() e chama execlp() diretamente com os argumentos separados, sem passar pelo shell.

Como corrigir

O pacote com a correção é o qubes-core-dom0-linux na versão 4.3.22, para o Qubes 4.3, no dom0. O boletim afirma que nenhuma ação especial é necessária além de atualizar normalmente: o pacote migra do repositório security-testing para o estável após um curto período de testes pela comunidade, e deve ser instalado via ferramenta de atualização do Qubes ou seus equivalentes de linha de comando.

Como é praxe do projeto, o QSB vem acompanhado de assinaturas PGP de Marek Marczykowski-Górecki e Simon Gaiser (HW42). O time reforça que a única forma de garantir que um boletim é autêntico é verificar essas assinaturas contra a Qubes Master Signing Key, procedimento detalhado na própria página do anúncio, algo que faz sentido para quem confia no dom0 como raiz da própria segurança.

A leitura da comunidade

No thread do Hacker News, charcircuit aponta o pecado original do padrão de código:

"Another example for why system() is so dangerous to use. I also don't understand why it needs to show the dialog in dom0. If you have the option to handle attacker controlled input on the unprivileged side, you should do that instead of putting a lot of logic on the privileged side."

charcircuit

A crítica ecoa a própria estrutura da falha: colocar processamento de entrada controlada pelo atacante do lado privilegiado é o tipo de decisão que transforma um bug de string em comprometimento total.

Já polotics relativiza o risco prático para o usuário comum, observando que "I would not have copied anything from dom0 to any another qube, the impact is low", justamente porque copiar arquivos a partir do dom0 é uma operação incomum no dia a dia. É um lembrete útil: o gatilho depende de um hábito que a maioria dos usuários bem-orientados evita.

O que fica em aberto

O boletim não menciona identificador CVE nem indica que a falha tenha sido explorada em campo, apenas credita a descoberta a Tim C. Para o profissional brasileiro que roda Qubes em máquina de trabalho sensível, o recado é direto: rodar a atualização do dom0 assim que o qubes-core-dom0-linux 4.3.22 chegar ao repositório estável, e, no intervalo, tratar operações qvm-copy-to-vm a partir do dom0 como movimento a ser evitado, especialmente para qubes de confiança duvidosa.

Fontes: Hacker News · Reações no Hacker News