Deux commits ont été poussés le 28 mars sur le serveur git.php.net. Leurs auteurs ? Rasmus Lerdorf et Nikita Popov, respectivement le créateur du langage et l’un des principaux développeurs de JetBrains. Il s’agissait cependant d’impostures.
« Nous ne savons pas encore comment cela s’est produit exactement, mais tout pointe vers la compromission du serveur git.php.net (plutôt que la compromission d’un compte git individuel) », a indiqué Nikita Popov.
Les changements faisaient référence à de soi-disant corrections orthographiques (« Fix Typo »). En vérité, des modifications pour amener à l’exécution d’un code PHP arbitraire depuis l’en-tête HTTP useragent, si la séquence commence par « zerodium ».
Zerodium est une entreprise bien connue dans le monde de la sécurité. Elle collecte les failles 0day pour les revendre. Elle propose régulièrement jusqu’à plusieurs millions de dollars pour une brèche exploitable, notamment dans les nouvelles versions d’iOS quand elles sortent. Les pirates pourraient avoir voulu lui revendre la faille du serveur PHP, mais il n’y a aucune preuve.
On ne sait pas actuellement si le code a été téléchargé durant le peu de temps qu’il est resté en ligne. Les modifications ont bien sûr été annulées.
Dans le sillage de cet incident, l’équipe de développement a pris plusieurs décisions radicales. Tout le projet PHP a déménagé chez GitHub, et y restera a priori. En outre, toute contribution au projet réclamera désormais que l’auteur ait d’abord été ajouté à l’organisation sur GitHub.
Commentaires (26)
#1
Aïe… Encore github… Je trouve ça dommage que les plus grands projets open source ne soient plus auto hébergés.
#1.1
Tout à fait, c’est dommage. Mais bon c’est une chose de moins à maintenir.
D’ailleurs je suggère a NXI, de supprimer le petit « v7 » de l’illustration de cette brève, car plus très à la page… Une chose en moins à maintenir 😉
#1.2
Je maintiens un GitLab pour ma boite, y’a quoi comme truc à sécuriser sur le serveur?
Il est à jour et tout.
Merci
#1.5
https://about.gitlab.com/blog/2020/05/20/gitlab-instance-security-best-practices/
#1.7
je check, merci !
#1.6
C’est hors de mon champ de compétences. Ça reste un travail supplémentaire que de simplement le mettre à jour.
Et d’après les commentaires ci dessus, ce n’était pas fait, ou pas comme ça aurait dû.
#1.3
Étrange réaction pour un article qui parle d’un hack sur un serveur git auto hébergé. C’est peut être vertueux d’héberger soit même ses services mais si tu ne peux pas t’en occuper sérieusement autant se reposer sur une boite dont c’est le boulot avant de te faire hack ou de voir ton serveur partir en fumée.
#1.4
Quelle importance ? Git libère les développeurs de toutes contraintes. Si demain GitHub ne fait plus le taff ils migrent n’importe où en quelques clics. C’est ce que toute cette histoire démontre, et c’est plutôt positif.
#2
Le jour où github se fera trouer, on rigolera peut être moins ;-)
#2.1
Alors que quand c’est le serveur auto-hébergé du code source du langage de programmation utilisé par 80% des sites web du monde qui se fait trouer, on rigole beaucoup plus ;-)
#3
@nextinpact : Nikita Popov est un garçon, pas une fille.
Et sinon, ça fait quelques années que le dépôt PHP était sur Github mais ils ne s’en servaient que comme miroir du dépôt officiel qui était auto-hébergé.
#4
Il y a des alertes sérieuse régulièrement.
Depuis le début de l’année il y a au moins eu un problème sur leur système d’auth (certains utilisateur se retrouvait connecté à un compte qui n’étais pas le leur) et des soucis avec leur CI qui permettait de lancer des pipeline avec un compte non autorisé (ce qui peut permettre de faire pas mal de choses aussi, ça a été essentiellement utilisé pour miner des crypto a priori…).
#5
Github troué, ça a une portée largement supérieure au gitlab de PHP (surtout que ça touchera aussi PHP du coup).
#5.1
Alors ça dépend quand même. Si c’est pour faire de l’injection de code dans les sources hébergées, ça va pas être très discret sans social engineering. Faut parier sur le principe que personne ne verra ce commit bizarre ajouté à l’improviste.
Pour des attaques ciblées, c’est plutôt faisable, mais les cibles intéressantes sont aussi celles qui sont le plus à même de détecter ce genre d’injections bizarres. Et comme la moindre tentative échouée équivaut à perdre l’accès à ta super faille, bah tu crames pas tes chances sur le premier projet venu.
#5.2
Bizarre de comparer situations réelles et hypothétiques mais bon, pourquoi pas.
#6
Quel manque d’imagination :-)
#7
Hmm… L’injection de code est carrément évidente ici. Il y avait des moyens plus discret pour insérer une faille que marquer en clair “ZERODIUM” et faire un zend_eval_string().
#8
Le commit en question : https://github.com/php/php-src/commit/c730aa26bd52829a49f2ad284b181b7e82a68d7d
#9
Pour info, le serveur git de PHP était un vieux gitweb (2006), dont l’IP du serveur est visible dans le titre de la page.
Le serveur git est en 2.11, qui date de 2016.
Autrement dit, ils n’ont pas l’air d’avoir passé beaucoup de temps sur la config / maintenance du serveur, ce n’est donc que très peu étonnant si une faille a été trouvée dessus.
Un Gitlab (dockerisé pour faciliter le déploiement) sera “de base” probablement largement mieux sécurisé.
#9.1
Ah oui c’est violent en effet.
#10
Ouai, mais l’imagination, ça ne remplis pas le porte-monnaie, le minage de crypto, si.
#11
sans compter qu’une grande quantité des dépôts dits open source contiennent (intentionnellement ?) des malwares
#11.1
Des preuves pour étayer tes propos ?
#12
L’autre avantage de cette migration c’est une augmentation de la visibilité et probablement une augmentation des contributions
#13
Hypothétique, pas plus que ça (tous les grands de l’IT se sont fait trouer un certain nombre de fois, et ça ne s’arrêtera pas comme ça).
#14
Pas exactement, dans les commits malveillants, c’est “HTTP_USER_AGENTT”, avec deux “T” à la fin.