Rapport d’audit de Homebrew

Audit de Homebrew

• Aperçu de l’audit de Homebrew
  • Audit des aspects liés à la sécurité de Homebrew, y compris Homebrew/brew et trois dépôts associés
  • Les problèmes découverts ne sont pas critiques, mais ils peuvent permettre à un attaquant de charger du code exécutable à un moment inattendu et de compromettre l’intégrité de Homebrew
  • Réalisé avec le soutien de l’Open Tech Fund

Homebrew

• Présentation de Homebrew

  • Gestionnaire de paquets pour macOS et Linux
  • Largement utilisé par les développeurs logiciels, avec des millions d’installations de paquets traitées
  • Comme il inclut des paquets importants tels que Golang, Node.js et OpenSSL, la sécurité de Homebrew est essentielle à celle de l’ensemble de l’écosystème logiciel

• Historique de Homebrew

  • Depuis son lancement en 2009, le projet a connu plusieurs changements d’architecture
  • Adoption des builds binaires (bottles) comme mécanisme d’installation par défaut en remplacement des builds locaux à partir des sources
  • L’intégrité des builds est maintenue via le CI/CD

Périmètre de l’audit

• Questions de l’audit
  • Un acteur local peut-il exécuter la DSL officielle sans brew install ?
  • Un acteur local peut-il évaluer la DSL officielle avec le seul brew tap ?
  • Peut-il provoquer une confusion ou des collisions d’espace de noms ?
  • Une formule installée localement peut-elle contourner le mécanisme d’isolation des builds de Homebrew ?
  • Un acteur CI/CD à faibles privilèges peut-il escalader vers des privilèges plus élevés ?
  • Un acteur CI/CD à faibles privilèges peut-il contaminer les builds de bottles ?
  • Un acteur CI/CD à faibles privilèges peut-il maintenir une persistance dans le CI/CD ?

Principales conclusions

brew

• Principales conclusions
  • Une formule peut échapper au sandbox via une interpolation de chaînes
  • Une fonction de hachage sujette aux collisions (MD5) peut être utilisée pour provoquer une confusion à l’exécution
  • Une formule peut inclure dans le build des ressources réseau non déclarées
  • Une évasion du sandbox est possible via un pivot de socket
  • Une élévation de privilèges peut être réalisée via un jeton sudo
  • Il est possible d’installer une formule depuis une URL non locale

CI/CD de Homebrew

• Principales conclusions
  • En utilisant le déclencheur pull_request_target, un PR tiers peut exécuter du code dans le dépôt amont de Homebrew
  • Une injection shell est possible via les entrées de workflow_dispatch
  • Le manque de sandboxing/isolation lors de l’extraction d’archives peut permettre une escalade de privilèges
  • L’installation d’une formule depuis une URL non locale peut conduire à l’exécution de code arbitraire

Principaux enseignements

• Défis de l’audit des écosystèmes de gestion de paquets

  • Par conception, les outils de gestion de paquets installent et exécutent du code arbitraire provenant de tiers
  • Dans un écosystème de packaging comme Homebrew, le format de paquet (la formule) est lui-même du code exécutable

• Collaboration autour de l’audit

  • Collaboration étroite avec les mainteneurs de Homebrew et Homebrew PLC
  • Remerciements au responsable sécurité de Homebrew, Patrick Linnane

Le résumé de GN⁺

• Homebrew est un gestionnaire de paquets largement utilisé sur macOS et Linux
• L’audit a mis en évidence des problèmes de sécurité qui, sans être critiques, existent bien
• La sécurité de Homebrew est importante pour celle de l’ensemble de l’écosystème logiciel
• En raison de la nature même des outils de gestion de paquets, capables d’exécuter du code arbitraire de tiers, les audits de sécurité sont essentiels
• Parmi les outils de gestion de paquets aux fonctions similaires, on peut citer apt et yum