WinPcap驱动畸形参数漏洞解析[网络技术]

文/图 gyzy[江苏大学信息安全系&EST]===================================
Winpcap（Windows Packet Capture）是Windows平台下一个免费、大众的网络拜候系统,它为Win32利用程序供应了拜候网络底层的本领.Winpcap不能阻塞、过滤或掌握其他利用程序数据报的收发,它仅仅只是监听同享网络上传送的数据报.它供应了以下的各项功效,这些功效均有助于以太网数据流监督软件功效的实现.
1）捕捉原始数据报,包含在同享网络上各主机发送/接纳的以及彼此之间交换的数据报;
2）在数据报发往利用程序之前,按照自定义的法则将某些特别的数据报过滤掉;
3）在网络上发送原始的数据报;
4）汇集网络通信历程中的统计信息.
Winpcap有一个致命的弱点,就是答应非管理员组的用户利用它的驱动程序,假定管理员利用过Ethereal等利用WinPcap的抓包工具,并且驱动程序没有被手动卸载,那么便大概被恶意操纵,比方非受权的嗅探,乃至蓝屏当机.
黑防在从前的几期杂志中已经介绍过通过驱动举行本地提权的相关概念,这里就不再赘述了.WinPcap的驱动npf.sys在处理0x2347号IOCTL时没有对参数举行合理性考证,招致可以肆意改正内存,但是由于覆盖的内容老是为0,所以传送一个高2GB中不可写地址的话,就可以招致蓝屏当机.

Ring0与Ring3的通信
在DOS操作系统中,利用程序可以直接与硬件打交道,包含I/O端口读写、中止恳求与呼应以及DMA操作等.这种对硬件过于直接的操作方法给软件计划供应了一定的便利,但也有它自身的一些缺陷.首先,一些不法操作有大概改写某些硬件存放器的内容,招致操作系统崩溃,从而使操作系统变得不安全,性能不安定;其次,利用程序的可移植性变差.为了保证操作系统的安全性和安定性以及利用程序的可移植性,Windows操作系统不答应利用程序直接拜候系统的硬件资源,而是必须借助于呼应的设备驱动程序.设备驱动程序可以直接操作硬件,假如利用程序和设备驱动程序之间实现了双向通信,也就到达了利用程序掌握底层硬件设备的目的.它们之间的通信包含两个方面:一方面是利用程序传送给设备驱动程序的数据;另一方面是设备驱动程序发送给利用程序的消息.前者的实现较简单,通过CreateFile()函数获得设备驱动程序的句柄后,便可以利用Win32函数,如DeviceIoControl()、ReadFile()或WriteFile()等实现利用程序与设备驱动程序之间的通信.

漏洞解析
milw0rm上公布了PoC代码,不过看的人对比费解,在VC中报了10个错误,都是语法上的小问题,还有错误的地方,在获得ntkrnlpa.exe加载基址的函数中:

if (!strcmp(lpBaseName,"ntoskrnl.exe"))
{
NtosBase = lpImageBases[i];
printf("NTOSKRNL Base found at %#p\n",NtosBase);
break;
}
此中的对比函数竟然用了Win2k的ntoskrnl.exe,而在注释中阐明是该Poc是针对XP的,也不知道作者是疏漏还是成心的.改正了这个小Bug之后,代码在我的Windows XP下顺利运行了,不过立即蓝屏了,如图1所示.
 
图1
为了准肯定位出错的代码,在运行POC之前有几件事情要先完成.在"我的电脑->属性->启动和弊端恢复"中的"写入调试信息"挑选"完好内存转储",这样Windows会保存Crash Dump,以便于用Windbg调试出错的位置,设置好Windbg的Symbol Path,重启后利用Windbg的Open Crash Dump加载C:\Windows下的MEMORY.DMP.等到呈现如图2所示的内容后,输入"!analyze –v"就可以看到驱动出错的具体信息了.

 
DEFAULT_BUCKET_ID:  INTEL_CPU_MICROCODE_ZERO

BUGCHECK_STR:  0xBE
PROCESS_NAME:  winpcap.exe
TRAP_FRAME:  f9001ba4 -- (.trap fffffffff9001ba4)
ErrCode = 00000003
eax=8057e7ff ebx=80e6a000 ecx=00000000 edx=00000010 esi=ffb495b0 edi=ffb49540
eip=faf0bfdd esp=f9001c18 ebp=f9001c34 iopl=0  nv up ei pl zr na pe nc
cs=0008  ss=0010  ds=0023  es=0023  fs=0030  gs=0000  efl=00010246
npf+0xfdd:
faf0bfdd 89480c  mov dword ptr [eax+0Ch],ecx ds:0023:8057e80b=84a38055
Resetting default scope

