r3dxpl0it/rtspserver-code-execution-vulnerabilityRTSPServer Vulnérabilité d'exécution de code CVE-2018-4013
CVE-2018-4013
Une vulnérabilité d'exécution de code exploitable existe dans la fonctionnalité d'analyse de paquets HTTP de la bibliothèque serveur RTSP LIVE555. Un paquet spécialement conçu peut provoquer un débordement de tampon basé sur la pile, entraînant une exécution de code. Un attaquant peut envoyer un paquet pour déclencher cette vulnérabilité.
Les bibliothèques LIVE555 Media Libraries sont un ensemble léger de bibliothèques de streaming multimédia pour RTSP/RTCP/RTSP/SIP, avec un support de code pour les serveurs et les clients. Elles sont utilisées par des lecteurs multimédias populaires tels que VLC et MPlayer, ainsi que par une multitude de dispositifs embarqués (principalement des caméras). Cette vulnérabilité se trouve dans le composant serveur qui interagit avec ces lecteurs multimédias mais n'affecte pas les lecteurs.
L'une des fonctionnalités offertes par LIVE555 pour son serveur RTSP standard est la possibilité de tunnelliser RTSP sur HTTP, qui est servie sur un port différent lié par le serveur, généralement TCP 80, 8000 ou 8080, selon les ports disponibles sur la machine hôte. Ce port peut supporter du RTSP normal, mais dans certains cas, le client HTTP peut négocier le tunnel RTSP sur HTTP. Le code qui gère cette fonctionnalité est :
// 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]
Comme illustré ci-dessus en [3], les en-têtes HTTP « Accept » et « x-sessioncookie » sont ceux qui déterminent s'il s'agit d'un tunnel RTSP sur HTTP ou non. Ainsi, les paramètres sont lus à partir des octets d'entrée dans les tampons sessionCookie [1] et acceptStr [2] sur la pile (tous deux de taille 200), puis analysés plus loin.
Le chemin de code mène à la fonction 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]
Les seules choses vraiment importantes à noter sont que les tableaux de caractères de la fonction parente sont à nouveau passés directement à une nouvelle fonction en [1] (sessionCookie) et [2] (acceptStr). Cela mène à la fonction 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]
}
}
}
}
}
La boucle la plus externe parcourt nos octets d'entrée jusqu'à ce que le nom d'en-tête soit trouvé. Dans le cas de ce programme, elle cherche continuellement « Accept : » et « x-sessioncookie : » avec strncmp en [1]. Comme le commentaire le note, une autre boucle ignore tout espace blanc trouvé, puis commence à chercher les caractères de nouvelle ligne attendus '\r\n' en [2]. Après cela, le programme limite correctement la taille de la copie à resultMaxSize, qui est correctement définie à 0xc8 (200) sur les deux appels à cette fonction.
Après la copie, le break en [3] est atteint, qui ne sort en réalité que de la boucle en [4], ce qui fait que le code revient à la boucle strncmp initiale mentionnée ci-dessus. Ainsi, s'il y a une autre chaîne « Accept : » ou « x-sessioncookie » dans le tampon, la copie a lieu à nouveau, et si l'on examine la méthode de copie réelle en [5], on peut voir que notre pointeur initial (qui pointe vers une adresse dans la trame de pile de la fonction handleRequestBytes) continue d'augmenter, et bien que la longueur d'une copie donnée soit limitée à la taille du tampon, quand il n'y a pas de limite sur le nombre de copies pouvant se produire sur une adresse de destination toujours croissante, un débordement de tampon basé sur la pile peut facilement être déclenché.
Sortie de crash
==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 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
Découvert par Lilith ¯_(ツ)_/¯ de Cisco Talos.