CVE-2013-3346Adobe Reader和Acrobat 内存损坏漏洞分析

   [CNNVD]Adobe Reader和Acrobat 内存损坏漏洞(CNNVD-201308-479)

Adobe Reader和Acrobat都是美国奥多比(Adobe)公司的产品。Adobe Reader是一款免费的PDF文件阅读器,Acrobat是一款PDF文件编辑和转换工具。
        Adobe
Reader和Acrobat中存在安全漏洞。攻击者可利用该漏洞执行任意代码或造成拒绝服务(内存损坏)。以下版本受到影响:Adobe
Reader和Acrobat 9.5.5之前的9.x版本,10.1.7之前的10.x版本,11.0.03之前的11.x版本。

测试环境是Adobe Reader11+Windows 7。挂载调试器打开poc后程序异常退出,但是并未中断在调试器中,在任务管理器中发现Adobe Reader存在2个进程,于是启用子进程调试,重新加载,并中断在调试器中,信息如下。

eax=00000001 ebx=00000001 ecx=64f7f4ea edx=04bb1078 esi=3ef2cc90 edi=00000000
eip=64f7e84b esp=0016e540 ebp=0016e564 iopl=0         nv up ei pl nz ac po cy
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00210213
*** ERROR: Symbol file could not be found.  Defaulted to export symbols for C:\Program Files\Adobe\Reader 11.0\Reader\AcroRd32.dll -
AcroRd32!DllCanUnloadNow+0x150524:
64f7e84b 8b06            mov     eax,dword ptr [esi]  ds:0023:3ef2cc90=????????

我们往前面看一下会发现esi来自ecx,而由于ecx就是this指针,这里怀疑是对象指针。再后面看一下又有call    dword ptr [eax+364h]。于是重新加载启用堆分配记录。如下

1:007> !heap -p -a esi
    address 3eaeac90 found in
    _DPH_HEAP_ROOT @ 4451000
    in free-ed allocation (  DPH_HEAP_BLOCK:         VirtAddr         VirtSize)
                                   3136171c:         3eaea000             2000
    778890b2 verifier!AVrfDebugPageHeapFree+0x000000c2
    77775674 ntdll!RtlDebugFreeHeap+0x0000002f
    77737aca ntdll!RtlpFreeHeap+0x0000005d
    77702d68 ntdll!RtlFreeHeap+0x00000142
    768af1ac kernel32!HeapFree+0x00000014
*** ERROR: Symbol file could not be found.  Defaulted to export symbols for C:\Windows\system32\MSVCR100.dll -
    6b41016a MSVCR100!free+0x0000001c
    627e1325 AcroRd32!CTJPEGLibInit+0x0000f6d5
    6290c2af AcroRd32!DllCanUnloadNow+0x0010df88
    628b3381 AcroRd32!DllCanUnloadNow+0x000b505a
    6294723b AcroRd32!DllCanUnloadNow+0x00148f14
    628980b1 AcroRd32!DllCanUnloadNow+0x00099d8a
    62e54bbf AcroRd32!CTJPEGRotateOptions::operator=+0x001b0aa3
    628980b1 AcroRd32!DllCanUnloadNow+0x00099d8a
    62cfabca AcroRd32!CTJPEGRotateOptions::operator=+0x00056aae
    62cfb275 AcroRd32!CTJPEGRotateOptions::operator=+0x00057159
    62cf93be AcroRd32!CTJPEGRotateOptions::operator=+0x000552a2
    62da391e AcroRd32!CTJPEGRotateOptions::operator=+0x000ff802
    62da3b7c AcroRd32!CTJPEGRotateOptions::operator=+0x000ffa60
    62da3eca AcroRd32!CTJPEGRotateOptions::operator=+0x000ffdae
*** WARNING: Unable to verify checksum for C:\Program Files\Adobe\Reader 11.0\Reader\plug_ins\Annots.api
*** ERROR: Symbol file could not be found.  Defaulted to export symbols for C:\Program Files\Adobe\Reader 11.0\Reader\plug_ins\Annots.api -
    64989a3a Annots!PlugInMain+0x00078015
    6498a692 Annots!PlugInMain+0x00078c6d
    6498af61 Annots!PlugInMain+0x0007953c
*** WARNING: Unable to verify checksum for C:\Program Files\Adobe\Reader 11.0\Reader\plug_ins\EScript.api
*** ERROR: Symbol file could not be found.  Defaulted to export symbols for C:\Program Files\Adobe\Reader 11.0\Reader\plug_ins\EScript.api -
    66e2a8e8 EScript!PlugInMain+0x000392b6
    66dfff65 EScript!PlugInMain+0x0000e933
    66e19749 EScript!PlugInMain+0x00028117
    66e157ec EScript!PlugInMain+0x000241ba
    66e378e6 EScript!PlugInMain+0x000462b4
    66e3786c EScript!PlugInMain+0x0004623a
    66e36951 EScript!PlugInMain+0x0004531f
    66e3626c EScript!PlugInMain+0x00044c3a
    66e342da EScript!PlugInMain+0x00042ca8
    64989e26 Annots!PlugInMain+0x00078401

