Vulnerabilidade de execução arbitrária de código que rompe o sandbox no KDE Plasma

 (blog.kimiblock.top)
1 pontos por GN⁺ 5 시간 전 | 1 comentários | Compartilhar no WhatsApp
  • Foi comprovado em um PoC que, devido ao comportamento de gerenciamento de janelas do KDE Plasma, apps em sandbox podem executar binários arbitrários do host a partir de uma ação de clique do usuário
  • A causa central é que o KWin confia no app_id fornecido pelo app e manteve um caminho de execução baseado em /proc/PID/cmdline sem correspondência real com o arquivo .desktop
  • O PoC reproduz o fluxo em que /usr/bin/kcalc é executado fora do sandbox combinando um host Arch Linux, um app Flatpak e uma versão modificada do eglgears_wayland do Mesa
  • Quando o usuário seleciona Open New Window no ícone da barra de tarefas ou clica com o botão do meio, o processo alvo é iniciado exposto no cgroup app.slice e no namespace de montagem do host
  • Para mitigar, é preciso verificar o ID do app pelo contexto de segurança do sandbox, XdpAppInfo e control groups, além de bloquear a abertura de nova janela para janelas que não correspondam a um arquivo .desktop

Fluxo de escape do sandbox mostrado pelo PoC

  • Um app malicioso em sandbox pode se passar por outro app e executar binários arbitrários no host no momento em que o usuário aciona Open New Window
  • O PoC foi reproduzido com Flatpak, mas o texto conclui que ele também pode se aplicar a outros sandboxes, independentemente de suportarem contexto de segurança
  • A configuração do experimento foi a seguinte
    • Host Arch Linux
    • Dependências de build wget, unzip, meson
    • App Flatpak sem permissões io.github.johannesboehler2.BmiCalculator
    • Como compilar dentro do sandbox não era simples, apenas o caminho do binário malicioso foi passado ao Flatpak
    • Binário alvo definido: /usr/bin/kcalc
  • Quando o binário malicioso é executado, a barra de tarefas mostra o ícone do KCalc
  • Se o usuário clicar com o botão direito e escolher Open New Window, /usr/bin/kcalc será iniciado fora do sandbox
    • O local de execução é o cgroup app.slice
    • O namespace de montagem é o do host
    • Na prática, ele é executado totalmente exposto

Processo de descoberta e indícios

  • Ao testar sandboxes Portable no KDE Plasma em uma máquina virtual QEMU, foi observado que algumas janelas não eram associadas ao arquivo .desktop correto e apareciam na barra de tarefas com um ícone genérico do Wayland
  • Esse fenômeno foi reportado em KWin trusts on Apps fully for app_id e leva ao problema de um app poder se passar por outro
  • Depois, um clique acidental com o botão do meio na barra de tarefas acionou o comportamento padrão de Open New Window
  • A nova janela foi aberta, mas não usou as credenciais de login salvas nem as configurações modificadas; ao verificar juntos o PID no KWin Debug Console e as informações de control groups e rootfs no procfs, o escape do sandbox ficou evidente

Como a vulnerabilidade funciona

  • Mesmo quando o KWin não consegue associar a janela ao arquivo .desktop real, ainda resta um caminho para encontrar o argv0 a ser executado
  • Os testes confirmaram a suspeita de que o valor é lido por meio de /proc/PID/cmdline
  • O problema não se limita a executar fora do sandbox uma instância de aplicativo já existente
  • Todos os processos, inclusive processos sem privilégios, podem alterar o argv0
    • O namespace de montagem também poderia ser usado, mas foi considerado menos flexível
  • A combinação da falta de proteção para o app_id fornecido pelo app com a insegurança da leitura de /proc/PID/cmdline torna possível a execução arbitrária de código no host

Demo e cenário de ataque real

  • O código da demo foi escrito por GalaxySnail e usa o eglgears-wayland do Mesa
  • O fluxo da demo é o seguinte
    • Clonar o repositório mesa-demos-argv0
    • Modificar, dentro da função main de src/egl/opengl/eglgears.c, o comando especificado para o comando desejado
    • Compilar com meson setup build && meson compile -C build
    • Executar ./build/src/egl/opengl/eglgears_wayland
    • Clicar com o botão do meio no ícone da barra de tarefas ou escolher Open New Window no menu de contexto
    • O binário malicioso especificado será iniciado
  • Em um ataque real, seria possível criar um script de shell em $HOME
    • Em geral, $HOME também fica no mesmo caminho no host
    • O app malicioso pode trocar silenciosamente o argv0 por um binário criado ou baixado
    • Se o usuário clicar em Open New Window ou acidentalmente usar o botão do meio no ícone do app, a sessão poderá ser completamente comprometida

