r3dxpl0it/rtspserver-code-execution-vulnerabilityRTSPServer कोड निष्पादन भेद्यता CVE-2018-4013
CVE-2018-4013
LIVE555 RTSP सर्वर लाइब्रेरी के HTTP पैकेट-पार्सिंग कार्यक्षमता में एक शोषण योग्य कोड निष्पादन भेद्यता मौजूद है। एक विशेष रूप से तैयार किया गया पैकेट स्टैक-आधारित बफर ओवरफ्लो का कारण बन सकता है, जिसके परिणामस्वरूप कोड निष्पादन हो सकता है। एक हमलावर इस भेद्यता को ट्रिगर करने के लिए एक पैकेट भेज सकता है।
LIVE555 मीडिया लाइब्रेरीज़ RTSP/RTCP/RTSP/SIP के लिए एक हल्के मल्टीमीडिया स्ट्रीमिंग लाइब्रेरीज़ का सेट हैं, जिसमें सर्वर और क्लाइंट दोनों के लिए कोड समर्थन है। इनका उपयोग लोकप्रिय मीडिया प्लेयर जैसे VLC और MPlayer, साथ ही कई एम्बेडेड डिवाइसों (मुख्य रूप से कैमरे) द्वारा किया जाता है। यह भेद्यता सर्वर घटक में है जो इन मीडिया प्लेयरों के साथ इंटरैक्ट करता है, लेकिन मीडिया प्लेयरों को प्रभावित नहीं करता है।
LIVE555 द्वारा अपने मानक RTSP सर्वर के लिए सक्षम की गई एक कार्यक्षमता HTTP पर RTSP को टनल करने की क्षमता है, जो सर्वर द्वारा बाउंड किए गए एक अलग पोर्ट पर प्रदान की जाती है, आमतौर पर होस्ट मशीन पर उपलब्ध पोर्ट के आधार पर TCP 80, 8000, या 8080। यह पोर्ट सामान्य RTSP का समर्थन कर सकता है, लेकिन कुछ मामलों में, HTTP क्लाइंट RTSP-ओवर-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] में दिखाया गया है, "Accept" और "x-sessioncookie" HTTP हेडर यह तय करते हैं कि यह RTSP-ओवर-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 नहीं मिल जाता। इस प्रोग्राम के मामले में, यह लगातार [1] पर strncmp के साथ "Accept:" और "x-sessioncookie:" की तलाश करता है। जैसा कि टिप्पणी में बताया गया है, एक और लूप किसी भी व्हाइटस्पेस को छोड़ता है, और फिर [2] पर अपेक्षित न्यूलाइन वर्णों '\r\n' की तलाश शुरू करता है। इसके बाद, प्रोग्राम परिणाम की प्रतिलिपि के आकार को resultMaxSize तक सही ढंग से सीमित करता है, जो इस फ़ंक्शन में दोनों कॉल पर 0xc8 (200) पर सही ढंग से सेट है।
प्रतिलिपि के बाद, [3] पर break मारा जाता है, जो वास्तव में केवल [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
Cisco Talos की Lilith ¯_(ツ)_/¯ द्वारा खोजा गया।