Desarrolladores de Apache HTTPd considerados perjudiciales
Joe Schaefer
Antecedentes
Durante los últimos 25 años, he sido el desarrollador principal de apreq subproyecto dentro del Servidor HTTPd de Apache Proyecto principal. La idea original de libapreq, como seguro/performante Envío de formulario HTML y Cookie La biblioteca de análisis, surgió de una colaboración entre Lincoln Stein y Doug MacEachern a finales de 90s.
Fue mi visión en aquel entonces transformar la biblioteca en un genérico, no relacionado con Perl. C biblioteca que soportaría enlaces de lenguaje de otros lenguajes de programación, por lo que propuse que el proyecto se alojado bajo el paraguas HTTPd en lugar del Apache-Perl proyecto.
Con la llegada de httpd-2.X, totalmente nuevo I/O Filter arquitectura surgida de httpd núcleo, así como la separación completa de APR desde el propio núcleo como un tiempo de ejecución de portabilidad similar a POSIX de propósito más general para C proyectos como Subversion. De hecho, libapreq2 está más estrechamente alineada con la Apache APR proyecto en ese espíritu, y su API de Perl refleja que como parte de su APR::Request acumulación. Tiene un modo CGI incorporado para el funcionamiento independiente, fuera de la httpd tiempo de ejecución, lo que hace que las pruebas de unidades sean muy sencillas.
Sin embargo, el componente clave de apreq2 siempre ha sido el mod_apreq2 módulo Apache, que fue concebido por primera vez por Bill Wrowe a principios de 2000s. Lo que él diseñó, durante una sesión de lluvia de ideas conmigo (en persona), fue una sola biblioteca de analizadores interna de httpd, que compartió la solicitud enviada body con cada módulo de partes interesadas clave en el tiempo de ejecución. Esto significaba proporcionar datos analizados a los módulos conectados al motor de procesamiento de solicitudes before, during, y after que se ejecuta el manejador de contenido. Además, también tenía que trabajar para solicitudes secundarias, independientemente de si el manejador de contenido consumía o no los datos analizados, o consumía y volvía a analizar el propio cuerpo de solicitud sin procesar.
Le expliqué los objetivos de diseño varias veces a lo largo de los años, incluso en 2012. desarrollo@httpd. Pero siempre fue como hablar con el viento con estos chicos; simplemente nunca les importó.
Reunión de nubes de tormenta
Si bien esta visión tuvo un gran éxito, con enlaces de idiomas disponibles para varios idiomas como Perl, PHP, TCL, Rdesde 2010 ha demostrado ser trágico para la comunidad de usuarios existente compuesto por todos ellosNo sólo los miembros del Perl comunidad.
¿Qué pasó? Philip Gollucci, un colega mío de Perl/FreeBSD en ese momento, comenzó a agitar que promocionemos el proyecto para ser lanzado desde dentro del propio servidor HTTPd. Qué Felipe no sabía muy bien en aquel entonces era lo peevish, vapid y territorial ese equipo se había convertido enque habría significado tener que colaborar con ellos directamente en decisiones orientadas al usuario Sobre la base de código.
En 2012, Philip consiguió lo que quería y dejé de resistir, por lo que bifurcado el proyecto existente y copió el C componentes de la biblioteca en el núcleo HTTPd.
Fallo
En 2018 Renuncié a la Fundación en masa1. Puedes adivinar las razones.
En 2020, aproximadamente, el equipo de seguridad de Google aprovechó una versión alfa de httpd 2.5 al desconcertar su copia de 8 años de antigüedad de apreq2. Encontraron algunos puntos de acceso que necesitaban reparación.
En lugar de tener la cortesía de llegar a Felipe, Issac Goldstand, Max Kellermann (@MaxKellermann), yo mismo (@joesuf4), o cualquier otra persona involucrada en el desarrollo de libapreq2, un ingeniero junior en el equipo HTTPd pasó por el negocio de “corrección de bugs” las vulnerabilidades encontradas por Google. Puede ver un registro de su trabajo de prueba y error en cada versión desde entonces.
Por supuesto, los CVE reportados fueron escritos por aficionados:
Es imposible causar un desbordamiento de amortiguador (por diseño arquitectónico), por lo que tales afirmaciones siempre fueron tontas; como lo demuestra el hecho de que nunca se ha publicado ningún código de explotación.
A pesar de mis mejores esfuerzos, las des referencias del puntero NULL fueron posibles; con lo cual el desarrollador menor hizo una limpieza exhaustiva hace años.
Hace veinte años tuve un pedo en el cerebro alrededor de codificaciones de charset para encabezados MIME, que siempre están limpios ASCII de 7 bits cuando están bien formados. La injusticia de eso lógica del analizador era la única preocupación de seguridad significativa en todo el historial de la base de código — Y como un NPE, todo lo que un atacante podía hacer era bloquear el servidor web. Por supuesto, en un entorno de prefork esto es dispararse en el pie como un hacker; pero con @joesuf4/mod_perl, ejecutarlo dentro de HTTP/2 con mpm_event ahora es fácilmente alcanzable. Por lo tanto, la eliminación de todas las formas de bloqueos del servidor fue un trabajo vital y necesario. El desarrollador junior merece mucho crédito por ese logro eventual en el baúl de @apache/apreq. Reconocimiento.
Pero el golpe de gracia fue la liberación de 2022 de 2.17, en donde el desarrollador novato Introdujo deliberadamente un bug fatal en la base de código, romper una prueba de regresión de diecinueve años.
Postmortem
Si te estás preguntando cómo termina algo con una prueba de regresión rota / CVE excepcional CPAN como un accesorio permanente, tendrás que ver cómo RELENG se realiza en el proyecto del servidor.
Cuento largo, comentaron la prueba y lo envió de todos modos, y lo llamó una liberación de seguridad que Se solucionó una vulnerabilidad a la que cada versión anterior era susceptible de.
¿Por qué me importa ahora? Porque yo soy el tonto los usuarios se ponen en contacto para obtener respuestas como un experto en temas conocidos.
Esto apesta2Pero lamento decirles que mis días usando la capa de Superman en Apache terminaron hace aproximadamente una década.
En cualquier caso, lo mejor que puedo hacer en este punto es mostrarle mi árbol de origen de producción para libapreq2 — @joesuf4/apreq (y @joesuf4/mod_perl).
Notas al pie
Uno no simplemente “dimisión de la ASF”. Para hacer una pausa limpia, uno debe renunciar no solo a la membresía de la ASF, sino a cada proyecto / comité del que uno es miembro. De lo contrario, uno termina ahogándose en el e-mail spam infernal de Apache.
Los machos beta abandonaron el proyecto @apache/apreq, y están pasando a @apache/mod_perl, porque los machos beta no tienen nada mejor que ver con su tiempo. Yann Ylavic, el “desarrollador novato” Por encima de quien realmente trabajó en apreq mientras sus compañeros le fallaron, no emitió un voto para retirar el proyecto. No es sorprendente, porque es un solucionador de problemas, no un hombre beta.