Chromium Chronicle #5: Programação fora do sandbox

Episódio 5:de Ade em Mountain View, CA (agosto de 2019)
Episódios anteriores

O Chrome é dividido em processos. Alguns estão no sandbox, o que significa que têm acesso reduzido ao sistema e às contas dos usuários. Em um processo em sandbox, os bugs que permitem a execução de código malicioso são muito menos graves.

O processo do navegador não tem sandbox. Portanto, um bug pode dar acesso total de código malicioso a todo o dispositivo. O que você deve fazer de diferente? E qual é a situação com os outros processos?

Diagrama de sandbox

Todo o código tem bugs. No processo do navegador, esses bugs permitem que código malicioso instale um programa, roube dados do usuário, ajuste as configurações do computador, acesse o conteúdo de todas as guias do navegador, dados de login etc.

Em outros processos, o acesso ao SO é limitado por restrições específicas da plataforma. Para mais informações, consulte o guia de implementação de sandbox do Chrome.

Evite os erros comuns a seguir:

regra de dois

  • Não analise nem interprete dados não confiáveis usando C++ no processo do navegador.
  • Não confie na origem que um renderizador afirma representar. O RenderFrameHost do navegador pode ser usado para conseguir a origem atual com segurança.


O que fazer

Em vez disso, use as seguintes práticas recomendadas:

  • Seja paranoide se o código estiver no processo do navegador.
  • Validar toda a IPC de outros processos. Suponha que todos os outros processos já estejam comprometidos e possam enganar você.
  • Faça o processamento em um renderizador ou processo utilitário ou algum outro processo em sandbox. O ideal é usar também uma linguagem segura para a memória, como JavaScript (que resolve mais de 50% de bugs de segurança).

Durante anos, executamos pilhas de rede (por exemplo, HTTP, DNS, QUIC) no processo do navegador, o que levava a algumas vulnerabilidades críticas. Em algumas plataformas, a rede agora tem um processo próprio, com um sandbox chegando.

Outros recursos

  • Regra de dois do Chromium: no máximo dois dados não seguros, código não seguro e processo não seguro.
  • Como validar dados da IPC: um guia sobre como garantir que as IPCs do processo do renderizador não estejam cheias de fibs e declarações falsas.