[若渴計畫]CVE 2014-9322, CVE-2015-0235, CVE-2009-3547

Post on 19-Jul-2015

188 views 0 download

Transcript of [若渴計畫]CVE 2014-9322, CVE-2015-0235, CVE-2009-3547

CVE-2014-9322, CVE-2015-0235, CVE-2009-3547

AJ (張仁傑)

<ajblane0612@gmail.com>

2015.2.28

CVE(Common Vulnerabilities and Exposures)

• Vulnerabilities• An information security “vulnerability” is a mistake in software that can be

directly used by a hacker to gain access to a system or network (from CVE Terminology)

• Exposure• An information security "exposure" is a system configuration issue or a

mistake in software that allows access to information or capabilities that can be used by a hacker as a stepping-stone into a system or network (from CVE Terminology)

•其實不太知道為什麼要分Vulnerabilities/ Exposure,這兩字眼解釋

看到Vulnerabilities, Exposure我只會想到

已存在的軟體/系統(因為大家都可能用啊XD)

trigger

男人都想(Vulnerabilities, Exposure)

1

23

你們會想到?

接下來只介紹Vulnerabilities (一個idea,就像你知道buffer overflow是漏洞,但你不知道怎觸發)

• CVE-2014-9322• CVE-2015-0235• CVE-2009-3547• CVE-XXXX-XXXX=>可以慢慢研究XD

CVE-2014-9322: bad_iretSS exception• "The next two bugs are related to espfix. The IRET instruction has IMO

a blatant design flaw: IRET to a 16-bit user stack segment will leak bits 31:16 of the kernel stack pointer. This flaw exists on 32-bit and 64-bit systems. 32-bit Linux kernels have mitigated this leak for a long time, and 64-bit Linux kernels have mitigated this leak since 3.16. The mitigation is called espfix.“ from http://www.phoronix.com/scan.php?page=news_item&px=MTg2NzY

ss

kernel stackuser stack

0x0001_00000x0000_10000x0001_0000

IRETss

0x0001_1000

bad_iret(不正確返回)

CVE-2014-9322: bad_iret

•對象: Linux 64bit 3.11.10-301 on Intel X86

• The vulnerability

• 透過計算espfix製造bad_iret,先push espfix,在iret時,會發生#SS exception

• GS是X86的segment register,被linux拿來指向儲存CPU資料的結構,而SWAPGS如下描述

kernel’gs User’gs

current gs temp

kernel’gsUser’gs

SWAPGS

GS指向的資料結構

假設準備假的GS指向的資料結構會發生?fake’gs kernel’gs

SWAPGS

kernel’gs fake’gs

fake’gs kernel’gs

SWAPGS

kernel’gs fake’gs

SWAPGS

fake’gs kernel’gs

SWAPGS

kernel’gs fake’gs

SWAPGS

current gs temp

靠背! GP exception在執行fake’gs

• 為什麼會有兩個SWAPGS?只是contex switch時,store gs和restore gs而已

CVE-2015-0235:GHOST(glibc gethostbyname buffer overflow)

• 對象: gethostbyname*()• 要知道The vulnerability要了解gethostbyname_r

• 藉由name可拿到host的資訊(如: official name of host)• int gethostbyname_r( const char *name, //輸入hostname or IPv4 or IPv6

struct hostent *ret, //= =+不太了解char *buf,

//此buf存在目的只是根據name的大小,來配置足夠大的temp給內部處理

size_t buflen, struct hostent **result, // host的資訊int *h_errnop //錯誤訊息);

• 所以正確使用gethostbyname_r,使要先配置足夠大的buffer在執行gethostbyname_r,可參閱(How to use gethostbyname_r (correct example)

CVE-2015-0235: Buffer Overflow Vulnerability

len= 991

(gdb) p name

$19 = '0' <repeats 991 times

>, "\000\377\262\360\000\000

000\000\000\320\006@", '\000

' <repeats 13 times>"\360, \

004@\000\000\000\000"

(gdb)p temp

$16 = {

buffer = '\000' <repeats 16 t

imes>, "\020", '\000' <repeat

s 21 times>, '0' <repeats 984

times>, canary = "0000000\000

oal_mine"}

因為在name很大時, buffer會overflow,所以複寫到canary屬性(條件成立可以參閱: Qualys Security Advisory CVE-2015-0235 )

CVE-2009-3547•對象: 2.6.29 release of the Linux kernel的 fs/pipe.c

靠!有啥問題@@?

• The vulnerability• Process A : open pipe

• Process B : release pipe

• 執行順序 A|B(意思是A,B都在mutex_lock)->B->A

• 結果A process會執行(NULL)->writers++mutex_lock(&inode->i_mutex);inode->i_pipe->writers--;mutex_unlock(&inode->i_mutex);

A

B

mean: 控制(NULL)->writers位置的值+1

為了 ,給自己一個目標

模擬 the Carbanak APT攻擊

討論紀錄與補充

bad_iret的問題討論

•由Intel® 64 and IA-32 Architectures Software Developer’s Manual知道iret是使用16-bit operand size,並不代表是在16 mode下做運作,而是指stack可使用的範圍

• Large memory management vulnerabilitiesp.16頁中 linux 2.6 kernel stack被安裝在 3G的地方

•由於linux的stack位置設計,所以會有此投影片p.5的狀況

如何Trigger CVE-2014-9322 Vulnerabilities?

• Exploiting “BadIRET” vulnerability (CVE-2014-9322, Linux kernel privilege escalation)的 Triggering the vulnerability小節

(NULL)->writers++為啥可執行?

•因為(NULL)->writers++是在kernel mode執行,在user mode會跳exception