Apache HTTPd Devs betraktas som skadliga

Bakgrund
Under de senaste 25 åren har jag varit ledande utvecklare av apreq delprojekt inom Apache HTTPd-server Överordnat projekt. Den ursprungliga idén om libapreqsom säker/presterande Inskickning av HTML-formulär och Cookies parsning bibliotek, kom ut ur ett samarbete mellan Lincoln Stein och Doug MacEachern i slutet av 90s.
Det var min vision då att omvandla biblioteket till en generisk, icke-Perl-relaterad C bibliotek som skulle stödja språkbindningar från andra programmeringsspråk, varför jag pressade för projektet att vara hemlagad under paraplyet HTTPd i stället för Apache-Perl projekt.
Med tillkomsten av httpd-2.XEtt helt nytt I/O Filter arkitektur uppstod från httpd såväl som den fullständiga separationen av APR från själva kärnan som en mer allmän POSIX-liknande portabilitetsexekvering för C projekt som Subversion. Faktiskt, libapreq2 är närmare förbunden med Apache APR projektet i den andan, och dess Perl API återspeglar att som en del av dess APR::Request bygga ut. Den har ett inbyggt CGI-läge för fristående drift, utanför httpd körtid, vilket gör enhetstestning en bris.
Den viktigaste komponenten i apreq2 har alltid varit den mod_apreq2 Apache-modulen, som först utformades av Bill Wrowe I början av 2000s. Vad han designade, under en brainstorming-session med mig (personligen), var ett enda parserbibliotek internt för httpd, som delade den skickade begäran text med varje nyckelintressentmodul i exekveringen. Det innebar att tillhandahålla parsade data till moduler som är anslutna till bearbetningsmotorn för begäran före, under och efter att innehållshanteraren körs. Och det behövde också fungera för delbegäranden, oavsett om innehållshanteraren konsumerade parsade data eller konsumerade och reparerade själva råbegärans textdel.
Jag förklarade designmålen flera gånger under åren, även under 2012 på dev@httpd. Men det var alltid som att prata med vinden med dessa killar; de brydde sig bara aldrig.
Stormmoln samlas
Även om denna vision var väldigt framgångsrik, med språkbindningar tillgängliga för flera språk som Perl, PHP, TCL, RSedan 2010 har det varit tragiskt för befintligt användarforum som består av allaInte bara medlemmarna i Perl samhälle.
Vad hände? Philip Gollucci, en Perl/FreeBSD kollega till mig vid den tiden, började agitera att vi främjar projektet som ska släppas inifrån HTTPd servern själv. Vad Filip visste inte mycket väl då var hur fullständigt peevish, vapid och territorialvatten Det laget hade blivitDet hade varit nödvändigt att samarbeta med dem direkt. användarstyrda beslut om kodbasen.
2012 fick Philip vad han ville ha och jag slutade motstå, så han kluven Det befintliga projektet och kopierade C bibliotekskomponenter till HTTPd-kärnan.
Fallout
År 2018 Jag avgick från stiftelsen en masse1. Du kan gissa orsakerna.
Under 2020 eller så utnyttjade Googles säkerhetsteam en alfautgåva av httpd 2.5 genom att fuzzing sin 8-åriga kopia av apreq2. De hittade några hotspots som behövde repareras.
I stället för att ha artighet att nå ut till Philip, Issac Goldstand, Max Kellermann (@MaxKellermann), mig själv (@joesuf4), eller någon annan som är involverad i utvecklingen av libapreq2, en junior ingenjör på HTTPd laget gick om verksamheten i “buggfix” Sårbarheterna som Google hittade. Du kan se ett register över hans rättegång och felarbete i varje utgåva sedan dess.
CVE: s rapporterades av amatörer:
Det är omöjligt att orsaka ett buffertspill (genom arkitektonisk design), så sådana påståenden var alltid baloney; vilket framgår av det faktum att ingen exploateringskod någonsin har publicerats.
Trots mina bästa ansträngningar var NULL-pekardereferenser möjliga; med vilken juniorutvecklaren gjorde en grundlig rensning för flera år sedan.
Jag hade en hjärnfis för tjugo år sedan runt teckenuppsättningskodningar för MIME-huvuden, som alltid är 7-bitars ASCII rena när välformade. Felaktigheten i det tolkningslogik var det enda meningsfulla säkerhetsproblemet i kodbasens hela historia — och som en NPE, allt en angripare kunde göra var att krascha webbservern. Naturligtvis, i en prefork inställning detta är att skjuta dig själv i foten som en hackare; men med @joesuf4/mod_perl, kör det inuti HTTP/2 med mpm_event är nu lätt att uppnå. Så eliminering av alla former av serverkrascher var viktigt och nödvändigt arbete. Den yngre utvecklaren förtjänar mycket beröm för den eventuella prestationen i @apache/apreqs stam. Kudos.
Men statskuppen var 2022 års frigivning av 2.17, där i rookie utvecklare avsiktligt introducerade en dödlig bugg i kodbasen, bryta Ett nittonårigt regressionstest.
Postkort
Om du undrar hur något med ett trasigt regressionstest / enastående CVE hamnar på CPAN Som en permanent fixtur måste du titta på hur RELENG Detta görs i serverprojektet.
Lång historia kort, De kommenterade provet och skickade det ändå och kallade det en säkerhetsutgåva som fixade en sårbarhet varje tidigare utgåva var mottaglig för.

Varför bryr jag mig nu? För jag är sucker användare når ut till för svar som känd ämnesexpert.
Detta suger2, men jag är ledsen att berätta att mina dagar med Superman cape i Apache slutade ungefär ett decennium sedan.
Hur som helst, det bästa jag kan göra just nu är att visa er mitt produktionskällträd för libapreq2 — @joesuf4/apreq (och @joesuf4/mod_perl).
Fotnoter
En är inte bara “avgå från ASF”. För att göra en ren paus måste man avgå från inte bara ASF-medlemskapet, men från varje projekt / kommitté är man medlem i. Annars hamnar man drunkna i oändliga helvetiska Apache e-post spam.
Beta män malballed @apache/apreq projektet, och går vidare till @apache/mod_perl, eftersom beta män har inget bättre att göra med sin tid. Yann Ylavic, the “rookie-utvecklare” Ovanför vem som faktiskt arbetade på apreq medan hans lagkamrater misslyckades honom, inte kasta en omröstning för att gå i pension projektet. Inte överraskande, för att han är en problemlösare, inte en beta-man.
