Biuletyn Bezpieczeństwa PLOUG

Od 2006-01-31 do 2006-05-03

Wojciech Dworakowski, SecuRing
wojtekd@securing.pl

18 kwietnia 2006 ukazał się kwartalny zestaw poprawek
Critical Patch Update. Tym razem poprawek jest nieco mniej. Poprawiono 36
podatności z czego 13 dotyczy bazy danych. Poniżej opisano kilka
najistotniejszych podatności, o których udało się uzyskać nieco więcej
informacji niż
w standardowym opisie CPU. Publikujemy również informacje o dwóch podatnościach
jeszcze nie załatanych przez Oracle.

Opisywany okres obfitował w warte odnotowania wydarzenia
dotyczące bezpieczeństwa Oracle. Pierwszym
z nich jest kuriozalny wręcz przypadek opublikowania przykładu wykorzystania
(exploita) niepoprawionej jeszcze dziury przez… samego producenta. 06 kwietnia
na Metalinku ukazał się artykuł o nowej dziurze „363848.1 – A User with SELECT
Object Privilege on Base Tables Can Delete Rows from a View”. Co ciekawsze (i
jeszcze bardziej kuriozalne) artykuł ten zawierał przykład wykorzystania tej
niepoprawionej podatności (czyli tzw. 0-day exploit). Kilka dni później fakt ten
został zauważony przez jednego z ekspertów badających bezpieczeństwo Oracle,
który poinformował o tym producenta i niefortunny artykuł został zdjęty z
Metalinku. Niestety pomimo zapowiedzi Oracle, poprawka dotycząca podatności nie
znalazła się w najnowszym zestawie poprawek CPU-Apr-2006. Na szczęście
publicznie dostępne w Internecie przykłady jej wykorzystania mają
„wycenzurowaną” kluczową część. Podatność tę opisano poniżej jako drugą.

