Jedenaście bajtów i czekający wątek

Ktoś z zespołu czerwonego firmy Okta wysłał serwerowi 11 bajtów i patrzył, jak ten odkłada 131 kilobajtów. Sztuczka tkwi w sposobie, w jaki otwiera się rozmowa TLS. Pierwsze cztery bajty wiadomości powitalnej deklarują, jak długa będzie wiadomość, a starsze wersje OpenSSL wierzyły tej deklaracji i rezerwowały bufor, zanim dotarła reszta albo zanim wykonano jakąkolwiek weryfikację. Reszta wiadomości nigdy nie nadeszła. Pamięć pozostała zarezerwowana, a wątek roboczy czekał na dane, które już nie miały przyjść.

Powtórzone, przestaje to być subtelne. Na serwerze z jednym gigabajtem zespół zostawił 547 megabajtów zamrożonych w bezużytecznych fragmentach. Na maszynie z szesnastoma gigabajtami zablokował ćwierć całej pamięci. W systemach korzystających z alokatora glibc pamięć nie wraca czysto nawet po rozłączeniu się napastnika, ponieważ zwolnionych fragmentów nie da się ponownie wykorzystać. Nie były potrzebne żadne poświadczenia, nie nawiązano żadnej sesji, a nic w tej wymianie nie wyglądało na atak.

Część, która powinna niepokoić kierownika bardziej niż inżyniera

OpenSSL to naprawił. Wersje 4.0.1, 3.6.3, 3.5.7, 3.4.6 i 3.0.21 ukazały się wszystkie 9 czerwca 2026 roku z poprawionym zachowaniem, przydzielając pamięć dopiero w miarę faktycznego napływu danych. Zmianę wniosły trzy prośby o scalenie, o numerach 30792, 30793 i 30794. Potem przez ponad pięć tygodni nic o tym nie powiedziano. Publiczne ujawnienie dotarło na listę oss-security 18 lipca, 39 dni po tym, jak poprawka już krążyła w świecie.

Zespół bezpieczeństwa podjął świadomą decyzję. OpenSSL prowadzi czterostopniowy system wagi zagrożenia, od Krytycznego do Niskiego, i uznał, że ten przypadek nie należy do żadnego z nich. Prośba o scalenie wprost stwierdza, że zespół postanowił potraktować zgłoszenie jako poprawkę typu "błąd lub wzmocnienie". Nie ma zatem identyfikatora CVE, nie ma ostrzeżenia o bezpieczeństwie ani wpisu w dziennikach zmian objętych wydań. Każdy z tych braków jest decyzją, i każdy usunął sygnał, na którego wykrywanie czyjś proces został zbudowany.

Zdyscyplinowany proces przegrał z niezdyscyplinowanym

Wyobraźcie sobie dwie firmy. Pierwsza aktualizuje OpenSSL w stałym miesięcznym rytmie, niezależnie od tego, co zawiera wydanie. To podejście, z którego dojrzała funkcja bezpieczeństwa zwykle wyrasta, bo zużywa okna serwisowe na wydania bez znaczenia. Ta firma jest chroniona od czerwca i nie ma pojęcia, że kiedykolwiek była zagrożona.

Druga ustala priorytety według wagi zagrożenia. Czyta ostrzeżenia, punktuje wpisy CVE, przesuwa do przodu Krytyczne i Wysokie, a resztę odkłada z udokumentowanym uzasadnieniem. To podejście, które przechodzi audyt, zadowala ubezpieczyciela i wytrzymuje pytanie na posiedzeniu zarządu. Ta firma spojrzała na czerwcowe wydanie OpenSSL, nie znalazła treści dotyczących bezpieczeństwa i całkiem słusznie zdecydowała nie poświęcać na nie okna serwisowego. Nadal jest narażona, a jej proces zadziałał dokładnie tak, jak go zaprojektowano.

Niewygodny wniosek brzmi tak: łatanie według wagi zagrożenia oznacza oddanie własnych decyzji o ryzyku temu, kto tę wagę przypisuje. To nie jest zarzut wobec OpenSSL, projektu opartego w dużej mierze na wolontariuszach, który podejmuje obronialne decyzje wobec czterostopniowej skali, której nikomu nie jest winien. To spostrzeżenie o tym, gdzie naprawdę leży osąd. Jeśli Wasz proces podnosi rangę wyłącznie temu, co przychodzi już oznaczone jako groźne, to Waszym modelem zagrożeń jest w istocie polityka etykietowania Waszych dostawców.

Dwie rzeczy pozostają dziś prawdziwe

Ścieżkę DTLS zostawiono w spokoju. Porządne jej naprawienie uznano na razie za zbyt inwazyjne, więc ten kod nadal wymiaruje bufor według długości deklarowanej przez drugą stronę. Jeśli gdziekolwiek kończycie DTLS, a robi to wiele koncentratorów VPN, serwerów multimedialnych WebRTC i przemysłowych bram internetu rzeczy, tego ryzyka nie usuwa nic z opisanych tu zmian. Nie jest to też ukryty sekret. Powiedziano to otwarcie w ujawnieniu, co samo w sobie jest ostrzeżeniem.

Druga rzecz dotyczy czasu. Zwykle ujawnienie i poprawka pojawiają się razem, a obrońcy i napastnicy startują z tej samej linii. Tutaj poprawiony kod leżał w publicznych zatwierdzeniach przez 39 dni, zanim ktokolwiek wyjaśnił, co poprawia. Czytanie porównania zatwierdzeń nie jest egzotyczną umiejętnością. Przez ponad miesiąc ci, którzy czytają kod, mieli przewagę nad tymi, którzy czytają biuletyny, a ta druga grupa nie wiedziała, że wyścig się rozpoczął.

Pytanie do dodania przy najbliższym przeglądzie

Nie przebudowujcie całego programu podatności z powodu jednego błędu wyczerpującego pamięć. Dodajcie natomiast jedno powracające pytanie do spotkania, które i tak odbywacie: czego nie zdecydowaliśmy się załatać w tym kwartale, bo przyszło bez oceny wagi zagrożenia? Nie to, co odłożyliśmy jako Niskie. Lecz to, co nigdy nie trafiło do kolejki, bo nic tego nie oznaczyło. Taka lista istnieje w każdej organizacji i prawie nikt do niej nie zagląda.

Następnie porównajcie swoje wersje OpenSSL z wydaniami z 9 czerwca, co zajmuje kilka minut, i zanotujcie, czy chroni Was polityka, czy szczęście. Różnica między tymi dwiema odpowiedziami jest sednem sprawy. Zabezpieczenie, które chroni Was przypadkiem, nie jest zabezpieczeniem, a następnym razem, gdy przypadek się nie zdarzy, dowiecie się o tym drogą kosztowną.

Czytaj dalej: Poprawka była publiczna 81 dni przed ostrzeżeniem  |  Jedno żądanie mogło przejąć twoją witrynę WordPress