La panique autour de PHP prouve qu’on ne peut plus corriger à vitesse humaine

Que dit-il de l’état de la sécurité sur internet quand la décision responsable consiste à éteindre son site ? C’est le conseil que des agences du monde entier ont donné cette semaine, et de nombreuses organisations l’ont suivi.

La semaine où la solution la plus sûre était de tout éteindre

Deux failles critiques dans PHP, le langage qui fait tourner une grande part du web, ont été découvertes avec des outils d’IA. Selon la BBC, la PHP Foundation a publié un correctif mercredi, et des agences dont le NCSC britannique ont indiqué que les organisations incapables de corriger immédiatement devaient envisager de mettre leurs systèmes hors ligne. La Finlande a temporairement coupé ses services web publics, l’agence néerlandaise de cybersécurité a mis son propre site hors service, et certaines parties de Wikipédia sont devenues inaccessibles. La NSA a prévenu que ces bogues donnent souvent un accès direct au système de fichiers ou à la base de données d’un serveur.

Ces failles étaient passées inaperçues pendant plus d’une décennie. Des détails ont fuité sur les réseaux sociaux avant la divulgation prévue, ce qui a forcé une annonce précipitée. Le directeur technique de Cloudflare a dit observer déjà des attaques précoces.

Le bogue n’est pas le sujet; le chronomètre, si

De vieux bogues profondément enfouis existent dans toute grande base de code. Ce qui a changé, c’est qui les trouve et à quelle vitesse. Wiz affirme que les modèles de pointe ont permis à ses chercheurs de développer en quelques heures des exploits fonctionnels sur plusieurs applications. OpenAI, qui dit que ses outils ont aidé à trouver les failles, écrit que ces mêmes capacités « peuvent aussi aider les attaquants à développer rapidement des outils offensifs et des exploits ».

Comparons avec le côté des défenseurs. The Record rapporte que l’un des bogues remonte à un audit de 2024, puis est resté en suspens pendant des mois, une petite équipe de développeurs principaux peinant à arbitrer des questions de compatibilité. Nous ne les blâmons pas. Leur raisonnement paraît sensé dans un monde où personne ne pouvait exploiter rapidement le bogue. Ce monde n’existe plus.

À notre avis, voilà le décalage central: la découverte prend désormais des semaines ou des heures, tandis que la correction par consensus, l’empaquetage puis le déploiement dans des milliers d’organisations prennent des mois. Quiconque se trouve dans cet intervalle est exposé.

Éteindre les sites est un symptôme, pas une stratégie

Retirer un site du réseau fonctionne, et nous pensons que les agences ont eu raison de le dire. Mais c’est un frein d’urgence, pas un plan. Don Smith, de Sophos, a mis le doigt sur le vrai problème: avant de corriger, il faut trouver tous les endroits où PHP tourne, y compris dans les systèmes de gestion de contenu, les plateformes d’hébergement et les produits tiers, parfois à l’insu de l’organisation.

C’est un problème d’inventaire, et on ne le règle pas le jour de la publication de l’alerte. Nous soupçonnons que les organisations qui savaient ce qu’elles exploitaient ont pu corriger ou isoler en quelques heures, tandis que les autres ont dû deviner, et deviner mène au black-out.

Il y a aussi un groupe plus difficile: les systèmes anciens. Selon The Record, les correctifs ne couvrent que PHP 8.2 et les versions ultérieures, et le média cite des estimations de Cisco Talos selon lesquelles environ 50 % des systèmes PHP vulnérables pourraient ne recevoir aucun correctif. Ces exploitants ne peuvent pas s’en sortir par l’automatisation avec une version non prise en charge. Pour eux, la fenêtre d’exposition ne se referme pas; elle reste simplement ouverte. C’est la partie sous-estimée de cette histoire.

Les défenseurs doivent traiter l’inventaire et la vitesse comme des contrôles

Premièrement, considérer l’inventaire comme un contrôle de sécurité. Connaître chaque instance PHP, y compris celles que les éditeurs intègrent, et interroger directement les fournisseurs.

Deuxièmement, automatiser la partie fastidieuse: déploiements progressifs, retours arrière testés et circuits d’urgence préapprouvés pour qu’une mise à jour critique n’attende pas un comité. Les mainteneurs ont besoin de la même chose; la PHP Foundation dit modifier sa structure interne pour que les bogues graves remontent plus vite à sa direction.

Troisièmement, retirer les versions non prises en charge avant la prochaine alerte, pas pendant.

Il existe un contre-argument légitime. OpenAI note qu’à sa connaissance, une IA de pointe a trouvé ces failles avant les attaquants, ce qui donne une longueur d’avance aux défenseurs, et l’entreprise s’est engagée à fournir 1 milliard de dollars d’accès subventionné aux organisations disposant de peu de ressources en sécurité. C’est encourageant, même s’il s’agit de la présentation de l’entreprise elle-même, et la fuite comme les attaques précoces montrent à quelle vitesse une avance s’évapore. Le PDG de Chainguard a déclaré que le secteur devait « trouver comment les traiter plus vite, de façon plus coordonnée et mieux », et nous sommes d’accord. OpenAI s’attend aussi à ce que des découvertes similaires augmentent fortement dans les mois à venir. Prenons cela comme une prévision, mais plausible.

Le verdict: cette semaine était une répétition. Les organisations capables de corriger en quelques heures verront la prochaine fois comme un mardi ordinaire. Toutes les autres répéteront de nouveau le black-out.