Równie dziwny jest sposób publikowania poprawek przez Oracle.
Pomimo tego, że termin 18 kwietnia był zapowiedziany już dawno, to w tym dniu
były dostępne poprawki jedynie dla niektórych wersji i niektórych platform.
Reszta poprawek do oficjalnie wspieranych wersji (wg zapewnień producenta) miała
ujrzeć światło dzienne 1 maja. Tymczasem tego dnia ukazał się kolejny komunikat
przekładający ten termin na 15 maja.
(Ze względu na to że artykuł ten oddaję do druku 4 maja nie jestem w stanie
stwierdzić czy termin ten zostanie dotrzymany). Taki niefrasobliwy sposób
publikowania poprawek spotkał się z szeroką falą krytyki ze strony ekspertów
bezpieczeństwa Oracle. Przypomnijmy, że kwartalny, z góry zapowiedziany cykl
wypuszczania poprawek miał ułatwić administratorom przygotowanie się do
instalacji poprawek i szczegółowe zaplanowanie przestojów kluczowych systemów.
Tymczasem w praktyce poprawki nie ukazują się na czas dla wszystkich wspieranych
wersji, a ponadto często zdarza się że Oracle ponownie wypuszcza poprawki. David
Litchfield na
liście Full Disclosure (http://seclists.org/lists/fulldisclosure/2006/May/0018.html) wylicza, że 18 kwietnia nie ukazały
się poprawki do wersji bazy: 10.2.0.2, 10.1.0.4, 10.1.0.3, 9.2.0.5, 8.1.7.4 i
tylko częściowo do wersji 10.1.0.5. Poprawki były dostępne tylko dla 33% z
obecnie wspieranych wersji produktów Oracle. Ponadto poprzednie CPU były
wielokrotnie poprawiane i wznawiane (CPU Jan 2006 – 7 razy, CPU Oct 2005 – 3
razy, CPU Jul 2005 – 9 razy!). Jeśli administrator planuje przestój systemu
w związku z instalacją zbioru poprawek, a poprawki te nie ukazują się na czas
lub są wielokrotnie wznawiane, to jego plany idą w łeb i w rezultacie mamy
większy chaos niż przed wprowadzeniem kwartalnych CPU.

Na koniec tego wstępu – prawdziwy „przebój” ostatnich dni: 19
kwietnia (jeden dzień po wypuszczeniu CPU przez Oracle), anonimowy autor na
liście dyskusyjnej BugTraq opublikował działający exploit pozwalający na
wykonanie własnej procedury
PL/SQL z prawami SYS. Co gorsza okazało się, że exploit działa nawet po wgraniu
najnowszego zestawu poprawek z kwietnia. Podatność tę opisano poniżej jako
pierwszą.

Błąd pozwalający na wykonanie wrogiego kodu PL/SQL w pakiecie
DBMS_EXPORT_EXTENSION

Produkty podatne na zagrożenie:

Oracle Database – wszystkie wersje od 9i.

Data publicznego ujawnienia:

19.04.2006 – anonimowy artykuł na listach Full Disclosure i
Bugtraq.

Opis:

Podatność umożliwia wykonanie własnej procedury PL/SQL z
prawami SYS w wyniku wykorzystania jednej z funkcji podatnego pakietu.

Status:

Podatności nie poprawiono w CPU Apr 2006.

Ryzyko: bardzo duże

Aby wykorzystać podatność, intruz musi mieć dowolne konto w
bazie. Podatność może zostać wykorzystana nawet przez niedoświadczonego intruza
ze względu na to, że przykładowy kod został opublikowany na listach dyskusyjnych
BugTraq i Full Disclosure.

Skutki potencjalnego ataku: duże

Skutkiem udanego ataku jest wykonanie własnej procedury z
prawami SYS. Opublikowany exploit zakłada w bazie użytkownika z prawami DBA.

Szczegóły techniczne:

Podatność istnieje w procedurze GET_DOMAIN_INDEX_METADATA
pakietu DBMS_EXPORT_EXTENSION. Podstawienie nazwy własnej procedury pod jeden z przekazywanych
parametrów (TYPE_NAME) powoduje wykonanie tej procedury z przywilejami SYS.

Usunięcie podatności:

Jako tymczasowe obejście problemu sugerowane jest zabranie
przywilejów do pakietu DBMS_EXPORT_EXTENSION grupie PUBLIC.

Możliwość uzyskania większych uprawnień przez manipulację widokami

Produkty podatne na zagrożenie:

Oracle Database – wszystkie wersje.

Data publicznego ujawnienia:

06.04.2006 – Artykuł na Metalinku.

Opis:

Odpowiednio manipulując widokami można uzyskać prawa
modyfikacji danych do których standardowo użytkownik ma tylko prawa odczytu.

Status:

Podatności nie poprawiono w CPU Apr 2006.

Ryzyko: bardzo duże

Podatność może zostać wykorzystana przez dowolnego
użytkownika, który ma nadane bezpośrednio uprawnienia SELECT do atakowanej
tabeli. Na Metalinku był dostępny przez kilka dni przykład pokazujący, jak
wykorzystać opisywaną podatność.

Skutki potencjalnego ataku: duże

Intruz może modyfikować dowolne dane w bazie, do których ma
jedynie przywilej SELECT.

Szczegóły techniczne:

Wykorzystanie podatności polega na utworzeniu odpowiedniego
widoku do atakowanych danych i modyfikowaniu tych danych za pośrednictwem tego
widoku. Podatność wynika prawdopodobnie z nieprawidłowego sprawdzania praw
dostępu przez bazę Oracle podczas tworzenia widoków.

Usunięcie podatności:

Jedynym znanym i skutecznym obejściem problemu jest nadawanie
przywileju SELECT wyłącznie przez rolę a nie bezpośrednio (podatności nie da się
wykorzystać jeśli przywilej
SELECT jest nadany przez rolę a nie bezpośrednio dla użytkownika).

Błąd pozwalający na wykonanie wrogiego kodu PL/SQL w pakiecie
DBMS_LOGMNR_SESSION

Produkty podatne na zagrożenie:

Oracle Database – wszystkie wersje od 9iR2.

Data publicznego ujawnienia:

18.04.2006 – Alexander Kornburst (Red Database Security).

Opis:

Błąd w implementacji jednej z procedur umożliwia uzyskanie
większych przywilejów w wyniku wykonania kodu PL/SQL doklejonego do jednego z
parametrów.

Status:

Oracle opublikowało poprawkę (CPU Apr 2006). Uwaga: poprawka
nie jest dostępna dla wszystkich wspieranych wersji. Oracle zapowiada
uzupełnienie brakujących poprawek 15 maja 2006.

Ryzyko: średnie

Podatny pakiet jest standardowo dostępny przez rolę
EXECUTE_CATALOG_ROLE. Nie opublikowano przykładów wykorzystania podatności, ale
ujawniono nazwę procedury w której występuje błąd, co znacznie ułatwia
samodzielne odkrycie podatności przez doświadczonego intruza.

Skutki potencjalnego ataku: duże

Doklejony wrogi kod PL/SQL wykona się z przywilejami SYS.

Szczegóły techniczne:

Podatność występuje w procedurze DELETE_FROM_TABLE pakietu
SYS.DBMS_LOGMNR_SESSION.

Usunięcie podatności:

Wgranie ostatniego zestawu poprawek CPU-Apr-2006. Podatność
usunięto przy wykorzystaniu pakietu DBMS_ASSERT (pakiet służący do filtrowania
parametrów wprowadzony w 10gR2 oraz w CPU-Oct-2005). Może to oznaczać że w
przyszłości podatność znowu będzie można wykorzystać, ponieważ istnieją
doniesienia o licznych błędach pozwalających obejść filtrowanie zaimplementowane
w DBMS_ASSERT.

Możliwość przepełnienia bufora wejściowego
w procedurze z pakietu DBMS_SNAPSHOT_UTL

Produkty podatne na zagrożenie:

Oracle Database – od wersji 10gR1.

Data publicznego ujawnienia:

18.04.2006 – Esteban Martínez Fayó (Argeniss Information
Security).

Opis:

Manipulacja parametrami przekazywanymi do procedury
VERIFY_LOG z pakietu DBMS_SNAPSHOT_UTL może doprowadzić do wykonania wrogiego
kodu w systemie operacyjnym. Kod wykona się z uprawnieniami właściciela
instalacji Oracle.

Status:

Oracle opublikowało poprawkę (CPU Apr 2006).
Uwaga: poprawka nie jest dostępna dla wszystkich wspieranych
wersji. Oracle zapowiada uzupełnienie brakujących poprawek 15 maja 2006.
Jest możliwe obejście problemu przez odpowiednią modyfikację
uprawnień.

Ryzyko: duże

Podatność może być wykorzystana przez dowolnego użytkownika
mającego możliwość wywoływania procedur z bazy danych (podatne procedury są
dostępne dla grupy PUBLIC).
Nie są znane publicznie dostępne exploity wykorzystujące tę
podatność, jednak jedna z firm sprzedaje exploit wykorzystujący ją jako część
pakietu exploitów na Oracle (cena 2500 USD).

Skutki potencjalnego ataku: duże

Skutkiem ataku jest wykonanie dowolnego kodu w systemie
operacyjnym
z uprawnieniami właściciela instalacji Oracle lub zawieszenie procesu serwera
bazy danych.

Szczegóły techniczne:

Podatność istnieje w procedurze
VERIFY_LOG z pakietu DBMS_SNAPSHOT_UTL. Standardowo procedura ta jest dostępna dla grupy PUBLIC. Pakiet
DBMS_SNAPSHOT_UTL służy do zarządzania tzw. „materialized views” i jest częścią
komponentu „Advanced Replication”.

Usunięcie podatności:

Podatność jest usuwana przez wgranie zestawu poprawek „Oracle
Critical Patch Update January 2006”. Istnieje również możliwość obejścia
problemu przez obcięcie praw do pakietu DBMS_SNAPSHOT_UTL. Zainteresowany tym
rozwiązaniem czytelnik znajdzie szczegóły pod adresem: http://www.argeniss.com/research/Workaround-ADV-040603.sql

Liczne podatności
w Oracle Diagnostics

Produkty podatne na zagrożenie:

Oracle E-Business Suite 11i od wersji 11.5.3.

Data publicznego ujawnienia:

24.02.2006 – Integrigy Corporation.

Opis:

W komponencie Oracle Diagnostics wykryto wiele podatności
związanych z interfejsem WWW i klasami Java.

Status:

Podatności zostały usunięte w uaktualnieniu „Diagnostics
Support Pack February 2006 with Oracle Diagnostics 2.3 RUP A”.

Ryzyko: duże

Wykorzystanie części z podatności wymaga jedynie dostępu do
ścieżki HTTP Oracle Diagnostics (standardowo: /OA_HTML/jtfqalgn.htm). Nie
opublikowano dokładnych przykładów wykorzystania podatności, ale są dostępne
dość szczegółowe analizy które mogą ułatwić zadanie doświadczonemu intruzowi.

Skutki potencjalnego ataku: duże

Skutkiem ataków wykorzystujących opisywane podatności może
być m.in.: wykonanie wrogiego kodu
PL/SQL w bazie danych, uzyskanie większych przywilejów na serwerze aplikacji,
dostanie się do logów z testów innych użytkowników.

Szczegóły techniczne:

Podatności umożliwiają atakowanie Oracle Diagnostics na wiele
sposobów. Znaleziono m.in. błędy SQL-injection, błędy umożliwiające uzyskanie
większych przywilejów, a także trywialne podatności związane z brakiem
jakiegokolwiek uwierzytelniania do części testów wykonywanych przez Oracle
Diagnostics. Dokładniejsza analiza błędów i poprawek jest dostępna pod adresem: http://www.integrigy.com/info/IntegrigySecurityAnalysis-OracleDiag0206.pdf

Usunięcie podatności:

Wgranie uaktualnienia „Diagnostics Support Pack February 2006 with Oracle
Diagnostics 2.3 RUP A”. Oracle Diagnostics jest również wymienione w „Risk
Matrix” CPU-Apr-2006 (podatność APPS09) ale nie jest jasne, czy poprawka dotyczy
opisywanych podatności.