Jóváhagyta a Mozilla a cURL file-transzfer library-t biztonsági ellenőrzése során, mely egyébként kilenc sérülékenységet tárt fel. A biztonsági áttekintés alatt fellelt hibák közül négy magas kockázatúnak bizonyult, ami távolról való kód futtatását teszi lehetővé. Négy másik közepes veszélyességű besorolást kapott, míg a közbeékelődéses (man-in-the-middle) TLS támadás alacsony kockázatú lett.
Nem minden hibát kellett ugyanakkor javítani. Az egyik, közepes veszélyességűnek minősített sebezhetőség a ConnectionExists()-ben rejlik; a jelszavak összehasonlításában fellelt sérülékenység azonban annyira elavult és olyan nehéz kihasználni, hogy megszüntetését nem tartotta szükségesnek a Mozilla. A többit viszont hét patch iktatja ki.
Ezzel egyébként nem ért véget a munka ezen a téren, hamarosan még több javítás várható, közölte Daniel Stenberg.
„Miközben azon dolgoztunk, hogy egyesével javítsuk a felbukkant hibákat, további négy biztonsági sebezhetőségre akadtunk.” – mondta a Mozilla mérnöke, aki egyben a cURL vezető fejlesztője is – „Ezek a hibák egy nagyon sűrű időszakban jelentek meg [..] szükségünk van egy rövid időszakra, mielőtt a következő hibacunami beüt.”
Öt Mozilla mérnök a berlini Cure53 csapatából vitte végbe a húsz napos forráskód-auditot. „Vizsgáltuk a hitelesítést, különböző protokollokat és részben az SSL/TLS kezelést is. A fókuszt az irányította, hogy a cURL eszköz ezen részei hajlamosak valós támadási forgatókönyveknek áldozatul esni”, írta a csapat összegzésében. Azt azonban fontosnak tartotta kihangsúlyozni, hogy a cURL library általános biztonsága és robusztussága által kialakított kép összességében pozitív volt.
A jelentés egyébként még szeptember 23-ára elkészült, az ezt követő hónapok a javítások elkészítésével teltek.
Titkos tesztelés
A fejlesztők szerint néhány ellenőrzés és pár újabb patch még jöhet a témában, ami abból a döntésből ered, hogy az auditot – szemben a nyílt forrás alapvető koncepciójával – titokban végezték, a nyilvánosságtól elzártan.
„Ennek egyik árnyoldala, hogy sokkal kevesebb szem vizsgálta a hibákat, nem vett annyi ember részt a folyamatban, mint egyébként egy hasonló kaliberű projektnél, a lehetőségek és megoldások megbeszélése során. Szintén hátránynak bizonyult ebben a bizonyos esetben, hogy tesztinfrastruktúránk nyilvános kód számára készült, vagyis nem tudunk mindent teljesen végig próbálni, amíg az nincsen összefűzve a nyilvános git gyűjteménnyel” – tette teljessé a képet Stenberg.
Projektek O-gyűrűje. Mit tanulhat egy projektvezető a Challenger tragédiájából?