•  

    读书只是一种习惯,一种修行,没什么搞笑不搞笑的,高手不解释!          

                                                                                                        —— 泉哥

    修身篇

    1、《史蒂夫·乔布斯传》(已阅过半,越看越没意思,过年的时候扔回家了

    2、《秘密》

    3、《力量》

    4、《异类》

     

    学习篇

     

    1、内核漏洞利用技术文章集合(已阅过半,停止)

    2、《windows核心编程》

    3、《软件调试》

    4、《黑客防线VC编程专辑》

    5、《Python灰帽子——黑客与逆向工程师的Python编程之道》(已阅

     

  • 2012-05-13

    写字 - [随笔杂谈]

    Tag:

    下午一时兴起,直接写了半根水笔,因为写行草或者草书用得都比较快。

    现在电脑普及了,写字的机会就比以往更少,搞IT的朋友就更少了,大多时间还是花在敲键盘上了。

    在心烦意乱或者无聊寂寞之时,写写字感觉挺好的。

    特别是写行草或者草书,很利于发泄情绪,进入状态后,很容易忘记身边的一切,包括烦恼。

    感觉写草书的难点在于字体之间的流畅性和准确性,因为字写快了就很易出错,或有停顿等笔画涩滞的痕迹,较难把握。

    写草书确实可以锻炼思维和动作的灵敏性,有事没事都可以拿笔乱涂一翻。

    因此,练字练的不仅仅是字,练的是更是一种寂寞、一种心境。

  • 2012-05-03

    黑色的五一 - [随笔杂谈]

    Tag:

    饭桌上众兄弟谈笑言欢,怎想却成了绝别。

    白天还电话寒喧,晚上人就没了。

    事情转变实在是太快了,一点心理准备都没有,实在是没法接受。

    每次都觉得只是梦幻,但总是一次又一次地被现实狠狠地拍醒!

    生命说短不短,说长不长,也就几十年的事,但活着就得承担着一定的责任,逃避现实也不是办法,况且生命并不属于你自己的,更多的还是属于你的亲人、朋友。

    死者已矣,活着的人还得继续地生活下去……

    以后请别对我说:“五一快乐“!!!

     

  • 2012-04-26

    部门LOL亚军 - [随笔杂谈]

    Tag:

    之前部门LOL(英雄联盟)比赛我们组获得了亚军,奖了一个鼠标垫和LOL T恤,可惜T恤太小了,穿不了,可惜了啊……

  • 2012-04-15

    phrack #68 出来了! - [随笔杂谈]

    Tag:

    http://www.phrack.org/issues.html?issue=68

  • 2012-04-15

    五一回家 - [随笔杂谈]

    Tag:

    近来博客少更新了,上来扯蛋下,以证明哥还活着:


  • 2012-03-24

    推荐几本书 - [随笔杂谈]

    Tag:

  • xxd -u -g 1 -l 1024 -c 16 test.txt

    -u  显示大字字母

    -g 显示每组的字节数,默认为2,即xxxx xxxx这样的形式,改为1后为xx xx xx xx这样的形式

    -l 显示的字节长度

    -c 每行显示的字节数,16字节看起来比较习惯

    最后要打开的文件名即可,前面可加相对路径:

     

  •  

    作者:泉哥

    主页:http://riusksk.blogbus.com

     

    漏洞描述

             CVE-2012-0809Sudo 1.8.0 ~ 1.8.3p1版本之间的sudo_debug函数存在格式化字符串漏洞,当把程序名作为格式化字符串的一部分传递给fprintf() 函数时就会触发该漏洞。而程序名可通过ln命令来创建符号连接或者其它一些方式来被利用。例如:

      /tmp $ ln -s /usr/bin/sudo %n
      /tmp $ ./%n -D9

    借助通用的格式化字符串漏洞利用技术可能执行任意代码,进而获得Root权限。

     

    源码比对

           下面是对版本号1.8.3p11.8.3p2的源码比较,在漏洞函数sudo_debug中,getprogname用于获取程序名,相当于argv[0],将其保存在fmt2中,然后将它作为格式化字符串的一部分通过vfprintf函数传递给stderr,导致格式化字符串漏洞的发生。修复后的版本,则不再使用fmt2参数来传递格式化字符,而是直接将"%s: %s\n"作为参数,这样格式化字符参数就不可控制的,从而修复格式化字符串漏洞。

    关于该漏洞的利用,老外已经有分析过,具体见《Exploiting Sudofromat string vunerability》:http://www.vnsecurity.net/2012/02/exploiting-sudo-format-string-vunerability/

     

     

  • 作者:riusksk(泉哥)

    主页:http://riusksk.blogbus.com

     

    漏洞描述

        CVE-2011-3026libpng库的png_decompress_chunk函数存在整数溢出漏洞,该库被许多应用程序所使用,包括ChromeFirefox及其它部分使用WebKit内核的浏览器,因此漏洞影响涉及的范围也是比较广泛的,后面的分析我主要是基于Firefox来分析的,因为它是开源的,并且有提供符号表,对于定位漏洞更为方便。

     

    漏洞分析

    Windbg附加Firefox,并运行,然后用它打开Poc.png文件:

     

    0:000> g

    (12a0.7e4): Access violation - code c0000005 (first chance)

    First chance exceptions are reported before any exception handling.

    This exception may be expected and handled.

    eax=00000041 ebx=00008000 ecx=3ffe47ff edx=00000000 esi=061ffffe edi=00498400

    eip=6206768e esp=0026efc0 ebp=0026efc8 iopl=0         nv up ei pl nz na pe nc

    cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00210206

    MOZCRT19!LeadUpVec+0x52:

    6206768e f3a5            rep movs dword ptr es:[edi],dword ptr [esi]

     

    0:000> kb

    ChildEBP RetAddr  Args to Child             

    0026efc8 51b47130 0042a402 06192000 fffffffa MOZCRT19!LeadUpVec+0x52 [F:\SP\vctools\crt_bld\SELF_X86\crt\src\intel\memcpy.asm @ 271]

    0026f02c 51b47246 09200102 003fb2b2 0042a402 xul!png_inflate+0x8a [e:\builds\moz2_slave\rel-192-w32-bld\build\modules\libimg\png\pngrutil.c @ 243]

    0026f0a4 51b4849d 059f1200 00000000 003fb3b4 xul!MOZ_PNG_decomp_chunk+0xa7 [e:\builds\moz2_slave\rel-192-w32-bld\build\modules\libimg\png\pngrutil.c @ 353]

     

    根据漏洞公告我们可以知道漏洞主要出现在 png_decompress_chunk 函数中,其实这里就相当于Firefox中的xul!MOZ_PNG_decomp_chunk,调试前记得先加载Firefox符号表,这也是我为什么选用Firefox来调试libpng漏洞的原因。接下来我们直接通常IDAxul.dll,然后加载xul.pdb,就可以直接找到MOZ_PNG_decomp_chunk函数。不过这里我们先来看下png_inflate函数:

     

    unsigned int __usercall png_inflate(png_struct_def *png_ptr, const char *data, unsigned int size, char *output, unsigned int output_size)

    {

      png_struct_def *v5; // esi@1

      z_stream_s *v6; // edi@1

      int v7; // eax@2

      int v8; // ebx@2

      size_t v9; // eax@7

      unsigned int result; // eax@13

      const char *v11; // eax@17

      int count; // [sp+10h] [bp-40h]@1 count默认为有符号整数

      int ret; // [sp+14h] [bp-3Ch]@2

      char umsg[52]; // [sp+18h] [bp-38h]@20

      unsigned int v15; // [sp+4Ch] [bp-4h]@1

      int v16; // [sp+50h] [bp+0h]@1

     

      v15 = (unsigned int)&v16 ^ __security_cookie;

      count = 0;

      v5 = png_ptr;

      v6 = &png_ptr->zstream;

      png_ptr->zstream.next_in = (char *)data;

      png_ptr->zstream.avail_in = size;

      do

      {

        v5->zstream.next_out = v5->zbuf;

        v5->zstream.avail_out = v5->zbuf_size;

        v7 = MOZ_Z_inflate(v6, 0);

        v8 = v5->zbuf_size - v5->zstream.avail_out;

        ret = v7;

        if ( (!v7 || v7 == 1) && v8 > 0 )

        {

          if ( output && output_size > count )

          {

            v9 = output_size - count;   // 样本测试时的值为 0xFFFFFFFA - 0

            if ( v8 < (signed int)(output_size - count) )      

              v9 = v5->zbuf_size - v5->zstream.avail_out;   // 未执行到这里

            memcpy(&output[count], v5->zbuf, v9);          // 把负数当作size参数时即可触发溢出!!!

          }

          count += v8;

        }

      }

      while ( !ret );

      v5->zstream.avail_in = 0;

      MOZ_Z_inflateReset(v6);

      if ( ret == 1 )

      {

        result = count;                  // 注意这里,countint类型,默认为有符号整数,而result是无符号整数,当count为负数时,result会变得很大,比如0xFFFFFFFA

      }

      else

      {

        ……省略部分代码……

        }

        result = 0;                 

      }

      return result;

    }

     

    下面是通过设置条件记录断点,记录了v7v8output_sizecountmemcpy参数。

    注意:这里记录的countMOZ_PNG_decomp_chunk函数里面的第二个png_inflate里的count值:

    跟进MOZ_PNG_decomp_chunk函数作进一步分析:

    void __cdecl MOZ_PNG_decomp_chunk(png_struct_def *png_ptr, int comp_type, unsigned int chunklength, unsigned int prefix_size, unsigned int *newlength)

    {

      unsigned int v5; // edi@1

      unsigned int v6; // eax@4

      unsigned int v7; // ebx@4

      unsigned int v8; // eax@4

      void *v9; // eax@6

      unsigned int v10; // eax@7

      void *v11; // eax@11

      unsigned int v12; // [sp+14h] [bp-40h]@4

      char *v13; // [sp+14h] [bp-40h]@11

      char *text; // [sp+18h] [bp-3Ch]@6

      char umsg[50]; // [sp+1Ch] [bp-38h]@10

      unsigned int v16; // [sp+50h] [bp-4h]@1

      int v17; // [sp+54h] [bp+0h]@1

     

      v16 = (unsigned int)&v17 ^ __security_cookie;

      v5 = prefix_size;

      if ( prefix_size <= chunklength )

      {

        if ( comp_type )

        {

          __snprintf(umsg, 0x32u, "Unknown zTXt compression type %d", comp_type);

        }

        else

        {

          v6 = png_inflate(png_ptr, &png_ptr->chunkdata[prefix_size], chunklength - prefix_size, 0, 0); 

          v7 = v6;                  // 通过对png_inflate的分析,我们知道这里v6可能为一个很大的数据,而v6-count(count作为计数器,从0开始)最终会作为png_inflate中的memcpysize参数,就有可能导致复制很大一块内存过去,另外,它也可能导致整数上溢,造成内存分配过小,具体见下面分析。

          v8 = prefix_size + v6;

          v12 = v8;

          if ( v8 < 0x3D08FF )

          {

            if ( v7 )

            {

              v9 = MOZ_PNG_malloc_warn(png_ptr, v8 + 1);      // 分配缓冲区text,大小为 prefix_size + v6 + 1,这里prefix_sizev6均为无符号整数,若 prrfix_size + v6 + 1 > 0xFFFFFFFF时就会造成整数上溢,得到的值反而更小。

     

              text = (char *)v9;

              if ( v9 )

              {

                memcpy(v9, png_ptr->chunkdata, prefix_size);

                v10 = png_inflate(                               // 该函数触发崩溃,跟进

                        png_ptr,

                        &png_ptr->chunkdata[prefix_size],

                        chunklength - prefix_size,

                        &text[prefix_size],

                        v7);                             

          ……省略部分代码……

    }

     

    下面是设置条件记录断点时的日志输出情况,分别对v6作了记录:


    漏洞修复

        目前官方发布的 libpng 1.5.9版本已修复该漏洞,大家可以另外下载1.5.8的漏洞版本进行源码比对,看看官方是如何修复此漏洞的。下面的expanded_size就相当于v6,修复版本添加一些参数检测,防止整数上溢,进而也避免了后面memcpy复制内存时size参数过大:

     

     

  • CVE-2012-0150是Windows C运行库msvcrt.dll上存在的一个堆溢出漏洞,微软已在2月份发布补丁。如果直接借助bindiff进行补丁比较,还是很容易定位漏洞函数,通常漏洞函数都是在相似度为0.7 ~ 0.9的地方,而且大多有G标志,也就是说图表结构存在变化:


    基本上可以断定是在前4个函数,如果你打开看的话还会发现,它们的指令内容都差不多,这就更好定位漏洞,而且里面还有memcpy这个敏感函数。下面是对比的情况,我直接通过F5来比较,显得更直观一些:


    左右两边的差别在于SizeTMult函数的第1个参数,漏洞函数多乘以2,而乘2后的值指向是memcpy中的size参数,虽然size改变了,但calloc分配的内存块并没有跟着扩大,导致分配了X大小的堆块,却可memcpy大小为2X的数据到堆块(由于漏洞函数会被循环调用,为触发漏洞创建了条件),造成堆溢出!!!

    ‍函数调用流程图:

     其实它就是在格式化浮点字符串时造成的溢出,比如1.000...000这样的超长字符串,然后在重分配缓冲区时错误地计算了缓冲区大小。我们往上追溯到winput_s函数,发现里面有多处循环调用到漏洞函数,这为触发漏洞创建了条件: