Apache HTTPd Devs considéré comme dangereux

[VÉRIFIÉ] Dernière mise à jour par Joe Schaefer sur mer., 13 mai 2026    source

 

Contexte

Au cours des 25 dernières années, j’ai été le développeur principal de apreq sous-projet au sein de Serveur Apache HTTPd Projet parent. L’idée originale de libapreq, en tant que sûr/performant Soumission de formulaire HTML et Piscine parsing library, est né d’une collaboration entre Lincoln Stein et Doug MacEachern à la fin de 90s.

C’était ma vision à l’époque de transformer la bibliothèque en une bibliothèque générique, non liée à Perl. C bibliothèque qui prendrait en charge les liaisons linguistiques à partir d’autres langages de programmation, c’est pourquoi j’ai poussé pour que le projet soit à domicile sous le parapluie HTTPd au lieu de Apache-Perl projet.

Avec l’avènement de httpd-2.X, entièrement nouveau I/O Filter L’architecture a émergé de httpd ainsi que la séparation complète des APR du noyau lui-même en tant qu’exécution de portabilité POSIX à usage plus général pour C projets comme Subversion. En fait, libapreq2 est plus proche de la Apache APR projet dans cet esprit, et son API Perl reflète cela dans son APR::Request buildout. Il dispose d’un mode CGI intégré pour un fonctionnement autonome, en dehors de httpd l’exécution, ce qui rend les tests unitaires un jeu d’enfant.

Pourtant, l’élément clé de apreq2 a toujours été le mod_apreq2 Module Apache, conçu pour la première fois par Bill Wrowe au début 2000s. Ce qu’il a conçu, lors d’une séance de brainstorming avec moi (en personne), était une seule bibliothèque d’analyseurs interne à httpd, qui partage le corps de la demande soumise avec chaque module de parties prenantes clé dans l’exécution. Cela signifiait fournir des données analysées aux modules connectés au moteur de traitement des demandes avant, pendant et après l’exécution du gestionnaire de contenu. Il devait également fonctionner pour les sous-demandes, que le gestionnaire de contenu ait consommé ou non les données analysées, ou qu’il ait consommé et analysé le corps de la demande brute lui-même.

J’ai expliqué les objectifs de conception plusieurs fois au fil des ans, même en 2012 sur dev@httpd. Mais c’était toujours comme parler au vent avec ces gars ; ils ne se souciaient tout simplement pas.

Rassemblement de nuages orageux

Bien que cette vision ait été extrêmement réussie, avec des liaisons linguistiques disponibles pour plusieurs langues comme Perl, PHP, TCL, R, etc., depuis environ 2010, il a prouvé tragique pour la communauté d’utilisateurs existante composé de touspas seulement les membres de Perl communauté.

Que s’est-il passé ? Philip Gollucci, un de mes collègues Perl/FreeBSD à l’époque, a commencé à s’agiter pour promouvoir le projet à sortir de l’intérieur du serveur HTTPd lui-même. Quoi Philippe ne savait pas très bien à l’époque à quel point peevish, vapid et territorial Cette équipe était devenue, qui aurait dû collaborer directement avec eux sur décisions utilisateur sur la base de code.

En 2012, Philippe a obtenu ce qu’il voulait et j’ai cessé de résister. fourchu le projet existant et copié le C composants de la bibliothèque dans le noyau HTTPd.

Chute

En 2018 J’ai démissionné de la Fondation en masse¹. Vous pouvez deviner les raisons.

En 2020 environ, l’équipe de sécurité de Google a profité d’une version alpha de httpd 2.5 en flouant sa copie de 8 ans de apreq2. Ils ont trouvé quelques points chauds qui ont besoin de réparation.

Au lieu d’avoir la courtoisie de tendre la main à Philippe, Issac Goldstand, Max Kellermann (@MaxKellermann), moi-même (@joesuf4), ou toute autre personne impliquée dans le développement de libapreq2, un ingénieur junior de l’équipe HTTPd s’est occupé de “correction de bug” les vulnérabilités trouvées par Google. Vous pouvez voir un enregistrement de son travail d’essai et d’erreur dans chaque version depuis.

Bien sûr, les CVE rapportés ont été écrits par des amateurs :

1. il est impossible de provoquer un débordement de tampon (par conception architecturale), de sorte que ces revendications ont toujours été baloney ; comme en témoigne le fait qu’aucun code d’exploitation n’a jamais été publié.

2. Malgré tous mes efforts, des déréférences de pointeurs NULL étaient possibles ; avec lequel le développeur junior a fait un nettoyage complet il y a des années.

3. J’ai eu un cerveau il y a vingt ans autour des encodages de jeu de caractères pour les en-têtes MIME, qui sont toujours 7 bits ASCII propre quand bien formé. L’erreur de cela logique d’analyseur était la seule préoccupation de sécurité significative dans l’histoire entière de la base de code — et comme un NPE, tout ce qu’un attaquant pouvait faire était de planter le serveur Web. Bien sûr, dans un cadre de pré-fourche, cela vous tire dans le pied en tant que pirate ; mais avec @joesuf4/mod_perl, l’exécuter dans HTTP/2 avec mpm_event est maintenant facilement réalisable. Donc, l’élimination de toutes les formes de pannes de serveur était un travail vital et nécessaire. Le développeur junior mérite beaucoup de crédit pour cette réalisation éventuelle dans le coffre de @apache/apreq. Félicitations.

Mais le coup de grâce a été la libération de 2022 2.17, dans lequel le développeur recrue introduit intentionnellement un bug fatal dans la base de code, rupture un test de régression de dix-neuf ans.

Affaire

Si vous demandez comment quelque chose avec un test de régression cassé / CVE exceptionnel se termine sur CPAN En tant qu’installation permanente, vous devrez examiner comment RELENG est effectuée dans le projet serveur.

Longue histoire courte, Ils ont commenté le test et l’a envoyé quand même, et l’a appelé une version de sécurité qui a corrigé une vulnérabilité chaque version antérieure était susceptible de.

Pourquoi je m’en soucie maintenant ? Parce que je suis le suceur les utilisateurs contactent pour obtenir des réponses en tant qu’expert connu.

Cette suce², mais je suis désolé de vous dire que mes jours de port de la cape Superman à Apache se sont terminés il y a environ une décennie.

Dans tous les cas, le mieux que je puisse faire à ce stade est de vous montrer mon arbre source de production pour libapreq2 — @joesuf4/apreq (et @joesuf4/mod_perl).

Notes de bas de page

1. L’un ne se contente pas “démission de l’ASF”. Pour faire une pause propre, il faut démissionner non seulement de l’adhésion à l’ASF, mais de chaque projet / comité dont un est membre. Sinon, on finit par se noyer dans le spam e-mail d’Apache sans fin.

2. Les mâles bêta ont appelé le projet @apache/apreq et passent à @apache/mod_perl, car les mâles bêta n’ont rien de mieux à voir avec leur temps. Yann Ylavic, le “développeur rookie” au-dessus qui a effectivement travaillé sur apreq alors que ses coéquipiers l’ont échoué, n’a pas voté pour retirer le projet. Sans surprise, parce qu’il est un résolveur de problèmes, pas un mâle bêta.