29 kwietnia na stronie https://copy.fail/ zamieszczono informacje o całkiem krytycznej podatności określanej jako Copy Fail, która to otrzymała oznaczenie CVE-2026-31431. Podatność wykorzystuje skomplikowany błąd w obsłudze authencesn, z którego szerokim opisem można zapoznać się w tym opracowaniu. Istotne jest zrozumienie, że podatność istniała w tym module kernela od 2017 roku (tutaj commit zawierający wadliwe zmiany), a w związku z tym dotyczy każdej „nowej” dystrybucji Linux.
Użycie podatności jest bardzo proste, co jeszcze zwiększa ewentualny poziom zagrożenia. Copy Fail do działania wymaga dostępu do powłoki (czy to poprzez SSH czy lokalnie), co w ogólnym ujęciu nie jest standardem – port SSH często jest nieosiągalny z zewnątrz, a jeśli już, to dostęp wymaga autoryzacji kluczem lub hasłem. Odmienna sytuacja dotyczy jednak wszelkich usług hostingowych, gdzie różni użytkownicy otrzymują własne konta SSH w celu wygodniejszego dostępu do swoich danych i zarządzania aplikacjami internetowymi – tutaj zalecane jest jak najszybsze wdrożenie aktualizacji systemu przez administratorów.
Praktyczne wykorzystanie Copy Fail może ograniczyć się do uruchomienia skryptu Python opracowanego przez zespół Theroi, który odnalazł tę podatność.
Warto dodać, że swój udział w odkryciu podatności miała sztuczna inteligencja w postaci narzędzia Xint Code będącego jednym z produktów w ofercie Theroi. Trudno wyobrazić sobie lepszą reklamę dla swojego oprogramowania. Pokazuje to również rosnący udział AI w testach bezpieczeństwa i pewnie za kilka lat opisywana podatność będzie wymieniana jako jedna z pierwszych czy też ważniejszych „odkrytych” przez sztuczną inteligencję. W tym kontekście można polecić nasz artykuł o konkurencyjnym rozwiązaniu Claude Mythos, jak również szerszy test wiodących chatbotów.
Dostęp do systemu jako root oznacza nieograniczone uprawnienia. Osiągnięcie ich przez nieautoryzowane osoby może narazić nas na poważne problemy techniczne, prawne i wizerunkowe. W przypadku hostingu może nastąpić kradzież danych innych użytkowników, co na lata obniży zaufanie do takiego dostawcy.
Jeśli aktualizacja systemu z jakiegoś powodu nie jest możliwe, to sugerowałbym „zamknięcie” użytkowników w osobnych chroot. To bardzo dobra praktyka w środowiskach hostingowych, bo skutecznie ogranicza dostęp do zasobów systemowych (a część „wrażliwych” danych niestety jest widoczna dla wszystkich). Po stronie użytkowników mogą w tej sytuacji wystąpić jednak poważne trudności – dla przykładu nie będą działać ich usługi w tle, takie jak popularny Tomcat. Mimo wszystko chroot świetnie zabezpiecza przed podobnymi podatnościami, co widać na poniższym zrzucie ekranu. Użytkownik uruchomił exploit bez błędów, ale „pozostał” na swoich uprawnieniach.
Co więcej, udostępniony skrypt copy_fail_exp.py korzysta z funkcji splice() dostępnej od Python 3.10. Jeśli w systemie zainstalowana jest starsza wersja (ma to miejsce m.in. we wciąż wspieranych systemach RHEL 9), to użytkownik nie wykona tego konkretnego skryptu – chyba że lokalnie skompiluje wersję 3.10 dla własnego użytku. Mimo wszystko pod żadnym względem nie można tego uznać za zabezpieczenie, bo analogiczny kod można napisać w innym języku. Zresztą powstał już exploit napisany w C, który zadziała na wszystkich podanych systemach.
Opisywana podatność kolejny raz udowadnia, że niezmienna pozostaje zasada minimalizacji dostępu. Obejmuje to przede wszystkim praktykę wystawiania na zewnątrz wyłącznie wymaganych usług webowych (najlepiej przy użyciu rozwiązań WAF), a pozostałe porty powinny być osiągalne wyłącznie z sieci wewnętrznej – do których zdalny dostęp wymagałby zestawienia połączenia VPN.
Z kolei w mniej optymalnym pod względami bezpieczeństwa scenariuszu, gdy zewnętrzny dostęp SSH jest wymagany, to zdecydowanie należy rozważyć korzystanie z chroot.
Aktualizacje są ważne i chyba nikt nie ma wątpliwości. Trzeba jednak pamiętać, że automatyczne instalowanie aktualizacji jest błędnym podejściem. Nigdy nie mamy pewności, że dana aktualizacja poprzez poprawę jednego problemu (nawet niekoniecznie związanego z security) nie powoduje nieoczekiwanego zachowania innego pakietu. Należy wyłączyć automatyczne aktualizacje w środowiskach serwerowych (Ubuntu pod tym względem jest negatywnym wyjątkiem z uwagi na domyślne działanie unattended-upgrades), a aktualizacje wdrażać w określonych oknach serwerowych z wcześniejszym zapewnieniem dostępu awaryjnego i wykonaniem kopii zapasowej (również w postaci snapshota maszyny wirtualnej).
