Reforçando a segurança de memória das web fonts

 (developer.chrome.com)
3 pontos por GN⁺ 2025-03-21 | 2 comentários | Compartilhar no WhatsApp
  • Skrifa é uma nova biblioteca de processamento de fontes escrita em Rust, desenvolvida para substituir o FreeType e tornar o processamento de fontes no Chrome mais seguro
  • Graças à segurança de memória do Rust, os problemas de segurança são reduzidos e a velocidade de evolução da tecnologia de fontes aumenta
  • Com a transição de FreeType para Skrifa, a qualidade do código melhorou e o tempo para corrigir problemas de segurança foi reduzido

Por que substituir o FreeType

  • No ambiente web, é necessário poder obter recursos não confiáveis de várias origens e usá-los com segurança

  • O Chrome já aplicava várias medidas de segurança para usar web fonts com segurança

    • Sandboxing: como o código não é seguro e as fontes não são confiáveis, ele é executado em um ambiente de proteção separado
    • OpenType Sanitizer: limpa e inspeciona a fonte antes do processamento
    • Fuzzing: testa extensivamente as bibliotecas relacionadas ao processamento de fontes

  • O FreeType é usado como biblioteca padrão de processamento de fontes no Android, ChromeOS e Linux

    • Se surgir uma vulnerabilidade de segurança, há o risco de afetar muitos usuários

Principais problemas de segurança encontrados no FreeType

  • 1. Uso de uma linguagem insegura
    • Como o FreeType foi escrito em C, podem surgir vulnerabilidades como erros de memória e buffer overflow
  • 2. Problemas específicos do projeto
    • Falta de tipos de tamanho explícitos devido ao uso de macros
      • As macros (FT_READ_*, FT_PEEK_*) ocultam tipos de tamanho explícitos (como int16_t)
    • Bugs recorrentes em código novo
      • Houve problemas ao adicionar suporte a COLRv1 e OT-SVG
    • Falta de testes
      • Como é difícil criar fontes de teste complexas, surgiu o problema de cobertura insuficiente de testes
  • 3. Problemas de dependências
    • Houve problemas recorrentes em bibliotecas usadas pelo FreeType, como bzip2, libpng e zlib
  • 4. Limites do fuzzing
    • Arquivos de fonte têm estruturas de dados complexas, o que faz com que alguns problemas não sejam encontrados por fuzzing
      • As fontes incluem regras compostas e máquinas de estado (state machine)
      • Como é difícil gerar estruturas válidas, fica complicado realizar fuzzing de forma eficaz

Adoção do Skrifa e processo de aplicação no Chrome

  • A biblioteca gráfica Skia, usada no Chrome, utiliza o FreeType para metadados e renderização de fontes
  • Para substituir o FreeType por Skrifa, o Chrome reconstruiu o backend de fontes do Skia

Etapas de adoção do Skrifa

  • Chrome 128 (agosto de 2024):
    • Aplicação piloto do Skrifa a formatos de fonte menos usados, como fontes coloridas e CFF2
  • Chrome 133 (fevereiro de 2025):
    • Adoção total do Skrifa no processamento de web fonts em Linux, Android e ChromeOS
    • No Windows e no Mac, ele é usado como processador alternativo quando o sistema não oferece suporte ao formato da fonte

Reforço de segurança e desempenho

  • 1. Maior segurança de memória
    • O Rust garante segurança de memória por padrão
    • No entanto, a biblioteca bytemuck é usada por questões de desempenho
      • Ela é usada quando é necessário reinterpretar bytes com uma estrutura de tipos forte
      • Quando futuras atualizações do Rust permitirem conversões seguras, está prevista a migração para esse recurso
  • 2. Melhoria de correção
    • O Skrifa reforça legibilidade, manutenção e desempenho em multithreading ao garantir a imutabilidade (immutable) das estruturas de dados
    • Aproximadamente 700 testes unitários verificam a qualidade do código
    • A ferramenta fauntlet é usada para comparar a saída do FreeType e do Skrifa → verificar se a qualidade visual é equivalente
  • 3. Testes amplos e reforço de segurança
    • Desde junho de 2024, vêm sendo realizados testes de fuzzing no Skrifa e no código de integração
      • Até o momento, foram encontrados 39 bugs → não são vulnerabilidades de segurança (erros visuais ou falhas controladas)
      • Isso confirma melhorias na qualidade do código sem evoluir para problemas de segurança

Conclusão e próximos passos

  • A adoção do Skrifa com base em Rust fortaleceu a segurança e melhorou a qualidade do código
  • Houve ganho de produtividade no desenvolvimento e os usuários passam a ter um ambiente de fontes mais seguro
  • No futuro, há planos para aplicar o Skrifa ao processamento de fontes do sistema no Linux e no ChromeOS

Leituras relacionadas

2 comentários

 
iolothebard 2025-03-22

Da outra vez foi o zlib, agora é o freetype…
Ver os veteranos de longa data sendo empurrados para fora, um por um… é parecido com o mundo em que as pessoas vivem, né
 
GN⁺ 2025-03-21
Comentários do Hacker News

  • Corrigir problemas encontrados pelo fuzzing no Google exige pelo menos 0,25 engenheiro de software

    • Gosto dessa forma de medir esse trabalho adicional
    • Gostaria que houvesse uma maneira de usar totalmente as instruções de hinting TTF mesmo sem usar o FreeType
    • Parece que Windows e macOS já não têm mais uma forma de ativar hinting adequado
    • O FreeType também passou a definir hinting inadequado como padrão desde a versão 2.7
    • Se quiser ver como fica um texto com hinting adequado, dá para consultar as capturas de tela
    • Suspeita-se que o Windows abandonou o hinting de fontes desde o XP
    • O dimensionamento da interface e a visualização de imagens raster em telas com diferentes resoluções causam borramento

  • A verdadeira força do Rust está na transição gradual em direção à segurança e na capacidade de integração com projetos existentes

    • É possível migrar componentes um por um sem uma reescrita em larga escala

  • Estou aprendendo sobre como as fontes são renderizadas de acordo com o layout de subpixels do painel do monitor

    • O Windows assume que todos os painéis usam layout RGB, e o software ClearType renderiza as fontes com base nessa suposição
    • Em tipos de display mais novos, isso causa franjamento no texto
    • Existem ferramentas de terceiros como MacType e Better ClearType Tuner, mas elas não funcionam no Chrome nem no Electron
    • À medida que novas tecnologias de painel se tornam comuns, será necessário definir um padrão para transmitir o layout de subpixels para a camada gráfica
    • Há algum esforço visível no Blur Busters, mas os fornecedores ainda têm pouca consciência disso

  • O Skia é uma biblioteca avançada que faz layout de texto sofisticado e armazena glifos em cache

    • O Skia é escrito em C++ e foi criado pelo Google
    • O FreeType mede e renderiza glifos, além de oferecer suporte a vários modos de antialiasing e hinting
    • O FreeType é escrito em C e não foi criado pelo Google
    • Fico curioso para saber por que o FreeType foi reescrito em Rust primeiro

  • As fontes passam pelo OpenType Sanitizer antes de serem processadas

    • Fico pensando se o formato de fonte é tão ruim assim a ponto de precisar sanitizar o arquivo
    • Overflow de inteiro foi identificado como uma das causas de vulnerabilidades
    • Muitas linguagens não detectam overflow, e arquiteturas modernas como RISC-V também não incluem traps de overflow
    • Não consigo entender por que linguagens novas como Rust não incluem traps de overflow