De nombreux sites publics sont hors service ce jeudi, et ce depuis la veille. Derrière ces coupures volontaires et préventives, on retrouve deux failles critiques affectant PHP, un langage informatique méconnu mais présent sur une large part du Web.
Ils ont raison de couper, moi j’ai tout patché cette nuit mais en attendant, nous étions vulnérable et cloudflare a déjà indiqué que des attaques avaient commencées. Pour une fois, l’État a pris la bonne décision !
3 « J'aime »
Ma distrib linux (manjaro) vient de me soumettre les updates sûrement liés aux dernières alertes
Les 3 du haut = sûrement le certificat indien troué et celle ci en bas.
Bon ce n’est pas un serveur donc je ne me sens pas trop concerné mais je suppose que les serveurs de mise a jour des distribs vont tourner à plein qq heures
Au final combien de sites vont rester les portes grandes ouvertes, c’est cela la blague. N’y aura t’il pas une explosion des attaques massives rendues bien plus facile avec des tonnes de serveurs zombies?
1 « J'aime »
Mettre les sites hors ligne pour se mettre en sécurité: ok.
Par contre, s’ils ne remontent pas, c’est parfois (souvent?) lié à l’utilisation d’un vieux PHP 5 ou 7 - les « breaking changes » de PHP 7 → PHP 8 nécessitent de refaire des tests profonds de l’appli (raison pour laquelle je déteste PHP: les breaking changes impossibles à tracker).
Donc on peut se demander si les sites qui tardent à remonter n’étaient pas déjà sous une bien vieille version…
1 « J'aime »
Les breaking change don’t tu parle sont la pire connerie de php. Rendre tout un logiciel « non compatible », à cause d’une manière d’écrire / coder qui ne leur va pas (et ça s’entend, je critique pas cela) , pose ces soucis majeurs.
Oui, c’est possible, hélas. C’est le problème avec le versions qui cassent la compatibilité. La priorité est rarement de faire un portage vers la nouvelle version tant qu’il n’y a pas une raison majeure de le faire (coût difficile à justifier auprès des décideur…) et quand arrive la faille sur la version non maintenue, c’est déjà trop tard…
Mais les versions supportées (8.2+) représentent quand même 86% des utilisations actuelles (bon, avec les biais habituels de ce genre de stats, notamment comme c’est basé sur les download de packages sur packagist, les sites et applications qui ne sont plus activement développés mais toujours en service n’apparaissent pas du tout, et donc ça conduit forcément à une surreprésentation des versions récentes).
Et exceptionnellement la fondation PHP a patché cette faille aussi sur des versions non supportées de PHP (7.4, 8.0 et 8.1), mais sans fournir officiellement de binaires. En comptant celles là, on arrive à 97% des utilisations.
Ça m’a permis de mettre à jour un de mes conteneurs qui tourne encore sur une version 7.4 (et ça tourne encore en 7 parc que c’est un truc que je ne porterai jamais en 8, c’est un ancien site, fait à l’époque de PHP 5, que je garde surtout par nostalgie, mais je ne fait plus de PHP depuis des années, donc le jour où je ne pourrai plus le garder dans des conditions acceptables de sécurité, je le mettrai totalement hors-ligne).
C’est sûr que c’est pas idéal. Mais dès fois il faut quand même aussi savoir couper les vieilles branches pour ne pas les trainer éternellement… C’est ce qui permet d’assainir la base de code et de la garder maintenable. Mais c’est vrai que côté PHP c’est particulièrement problématique (la faute à un historique contenant beaucoup de choses à assainir 
), mais ça existe aussi dans d’autres langages. Le passage de Python 2 à Python 3 a par exemple été très violent en termes de compatibilité, et à chaque mineure de Python il y a presque toujours des petits soucis, même si le but c’est de rester un maximum compatible, et dans quelques temps il risque d’y avoir pas mal de problèmes quand le free threading va être activé par défaut.
Il y a au final assez peu de langages qui n’ont jamais de breaking change. Je dirai essentiellement Rust et Go à ma connaissance, mais c’est encore des langages relativement « jeunes », donc même s’ils ont une politique clairement axée sur une rétrocompatibilité maximale, c’est quand même pas exclu qu’à un moment ils soient obligés de faire un breaking change.