LAST_CONTROL_TRANSFER:  from 8051cf07 to 804f9925

STACK_TEXT:  
f9001b2c 8051cf07 000000be 8057e80b 0057e121 nt!KeBugCheckEx+0x1b
f9001b8c 805406ec 00000001 8057e80b 00000000 nt!MmAccessFault+0x8e7
f9001b8c faf0bfdd 00000001 8057e80b 00000000 nt!KiTrap0E+0xcc
WARNING: Stack unwind information not available. Following frames may be wrong.
f9001c34 804eedf9 ffb457c0 ffb49540 806d12d0 npf+0xfdd
f9001c44 80574b42 ffb495b0 ffba12e0 ffb49540 nt!IopfCallDriver+0x31
f9001c58 805759d1 ffb457c0 ffb49540 ffba12e0 nt!IopSynchronousServiceTail+0x60
f9001d00 8056e33c 0000002c 00000000 00000000 nt!IopXxxControlFile+0x5e7
f9001d34 8053d808 0000002c 00000000 00000000 nt!NtDeviceIoControlFile+0x2a
f9001d34 7c92eb94 0000002c 00000000 00000000 nt!KiFastCallEntry+0xf8
0012fe48 7c92d8ef 7c801671 0000002c 00000000 ntdll!KiFastSystemCallRet
0012fe4c 7c801671 0000002c 00000000 00000000 ntdll!ZwDeviceIoControlFile+0xc
0012feac 004015aa 0000002c 00002347 00000000 kernel32!DeviceIoControl+0xdd
0012ff48 7c9306eb 00404515 00370000 00000009 winpcap+0x15aa
00130160 00000000 00000002 00000024 00000034 ntdll!RtlAllocateHeap+0xeac

STACK_COMMAND:  kb
FOLLOWUP_IP:
npf+fdd
faf0bfdd 89480c  mov  dword ptr [eax+0Ch],ecx

SYMBOL_STACK_INDEX:  3
SYMBOL_NAME: npf+fdd
FOLLOWUP_NAME: MachineOwner
MODULE_NAME: npf
IMAGE_NAME: npf.sys
DEBUG_FLR_IMAGE_TIMESTAMP: 42efe135
FAILURE_BUCKET_ID:  0xBE_npf+fdd
BUCKET_ID:  0xBE_npf+fdd
Followup: MachineOwner
一目了然,0xfaf0bfdd处的指令"mov dword ptr [eax+0Ch],ecx"试图写入只读内存招致了蓝屏.接下来就是在IDA中静态解析.

.text:00010FCC  push  10h
.text:00010FCE  pop  edx
.text:00010FCF  cmp  [esi+4], edx
.text:00010FD2  jb  loc_110C4
.text:00010FD8  mov  eax, [edi+3Ch]
//[edi+3Ch]为UserBuffer的内容
.text:00010FDB  xor  ecx, ecx
.text:00010FDD  mov  [eax+0Ch], ecx
.text:00010FE0  mov  eax, [edi+3Ch]
.text:00010FE3  mov  [eax], ecx
.text:00010FE5  mov  eax, [edi+3Ch]
.text:00010FE8  mov  [eax+4], ecx
.text:00010FEB  mov  eax, [edi+3Ch]
.text:00010FEE  mov  [eax+8], ecx

0x00010FDD、0x00010FE3、0x00010FE8和0x00010FEE四条语句招致内存的16字节被覆盖,由于前面的"xor ecx,ecx",所以招致ecx不可掌握,不然还可以以Ring0权限履行肆意代码.但是在原作者给出的POC中仿佛是可以履行代码的,我利用的Winpcap是3.1版本的,是ethereal-setup-0.10.14中自带的,运行一次ethereal今后驱动就被加载进内核了.不知道是版本差别的问题,还是别的问题.因为明显上面的代码中ecx是不可掌握的.
假定ecx可控,那么可以通过覆盖SSDT中的函数地址,然后在Ring3下调用呼应的函数来履行ShellCode.Ring0下的ShellCode又和Ring3下的ShellCode有很大的差别,在内核态下不像用户态下有现成的API可以操纵,所以这也算一个研究的对比少的方向,在下期文章中,我将结合可操纵漏洞具体讲授一下若何操纵这些驱动程序履行对比实用的ShellCode.

小结
通过这次漏洞解析,我们知道了若何调试蓝屏的转储文件,并解析了漏洞产生的缘由,理解了用户态下的程序和内核态的驱动是若何举行通信的,在这里权当举一反三,但愿能给广大黑防读者带来一点帮忙,若有错误忽略,欢送指正.