Jay Gazlay, pełniący obowiązki zastępcy dyrektora ds. zarządzania podatnościami w CISA, skrytykował Chainguard 28 października podczas konferencji Red Hat w Waszyngtonie. Powodem było wcześniejsze opublikowanie poprawek PHP: według PHP Foundation ukazały się one 21 października, ponad sześć godzin przed planowanym skoordynowanym ujawnieniem. Gazlay nazwał tę decyzję niebezpieczną.
Dlaczego liczy się skoordynowane ujawnianie
W skoordynowanym ujawnianiu podatności wybrane firmy dostają informacje z wyprzedzeniem, by przygotować poprawki na wspólną publikację. PHP Foundation ostrzegała, że wcześniejsze udostępnienie poprawki mogło pozwolić atakującym analizować ją, zanim pozostali użytkownicy PHP otrzymali aktualizację.
Dan Lorenc, dyrektor generalny Chainguard, bronił decyzji firmy. Powołał się na informacje o podatnościach i poprawkach, które już krążyły, możliwość samodzielnego wykrycia luki i zbudowania exploita przez Chainguard oraz sygnały złośliwej aktywności. Według Lorenca próba wykorzystania podatności przez napastników mogła uzasadniać reakcję, nawet bez udanego ataku.
Wcześniejszy artykuł NeoTeo o poprawkach PHP wymienia naprawione wydania i numery CVE.
Co mówią poszczególne sygnały o wykorzystaniu luki
Według badań AWS próby wykorzystania podatności miały sięgać 17 października. PHP Foundation podała, że w chwili publicznego ujawnienia jej zespół bezpieczeństwa nie zidentyfikował funkcjonalnego exploita. Te informacje dotyczą różnych obserwacji i momentów: zgłoszonych prób oraz oceny zespołu Fundacji w dniu ujawnienia.
Gazlay powiedział, że po kilku dniach analitycy CISA, korzystając z modeli, stworzyli działający proof of concept (PoC) we własnej infrastrukturze. Kilka dni po publicznym ujawnieniu badacze potwierdzili działającego exploita, a 26 października CISA dodała podatność do katalogu Known Exploited Vulnerabilities (KEV). Wpis do KEV sam w sobie nie mówi, jak łatwo wykorzystać lukę ani czy udane ataki są powszechne.
Joe Slowik z Dataminr oceniał, że w chwili jego wypowiedzi podatność nie była wykorzystywana na dużą skalę. Twierdził też, że publiczne dowody nie uzasadniały wcześniejszej publikacji poprawek. Próby, działający PoC, potwierdzony exploit i ocena skali opisują różne rodzaje sygnałów.
Dlaczego eksperci różnili się w ocenie decyzji
Spór dotyczył tego, jaki poziom zagrożenia uzasadnia przerwanie uzgodnionego terminu. Gazlay podkreślał znaczenie zaufania i przestrzegania embarga, które daje innym użytkownikom czas na przygotowanie aktualizacji. Lorenc argumentował, że Chainguard miało wystarczające powody, by opublikować poprawki wcześniej, i apelował o jaśniejsze kryteria skoordynowanego ujawniania.
Slowik sprzeciwiał się wykluczeniu Chainguard z przyszłych rozmów o ujawnianiu podatności. Ramy Rahman z ArmorCode również opowiadał się za równowagą i współpracą przy odpowiedzialnym ujawnianiu.
