利用HEVD学习windows kernel exploit 正式篇1.5 StackOverflowGS
Window Kernel Exploit 01.5 - StackOverflowGS
这一篇和上一篇的技巧几乎一致,所以就咕咕咕不写EXP了(主要还是因为懒),不过可以介绍一下和内核相关的SEH
利用技巧:
SEH with user mode
记得之前曾经写过一篇和SEH相关的文章:WindowsSEH
当时虽然写了一大串的利用方法,但是没写到关键上。形如如下的代码:
|
|
实际上是不会打印Now we get exception....
这句话的。因为当Cookie被修改的时候,代码会陷入上文提到的int 29中断,这个中断会让程序直接终止,而不是去调用异常处理链。(可以这么理解:检查cookie这个过程实际上是发生在函数调用结束的时候,此时代码并没有被try...except
包含,也就不会触发异常链。)如果想要实现劫持SEH链的目的,那么需要做到的其实是
在try…except包含的代码块中间直接抛出错误
在这类代码中可以通过写入大量数据做到:
|
|
刚刚不是说了不能通过修改cookie触发SEH吗?
对的,这里并不是修改cookie,而实直接写爆栈:
user-mode 下,正确的触发SEH的姿势就是在gets的过程中,访问了不可访问的地址,从而抛出access deny的错误
此时,就能够通过修改SEH handler
的方法来劫持程序流
SEH with kernel mode
然而在内核模式下,如果存在一个栈溢出的漏洞,却不能像用户空间那样玩。因为在内核中,如果访问了内核空间中不可访问的地址,那么会直接触发BSoD,并不会进入异常处理的逻辑中。那么这个时候要如何触发SEH呢?
对于这类特定的状况下,有一种处理方法:
|
|
如上,我们会发现,有漏洞的函数TriggerStackOverflowGS 所拷贝的UserBuffer
实际上是来自于IrpSp->Parameters.DeviceIoControl.Type3InputBuffer
。这个Type3InputBuffer
实际上 是一个从用户态传来的指针。这个是由IRP
控制的缓冲区,所以说不会触发SAMP
。那么此时相当于说指针本身也是由我们控制的。
可以人为的创造出用户空间的访问异常,从而抛出异常。
此时可以利用CreateFileMapping
和MapViewOfFile
。这两个API会向进程申请一段地址空间(保留一个地址空间的区域用来存放内存映射文件),并且将这段文件映射到地址空间上。这个过程其实和系统调用VirualAlloc
类似,唯一不同的就是这个分配的过程我们是全程可控。那么在获取了映射的地址之后,我们可以修改本来指向分配在用户地址空间开头的指针,让其指向映射地址的结尾。这样在内核在调用RtlCopyMemory
的时候,就能控制其访问到不可访问的地址,触发SEH
|
|
触发SEH之后,就和普通的Buffer Overflow
一样操作即可。