Luka w APT: pakiet podmieniony po weryfikacji podpisu i kod wykonany jako root

WSTĘP: Podpis się zgadzał, paczka już nie

Debian i Ubuntu załatały 4 listopada 2026 roku lukę w APT, menedżerze pakietów używanym przez obie dystrybucje i ich pochodne. Podatność CVE-2026-109518 pozwala atakującemu, który kontroluje ruch HTTP między komputerem a serwerem repozytorium, podmienić pakiet już po weryfikacji podpisu. Efekt: instalacja pakietu atakującego i wykonanie kodu jako root.

Odkrywcą jest Max Justicz - ten sam badacz, który w 2019 roku znalazł w APT inną lukę pozwalającą na zdalne wykonanie kodu przez atak man-in-the-middle. Debian opublikował biuletyny DSA-6607-1 (Debian 13) i DLA-4880-1 (Debian 12), a Canonical - USN-8996-1 z poprawkami dla wszystkich wydań Ubuntu od 14.04 LTS.

Atak nie jest trywialny: wymaga pozycji w środku połączenia i spełnienia kilku warunków. Te warunki są jednak spełnione domyślnie w większości współczesnych instalacji, a pozycję „w środku” daje m.in. publiczne Wi-Fi, przejęty router, złośliwy serwer proxy albo zainfekowany mirror.

ROZDZIAŁ I: Dlaczego podpis nie wystarczył

Bezpieczeństwo APT nie opiera się na szyfrowaniu transportu, tylko na podpisach. Plik Release repozytorium jest podpisany kluczem GPG, zawiera skróty plików Packages, a te z kolei skróty każdego pakietu .deb. Dzięki temu łańcuchowi APT może pobierać paczki zwykłym HTTP z dowolnego mirrora: nawet jeśli ktoś zmodyfikuje plik po drodze, skrót się nie zgodzi i instalacja zostanie przerwana.

CVE-2026-109518 nie łamie tego łańcucha kryptograficznie. Uderza w moment między weryfikacją a instalacją. Według biuletynu Debiana nieprawidłowa obsługa plików przy wznawianiu pobierania przez HTTP pozwala atakującemu podmienić zawartość pakietu po tym, jak przeszedł on kontrolę. Ubuntu ujmuje to wprost: luka pozwala nakłonić APT do instalacji pakietu, który nie przeszedł weryfikacji podpisu.

To klasyczny błąd typu TOCTOU (time-of-check to time-of-use). NVD przypisuje mu dwie kategorie słabości: CWE-367 (wyścig między sprawdzeniem a użyciem) oraz CWE-62 (podatność związana z twardymi linkami w systemach uniksowych).

ROZDZIAŁ II: Mechanizm - przekierowanie, wznowienie, twardy link

Szczegółowy kod ścieżki ataku nie został opublikowany, ale z biuletynu Debiana, rekordu CVE i changelogu poprawki da się złożyć jego ogólny obraz. Składają się na niego trzy elementy:

• Przekierowanie HTTP. APT może połączyć dwa różne pobierania pakietów, jeśli przekierowanie HTTP sprawi, że oba wskazują ten sam URI.
• Ponowienie i wznowienie pobierania. Atak wymaga, by klient ponawiał nieudane pobrania. Według deweloperów APT atakujący może wymusić ponowienia, łącząc przekierowania ze zwykłymi tymczasowymi błędami serwera.
• Ponowne użycie twardych linków. Rekord CVE wskazuje, że źródłem problemu jest ponowne użycie twardych linków - czyli kilku nazw w systemie plików wskazujących ten sam plik. W efekcie dwa pobierania mogą „dzielić” jeden plik docelowy.

Uproszczony przebieg ataku, odtworzony na podstawie opisów źródłowych (kolejność środkowych kroków jest interpretacją, nie opublikowanym kodem):

