riusksk's blog

 

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

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

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

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

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

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

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

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

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

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

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

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

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

以后请别对我说：“五一快乐“！！！

 

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

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

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

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

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

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

 

源码比对

       下面是对版本号1.8.3p1与1.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-3026是libpng库的png_decompress_chunk函数存在整数溢出漏洞，该库被许多应用程序所使用，包括Chrome、Firefox及其它部分使用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漏洞的原因。接下来我们直接通常IDA加xul.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;                  // 注意这里，count为int类型，默认为有符号整数，而result是无符号整数，当count为负数时，result会变得很大，比如0xFFFFFFFA。

  }

  else

  {

    ……省略部分代码……

    }

    result = 0;                 

  }

  return result;

}

 

下面是通过设置条件记录断点，记录了v7、v8、output_size、count及memcpy参数。

注意：这里记录的count是MOZ_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中的memcpy的size参数，就有可能导致复制很大一块内存过去，另外，它也可能导致整数上溢，造成内存分配过小，具体见下面分析。

      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_size与v6均为无符号整数，若 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函数，发现里面有多处循环调用到漏洞函数，这为触发漏洞创建了条件：