Direção proposta para correção

  • Para bloquear esse exploit, o KDE Plasma não deve confiar cegamente no ID fornecido pelo app
  • Foi proposto que o ID do app seja obtido a partir dos seguintes caminhos
    • Contexto de segurança do sandbox
    • XdpAppInfo
    • Control groups
  • Se uma janela específica não corresponder a um arquivo .desktop, Open New Window não deve ser permitido
  • O autor afirma que não recebeu atualizações da lista de segurança do KDE

Linha do tempo da divulgação

  • No e-mail original, arbitrary code execution foi incorretamente abreviado como RCE
  • Todos os eventos usam UTC+8 e formato de 24 horas
  • 1 de abril de 2026 às 23:51: primeiro e-mail enviado para security@kde.org
  • 2 de abril de 2026 às 00:15: David Edmundson respondeu confirmando o relatório
  • 2 de abril de 2026 às 00:24: David Edmundson respondeu que acreditava que a funcionalidade usava o Exec= do arquivo .desktop e não poderia ser usada para execução arbitrária de código
  • 2 de abril de 2026 às 11:59: com ajuda de GalaxySnail, foi confirmado que outro PoC que não dependia do arquivo .desktop também funcionava
  • 2 de abril de 2026 às 18:26: um e-mail de acompanhamento com o arquivo do exploit e a explicação foi enviado para security@kde.org, mas não houve resposta
  • 2 de maio de 2026 às 11:59: foi confirmado que o exploit não havia sido corrigido no Plasma 6.7 Beta
  • 2 de julho de 2026 às 18:30: como o exploit permaneceu ativo além do período de espera de 90 dias, a divulgação foi realizada
  • Como não houve correção, nem resposta ao acompanhamento, e o período usual de 90 dias já havia passado, decidiu-se publicar o caso para conscientização
  • O texto acrescenta que não se trata de uma tentativa de criticar os desenvolvedores do KDE; projetos OSS vêm sofrendo com spam recentemente e pessoas têm limites de capacidade, mas o processo pode melhorar

Leituras relacionadas

1 comentários

 
GN⁺ 5 시간 전
Comentários no Lobste.rs
  • Eu realmente gostaria que a tentativa de levar o Capsicum para Linux não tivesse morrido por NIH
    Para sandboxing de apps de desktop, é um modelo muito melhor do que a miscelânea de abordagens que foram empilhadas no Linux para tentar fazer a mesma coisa. O launcher passa, com base nos metadados, o conjunto inicial de permissões — isto é, descritores de arquivos —, e o app não consegue acessar nada além disso; uma powerbox fornece as permissões para abrir e salvar outros arquivos
    • Todo o modelo de contêineres do Linux parece uma colcha de retalhos de conceitos meio desajeitados
      Em geral ele serve para ambientes em que algum processo “divino” orquestra serviços, como um serviço do Kubernetes, mas não se encaixa bem no desktop. Você quer entrar, a partir do espaço de usuário, em um cgroup/namespace com menos privilégios, mas precisa passar por rituais como um daemon root ou setuid, o que acaba trazendo risco de escalonamento de privilégios
    • Em tese, as principais ferramentas de sandboxing para desktop Linux, como o Flatpak, deveriam funcionar assim, usando SCM_RIGHTS + Wayland + D-Bus como blocos básicos
      Se você apertar um pouco os olhos, dá para enxergar os contornos de um desktop seguro
      Mas as implementações reais, no geral, são permissivas demais, inflexíveis demais ou meio quebradas. Parece que ninguém se importa com segurança de desktop de ponta a ponta tanto quanto se importa com a segurança de workloads de servidor. Por isso gVisor e Firecracker funcionam bem, enquanto o Flatpak tem dificuldade até para executar um app Gtk+ básico sem quebrar as fontes, e todo compositor Wayland precisa reimplementar metade da base de um desktop confiável
      Isso fica ainda mais constrangedor quando se considera que o Android fez um trabalho bem decente como uma distribuição Linux suficientemente reforçada para executar código não confiável, e que iOS e macOS mostraram que sandboxing de apps voltados ao usuário também pode ser suficientemente fácil de usar. É só fazer como eles fazem. Por que diabos algo dentro de um gerenciador de janelas está lendo /proc/{pid}/cmdline?
  • Não pega bem a situação ter ido para uma divulgação pública depois que o upstream não conseguiu corrigir
    Isso não é, de forma alguma, uma crítica ao pesquisador
  • Não sei se o relatório de issue enviado ao upstream também era assim, mas foi bem difícil de acompanhar
    Acho que teria entendido muito melhor se estivesse mais familiarizado com a estrutura interna do KDE ou do Flatpak