|
阅读：1917回复：12
关于WIN9x的c:\\con\\con漏洞问题
当WIN9x执行此行命令时会导致蓝屏，我用SoftIce跟踪了一下，发现在内核执行过程中到某一处调用时并没有进行堆栈的保护，导致调用返回时从堆栈中取得一错误的返回地址，从而产生蓝屏，但具体是什么原因会这样并不清楚，有哪位高人能指点一下，在下不胜感激！
|
|
|
沙发#
发布于：2002-05-11 19:57
你在NsFocus看到的吗？
哪里有注解！很清楚的！ 你自己看吧不贴了！ |
|
|
|
板凳#
发布于：2002-05-11 21:32
不是在绿盟看到的，是在微软的网站，不过我到绿盟去查过，并没有对该问题给出详细的解释，只是说是内核溢出导致该漏洞，我想彻底的弄清楚究竟是哪部分代码，什么原因导致的，看来路漫漫其修远兮，吾将上下而求索，在此对你的回帖表示感谢
|
|
|
地板#
发布于：2002-05-13 00:15
首先问一下：
1、\"发现在内核执行过程中到某一处调用时并没有进行堆栈的保护，导致调用返回时从堆栈中取得一错误的返回地址\"是怎么得出来的，你是在函数调用前后看其esp是否相同吗？ 2、你的出错处的函数是在ring0还是ring3。 |
|
|
|
地下室#
发布于：2002-05-13 20:22
当然是在内核级下，我是单步跟踪某一处调用时发现返回地址虽已压入堆栈，但从被调用的代码返回时其返回地址不是先头压入堆栈的，其值似乎不固定，从而蓝屏死机
|
|
|
5楼#
发布于：2002-05-15 11:30
你是使用ASM还是C，如果是ASM你可能需要自己保存堆栈，
如果是C，你需要注意不同调用规范之间的差别。 当然如果你使用其它非正规技术（如：修改Windows函数的代码），那么你可能需要考虑该函数是否使用了reigster传递参数等。 |
|
|
|
6楼#
发布于：2002-05-15 12:37
你是使用ASM还是C，如果是ASM你可能需要自己保存堆栈， 文不对题！ 另外，绿盟没有，袁哥的主页上有。 |
|
|
|
7楼#
发布于：2002-05-15 13:25
To yanghui：
你能否将被调用的函数和其调用代码贴出来看看是怎么回事 |
|
|
|
8楼#
发布于：2002-05-17 15:08
我跟踪的时候大概是二个多月以前，具体位置记不太清楚了，稍后我会整理一下并贴出来
|
|
|
9楼#
发布于：2002-05-20 00:08
对不起，时间隔久了，记错了，实际上不是堆栈的原因，函数的调用也没错，据我大概的跟踪分析，与该漏洞的解释相符，是windows内核对特殊设备名的解析错误，以下是我跟踪的代码片段：
0167:7fcb810e push dword ptr [ebp+08] //保存的缓冲地址入栈，该地址指向c:\\con\\con 0167:7fcb8111 call [kernel32!getfileattributesa] 跟踪进7fcb8111的call,来到 0167:bff77bb0 push edi ..... 0167:bff7547e call bff712b9 跟踪进bff7547e的call,来到 0167:bff712b9 push ecx ..... 0167:bff712c0 call kernel32!ord_0001 跟踪进bff712c0的call,来到 0167:bff713d4 mov eax,[esp+04] ..... 0167:bff713db call far cs:[bffca834] 跟踪进bff713db的call,来到 003b:03ac int 30 继续跟进，来到 0028:c0001d94 sub esp,04 ..... 0028:c02836e4 call [Exec_PM_Int] 跟踪进c02836e4的call,来到 0028:c0272348 push ebx ..... 0028:c027236a call [Exec_Int] 跟踪进c027236a的call,来到 0028:c0003a30 call [Simulate_Int] ..... 0028:c011e7e8 call [eax+ebx+0c] 跟踪进c011e7e8的call,来到 0028:c011db39 cmp ebx,[c0122510] ..... 0028:c011dd39 call [ecx*4+c0122a24] 跟踪进c011dd39的call,来到 0028:c0291a08 push ebp ..... 0028:c0291a12 call c0291660 跟踪进c0291a12的call,来到 0028:c0291660 push ebp ..... 0028:c0291981 call c011ed30 跟踪进c0291981的call,来到 0028:c011ed30 push ebp ..... 0028:c011ee8c call [ebp+08] 跟踪进c011ee8c的call,来到 0028:c0130dd4 push ebx ..... 0028:c0130e7b call c0138044 跟踪进c0130e7b的call,来到 0028:c0138044 sub esp,10 ..... 0028:c01381af call c01381f0 跟踪进c01381af的call,来到 0028:c01381f0 mov [ebp+3e],eax ..... 0028:c01383d3 call c012f852 跟踪进c01383d3的call,来到 0028:c012f852 mov eax,[ebp+4c] ..... 0028:c012f8d8 call c012eaf4 跟踪进c012f8d8的call,来到 0028:c012eaf4 mov edi,[ebp+1c] ..... 0028:c012eb17 call c01302b7 跟踪进c012eb17的call,来到 0028:c01302b7 push esi ..... 0028:c01302be call c0139333 跟踪进c01302be的call,来到 0028:c0139333 push ecx ..... 0028:c013933f call c01392b1 跟踪进c013933f的call,来到 0028:c01392b1 push edx 0028;c01392b2 sub eax,eax 0028:c01392b4 mov esi,[edi+14] ~~~~~~~~~~~~~~~~ 0028:c01392b7 bt dword ptr [ebp+38],oc 0028:c01392bc sbb edx,edx 0028:c01392be and edx,02000000 0028:c01392c4 test byte ptr [ebp+39],05 0028:c01392c8 jnz c0139313 0028:c01392ca mov ah,02 0028:c01392cc mov esi,[edi+14] 0028:c01392cf movzx ebx,word ptr [esi+0a] //到此处，就会导致页面错，即出现蓝屏，因edi的值为零，从而esi指向的内存地址是无效的，而正常情况下edi的值不为零，有一定的含义，具体是什么含义我还在分析，但我估计与该命令行路径有关，因为在即将蓝屏前会调用Ifs_ParsePath函数，初步分析对edi的值有影响，但windows的内核太庞大了，一大堆的call摆在你面前，这还不算完，还会你中有我，我中有你，只能发扬愚公移山的精神了，稍后我会贴出新的分析，望能与大家共同探讨研究！ |
|
|
10楼#
发布于：2002-05-20 10:48
勘误，Ifs_ParsePath实为IFSMgr_FSDParsePath,该服务用于路径的解析，以下是MSDN中的说明：
IFSMgr_FSDParsePath( pioreq pir ) This service calls the IFS manager\'s parse routine. It provides a way for an FSD to parse a given path if it is called via private APIs. There is never a reason to do this on calls routed through the IFS manager. |
|
|
11楼#
发布于：2002-05-20 22:00
我想是其它地方将内存破坏了，你跟踪一下正常的getfileattributesa函数调用，是按上面的调用吗？
|
|
|
|
12楼#
发布于：2002-05-22 14:51
不错，正常情况下也是按我跟踪的代码执行，不同的是edi的值具有一定的意义，不为0，具体我还要分析IFSMgr_FSDParsePath函数，因为调用它后edi的值就会变化
|
|