Od pewnego czasu każdy dzień przynosi nowe i istotne informacje ze świata bezpieczeństwa IT. Różnych ataków czy „podatności” jest w tej chwili tak wiele, iż trudno przedstawić wszystkie w odpowiedni sposób w ograniczonym czasie. Przedwczoraj zajmowaliśmy się podatnością w obsłudze TCP we współczesnych wersjach systemu Linux. Dostawcy wszystkich dystrybucji udostępnili już aktualizacje rozwiązujące ten problem – niestety z wyjątkiem Canonical. Wczoraj jednak firma odpowiadająca za Ubuntu poinformowała o jeszcze jednej ważnej podatności CVE-2026-109518. Opis na podanej stronie jest lakoniczny, ale zagrożenie pozostaje realne. Atakujący mający kontrolę nad ruchem sieciowym pomiędzy naszym hostem a repozytorium Ubuntu może tak zmanipulować narzędzie apt-get, aby zamiast oryginalnej paczki zawartej w repozytorium zainstalować własną, złośliwą wersję.
Ta sytuacja pokazuje w pewnym sensie skrajną niedbałość dostawców systemów Ubuntu i Debian, w których ruch do repozytoriów pakietów domyślnie nie jest szyfrowany. W plikach sources.list znajdują się adresy z podanym protokołem HTTP, a same repozytoria choćby nie wymuszają połączenia szyfrowanego. W 2026 roku nie można uznać takiego podejścia za profesjonalne. To wszystko pomimo faktu, iż apt-get znajdujący się w tych systemach i będący tradycyjnym menedżerem pakietów od 2017 roku natywnie obsługuje połączenia HTTPS do repozytoriów – wcześniej należało w tym celu używać dodatkowego pakietu apt-transport-https.
Domyślne lokalizacje repozytoriów dla Ubuntu 26.04. Zmiana nazwy katalogu /etc/apt uniemożliwia wykonanie aktualizacji bez wiedzy użytkownika
Jak wiadomo, ruch HTTP jest podatny na ataki MITM, w których nieupoważniona osoba jest w stanie podsłuchiwać komunikację, a także ją modyfikować. Problem ten najbardziej jest dostrzegalny w sieciach lokalnych, ale może występować również na „wyższym” poziomie sieci. Jako ciekawostkę warto podać, iż atak MITM nie jest ograniczony do połączeń HTTP. Równie skutecznie można przeprowadzić analizę komunikacji szyfrowanej, ale wymaga to zainstalowania w systemie ofiary własnego certyfikatu SSL (co związane jest z użyciem uprawnień administracyjnych), bo w innym przypadku przeglądarki i pozostali klienci HTTP nie zezwolą na taką komunikację bez jawnego dodania wyjątku. Dokładnie ta praktyka z własnym certyfikatem jest stosowana przez niektóre programy antywirusowe do analizy połączeń i ochrony użytkownika, więc w tym wypadku nie należy określać jej mianem ataku.
Mechanizmy weryfikacji pakietów w APT powinny mimo wszystko uniemożliwić instalację zmodyfikowanej paczki. Natomiast clou opisywanej podatności polega na błędzie, który pozwala „podmienić” poprawny pakiet po jego weryfikacji na złośliwy. W konsekwencji następuje instalacja pakietu od atakującego wykonywana na prawach użytkownika root. Pozwala to na przeprowadzenie w zasadzie dowolnej akcji w systemie. Zwróćmy uwagę, iż Debian czy Ubuntu to popularne systemy stosowane nie tylko w zwykłych komputerach biurkowych, ale również w środowiskach serwerowych i bardzo często też w kontenerach. Atakującego ogranicza więc dostęp sieciowy, wyobraźnia, cele i umiejętności – aczkolwiek dziś te „umiejętności” mogą oznaczać metodę napisania odpowiedniego prompta, aby dany model AI przygotował działające rozwiązanie wykonujące złośliwe operacje.
Aktualizacje zostały już wydane i ich wdrożenie jest zalecane. W tym przypadku pojawiły się wyjątkowo szybko, bo wraz z ogłoszeniem podatności, co niestety dla Ubuntu nie jest oczywiste.
Zauważalna jest różnica w podejściu do bezpieczeństwa pomiędzy systemami RHEL a Ubuntu, szczególnie w kontekście środowisk produkcyjnych. Domyślnie włączone automatyczne aktualizacje, pobieranie pakietów z użyciem nieszyfrowanego protokołu, uruchamianie usług bezpośrednio po ich instalacji, jakość AppArmor w stosunku do SELinux czy wreszcie wyłączony firewall to cechy systemu Ubuntu. Przygotowanie maszyny z tym systemem do bezpiecznej w przyjętych założeniach pracy w sieci zajmuje więcej czasu niż w przypadku serwerów z systemem RHEL i pokrewnymi. Wiele aspektów można zautomatyzować, co pokazałem w pierwszej części artykułów o Ansible Lockdown, ale nie wpływa to na porównanie systemów. Osobiście uważam, iż RHEL jest zdecydowanie bardziej odpowiedni dla środowisk profesjonalnych, natomiast warto nabyć praktykę w pracy z oboma systemami.
Z drugiej strony wersje desktopowe Ubuntu są lepiej dostosowane do zwykłych użytkowników, których nie interesuje konfiguracja SELinux czy reguły zapory. Dla nich najważniejszy pozostaje komfort codziennej pracy, a nie modyfikacja aspektów działania systemu. Obsługa środowiska graficznego w Ubuntu nie sprawia trudności. Podobnie z w pełni interaktywnym procesem instalacji. Ubuntu Desktop zwyczajnie nie wymaga zaawansowanych umiejętności czy doświadczenia w obsłudze Linuxa.
Nie zaszkodzi też stosować własnych lokalnych repozytoriów pakietów. W razie awarii oficjalnych repozytoriów nie będziemy ograniczeni oczekiwaniem na ich przywrócenie, a czas potrzebny na pobranie danych może być krótszy – chociaż przy obecnych technologiach sieciowych nie jest to główny argument.
Podatność w APT pokazuje, iż praktyki będące w użyciu od lat potrafią być zawodne. Zastanawiające jest, dlaczego twórcy Ubuntu i Debiana nie zdecydowali się na zmianę domyślnego protokołu na HTTPS, który od dawna jest standardem choćby w przypadku prostych witryn internetowych, wiedząc o słabościach jego nieszyfrowanej wersji. Zabezpieczenia po stronie APT miały zapobiegać podobnym scenariuszom, ale i one okazały się zawodne. Żadne oprogramowanie nie jest w pełni odporne na ataki, natomiast nie zadbano o podstawy bezpieczeństwa.
Ubuntu i Debian pozostaną popularne i wciąż będą wykorzystywane w środowiskach serwerowych. Dziś nie istnieje lepsza alternatywa dla obrazów bazowych, w których liczy się łatwość konfiguracji, a co za tym idzie czas potrzebny na uruchomienie tworzonego oprogramowania. Stąd obrazy bazowe z Debianem są stosowane m.in. w obrazach Docker zawierających PHP, aplikacje napisane w tym języku, bazy danych, środowisko .NET i wiele innych. Nie zawsze zależy nam na prawdziwej oszczędności i minimalizacji, jaką oferują obrazy z system Alpine. Oczywiście te cechy w konteneryzacji są pożądane, ale zwyczajnie nie zawsze można zastosować ich w praktyce.
Wpadki związane z bezpieczeństwem nie będą więc miały większego znaczenia. Same systemy operacyjne można zastąpić tymi opartymi o RHEL, ale wymaga to przestoju w działaniu środowiska i czasu poświęconego na przygotowanie i realizację migracji. Pomijając skrajne sytuacje nie każdy może sobie pozwolić na takie działania. Być może warto jednak zaplanować, aby kolejne środowiska posiadały już inny system operacyjny. w tej chwili przy rosnącym zastosowaniu konteneryzacji system operacyjny przestaje być najważniejszym elementem przy opracowywaniu infrastruktury, bo aplikacje działają we własnych, odseparowanych i pojedynczych kontenerach. jeżeli zmiana systemu ma przysłużyć się bezpieczniejszemu oraz stabilniejszemu działaniu, to można mówić o powzięciu odpowiedniej strategii.
