建设营销型网站流程,wordpress相册幻灯片,企业门户网站登录,专业房产网站建设公司CVE-2016-0143漏洞分析 0x00 背景 4月20日#xff0c;Nils Sommer在exploitdb上爆出了一枚新的Windows内核漏洞PoC。该漏洞影响所有版本的Windows操作系统#xff0c;攻击者利用成功后可获得权限提升#xff0c;微软在4月补丁日修复了该漏洞。 0x01 漏洞分析 Nils Sommer并没…CVE-2016-0143漏洞分析 0x00 背景 4月20日Nils Sommer在exploitdb上爆出了一枚新的Windows内核漏洞PoC。该漏洞影响所有版本的Windows操作系统攻击者利用成功后可获得权限提升微软在4月补丁日修复了该漏洞。 0x01 漏洞分析 Nils Sommer并没有说明该漏洞为何种类型的漏洞咋看崩溃场景会认为是NULL Pointer dereference或者UAF漏洞粗略分析后觉得是整数溢出漏洞但是最后还是将其定义为特殊的NULL Pointer dereference漏洞。下面对漏洞成因进行简单分析。 In xxxRealDrawMenuItem 崩溃的地方是在win32k!xxxRealDrawMenuItem函数内在windbg中查看崩溃时的内存状态 崩溃上下文代码的IDA截图将其命名为过程A最后说明时会用到: 在crash之前eax会和[ebparg_8]做有符号乘法并将结果和ebx做比较来确定是否执行crash的指令。 此时的eax为PoC中r.bottom和r.top运算后的结果具体操作在win32k!xxxDrawMenuBarTemp内算法为eax r.bottom-r.top-1; [ebparg_8]为PoC中的info.bmiHeader.biSize; PoC 给的值会让imul eax,[ebparg_8]产生溢出走向crash流程。这里看起来是由于整数溢出造成的漏洞其实正常流程都会走这个流程的这并不是漏洞成因所在。 所操作的ecx从[ebpvar_28]获取原始值为1[ebpvar_28]本应该为DIBObject的地址但是在为其分配内存的函数win32k!SURFMEM::bCreateDIB中并没有为其分配内存空间漏洞的关键在这里。 下面分析创建DIBObject失败的原因。 In SURFMEM::bCreateDIB SURFMEM::bCreateDIB的函数调用栈 xxxDrawMenuBarTemp à GreCreateDIBitmapReal àSURFMEM::bCreateDIB 在SURFMEM::bCreateDIB函数内有这样一段代码将其命名为过程B: 此时eax等于xxxRealDrawMenuItem函数中的edi[ebparg_0]为PoC中的info.bmiHeader.biSize*4按照PoC中设定的值两者分别为0x7fffff69和0x274。 当两者进行乘法运算后同样发生了溢出但由于是无符号运算所以edx!0。调用函数ULongLongAdd后[ebpAllocationSize4]edx139h!0因此便走向了失败的流程不会为DIBObject分配内存也导致GreCreateDIBitmapReal函数的返回值为0。 如果未发生溢出并且两者的乘积(0x154)小于7FFFFFFFh, SURFMEM::bCreateDIB函数就会根据这个乘积(0x154)为DIBObject分配一块内存。分配内存的代码在IDA中的截图 分配成功后会将AllocateObject的返回值作为GreCreateDIBitmapReal函数返回值并且赋值给xxxRealDrawMenuItem 函数中的[ebpvar_28]。 0x02 补丁对比 来看看微软是怎么来补这个漏洞的补丁后的部分xxxRealDrawMenuItem函数代码在IDA中的截图 可以看到补丁后xxxRealDrawMenuItem函数在调用GreCreateDIBitmapReal函数后对返回值做了检查:如果返回值等于0表示创建DIBObject失败则不会再进入到操作DIBObject的流程也就是过程A中了。 0x03 可能的利用 目前还没有人公开自己的利用代码下面对该漏洞存在的可能利用方式做一个说明。 crash处是一个对ecx进行循环操作的代码段循环次数为imul eax,[ebparg_8]的乘积。正常情况下是对申请的DIBObject进行操作。 这个循环操作中存在一个可控的写入操作指令在IDA中的截图 红框中的指令就是所说的写入操作指令edx虽然经历多条指令操作后才得到但是参与操作的都是ecx相关内存值因为ecx也就是零页地址的内容可控所以edx也是可控的。 那么理论情况下在win8之前的系统中是可以将这条指令操作转变为 mov [HalDispatchTable4],shellcodeAddress 之后用户层再触发一下就完成了提权。 0x04 其他 经过深入分析后要触发漏洞r.bottom、r.top和info.bmiHeader.biWidth满足一定的约束就行了不一定需要和作者给出PoC的数值完全相同。r.bottom、r.top和info.bmiHeader.biWidth的值能满足下面两个条件就可以导致crash 过程B分配DIBObject失败。 过程A走向crash流程。 过程B和过程A要满足这两个条件具体情况如下。 过程B1. 过程B未发生溢出并且乘积后的值 0x7FFFFFFF造成AllocateObject调用失败。 2. 过程B未发生溢出并且乘积后的值 0x7FFFFFFF不走调用AllocateObject的流程。 3. 过程B发生溢出不走调用AllocateObject的流程。 过程A 1.未溢出。 2.溢出后的结果为负数并且改变sf位为1有符号数比较。 根据上面分析给出的过程A和过程B会导致crash的情况这里给出两种具体的组合有兴趣的可以修改原PoC中对应的值尝试一下都会crash的。 组合1 过程B情况1过程A的情况1两个地方都没有溢出但是还是crash了也说明了不是整数溢出漏洞。 组合2 过程B情况3过程A情况2: by会飞的猫转载请注明:http://www.cnblogs.com/flycat-2016转载于:https://www.cnblogs.com/flycat-2016/p/5449769.html