很明显是已经释放的内存块,那我们来看下这个内存块是在哪里分配的。通过对分配函数下断向前摸到了这块内存的分配记录

1:011> !heap -p -a 04878de8
    address 04878de8 found in
    _DPH_HEAP_ROOT @ 45f1000
    in busy allocation (  DPH_HEAP_BLOCK:         UserAddr         UserSize -         VirtAddr         VirtSize)
                                 48f05e4:          4878de8              214 -          4878000             2000
    77888e89 verifier!AVrfDebugPageHeapAllocate+0x00000229
    77774ea6 ntdll!RtlDebugAllocateHeap+0x00000030
    77737d96 ntdll!RtlpAllocateHeap+0x000000c4
    777034ca ntdll!RtlAllocateHeap+0x0000023a
    6b7709ee MSVCR100!unlock+0x000000ba
    6b771e32 MSVCR100!calloc_crt+0x00000016
    6b771d93 MSVCR100!mbtowc_l+0x000001be
    6b771e16 MSVCR100!mbtowc_l+0x00000241
    7770af24 ntdll!LdrpCallInitRoutine+0x00000014
    7770b511 ntdll!LdrpInitializeThread+0x0000015b
    7770b298 ntdll!_LdrpInitialize+0x000001ad
    7770b2c5 ntdll!LdrInitializeThunk+0x00000010

最后再看一下重用时的操作

1:007> kp
ChildEBP RetAddr
WARNING: Stack unwind information not available. Following frames may be wrong.
001fe028 64f7e0d2 AcroRd32!DllCanUnloadNow+0x150524
001fe04c 64f7f3e3 AcroRd32!DllCanUnloadNow+0x14fdab
001fe054 64f7d996 AcroRd32!DllCanUnloadNow+0x1510bc
001fe0a0 64f7c68c AcroRd32!DllCanUnloadNow+0x14f66f
001fe0d0 64f7c50e AcroRd32!DllCanUnloadNow+0x14e365
001fe160 64f7c206 AcroRd32!DllCanUnloadNow+0x14e1e7
001fe170 64f7c1a1 AcroRd32!DllCanUnloadNow+0x14dedf
001fe17c 64ed712e AcroRd32!DllCanUnloadNow+0x14de7a
001fe1a8 64f7ae0e AcroRd32!DllCanUnloadNow+0xa8e07
001fe1d8 64f76d1d AcroRd32!DllCanUnloadNow+0x14cae7
001fe1fc 64f76bf1 AcroRd32!DllCanUnloadNow+0x1489f6
001fe214 64f7434c AcroRd32!DllCanUnloadNow+0x1488ca
001fe2ac 64e2e440 AcroRd32!DllCanUnloadNow+0x146025
001fe2d8 64f73a64 AcroRd32!DllCanUnloadNow+0x119
001fe300 653d38ef AcroRd32!DllCanUnloadNow+0x14573d
001fe37c 653d3b7c AcroRd32!CTJPEGRotateOptions::operator=+0xff7d3
001fe390 653d3eca AcroRd32!CTJPEGRotateOptions::operator=+0xffa60
*** WARNING: Unable to verify checksum for C:\Program Files\Adobe\Reader 11.0\Reader\plug_ins\Annots.api
*** ERROR: Symbol file could not be found.  Defaulted to export symbols for C:\Program Files\Adobe\Reader 11.0\Reader\plug_ins\Annots.api -
001fe39c 63009a3a AcroRd32!CTJPEGRotateOptions::operator=+0xffdae
001fe3b0 6300a692 Annots!PlugInMain+0x78015
001fe3c8 6300af61 Annots!PlugInMain+0x78c6d
时间: 2024-11-02 23:33:12

CVE-2013-3346Adobe Reader和Acrobat 内存损坏漏洞分析的相关文章

进程内存和内存损坏

本教程的这一部分的先决条件是对ARM汇编的基本了解(在第一个教程系列" ARM汇编基础 "中有介绍).在本章中,您将了解32位Linux环境中进程的内存布局.之后,您将学习堆栈和堆相关的内存损坏的基本原理,以及它们在调试器中的样子. 缓冲区溢出 堆栈溢出 堆溢出 摇摇欲坠的指针 格式字符串 本教程中使用的示例是在ARMv6 32位处理器上编译的.如果您无法访问ARM设备,则可以按照以下教程创建自己的实验室并在VM中模拟Raspberry Pi发行版:使用QEMU模拟Raspberry

