●概述：
由Live Networks, Inc以C++開發的LIVE555 Streaming Media，係公開原始碼，跨平台支援多種影音格式，包含MPEG、H.265、H.264、H.263+、VP8、DV、AAC、AMR、AC-3、Vorbis，經Cisco Talo分析原始碼，證實確有堆疊緩衝區溢位問題，其CVSS V3評分10.0，乃罕見嚴重破綻，關鍵程式為RTSP server元件內lookForHeader()函數，其HTTP封包解析功能未顧慮異常條件，駭客特製封包，若包含鉅量“Accept”或“x-sessioncookie”字串，持續複製資料，可無窮盡增加指標指向位址，觸發buffer overflow，甚能衍生惡意執行代碼事件，對於安裝RTSP server之主機形成威脅，因其技術廣泛運用於播放器和IP camera，且source code極易取得，攻擊門檻低，幾乎是掌握IP即能循port 80、8000、8080入侵，目前已釋出改良版，線上影音業者及監控產品原廠，宜關注設備修補作業。另VLC澄清其軟體僅使用LIVE555 RTSP client，無涉RTSP server，使用者可安心。
●編註：
(1)何謂LIVE555 Streaming Media
LIVE555 Streaming Media的函式庫採輕量設計，支援多種公開標協定RTP(Real time Transport Protocol)、RTCP(Real Time Control Protocol)、RTSP(Real Time Streaming Protocol)、SIP(Session Initiation Protocol)，相關技術廣泛運用於VLC、MPlayer等播放器，亦成為多種內嵌Streaming Media播放器的選擇，尤其是IP camera。
其RTSP應用程式分別為server、client、proxy server版本，通常server經過port 80、8000、8080建立通道。
(2)程式漏洞說明
本次提及瑕疵落於RTSP server元件，RTSP server元件雖與使用者撥放器溝通，但不影響用戶，主要風險仍在server端，既然函式庫屬自由軟體，故直接從原始碼分析，RTSP server接收用戶傳來的http request，首先檢查表頭是否出現2個關鍵字“Accept”或“x-sessioncookie”，作為開啟通道的依據，驗證成功後，request資料填入acceptStr或 sessionCookie二個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); 
lookForHeader("Accept", &reqStr[i], reqStrSize-i, acceptStr, acceptStrMaxSize); 

可觀察到acceptStr與 sessionCookie參數又被送到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 && ource[i+headerNameLen] == ':') { // [1]
for (i += headerNameLen+1; i < (int)sourceLen && (source[i] == ' ' || source[i] == '\t'); ++i) {} 
for (unsigned j = i; j < sourceLen; ++j) {
if (source[j] == '\r' || source[j] == '\n') { // [2]
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]
} } } } }
最外層for迴圈反覆使用strncmp()於接收資料中找headerName變數值是否吻合“Accept”或“x-sessioncookie”字串，中層for迴圈找到半形空白就略過，裡層for迴圈檢查換行符號’\r及’\n’，而if (j-i+1 > resultMaxSize) break;是限制資料不得超過200字元，否則就不能copy至resultStr變數，最底下break讓程式回到最外層for迴圈，繼續找“Accept”或“x-sessioncookie”，再來一次複製動作，儘管程式有顧慮每次複製資料的上限(200 byte)，但未記錄copy發生次數，自然無法限制，此際handleRequestBytes( )函數的指標隨著copy行為增長，後果就是觸發堆疊緩衝區溢位。