Apache HTTPd Devs Considerados Prejudiciais

[VERIFICADO] Última atualização por Joe Schaefer em qua, 13 mai 2026    origem

 

Plano de fundo

Nos últimos 25 anos, tenho sido o principal desenvolvedor do apreq subprojeto dentro do Servidor Apache HTTPd Projeto Pai. A ideia original de libapreqcomo um seguro/performável Envio de formulário HTML e Biscoito Analisando a biblioteca, surgiu de uma colaboração entre Lincoln Stein e Doug MacEachern no final 90s.

Era minha visão naquela época transformar a biblioteca em uma biblioteca genérica, não-perl. C biblioteca que suportaria ligações de linguagem de outras linguagens de programação, e é por isso que eu pressionei para que o projeto fosse homen sob o guarda-chuva HTTPd, em vez de Apache-Perl projeto.

Com o advento da httpd-2.X, um inteiramente novo I/O Filter arquitetura emergiu de httpd bem como a completa separação de APR do próprio núcleo como um tempo de execução de portabilidade semelhante ao POSIX de propósito mais geral para C projetos como Subversion. Na verdade, libapreq2 está mais alinhado com o Apache APR projeto nesse espírito, e sua API Perl reflete isso como parte de sua APR::Request construção. Tem um modo CGI incorporado para a operação autônoma, fora do httpd tempo de execução, o que torna o teste de unidade uma brisa.

No entanto, o componente-chave da apreq2 sempre foi o mod_apreq2 Módulo Apache, que foi concebido pela primeira vez por Bill Wrowe no início do 2000s. O que ele projetou, durante uma sessão de brainstorming comigo (pessoalmente), foi uma única biblioteca de analisadores interna. httpd, que compartilhou a solicitação enviada body com todos os principais módulos de partes interessadas no runtime. Isso significava fornecer dados analisados para módulos conectados ao mecanismo de processamento de solicitações antes, durante e após a execução do processador de conteúdo. E também precisava trabalhar para sub-solicitações, independentemente de o manipulador de conteúdo consumir ou não os dados analisados, ou consumiu e reparou o próprio corpo de solicitação bruto.

Expliquei as metas de design várias vezes ao longo dos anos, mesmo em 2012 dev@httpd. Mas sempre foi como falar com o vento com esses caras; eles simplesmente nunca se importaram.

Coleta de Nuvens de Tempestade

Embora essa visão tenha sido bem-sucedida, com ligações de idiomas disponíveis para vários idiomas, como Perl, PHP, TCL, R, etc., desde cerca de 2010, provou ser trágico para o comunidade de usuários existente consistindo de todos elesNão apenas os membros do Perl comunidade.

O que aconteceu? Philip Gollucci, um colega meu do Perl/FreeBSD na época, começou a agitar que promovemos o projeto a ser lançado de dentro do próprio servidor HTTPd. O que Philip não sabia muito bem naquela época era o quão completamente peevish, vapid e territorial Essa equipe se tornou, o que significaria ter que colaborar com eles diretamente em decisões voltadas para o usuário sobre a base do código.

Em 2012, Philip conseguiu o que queria e eu parei de resistir, então ele bifurcado o projeto existente e copiou o C componentes da biblioteca no núcleo HTTPd.

Fallout

Em 2018 Eu renunciei à Fundação em massa¹. Você pode adivinhar as razões.

Em 2020, a Equipe de Segurança do Google aproveitou uma versão alfa do httpd 2.5 ao confundir sua cópia de 8 anos de idade de apreq2. Eles encontraram alguns hotspots que precisavam de reparo.

Em vez de ter a cortesia de chegar a Filipe, Issac Goldstand, Max Kellermann (@MaxKellermann), eu mesmo (@joesuf4), ou qualquer outra pessoa envolvida no desenvolvimento de libapreq2, um engenheiro júnior na equipe HTTPd foi sobre o negócio de “correção de bugs” vulnerabilidades encontradas pelo Google. Você pode ver um registro de seu trabalho de tentativa e erro em cada lançamento desde então.

É claro que os relatórios do CVE foram escritos por amadores:

1. é impossível causar um estouro de buffer (por projeto arquitetônico), de modo que tais reivindicações sempre foram falsificadas; como evidenciado pelo fato de que nenhum código de exploração foi publicado.

2. apesar dos meus melhores esforços, foram possíveis desreferências de ponteiro nulo; com o qual o desenvolvedor júnior fez uma limpeza completa anos atrás.

3. Eu tive um peido cerebral há vinte anos atrás em torno de encodings de charset para cabeçalhos MIME, que são sempre 7-bit ASCII limpo quando bem formado. A injustiça disso lógica do analisador foi a única preocupação de segurança significativa em todo o histórico da base de código — e como um NPE, tudo o que um invasor poderia fazer era travar o servidor web. É claro que, em uma configuração de prefork, isso está se atirando no pé como um hacker; mas com @joesuf4/mod_perl, executá-lo dentro de HTTP/2 com mpm_event agora é facilmente viável. Portanto, a eliminação de todas as formas de falhas do servidor era um trabalho vital e necessário. O desenvolvedor júnior merece muito crédito por essa eventual conquista no tronco de @apache/apreq. Felicitações.

Mas o golpe de graça foi o lançamento de 2022 da 2.17onde o desenvolvedor novato Introduziu propositalmente um bug fatal na base de códigoquebrando um teste de regressão de dezenove anos.

Postmortem

Se você está se perguntando como algo com um teste de regressão quebrado / excelente CVE acaba CPAN como um acessório permanente, você terá que olhar para como REENVIAR é feito no projeto do servidor.

Longa história curta, Eles comentaram o teste e o enviou de qualquer maneira, e o chamou de Security Release que corrigiu uma vulnerabilidade a cada versão anterior era suscetível a.

Por que me importo agora? Porque eu sou o otário os usuários procuram respostas como um conhecido especialista no assunto.

Isso é uma droga²Mas lamento dizer que meus dias usando a capa do Superman em Apache terminaram há cerca de uma década.

Em qualquer caso, o melhor que posso fazer neste momento é mostrar minha árvore de origem de produção para libapreq2 — @joesuf4/apreq (e @joesuf4/mod_perl).

Rodapés

1. Um não simplesmente “demissão do ASF”. Para fazer uma pausa limpa, deve-se renunciar não apenas aos membros da ASF, mas de todos os projetos / comitês dos quais é membro. Caso contrário, alguém acaba se afogando em intermináveis spam de email Apache.

2. Os machos beta equilibraram o projeto @apache/apreq e estão passando para @apache/mod_perl, porque os machos beta não têm nada melhor a ver com seu tempo. Yann Ylavic, o “desenvolvedor novato” acima de quem realmente trabalhou no apreq enquanto seus companheiros de equipe falharam com ele, não votou para aposentar o projeto. Sem surpresa, porque ele é um solucionador de problemas, não um homem beta.