r3dxpl0it/rtspserver-code-execution-vulnerabilityRTSPServer Уязвимость выполнения кода CVE-2018-4013
CVE-2018-4013
Существует эксплуатируемая уязвимость выполнения кода в функционале парсинга HTTP-пакетов библиотеки RTSP-сервера LIVE555. Специально сформированный пакет может вызвать переполнение буфера в стеке, что приводит к выполнению кода. Злоумышленник может отправить пакет для эксплуатации этой уязвимости.
Библиотеки LIVE555 Media Libraries — это легковесный набор библиотек для потоковой передачи мультимедиа по протоколам RTSP/RTCP/RTSP/SIP, с поддержкой кода как для серверов, так и для клиентов. Они используются популярными медиаплеерами, такими как VLC и MPlayer, а также множеством встраиваемых устройств (в основном камер). Эта уязвимость находится в серверном компоненте, который взаимодействует с этими медиаплеерами, но не затрагивает сами медиаплееры.
Одна из функций, предоставляемых LIVE555 для стандартного RTSP-сервера, — это возможность туннелирования RTSP через HTTP, который обслуживается через другой порт, привязанный сервером, обычно TCP 80, 8000 или 8080, в зависимости от доступных портов на хост-машине. Этот порт может поддерживать обычный RTSP, но в некоторых случаях HTTP-клиент может договориться о туннеле RTSP-over-HTTP. Код, обрабатывающий эту функцию:
// liveMedia/RTSPServer.cpp:607
void RTSPServer::RTSPClientConnection::handleRequestBytes(int newBytesRead) {
[...]
// The request was not (valid) RTSP, but check for a special case: HTTP commands
// (for setting up RTSP-over-HTTP tunneling):
char sessionCookie[RTSP_PARAM_STRING_MAX]; //[1]
char acceptStr[RTSP_PARAM_STRING_MAX]; //[2]
*fLastCRLF = '\0'; // temporarily, for parsing
parseSucceeded = parseHTTPRequestString(cmdName, sizeof cmdName,
urlSuffix, sizeof urlPreSuffix,
sessionCookie, sizeof sessionCookie,
acceptStr, sizeof acceptStr); //[3]
Как показано выше на [3], HTTP-заголовки «Accept» и «x-sessioncookie» определяют, является ли это туннелем RTSP-over-HTTP или нет. Таким образом, параметры считываются из входных байтов в буферы sessionCookie [1] и acceptStr [2] в стеке (оба размером 200), а затем обрабатываются далее.
Путь кода ведёт к функции parseHTTPRequestString:
Boolean RTSPServer:: RTSPClientConnection::parseHTTPRequestString(char* resultCmdName, unsigned resultCmdNameMaxSize,
char* eurlSuffix, unsigned urlSuffixMaxSize,
char* sessionCookie, unsigned sessionCookieMaxSize,
char* acceptStr, unsigned acceptStrMaxSize) {
[...]
lookForHeader("x-sessioncookie", &reqStr[i], reqStrSize-i, sessionCookie, sessionCookieMaxSize); // [1]
lookForHeader("Accept", &reqStr[i], reqStrSize-i, acceptStr, acceptStrMaxSize); //[2]
Единственное, что действительно важно отметить, — это то, что массивы char из родительской функции снова передаются в новую функцию непосредственно в [1] (sessionCookie) и [2] (acceptStr). Это приводит к функции lookForHeader:
static void lookForHeader(char const* headerName, char const* source, unsigned
sourceLen, char* resultStr, unsigned resultMaxSize) {
resultStr[0] = '\0'; // by default, return an empty string
unsigned headerNameLen = strlen(headerName);
for (int i = 0; i < (int)(sourceLen-headerNameLen); ++i) {
if (strncmp(&source[i], headerName, headerNameLen) == 0 && source[i+headerNameLen] == ':') { // [1]
// We found the header. Skip over any whitespace, then copy the rest of the line to "resultStr":
for (i += headerNameLen+1; i < (int)sourceLen && (source[i] == ' ' || source[i] == '\t'); ++i) {}
for (unsigned j = i; j < sourceLen; ++j) { // [4]
if (source[j] == '\r' || source[j] == '\n') { // [2]
// We've found the end of the line. Copy it to the result (if it will fit):
if (j-i+1 > resultMaxSize) break;
char const* resultSource = &source[i];
char const* resultSourceEnd = &source[j];
while (resultSource < resultSourceEnd) *resultStr++ = *resultSource++; // [5]
*resultStr = '\0';
break; //[3]
}
}
}
}
}
Внешний цикл перебирает наши входные байты до тех пор, пока не будет найден headerName. В случае этой программы он непрерывно ищет «Accept:» и «x-sessioncookie:» с помощью strncmp на [1]. Как отмечено в комментарии, другой цикл пропускает любые пробельные символы, а затем начинает искать ожидаемые символы новой строки '\r\n' на [2]. После этого программа корректно ограничивает размер копирования до resultMaxSize, который правильно установлен на 0xc8 (200) при обоих вызовах этой функции.
После копирования срабатывает break на [3], который фактически прерывает только цикл на [4], заставляя код вернуться к начальному циклу strncmp, упомянутому выше. Таким образом, если в буфере присутствует другая строка «Accept:» или «x-sessioncookie», копирование происходит снова, и если мы рассмотрим фактический метод копирования на [5], мы увидим, что наш начальный указатель (указывающий на адрес в стековом фрейме функции handleRequestBytes) продолжает увеличиваться, и хотя длина любой конкретной копии ограничена размером буфера, когда нет ограничения на количество копий, которые могут быть выполнены по постоянно увеличивающемуся адресу назначения, легко может возникнуть переполнение буфера в стеке.
Crash Output
==38574==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7fffffffd878 at pc 0x555555aad1fb bp 0x7fffffffced0 sp 0x7fffffffcec8
WRITE of size 1 at 0x7fffffffd878 thread T0
#0 0x555555aad1fa in lookForHeader /root/boop/work_work/triages/live555/live/liveMedia/RTSPServer.cpp:398
#1 0x555555aad847 in RTSPServer::RTSPClientConnection::parseHTTPRequestString(char*, unsigned int, char*, unsigned int, char*, unsigned int, char*, unsigned int) /root/boop/work_work/triages/live555/live/liveMedia/RTSPServer.cpp:479
#2 0x555555ab82ac in RTSPServer::RTSPClientConnection::handleRequestBytes(int) /root/boop/work_work/triages/live555/live/liveMedia/RTSPServer.cpp:828
#3 0x555555aa9c17 in GenericMediaServer::ClientConnection::incomingRequestHandler() /root/boop/work_work/triages/live555/live/liveMedia/GenericMediaServer.cpp:246
#4 0x555555e0063b in BasicTaskScheduler::SingleStep(unsigned int) /root/boop/work_work/triages/live555/live/BasicUsageEnvironment/BasicTaskScheduler.cpp:153
#5 0x555555e12c75 in BasicTaskScheduler0::doEventLoop(char volatile*) /root/boop/work_work/triages/live555/live/BasicUsageEnvironment/BasicTaskScheduler0.cpp:80
#6 0x555555a9452c in main /root/boop/work_work/triages/live555/live/mediaServer/live555MediaServer.cpp:89
#7 0x7ffff550b2b0 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x202b0)
#8 0x555555a978e9 in _start (/root/boop/work_work/triages/live555/live555MediaServer+0x5438e9)
Address 0x7fffffffd878 is located in stack of thread T0 at offset 2024 in frame
#0 0x555555ab6b9f in RTSPServer::RTSPClientConnection::handleRequestBytes(int) /root/boop/work_work/triages/live555/live/liveMedia/RTSPServer.cpp:607
This frame has 12 object(s):
[32, 33) 'reuseConnection'
[96, 97) 'deliverViaTCP'
[160, 164) 'contentLength'
[224, 232) 'proxyURLSuffix'
[288, 488) 'cmdName'
[544, 744) 'urlPreSuffix'
[800, 1000) 'urlSuffix'
[1056, 1256) 'cseq'
[1312, 1512) 'sessionIdStr'
[1568, 1768) 'sessionCookie'
[1824, 2024) 'acceptStr' <== Memory access at offset 2024 overflows this variable
[2080, 2480) 'urlTotalSuffix'
HINT: this may be a false positive if your program uses some custom stack unwind mechanism or swapcontext
(longjmp and C++ exceptions *are* supported)
SUMMARY: AddressSanitizer: stack-buffer-overflow /root/boop/work_work/triages/live555/live/liveMedia/RTSPServer.cpp:398 in lookForHeader
Shadow bytes around the buggy address:
0x10007fff7ab0: f4 f4 f2 f2 f2 f2 00 00 00 00 00 00 00 00 00 00
0x10007fff7ac0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f4
0x10007fff7ad0: f4 f4 f2 f2 f2 f2 00 00 00 00 00 00 00 00 00 00
0x10007fff7ae0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f4
0x10007fff7af0: f4 f4 f2 f2 f2 f2 00 00 00 00 00 00 00 00 00 00
=>0x10007fff7b00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00[f4]
0x10007fff7b10: f4 f4 f2 f2 f2 f2 00 00 00 00 00 00 00 00 00 00
0x10007fff7b20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x10007fff7b30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x10007fff7b40: 00 00 00 00 00 00 00 00 f4 f4 f3 f3 f3 f3 00 00
0x10007fff7b50: 00 00 00 00 00 00 00 00 00 00 f1 f1 f1 f1 00 00
Обнаружено Lilith ¯_(ツ)_/¯ из Cisco Talos.