datntsec/cve-2020-0796CVE-2020-0796 (SMBGhost) の技術的分析と概念実証、SMBv3 圧縮における整数オーバーフローの脆弱性で、Windows 10/Server でローカル特権昇格を引き起こす。
Windows 10/Server version 1903 から SMBv3 に追加された圧縮機能には、Microsoft が 2020 年 3 月 12 日に確認した整数オーバーフローの脆弱性が含まれています。これにより、攻撃者は Local Privilege Escalation (LPE) および Remote Code Execution (RCE) を実行できます。ここでは LPE の脆弱性についてのみ説明します。
影響を受けるバージョン:
srv2.sys ファイルを分析すると、Decompress に関連する関数が以下のように呼び出されていることがわかります。``` js
Srv2ReceiveHandler
|
|
v
Srv2DecompressMessageAsync
|
|
v
Srv2DecompressData -------> SrvNetAllocateBuffer
|
|
v
SmbCompressionDecompress
|
|
v
memcpy
まず、`Srv2ReceiveHandler`関数が呼び出され、SMBデータパケットを受信し、プロトコルID `ProtocolId`に対応する関数を呼び出します。`ProtocolId` = 0x424D53FCの場合、`Srv2DecompressMessageAsync`関数を呼び出し、その関数が`Srv2DecompressData`を呼び出してデータパケットを解凍します。`Srv2DecompressData`関数は`SrvNetAllocateBuffer`を呼び出して、解凍後のデータを格納するための`Alloc`を割り当て、次に`SmbCompressionDecompress`を呼び出してデータパケットを解凍し、最後に`memcpy`を呼び出します。このように、解凍プロセス全体は以下の主要なステップで構成されます。
- 1. 割り当て
- 2. 解凍
- 3. コピー
Microsoftが提供するドキュメントによると、`COMPRESSION_TRANSFORM_HEADER`構造体は、クライアントとサーバー間で圧縮データを送受信するために使用されます。その構造は以下の通りです。``` c
typedef struct _COMPRESSION_TRANSFORM_HEADER
{
ULONG ProtocolId;
ULONG OriginalCompressedSegmentSize;
USHORT CompressionAlgorithm;
USHORT Flags;
ULONG Offset;
} ;
ここでは、上記の2つの主要フィールドに焦点を当てます：
OriginalCompressedSegmentSize は、非圧縮データセグメントのサイズ（バイト単位）です。Offset は、圧縮データの開始点と _COMPRESSION_TRANSFORM_HEADER 構造体の終了点との間のバイト単位のオフセットです。したがって、圧縮されたデータパケットは次のような形式になります：
``` c
typedef struct _ALLOCATION_HEADER
{
// ...
PVOID UserBuffer;
// ...
} ALLOCATION_HEADER, *PALLOCATION_HEADER;
NTSTATUS Srv2DecompressData(PCOMPRESSION_TRANSFORM_HEADER Header, SIZE_T TotalSize) { PALLOCATION_HEADER Alloc = SrvNetAllocateBuffer( (ULONG)(Header->OriginalCompressedSegmentSize + Header->Offset), NULL); If (!Alloc) { return STATUS_INSUFFICIENT_RESOURCES; }
ULONG FinalCompressedSize = 0;
NTSTATUS Status = SmbCompressionDecompress(
Header->CompressionAlgorithm,
(PUCHAR)Header + sizeof(COMPRESSION_TRANSFORM_HEADER) + Header->Offset,
(ULONG)(TotalSize - sizeof(COMPRESSION_TRANSFORM_HEADER) - Header->Offset),
(PUCHAR)Alloc->UserBuffer + Header->Offset,
Header->OriginalCompressedSegmentSize,
&FinalCompressedSize);
if (Status < 0 || FinalCompressedSize != Header->OriginalCompressedSegmentSize) {
SrvNetFreeBuffer(Alloc);
return STATUS_BAD_DATA;
}
if (Header->Offset > 0) {
memcpy(
Alloc->UserBuffer,
(PUCHAR)Header + sizeof(COMPRESSION_TRANSFORM_HEADER),
Header->Offset);
}
Srv2ReplaceReceiveBuffer(some_session_handle, Alloc);
return STATUS_SUCCESS;
}
`Srv2DecompressData`関数の分析では、この関数が圧縮されたパケットデータ `COMPRESSION_TRANSFORM_HEADER`（ヘッダー）を受け取り、`SrvNetAllocateBuffer`関数を使用して `Header->OriginalCompressedSegmentSize` + `Header->Offset` の合計をパラメータとしてメモリ領域（Alloc）を割り当て、その後圧縮データを展開し、非圧縮データを `Alloc->Buffer` にコピーすることがわかります。
整数オーバーフローのバグは、`Srv2DecompressData` が `SrvNetAllocateBuffer` を呼び出すときに発生します。`SrvNetAllocateBuffer` 関数は実際には2つの64ビット値を受け取りますが、`Srv2DecompressData` が `SrvNetAllocateBuffer` を呼び出す際には、2つの32ビット値（ULONG）のみを渡します。一方、`OriginalCompressedSegmentSize` と `Offset` はどちらも ULONG であり、これらを加算すると32ビットを超える値が得られる可能性があります。そのため、整数オーバーフローが発生します（簡単に言えば、`0xffffffff`（`OriginalCompressedSegmentSize`）と `0x10`（`Offset`）を加算すると `0xf0000000f` という値が得られますが、`SrvNetAllocateBuffer` 関数は `0x0000000f` の値のみを受け取ります）。
整数オーバーフローにより、Alloc メモリ領域の割り当てが誤って行われ（割り当てられるべきサイズが実際のサイズよりも小さくなる）、バッファオーバーフローが発生する可能性があります：
バッファオーバーフローが発生するかどうか、またどのように発生するかを確認するには、`SrvNetAllocateBuffer` 関数と `SmbCompressionDecompress` 関数を分析します。``` c
PALLOCATION_HEADER SrvNetAllocateBuffer(SIZE_T AllocSize, PALLOCATION_HEADER SourceBuffer)
{
v2 = *MK_FP(__GS__, 420i64);
v3 = 0;
v4 = a2;
v5 = 0;
if ( SrvDisableNetBufferLookAsideList || allocSize > 0x100100 )
{
if ( allocSize > 0x1000100 )
return 0i64;
v11 = SrvNetAllocateBufferFromPool(allocSize, allocSize);
}
else
{
if ( allocSize > 0x1100 )
{
_RCX = allocSize - 256;
__asm
{
bsr rdx, rcx
bsf rax, rcx
}
if ( (_DWORD)_RDX == (_DWORD)_RAX )
v3 = _RDX - 12;
else
v3 = _RDX - 11;
}
v6 = SrvNetBufferLookasides[(unsigned __int64)v3];
v7 = *(_DWORD *)v6 - 1;
if ( (unsigned int)(unsigned __int16)v2 + 1 < *(_DWORD *)v6 )
v7 = (unsigned __int16)v2 + 1;
v8 = (unsigned int)v7;
v9 = *(_QWORD *)(v6 + 32);
v10 = *(_QWORD *)(v9 + 8 * v8);
if ( !*(_BYTE *)(v10 + 0x70) )
PplpLazyInitializeLookasideList(v6, *(_QWORD *)(v9 + 8 * v8));
++*(_DWORD *)(v10 + 20);
v11 = (unsigned __int64)ExpInterlockedPopEntrySList((PSLIST_HEADER)v10);
if ( !v11 )
{
++*(_DWORD *)(v10 + 24);
v12 = *(_DWORD *)(v10 + 44);
v13 = *(_DWORD *)(v10 + 40);
v14 = *(_DWORD *)(v10 + 36);
LODWORD(v15) = sub_1C00110B0(*(int (**)(void))(v10 + 48));
v11 = v15;
}
v5 = 2;
}
if ( v11 )
{
*(_WORD *)(v11 + 0x10) |= v5;
*(_WORD *)(v11 + 0x12) = v3;
*(_WORD *)(v11 + 0x14) = v2;
if ( v4 )
{
v24 = *(_DWORD *)(v4 + 0x24);
if ( v24 >= *(_DWORD *)(v11 + 0x20) )
v24 = *(_DWORD *)(v11 + 0x20);
v25 = *(void **)(v11 + 0x18);
*(_DWORD *)(v11 + 0x24) = v24;
memcpy(v25, *(const void **)(v4 + 0x18), v24);
v26 = *(_WORD *)(v4 + 0x16);
if ( v26 )
{
*(_WORD *)(v11 + 0x16) = v26;
memcpy((void *)(v11 + 0x64), (const void *)(v4 + 0x64), 0x10i64 * *(_WORD *)(v4 + 0x16));
}
}
else
{
*(_DWORD *)(v11 + 36) = 0;
}
}
return v11;
}
上記のコードはIDA Proの疑似コードから取られたもので、かなりわかりにくいです。しかし、Zecopsによって書き直されたコードを見ることで簡単に理解できます：``` c PALLOCATION_HEADER SrvNetAllocateBuffer(SIZE_T AllocSize, PALLOCATION_HEADER SourceBuffer) { // ...
if (SrvDisableNetBufferLookAsideList || AllocSize > 0x100100) {
if (AllocSize > 0x1000100) {
return NULL;
}
Result = SrvNetAllocateBufferFromPool(AllocSize, AllocSize);
} else {
int LookasideListIndex = 0;
if (AllocSize > 0x1100) {
LookasideListIndex = /* some calculation based on AllocSize */;
}
SOME_STRUCT list = SrvNetBufferLookasides[LookasideListIndex];
Result = /* fetch result from list */;
}
// Initialize some Result fields...
return Result;
}
関数`SrvNetAllocateBuffer`は、割り当てるサイズを受け取り、そのサイズが0x100100より大きいかどうかをチェックし、大きい場合はNULLを返します。この関数はさらに、変数`SrvDisableNetBufferLookAsideList`をチェックしますが、この変数に関する文書は見つからず、デフォルトで0に設定されているため、おそらく重要ではないでしょう。