Análise aprofundada da nova syscall `mseal` do Linux

Análise aprofundada da nova chamada de sistema mseal do Linux

• mseal é uma nova chamada de sistema introduzida no kernel Linux versão 6.10, oferecendo a funcionalidade de "selagem de memória" para proteção de memória.
• Essa chamada de sistema torna imutáveis determinadas regiões de memória contra modificações ilegítimas durante a execução do programa, impedindo que invasores alterem permissões de memória ou manipulem o layout da memória.
• mseal foi projetada para impedir execução de código por atacantes remotos, sendo diferente de memfd_create e memfd_secret, que já existiam para defender contra atacantes locais ao armazenar dados sensíveis na memória.

Como o mseal funciona

• A assinatura da função mseal é simples: ela recebe um endereço inicial e um comprimento para selar a região de memória correspondente.
• A função do_mseal bloqueia a região de memória e, por meio de check_mm_seal e apply_mm_seal, valida e sela essa região.
• Regiões de memória seladas não podem ter permissões alteradas, ser desmontadas nem redimensionadas por chamadas de sistema como mprotect, munmap e mremap.

Técnicas de ataque das quais o mseal protege

• Reforço de NX: mseal impede a alteração da permissão de execução da VMA, bloqueando ataques baseados em shellcode.
• Mitigação de ataques somente de dados baseados em unmapping: mseal evita a liberação arbitrária e o remapeamento de regiões de memória, barrando ataques somente de dados.

Fortalecimento de software com mseal

• mseal pode reforçar a segurança ao selar regiões específicas de memória de um software.
• Desenvolvedores podem usar mseal para selar seletivamente regiões de memória que possam conter dados não confiáveis.
• À medida que a integração com a glibc avança, há possibilidade de serem adicionados recursos de selagem automática.

Resumo do GN⁺

• mseal é um novo recurso de segurança introduzido no kernel Linux que sela regiões de memória para impedir a execução de código por atacantes remotos.
• Diferentemente dos métodos tradicionais de proteção de memória, essa chamada de sistema evita mudanças de permissão e o unmapping da memória, bloqueando ataques somente de dados.
• A introdução de mseal desempenha um papel importante no reforço da segurança de software, e sua integração com a glibc deve ampliar os casos de uso.
• Outros projetos com funcionalidades semelhantes incluem memfd_create e memfd_secret, voltados à proteção de memória.

[GN⁺]

Comentários no Hacker News

• Foi mencionado que houve uma "discussão acalorada" na lista de e-mails do kernel. Há um comentário perguntando se alguém de dentro poderia resumir as objeções e preocupações, já que a lista de e-mails tende a ser evitada por ser intensa demais

  • O mecanismo em si parece razoável, mas é surpreendente que ainda não existisse no kernel

• O Chrome quer essa chamada, mas como um invasor pode remapear com outras flags, não é possível desfazer o selo de páginas seladas

  • Isso significa que ela não pode ser usada em páginas alocadas em tempo de execução, a menos que a intenção seja mantê-las durante toda a vida do processo
  • Foi levantada a pergunta se isso significa que não pode ser usada em memória como a de um sandbox de JS
  • Não estou familiarizado com a forma como o Chrome gerencia memória/processos, então não tenho certeza de por que isso não seria um problema

• Foi fornecido um link para mseal() e para artigos posteriores sobre o assunto

• Há tristeza pelo fato de que, embora arquiteturas modernas (x86_64) tenham muitos recursos que promovem programação segura, o sistema operacional ainda precise implementar chamadas como essa

  • Tentativas de remendar sistemas legados acabam prejudicando o progresso da computação e colocando bilhões de pessoas em risco
  • Existem bugs de arquitetura, mas o software não consegue aproveitar adequadamente os recursos atuais

• Há uma pergunta sobre se a system call mseal pode ser anulada com truques de LD_PRELOAD

• O protótipo de mseal() no artigo não está sintaticamente correto. O primeiro argumento deveria ser unsigned long start_addr, e não unsigned start addr

• O OpenBSD já tem esse recurso há muito tempo. Foi levantada a dúvida sobre por que ele só está sendo introduzido no Linux agora