Renforcer la sûreté mémoire des polices web

 (developer.chrome.com)
3 points par GN⁺ 2025-03-21 | 2 commentaires | Partager sur WhatsApp
  • Skrifa est une nouvelle bibliothèque de traitement des polices écrite en Rust, développée pour remplacer FreeType et rendre le traitement des polices plus sûr dans Chrome
  • Grâce à la sûreté mémoire de Rust, les problèmes de sécurité diminuent et le rythme d’amélioration des technologies de polices s’accélère
  • Le passage de FreeType à Skrifa a amélioré la qualité du code et réduit le temps nécessaire pour corriger les problèmes de sécurité

Pourquoi remplacer FreeType

  • Dans l’environnement web, il doit être possible de récupérer des ressources non fiables depuis diverses sources et de les utiliser en toute sécurité

  • Chrome appliquait déjà plusieurs mesures de sécurité pour utiliser les polices web de manière sûre

    • Sandboxing : le code n’étant pas sûr et les polices n’étant pas fiables, l’exécution se fait dans un environnement protégé distinct
    • OpenType Sanitizer : nettoyage et vérification des polices avant leur traitement
    • Fuzzing : tests approfondis des bibliothèques liées au traitement des polices

  • FreeType est utilisé comme bibliothèque de traitement des polices par défaut sur Android, ChromeOS et Linux

    • En cas de faille de sécurité, le risque est d’affecter un grand nombre d’utilisateurs

Principaux problèmes de sécurité rencontrés avec FreeType

  • 1. Utilisation d’un langage non sûr
    • FreeType étant écrit en C, des vulnérabilités comme les erreurs mémoire et les dépassements de tampon peuvent survenir
  • 2. Problèmes propres au projet
    • Absence de types de taille explicites à cause de l’usage de macros
      • Les macros (FT_READ_*, FT_PEEK_*) masquent les types de taille explicites (int16_t, etc.)
    • Bugs récurrents dans le nouveau code
      • Des problèmes sont apparus lors de l’ajout de la prise en charge de COLRv1 et d’OT-SVG
    • Manque de tests
      • La difficulté à générer des polices de test complexes a entraîné un manque de couverture de test
  • 3. Problèmes de dépendances
    • Des problèmes récurrents sont survenus dans des bibliothèques utilisées par FreeType comme bzip2, libpng et zlib
  • 4. Limites du fuzzing
    • Les fichiers de police, du fait de leurs structures de données complexes, présentent des problèmes qui échappent au fuzzing
      • Les polices incluent des règles complexes et des machines à états (state machine)
      • Comme il est difficile de générer des structures valides, il est compliqué de mener un fuzzing efficace

Introduction de Skrifa et déploiement dans Chrome

  • La bibliothèque graphique Skia, utilisée par Chrome, s’appuie sur FreeType pour les métadonnées et le rendu des polices
  • Pour remplacer FreeType par Skrifa, Chrome a reconstruit le backend de polices de Skia

Étapes d’introduction de Skrifa

  • Chrome 128 (août 2024) :
    • Déploiement pilote de Skrifa pour des formats de police moins utilisés, comme les polices couleur et CFF2
  • Chrome 133 (février 2025) :
    • Adoption complète de Skrifa pour le traitement des polices web sur Linux, Android et ChromeOS
    • Sur Windows et Mac, utilisation comme processeur de remplacement lorsque le système ne prend pas en charge le format de police