内存损坏问题的演示样例及分析

原文以演示样例代码系统的讲述了三种内存损坏的情况: 全局内存.栈损坏及堆损坏, 以及它们产生的原因. 粗略整理例如以下. Global Memory Corruption 即全局变量的内存使用出了问题,主要还是越界. 例如以下代码: #include <stdio.h> #define MAX 6 int arrdata[MAX]; int endval; int main() { int i = 0; endval = 12; for (i = MAX; (endval) &&

内存损坏问题的示例及分析

原文以示例代码系统的讲述了三种内存损坏的情况: 全局内存.栈损坏及堆损坏, 以及它们产生的原因.粗略整理如下. Global Memory Corruption 即全局变量的内存使用出了问题,主要还是越界.如下代码: #include <stdio.h> #define MAX 6 int arrdata[MAX]; int endval; int main() { int i = 0; endval = 12; for (i = MAX; (endval) && (i >

内存故障与分析

内存故障与分析 一.开机无显示 由于内存条原因出现此类故障是比较普遍的现象,一般是因为内存条与主板内存插槽接触不良造成(在排除内存本身故障的前提下),只要用橡皮擦来回擦试其金手指部位即可解决问题(不要用酒精等清洗),还有就是内存损坏或主板内存槽有问题也会造成此类故障. 由于内存条原因造成开机无显示故障,主机扬声器一般都会长时间蜂鸣(针对Award Bios而言) 二.windows系统运行不稳定,经常产生非法错误 出现此类故障一般是由于内存芯片质量不良或软件原因引起,如若确定是内存条原因只有更换

Android内存泄露案例分析

一款优秀的Android应用,不仅要有完善的功能,也要有良好的体验,而性能是影响体验的一个重要因素.内存泄露是Android开发中常见的性能问题.这篇文章,通过我们曾经遇到的一个真实的案例,来讲述一个内存泄露问题,从发现到分析定位,再到最终解决的全过程. 这里把整个过程分为四个阶段: 第一阶段,现场勘查,分析Bug现象,找出有用线索: 第二阶段,初步推断,根据之前的线索,推断可能导致Bug的原因,并且进一步验证推断是否正确: 第三阶段,探究根源,找出导致Bug的真正原因: 第四阶段,解决方案,研

linux内存源码分析 - 内存压缩(同步关系)

本文为原创,转载请注明:http://www.cnblogs.com/tolimit/ 概述 最近在看内存回收,内存回收在进行同步的一些情况非常复杂,然后就想,不会内存压缩的页面迁移过程中的同步关系也那么复杂吧,带着好奇心就把页面迁移的源码都大致看了一遍,还好,不复杂,也容易理解,这里我们就说说在页面迁移过程中是如何进行同步的.不过首先可能没看过的朋友需要先看看linux内存源码分析 - 内存压缩(一),因为会涉及里面的一些知识. 其实一句话可以概括页面迁移时是如何进行同步的,就是:我要开始对这

list的内存分配机制分析

该程序演示了list在内存分配时候的问题.里面的备注信息是我的想法. /* 功能说明: list的内存分配机制分析. 代码说明: list所管理的内存地址可以是不连续的.程序在不断的push_back的过程中,程序仅会将操作的元素进行复制一份,保存到list中.通过复制构造函数和析构函数,可以看到这些操作. 实现方式: 限制条件或者存在的问题: 无 */ #include <iostream> #include <string> #include <list> #inc

java内存查看与分析

业界有很多强大的java profile的工具,比如Jporfiler,yourkit,这些收费的东西我就不想说了,想说的是,其实java自己就提供了很多内存监控的小工具,下面列举的工具只是一小部分,仔细研究下jdk的工具,还是蛮有意思的呢:) 1:gc日志输出 在jvm启动参数中加入 -XX:+PrintGC -XX:+PrintGCDetails -XX:+PrintGCTimestamps -XX:+PrintGCApplicationStopedTime,jvm将会按照这些参数顺序输出g

c/c++服务器程序内存泄露问题分析及解决

由 www.169it.com 搜集整理 对于一个c/c++程序员来说,内存泄漏是一个常见的也是令人头疼的问题.已经有许多技术被研究出来以应对这个问题,比如 Smart Pointer,Garbage Collection等.Smart Pointer技术比较成熟,STL中已经包含支持Smart Pointer的class,但是它的使用似乎并不广泛,而且它也不能解决所有的问题:Garbage Collection技术在Java中已经比较成熟,但是在c/c++领域的发展并不顺畅,虽然很早就有人思考