Zostały wydane poprawki dla wszystkich wspieranych wersji PostgreSQL 17.3, 16.7, 15.11, 14.16 i 13.19, w których naprawiono ponad 70 błędów oraz usunięto podatność (CVE-2025-1094), wykorzystaną pod koniec grudnia w ataku na firmę BeyondTrust oraz Ministerstwo Finansów USA. Problem w PostgreSQL ujawniono w trakcie analizy zdalnej podatności (CVE-2024-12356) w usługach BeyondTrust PRA (Privileged Remote Access) i BeyondTrust RS (Remote Support), w której dodatkowo wykorzystano wcześniej nieznaną (0-day) podatność w libpq.
W wyniku ataku cyberprzestępcy uzyskali dostęp do klucza API, używanego do zdalnego świadczenia usług wsparcia technicznego klientom usług SaaS firmy BeyondTrust. Ten API został wykorzystany do resetowania haseł i naruszenia infrastruktury Ministerstwa Finansów USA, które korzysta z produktów BeyondTrust. W trakcie ataku cyberprzestępcy mogli pobrać poufne dokumenty i uzyskali dostęp do stacji roboczych pracowników ministerstwa.
Podatność występuje w bibliotece libpq, która dostarcza API do interakcji z bazami danych z programów napisanych w języku C (na tej bibliotece realizowane są również biblioteki opakowujące dla C++, Perl, PHP i Python). Problem dotyczy aplikacji, które korzystają z funkcji PQescapeLiteral(), PQescapeIdentifier(), PQescapeString() lub PQescapeStringConn() w celu zabezpieczenia znaków specjalnych i neutralizacji cudzysłowów.
Atakujący może wprowadzić swój kod SQL, jeśli tekst otrzymywany z zewnątrz przed użyciem w zapytaniu SQL jest zabezpieczany przy pomocy wyżej wymienionych funkcji libpq. W aplikacjach BeyondTrust takie zabezpieczone zapytania były przekazywane za pomocą narzędzia wiersza poleceń psql. Podatność wynika z braku w funkcjach zabezpieczających weryfikacji poprawności używanych znaków Unicode w tekście, co pozwala na obejście normalizacji cudzysłowów poprzez wskazanie nieprawidłowych wielobajtowych sekwencji UTF-8.
Do wykorzystania lukę można użyć nieprawidłowego znaku UTF-8, składającego się z bajtów 0xC0 i 0x27 („└'”). Bajt 0x27 w kodowaniu ASCII odpowiada pojedynczemu cudzysłowowi („‘”), który wymaga eskapowania. W kodzie eskapowania kombinacja bajtów 0xC0 i 0x27 jest przetwarzana jako jeden znak Unicode. W związku z tym bajt 0x27 w tym ciągu pozostaje nieeskapowany, podczas gdy podczas przetwarzania zapytania SQL w narzędziu psql jest traktowany jako cudzysłów.
Przy uruchamianiu zapytań SQL za pomocą narzędzia psql do przeprowadzania kodu arbitralnego można wykorzystać zastąpienie w ciągu polecenia „\!”, które w psql służy do uruchamiania dowolnych programów. Na przykład, aby uruchomić na serwerze narzędziu „id” można przekazać wartość „hax\xC0′; \! id #”. W poniższym przykładzie do eskapowania wywoływany jest skrypt PHP dbquote, korzystający z funkcji PHP pg_escape_string, działającej na bazie funkcji PQescapeString z libpq: $ echo -e „hello \xC0’world'” | .\/dbquote 'hello └’world»' $ quoted=$(echo -e „hax\xC0′; \! id # ” | .\/dbquote) $ echo „SELECT COUNT(1) FROM gw_sessions WHERE session_key = $quoted AND session_type = ‘sdcust’ AND (expiration IS NULL OR expiration>NOW())” | psql -e SELECT COUNT(1) FROM gw_sessions WHERE session_key = ‘hax└’; ERROR: invalid byte sequence for encoding „UTF8”: 0xc0 0x27 uid=1000(myexamplecompany) gid=1000(myexamplecompany)
Źródło: opennet.ru
