Live Networks LIVE555 流媒体 RTSPServer lookForHeader 代码执行漏洞

CVE-2018-4013

概述

LIVE555 RTSP 服务器库的 HTTP 数据包解析功能中存在一个可被利用的代码执行漏洞。特制数据包可导致基于栈的缓冲区溢出，从而实现代码执行。攻击者可发送数据包触发此漏洞。

详细信息

LIVE555 媒体库是一套轻量级多媒体流库，支持 RTSP/RTCP/RTSP/SIP，提供服务器和客户端的代码支持。被 VLC、MPlayer 等流行媒体播放器以及众多嵌入式设备（主要是摄像头）所使用。此漏洞存在于与这些媒体播放器交互的服务器组件中，但不影响媒体播放器本身。

LIVE555 标准 RTSP 服务器启用的功能之一是能够通过 HTTP 隧道传输 RTSP，该功能由服务器绑定的不同端口提供服务，通常为 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] 所示，“Accept” 和 “x-sessioncookie” HTTP 头部决定是否为 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。在此程序的情况下，它通过 strncmp 在 [1] 处持续查找 “Accept:” 和 “x-sessioncookie:”。如注释所述，另一个循环跳过任何空白字符，然后开始查找预期的换行符 '\r\n' [2]。之后，程序正确地将拷贝大小限制为 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 ¯_(ツ)_/¯ 发现。

RTSPServer-Code-Execution-Vulnerability

最受欢迎