Renforcement de la sécurité et des performances

  • 1. Renforcement de la sûreté mémoire
    • Rust garantit par défaut la sûreté mémoire
    • Toutefois, la bibliothèque bytemuck est utilisée pour des raisons de performance
      • Elle sert lorsqu’il faut réinterpréter des octets avec des structures de types strictes
      • Lorsque de futures mises à jour de Rust permettront des conversions sûres, cette fonctionnalité sera remplacée
  • 2. Amélioration de la précision
    • Skrifa renforce la lisibilité du code, la maintenabilité et les performances multithread grâce à la garantie d’immuabilité (immutable) des structures de données
    • La qualité du code est vérifiée par environ 700 tests unitaires
    • L’outil fauntlet est utilisé pour comparer les sorties de FreeType et de Skrifa → vérification de la correspondance de la qualité de rendu
  • 3. Tests étendus et sécurité renforcée
    • Des tests de fuzzing sont menés sur Skrifa et sur le code d’intégration depuis juin 2024
      • À ce jour, 39 bugs ont été découverts → il ne s’agit pas de failles de sécurité (erreurs visuelles ou crashs contrôlés)
      • Cela confirme une amélioration de la qualité du code sans dérive vers des problèmes de sécurité

Conclusion et plan pour la suite

  • L’adoption de Skrifa, basé sur Rust, a permis de renforcer la sécurité et d’améliorer la qualité du code
  • La productivité de développement augmente et les utilisateurs bénéficient d’un environnement de polices plus sûr
  • À l’avenir, Skrifa devrait aussi être appliqué au traitement des polices système sur Linux et ChromeOS

À lire aussi

2 commentaires

 
iolothebard 2025-03-22

La dernière fois, c'était zlib, cette fois c'est freetype…
Voir les vieux briscards se faire évincer un à un… c'est assez semblable au monde dans lequel vivent les humains.
 
GN⁺ 2025-03-21
Avis Hacker News

  • Chez Google, corriger les problèmes découverts par fuzzing nécessite au moins 0,25 ingénieur logiciel

    • J’aime bien cette façon de mesurer le travail supplémentaire
    • J’aimerais qu’il existe un moyen d’utiliser pleinement les instructions de hinting TTF même sans utiliser FreeType
    • Il semble que Windows et macOS n’offrent plus vraiment de moyen d’activer un hinting correct
    • FreeType aussi utilise par défaut un hinting inadéquat depuis la version 2.7
    • Si vous vous demandez à quoi ressemble un texte correctement hinté, vous pouvez consulter les captures d’écran
    • Je soupçonne que Windows a abandonné le hinting des polices depuis XP
    • La mise à l’échelle de l’interface et l’affichage d’images raster sur des écrans de résolutions variées provoquent du flou

  • La véritable force de Rust réside dans la transition progressive vers la sécurité et dans sa capacité à s’intégrer à des projets existants

    • On peut migrer les composants un par un sans réécriture massive

  • J’apprends comment les polices sont rendues selon l’agencement des sous-pixels du panneau du moniteur

    • Windows part du principe que tous les panneaux utilisent un agencement RGB, et le logiciel ClearType rend les polices selon cette hypothèse
    • Sur les nouveaux types d’écran, cela provoque des franges sur le texte
    • Il existe des outils tiers comme MacType ou Better ClearType Tuner, mais ils ne fonctionnent pas dans Chrome ni Electron
    • À mesure que les nouvelles technologies de panneaux se généralisent, il faut définir une norme pour transmettre l’agencement des sous-pixels à la couche graphique
    • On voit quelques efforts chez Blur Busters, mais la prise de conscience des fournisseurs reste insuffisante

  • Skia est une bibliothèque avancée qui effectue une mise en page de texte avancée et met les glyphes en cache

    • Skia est écrit en C++ et a été créé par Google
    • FreeType mesure et rend les glyphes, et prend en charge divers modes d’anticrénelage ainsi que le hinting
    • FreeType est écrit en C et n’a pas été créé par Google
    • Je me demande pourquoi FreeType a été réécrit en Rust en premier

  • Les polices passent par OpenType Sanitizer avant d’être traitées

    • Je me demande si le format des polices est à ce point mauvais qu’il faille assainir les fichiers
    • Le dépassement d’entier est identifié comme l’une des causes des vulnérabilités
    • Beaucoup de langages ne détectent pas les dépassements, et des architectures modernes comme RISC-V n’incluent pas non plus de piège sur dépassement
    • Je ne comprends pas pourquoi les langages plus récents comme Rust n’incluent pas de piège sur dépassement