1. APT rozpoczyna pobieranie pakietu przez HTTP.
2. Atakujący w środku połączenia (lub złośliwy mirror) odpowiada przekierowaniem i tymczasowymi błędami.
3. Klient podąża za przekierowaniem i ponawia pobieranie - dwa różne pobrania zaczynają wskazywać ten sam URI.
4. Dzięki ponownemu użyciu twardego linku oba pobierania operują na tym samym pliku.
5. Plik zostaje zweryfikowany, a następnie jego zawartość zostaje zmieniona przez drugie, kontrolowane przez atakującego pobieranie.
6. Instalator dostaje pakiet atakującego i uruchamia jego skrypty jako root.

ROZDZIAŁ III: Warunki ataku i realne scenariusze

Rekord CVE wymienia trzy warunki, które muszą zostać spełnione jednocześnie:

1. atakujący znajduje się na ścieżce między klientem a serwerem archiwum - może to być także złośliwy mirror lub proxy,
2. klient podąża za przekierowaniami i ponawia pobieranie plików pakietów,
3. ustawienie Acquire::Retries ma wartość większą od zera.

Ostatni warunek decyduje o tym, kto jest domyślnie narażony. Wartość 3 jest ustawieniem domyślnym od Debiana 12 (bookworm) i Ubuntu 22.04 LTS. Starsze wydania w domyślnej konfiguracji nie są podatne - ale każdy system, w którym administrator ręcznie włączył ponawianie pobrań, wpada w zakres luki, sięgający według NVD aż do APT z serii 1.0.

Gdzie to ma znaczenie

Źródła nie szeregują środowisk według ryzyka, ale z warunków ataku wynikają dość oczywiste priorytety:

• Laptopy w sieciach publicznych - hotelowe, lotniskowe i konferencyjne Wi-Fi to podręcznikowa pozycja man-in-the-middle.
• Wspólne proxy i mirrory cache’ujące (np. apt-cacher-ng w firmie) - jeden przejęty punkt pośredni obsługuje setki maszyn.
• Serwery budujące i pipeline’y CI/CD - obrazy kontenerów budowane z Dockerfile’i, które wywołują apt-get install przez HTTP. Podatny jest APT wewnątrz obrazu bazowego, nie na hoście.
• Mirrory dodane bez weryfikacji - nieoficjalne repozytoria, „szybsze” mirrory z forów, wpisy, o których nikt już nie pamięta.

ROZDZIAŁ IV: Poprawka i wersje

