Na FreeBSD pięć luk, w tym problemy, które mogą potencjalnie prowadzić do nadpisywania danych na poziomie jądra podczas wysyłania niektórych pakietów sieciowych lub umożliwiać użytkownikowi lokalnemu eskalację jego uprawnień. Luki zostały naprawione w aktualizacjach 12.1-RELEASE-p5 i 11.3-RELEASE-p9.
Najbardziej niebezpieczna luka () jest spowodowane brakiem odpowiedniego sprawdzania rozmiaru pakietu w bibliotece libalias podczas analizowania nagłówków specyficznych dla protokołu. Biblioteka libalias jest używana w filtrze pakietów ipfw do translacji adresów i zawiera standardowe funkcje zastępowania adresów w pakietach IP i protokołów analizowania. Luka pozwala poprzez wysłanie specjalnie zaprojektowanego pakietu sieciowego na odczyt lub zapis danych w obszarze pamięci jądra (przy wykorzystaniu implementacji NAT w jądrze) lub przetworzenie
natd (jeśli używasz implementacji NAT w przestrzeni użytkownika). Problem nie dotyczy konfiguracji NAT zbudowanych przy użyciu filtrów pakietów pf i ipf ani konfiguracji ipfw, które nie korzystają z NAT.
Inne luki:
- - kolejna możliwa do zdalnego wykorzystania luka w libaliach związana z nieprawidłowym obliczaniem długości pakietów w procedurze obsługi FTP. Problem ogranicza się do wycieku zawartości kilku bajtów danych z obszaru pamięci jądra lub procesu natd.
- — luka w module cryptodev spowodowana dostępem do już zwolnionego obszaru pamięci (użyj po zwolnieniu) i umożliwieniem nieuprzywilejowanemu procesowi nadpisania dowolnych obszarów pamięci jądra. W ramach obejścia blokowania luki zaleca się wyładowanie modułu cryptodev za pomocą polecenia „kldunload cryptodev”, jeśli został załadowany (domyślnie cryptdev nie jest ładowany). Moduł cryptodev zapewnia aplikacjom przestrzeni użytkownika dostęp do interfejsu /dev/crypto w celu uzyskania dostępu do przyspieszanych sprzętowo operacji kryptograficznych (/dev/crypto nie jest używane w AES-NI i OpenSSL).
- - druga luka w cryptodev, która pozwala nieuprzywilejowanemu użytkownikowi zainicjować awarię jądra poprzez wysłanie żądania wykonania operacji kryptograficznej z nieprawidłowym MAC. Problemem jest brak sprawdzenia wielkości klucza MAC podczas przydzielania bufora do jego przechowywania (bufor został utworzony na podstawie danych o rozmiarze podanych przez użytkownika, bez sprawdzania rzeczywistego rozmiaru).
- - luka w implementacji protokołu SCTP (Stream Control Transmission Protocol) spowodowana błędną weryfikacją klucza współdzielonego wykorzystywanego przez rozszerzenie SCTP-AUTH do uwierzytelniania sekwencji SCTP. Lokalna aplikacja może zaktualizować klucz poprzez Socket API, jednocześnie kończąc połączenie SCTP, co umożliwi dostęp do już zwolnionego obszaru pamięci (use-after-free).
Źródło: opennet.ru