Bezpieczeństwo

Kilka dni temu ukazał się exploit umożliwiający zdalne wykonanie kodu przy wykorzystaniu znanej od 4 grudnia podatności przepełnienia sterty (heap overflow vulnerability) w procedurze systemowej sp_replwritetovarbin. Kilka dni po publikacji exploita Microsoft potwierdził, że narażonych jest całkiem sporo wersji systemu SQL Server. Problem dotyczy bowiem wszystkich wersji 2000 oraz wszystkich 2005 bez najnowszego SP3, który lukę eliminuje. SQL Server 2008 jest wolny od problemu.

sp_replwritetovarbin to rozszerzona procedura składowana (extended stored procedure - czyli de facto zewnętrzna biblioteka wywoływana w kontekście instancji SQL Server) wykorzystywana przez wewnętrzne interfejsy replikacyjne wyłącznie w jednej sytuacji - kiedy w replikacji transakcyjnej z modyfikowalnymi subskrypcjami (transactional replication with updatable subscriptions) o odpowiednim ustawieniu @update_mode ('failover' lub 'queued tran' - domyślne) dokonywana jest DMLowa operacja modyfikacji w tabelach subskrypcji. Aby zablokować możliwość przeprowadzenia ataku najlepiej odebrać prawa wykonywania procedury roli public (REVOKE) lub odmówić tego prawa (DENY):

USE master
DENY EXECUTE ON sp_replwritetovarbin TO public

a następnie - o ile to możliwe - podnieść wersję instancji do co najmniej SQL Server 2005 SP3. Oczywiście powyższa zmiana uprawnień będzie skutkowała wyłożeniem się replikacji (ale tylko w/w rodzaju, pozostałe replikacje - np. klasyczna transakcyjna - nie są zagrożone workaroundem).

Na czym polega problem z niesławną procedurą sp_replwritetovarbin? Na tym, że kiedy zostanie wywołana z takimi przykładowymi parametrami:

DECLARE @retcode int,
@end_offset int,
@vb_buffer varbinary,
@vb_bufferlen int,
@buf nvarchar;
EXEC master.dbo.sp_replwritetovarbin 1, @end_offset output, @vb_buffer output, @vb_bufferlenoutput,
'AAAAAAAAAAAAAAAA(..3 tysiące liter A..)AAAAAAAAAAAAAA','1','1','1', '1','1','1','1','1','1';

to biblioteka stojąca za procedurą wykona zapis do kontrolowanego adresu w pamięci, przez co możliwe jest wstrzyknięcie i wykonanie obcego kodu w kontekście procesu instancji SQL Server. Gotowy exploit można znaleźć tutaj (zapytania zaszyte w kodzie VB strony ASP, exploit tworzy tzw. reverse shella na porcie 4445). Atakujący musi dysponować uwierzytelnionym dostępem do instancji serwera (czyli mówiąc wprost musi być w stanie wykonać kod T-SQL choćby w kontekście konta o najsłabszych uprawnieniach), gdyż prawo wywołania procedury przypisane jest do roli public bazy master. Do wykorzystania exploita w scenariuszu prawdziwego ataku potrzebny jest więc także np. skuteczny SQL injection, choć oczywiście to tylko jedna z wielu możliwości.

Luka jest moim zdaniem całkiem poważna i występuje w miejscu, które od dawna wskazywane było i jest jako niebezpieczne - czyli wesoły i swawolny obszar rozszerzonych procedur składowanych. Od kiedy w wersji SQL Server 2005 pojawiła się możliwość integracji CLR (czyli pisania m.in. procedur składowanych w kodzie zarządzanym .NET), uzasadnienie istnienia procedur XP ogranicza się już tylko do kwestii interfejsów wewnętrznych/systemowych, a i te można przecież "unatywnić" w samym silniku bazodanowym, tak jak jest to zrobione m.in. z obsługą dziennika transakcji. Choć z drugiej strony całkowicie rozumiem programistów z Redmond - też bałbym się dotykać czegokolwiek związanego z replikacją :)

Więcej informacji:
Microsoft Security Advisory (961040): Vulnerability in SQL Server Could Allow Remote Code Execution
SEC Consult Security Advisory < 20081209-0 >
EXPLOIT: Microsoft SQL Server "sp_replwritetovarbin()" Heap Overflow - Reverse Shell