Ściana miedzy najemcami miała pęknięcie

Cicha obietnica każdego serwera w chmurze i każdego wirtualnego serwera prywatnego to rozdzielenie. Twoja maszyna i maszyna nieznajomego płacącego temu samemu dostawcy działają na tym samym fizycznym sprzęcie, a warstwa o nazwie KVM, wbudowana w jądro Linuksa, jest tym, co je rozdziela. Januscape, oznaczona jako CVE-2026-53359, to pęknięcie w tej ścianie. To sytuacja wyścigu w sposobie, w jaki KVM zarządza cieniowymi tablicami stron, wewnętrzną mapą tłumaczącą pamięć maszyny gościa na pamięć rzeczywistą. Przy tej luce host może przypisać jeden z tych wpisów do niewłaściwej ramki gościa, pomyłkę numeru ramki i typu, która prowadzona ostrożnie pozwala wrogiej maszynie wirtualnej zmusić host do mapowania pamięci wybranej przez atakującego. To ucieczka z gościa do hosta: najemca wychodzi ze swojego pudełka na podłogę, którą wszyscy dzielą.

Powaga wynika z zasięgu. Luka tkwi w kodzie wspólnym dla procesorów Intel i AMD, więc wyzwala się przy VMX i EPT z jednej oraz SVM i NPT z drugiej strony. Wprowadzono ją w 2010 roku i leżała uśpiona szesnaście lat, co oznacza, że niemal każde jądro Linuksa wydane w tym okresie ją niesie. Ujawniono ją 6 lipca na publicznej liście oss-security, naprawiono w kodzie źródłowym 16 czerwca, a poprawione stabilne jądra, wersje 7.1.3, 6.18.38, 6.12.95, 6.6.144, 6.1.177, 5.15.211 i 5.10.260, ukazały się dopiero 4 lipca.

Dlaczego zalatalismy ma teraz dwie odpowiedzi

Niezwykłe niebezpieczeństwo nie tkwi tu w luce, lecz w kształcie naprawy. Zamknięcie Januscape wymaga dwóch sprzężonych commitów w kodzie źródłowym, nie jednego: poprawki ucieczki niosącej CVE-2026-53359 i towarzyszącej poprawki numeru ramki niosącej CVE-2026-46113. Jeśli zainstalujesz tylko pierwszą, tę o zapadającej w pamięć nazwie, drzwi pozostają uchylone. Administrator, który przeczytał wyróżnione ostrzeżenie, wgrał tę jedną latkę i zamknął zgłoszenie, zrobił rzecz rozsądną i nadal jest narażony. Dlatego rutynowe zdanie, zalatalismy, nie zamyka już sprawy przy tej luce.

Dla właściciela narażenie rzadko jest własną szafą serwerową. To dostawca pod twoimi dostawcami: host VPS obsługujący twoją witrynę, chmura prywatna obsługująca twoje oprogramowanie biznesowe, zarządzana platforma obsługująca twoje dane. W Polsce kanałem zgłoszenia jest CSIRT NASK oraz CERT Polska, a NIS2 narzuca to samo oczekiwanie: nadal odpowiadasz za bezpieczeństwo usług świadczonych w twoim imieniu. Ucieczka z hipernadzorcy to dokładnie ten rodzaj awarii współdzielonej infrastruktury, dla którego napisano te przepisy, ponieważ jeden niezałatany host może zniweczyć rozdzielenie, za które płaciło tysiąc klientów.

Pytanie do dostawcy hostingu w tym tygodniu

Dla większości właścicieli to nie zadanie kompilacji jądra, lecz jasno postawione pytanie zakupowe. Zadaj temu, kto obsługuje twoje maszyny wirtualne, czy to host VPS, wewnętrzny zespół chmury prywatnej, czy dostawca zarządzanej platformy, trzech rzeczy: czy jądro hosta jest już na poprawionej stabilnej wersji lub latce na gorąco; czy ta poprawka zawiera oba commity, poprawkę ucieczki i jej towarzysza; oraz kiedy została wgrana. Nie ma przełącznika konfiguracji, który czyni to bezpiecznym. Załatane jądro z ponownym uruchomieniem lub latka na gorąco wgrana bez niego to jedyna pełna odpowiedź, a dopóki jej nie ma, każdy host wielonajemcy należy traktować jako osiągalny od wrogiego sąsiada.

Praktyczna zmiana jest niewielka, ale realna. Najemca obok ciebie, imię, którego nigdy nie poznasz, przeszedł w tym miesiącu z abstrakcyjnej obawy do wiersza w twoim modelu zagrożeń. Właściciele, którzy zamieniają to w konkretną pisemną odpowiedź dostawcy zamiast wygodnego założenia, to ci, którzy nie będą zgadywać, jeśli ta luka kiedykolwiek zostanie połączona w prawdziwe włamanie.

Czytaj dalej: CitrixBleed wraca, wykorzystany w ciągu doby  |  Sfałszowany token otwiera każdy PC pod zarządem narzędzia