CVE 2015-7547 glibc getaddrinfo() DNS Vulnerability

Posted by jstester007 on March 7th, 2016

Hello w0rld! JUMPSEC researchers have spent some time on the glibc DNS vulnerability indexed as CVE 2015-7547 (It hasn’t got a cool name like GHOST unfortunately…). It appears to be a highly critical vulnerability and covers a large number of systems. It allows remote code execution by a stack-based overflow in the client side DNS resolver. In this post we would like to present our analysis.

Google POC overview

1sts

Google POC Network Exploitation Timeline

draw-io_glibc (1)

Google POC Exploit Code Analysis

First response

 

test

Code snippet

 

alter1

Packet capture snippet

The dw() function calls a “struct” module from python library. According to the documentation, it performs conversion between python values and C structs represented as python strings. In this case, it interprets python integer and pack it into little-endian short type binary data. This is a valid response sent by the “malicious” DNS server when it receives any initial queries. This response packet is constructed intentionally in large size (with 2500 bytes of null), it forces the client to retry over TCP and allocate additional memory buffer for the next response. This also triggers the dual DNS query from getaddrinfo() on the client side, which is a single request containing A and AAAA queries concatnated.

 

Second Response
alter3

Code snippet

 

alter4

Packet capture snippet

This is the second response sent by the malicious DNS server. It is a malformed packet sending large numbers of “fake records” (184 Answer RRs) back to the client. According to google, this forces __libc_res_nsend to retry the query.

Third response
alter5

Code snippet

 

alter5b

Packet capture snippet

 

This is the third response sent by the “malicious” DNS server. It is another malformed packet which is carrying the payload. JUMPSEC researcher has modified the Google POC code to identify the the number of bytes to cause a segmentation fault (possibly overwriting the RET address) of the buffer. It is found that the RET address is being overwritten on the 2079th byte. With the addition of return_to_libc technique, an attacker can bypass OS protection such as NX bit or ASLR and perform remote code execution.

 

Google POC debugging and crash analysis

JUMPSEC has run it through the trusty gdb. It crashes with a SEGMENTATION FAULT which verifies that the DNS response has smashed the stack of the vulnerable client application when running getaddrinfo(). The vulnerable buffer is operated in gaih_getanswer. The entry address has been overwritten with 0x4443424144434241 (ABCDABCD). The state of the register also showing the overflowed bytes.

alter6

SEGFAULT from vulnerable client. RET address is overwritten with “ABCDABCD”

alter7

Backtrack

cropped

Registers

JUMPSEC has also tested it on a few other applications. It was found that the getaddrinfo() function in glibc is commonly used…

alter9

alter10

Iceweasel crashing

Conclusion

The best way to mitigate this issue is to enforce proper patching management. Make sure to update all your systems with the latest version of glibc . If you have any systems exposed on the internet and you want to make sure that this vulnerability is not triggered then the following Wireshark filter could be useful: (DNS.length>2048 to see malformed packets). A DNS response has a maximum of 512 bytes (typically), note that the DNS reply is truncated. Even if the client does not accept large response, smaller responses can be combine into a large one which can also trigger the vulnerability. A possible filter is to monitor the size of the entire conversation as a distinct amount of bytes in total is require to trigger specific responses from vulnerable client and all of them requires more than 2048 bytes.

The above vulnerability can be fixed by patching. If you are running RedHat or CentOS a simple

yum -y update glibc

will update the libc and resolve the issue (remember to restart the service right after the update!).

Reference links

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-7547

http://pubs.opengroup.org/onlinepubs/9699919799/functions/freeaddrinfo.html

https://googleonlinesecurity.blogspot.co.uk/2016/02/cve-2015-7547-glibc-getaddrinfo-stack.html

https://sourceware.org/ml/libc-alpha/2016-02/msg00416.html

 

Microsoft Onenote Image Caching Bug (Confidential Information Leakage)

Posted by Observer on March 1st, 2015

Bug Summary

A security bug in the Microsoft Onenote allows images placed in user created password protected sections to be cached persistently in the user profile temporary directory folder:

C:\Users\%username%\AppData\Local\Temp. 

Analysing the content the temporary folder will reveal images that should be securely protected by Onenote.

 

Bug Scope

This has only been tested with Microsoft Onenote 2013 with all known updates installed. Last testing on 01/03/2015.

 

Find the Bug Guide

1) Open Onenote and add a section to any existing notebook this will automatically create a page too.

Create Section in Onenote

Create Section in Onenote

 

2) Navigate to the REVIEW tab in the main menu and click password button (see image above), the pane on the right will appear and allow you to set a new section password (see image below). You should set one now.

Set a section password

Set a section password

 

3) Exit Onenote, then reopen it and enter password to unlock section. Now we are secure right!

 

4) Open your explorer, and navigate to the following location:   C:\Users\%username%\AppData\Local\Temp

Leave this window open, your images will appear here shortly!

Navigate to Temporary Directory

Navigate to Temporary Directory

 

5) Open your web browser/explorer, find some images and copy and paste them into OneNote.

Copy and Paste Image into Onenote

Copy and Paste Image into Onenote

On some occasions Onenote will cache the image immediately in the temp folder, you can delete these since they will be back shortly.

 

6) Now close and reopen Onenote, you should enter the password to unlock section. During this stage Onenote caches the images in this password protected section in the temporary directory. Go take a look.

Microsoft Onenote Caches Image

Microsoft Onenote Caches Image

 

Conclusion

Everything saved here is suppose to be in a password protected section, but image are saved persistently in the temp directory and could potentially leak confidential information.

 

Scenario

The are a number of problems that arise from this security bug, a few example could be a scanned image of a handwritten form reveals confidential information or a screenshot of usernames/passwords/finances saved in Onenote.