Upstreamowe wydanie APT 3.3.6 z 4 listopada 2026 roku opisuje zmianę jako aktualizację bezpieczeństwa „download verification bypass”. Wpis w changelogu jest lakoniczny: metody pobierania (methods/*.cc) otwierają teraz pliki docelowe w trybie wyłącznym. Oznacza to, że metoda pobierania odmówi zapisu do pliku, który już istnieje - co usuwa współdzielony plik, na którym opiera się atak. To nasza interpretacja; źródła nie rozpisują jej szczegółowo.

Ta sama aktualizacja usuwa też kilka błędów odczytu poza granicami bufora (out-of-bounds). Changelog 3.3.6 wspomina także odrzucanie pakietów .deb bez wymaganego pola Version oraz poprawkę sortowania w solverze zależności.

* Tylko jeśli Acquire::Retries ma wartość niezerową. Starsze wydania Ubuntu wymagają subskrypcji Ubuntu Pro (ESM), która jest bezpłatna dla maksymalnie 5 maszyn. Luka nie dotyczy pakietów snap ani transportów innych niż HTTP, np. FTP. Pochodne dystrybucje (Linux Mint, Pop!_OS, Kali, Raspberry Pi OS itd.) muszą wydać własne poprawki - warto śledzić komunikaty ich opiekunów.

ROZDZIAŁ V: Jak sprawdzić i zabezpieczyć system

Krok 1: sprawdź, czy jesteś podatny

# 1. Wersja APT (porównaj z tabelami powyżej)
apt --version

# Ubuntu: wszystkie pakiety z pakietu źródłowego apt
apt list --installed '?source-package(^apt$)'

# Czy changelog zainstalowanej wersji wymienia poprawkę
zgrep CVE-2026-109518 /usr/share/doc/apt/changelog.Debian.gz

# 2. Czy spełniony jest warunek ponowień
apt-config dump | grep -i retries

# 3. Skąd system pobiera pakiety i czy przez HTTP
grep -rE '^(deb|URIs)' /etc/apt/sources.list /etc/apt/sources.list.d/
apt-config dump | grep -i proxy

Jeśli wersja APT jest niższa niż poprawiona dla Twojego wydania, a Acquire::Retries ma wartość niezerową (domyślnie 3), system jest podatny.

Krok 2: zaktualizuj APT w bezpieczny sposób

Tu jest pewna ironia: poprawkę dla APT pobiera się… podatnym APT. Dlatego Canonical zaleca tymczasowe wyłączenie ponowień na czas samej aktualizacji - to usuwa jeden z warunków ataku, niezależnie od tego, czy zagrożeniem jest atakujący w sieci, czy złośliwy mirror. Najlepiej robić to też z zaufanej sieci.

# Ubuntu: aktualizacja z wyłączonymi ponowieniami (zalecenie Canonical)
sudo apt update && sudo apt upgrade -o Acquire::Retries=0

# Ubuntu: tylko APT, jeśli pełna aktualizacja nie jest możliwa
sudo apt update && sudo apt install -o Acquire::Retries=0 --only-upgrade '?source-package(^apt$)'

# Debian: analogicznie
sudo apt update -o Acquire::Retries=0
sudo apt install -o Acquire::Retries=0 --only-upgrade apt

W Ubuntu od 16.04 LTS domyślnie działa unattended-upgrades, które instaluje poprawki bezpieczeństwa w ciągu 24 godzin - o ile nie zostało wyłączone.

Krok 3: przejdź na HTTPS tam, gdzie to możliwe

Ponieważ exploitacja wymaga manipulowania ruchem HTTP, TLS chroni przed tą luką. Canonical podkreśla jednak, że po załataniu HTTPS jest już tylko dodatkowym zabezpieczeniem, a właściwą ochroną integralności pozostaje schemat podpisów archiwum, działający od końca do końca, a nie tylko w transporcie.

# Ubuntu: zamiana oficjalnych adresów HTTP na HTTPS (polecenie z biuletynu Canonical)
sudo sed -Ei 's!http://((([a-z]+\.)?archive|security|ports)\.ubuntu\.com)!https://\1!' \
  /etc/apt/sources.list /etc/apt/sources.list.d/*.list /etc/apt/sources.list.d/*.sources
sudo apt update

Polecenie zmienia tylko oficjalne adresy Ubuntu. Inne mirrory i repozytoria trzeba przejrzeć ręcznie, a część mirrorów społecznościowych - w tym niektóre krajowe - nie obsługuje HTTPS. W Debianie oficjalny deb.debian.org jest dostępny także przez HTTPS.

Rozwiązanie tymczasowe dla systemów, których nie da się od razu załatać

# /etc/apt/apt.conf.d/99-cve-2026-109518  (rozwiązanie tymczasowe)
Acquire::Retries "0";

Zerowa liczba ponowień usuwa warunek ataku, ale może pogorszyć niezawodność aktualizacji na słabych łączach. To łatka na kilka dni, nie zamiennik aktualizacji. W 2019 roku Max Justicz jako obejście poprzedniej luki zalecał wyłączenie przekierowań opcją Acquire::http::AllowRedirect=false; ponieważ podążanie za przekierowaniami jest jednym z warunków także obecnego ataku, ta opcja logicznie go utrudnia - nie jest to jednak zalecenie Debiana ani Canonical, a część infrastruktury mirrorów może z niej nie działać poprawnie.

Krok 4: przejrzyj ślady

Szczególnie na maszynach, które instalowały pakiety w niezaufanych sieciach przed aktualizacją, warto porównać pakiety w cache ze skrótami z indeksu i przejrzeć historię instalacji:

# Skrót pakietu z indeksu repozytorium...
apt-cache show PAKIET=WERSJA | grep ^SHA256
# ...porównany ze skrótem pliku w cache
sha256sum /var/cache/apt/archives/PLIK.deb

# Historia instalacji - na co zwrócić uwagę po pracy w niezaufanych sieciach
less /var/log/apt/history.log

ROZDZIAŁ VI: Déjà vu - CVE-2019-3462

To nie pierwszy raz, gdy Max Justicz pokazuje, że APT ma słaby punkt w obsłudze przekierowań. W styczniu 2019 roku opisał CVE-2019-3462 - lukę, która również pozwalała atakującemu w środku połączenia wykonać kod jako root przez przekierowanie HTTP. Wtedy problem polegał na tym, że dane z nagłówka przekierowania trafiały bez odpowiedniej walidacji do wewnętrznego protokołu, którym proces HTTP komunikuje się z głównym procesem APT.

Obecna luka to zupełnie inny błąd, ale lekcja jest ta sama. Kryptograficzny łańcuch zaufania jest tak mocny, jak kod, który go obsługuje. Przekierowania, wznawianie pobrań i zarządzanie plikami tymczasowymi to elementy, które rzadko trafiają do analizy zagrożeń, a działają z najwyższymi uprawnieniami w systemie.

EPILOG: Zaufanie do kanału aktualizacji

Mechanizm aktualizacji to najbardziej uprzywilejowany kanał w każdym systemie: z założenia instaluje kod, który wykona się jako root. Dlatego jego błędy mają inną wagę niż błędy w zwykłych aplikacjach. Tu nie trzeba było łamać kryptografii - wystarczyło, by w odpowiednim momencie podmienić plik, który kryptografia już „zatwierdziła”.

Praktyczne wnioski są proste: zaktualizować APT jak najszybciej, robić to z zaufanej sieci z wyłączonymi ponowieniami, przejrzeć mirrory i proxy, przejść na HTTPS tam, gdzie to możliwe, i nie zapomnieć o obrazach kontenerów. Na dzień publikacji nic nie wskazuje na aktywne wykorzystanie luki - i to jest najlepszy moment, żeby tak zostało.

Główne źródła

1. Ubuntu, "CVE-2026-109518 APT vulnerability fixes available", 4 listopada 2026 - https://ubuntu.com/blog/apt-vulnerability-fixes-available

2. Ubuntu, strona CVE-2026-109518 - https://ubuntu.com/security/CVE-2026-109518

3. Ubuntu Security Notice USN-8996-1 - https://ubuntu.com/security/notices/USN-8996-1

4. Debian Security Advisory DSA-6607-1, 4 listopada 2026 - https://lists.debian.org/debian-security-announce/2026/msg00526.html

5. Debian LTS Advisory DLA-4880-1, 4 listopada 2026 - https://lists.debian.org/debian-lts-announce/2026/11/msg00004.html

6. Debian Security Tracker, CVE-2026-109518 - https://security-tracker.debian.org/tracker/CVE-2026-109518

7. NVD, CVE-2026-109518 - https://nvd.nist.gov/vuln/detail/cve-2026-109518

8. Changelog APT 3.3.6 - https://metadata.ftp-master.debian.org/changelogs/main/a/apt/apt_3.3.6_changelog

9. Brandefense, "CVE-2026-109518: How an APT Download Retry Lets a Network Spy Swap a Verified Package", 4 listopada 2026 - https://brandefense.io/security-news/apt-cve-2026-109518-package-swap-root-explained/

10. Cyber Security News, "Debian and Ubuntu APT Flaw Lets Hackers Hijack Software Updates and Execute Code as Root", 4 listopada 2026 - https://cybersecuritynews.com/debian-apt-flaw-lets-hackers-hijack-updates/