一． tiff檔案格式介紹
1、 影象檔案頭（image file header
簡稱ifh）：
ifh資料結構包含
3個成員共計
8個位元組，
byte order
成員可能是
「mm」(0x4d4d)
或「ii」(0x4949)
，0x4d4d
表示該tiff
圖是motoral整數格式 0x4949
表示該圖是
intel
整數格式；
version
成員總是包含十進位制
42(0x2a)
；第三個成員是
ifd相對檔案開始處的偏移量。
2、影象檔案目錄（image file directory
簡稱ifd
）：ifd是
tif圖中最重要的資料結構，它包含了乙個
tif檔案中最重要的資訊，乙個
tif圖可能有多個
ifd，這說明檔案中有多個影象，每個
ifd標識
1個影象的基本屬性。
ifd結構中包含了三類成員，
directory entry count
指出該結構裡面有多少個目錄入口；接下來就是
n個線性排列的
de序列，數量不定（這就是 為什麼稱
tif格式檔案為可擴充標記的檔案，甚至使用者可以新增自定義的標記屬性），每個
de標識了影象的某乙個屬性；最後就是乙個偏移量， 標識下乙個檔案目錄相對於檔案開始處的位置，當然，如果該
tif檔案只包含了一幅影象，那麼就只有乙個
ifd，顯然，這個偏移量就等於0；
3、目錄入口（
directory entry
簡稱de
）：共12
個位元組。簡單說，乙個de
就是一幅影象的某乙個屬性。例如影象的大小、解析度、是否壓縮、畫素的行列數等。其中：
tag成員是該屬性的編號，在影象檔案目錄中，它是按照公升序排列的。屬性是用資料來表示的，那麼
type
就是代表著該資料的型別，
tif官方指定的有
5種資料型別。
type=1
就是byte
型別（8
位無標記整數）、
type=2
是ascii
型別（7
位ascii碼加1
位二進位制0）、
type=3
是short
型別（16
位無標記整數）、
type=4
是long
型別（32
位無標記整數）、
type=5
是rational
型別（2
個long
，第乙個是分子，第二個是分母）。
length
成員是資料的數量而不是資料型別的長度。第
4個成員
valueoffset
很重要，它是
tag標識的屬性代表的變數值相對檔案開始處的偏移量。如果變數值占用的空間小於
4個位元組，那麼該值就存放在
valueoffset
中即可，沒必要再另外指向乙個地方了。
二．分析漏洞產生的原因：
分析樣本發現，此漏洞與cve-2006-3459
類似，都是由於
dotrange
屬性引起的。
dotrange一般為兩個值，即
dotrange[0]
和dotrange[1]
。dotrange
標籤是乙個目錄項結構，
12位元組的資料定義了該標籤的
tag、資料型別，資料長度以及值偏移。通常情況下，
dotrange
的目錄項結構是這個樣子的：
tag type count value/offset
0x0150 0x0003/0x0001 0x00000002 0xaaaaaaaa
dotrange 的
tag值為
0x0150
，資料型別或為
short
型，或為
byte
型，資料長度如前所述，不能超過
2，而資料偏移則指出了
dotrange[0]
和 dotrange[1]
在檔案中的位置。然而，如果我們此時惡意的將
dotrange
目錄項中的
count
字段設定為任意大於
2的值，那會出現什麼情況呢？事實證明，這就是
dotrange
漏洞利用最原始的想法，
libtiff
根據count
的值，讀入
dotrange
資料。如果攻擊者精心構造了
count
值，並在檔案的特殊位置提供了惡意**的話，那讀入的多餘資料將覆蓋
libtiff
的棧結構，引起緩衝區溢位，最終導致
shellcode
的執行。
tiffreaddirectory()函式在switch-case
中，在遇到
tifftag_pagenumber
、 tifftag_halftonehints
、tifftag_ycbcrsubsampling
和tifftag_dotrange
標籤時進入
tifffetchshortpair()
的處理流程。
tifffetchshortpair ()
函式，這裡沒有判斷
count
的大小，從而產生了此漏洞。
安裝補丁之後，tifffetchshortpair ()
增加了判讀，當
count
小於等於就跳過報錯**繼續正常執行，當
count大於2
時就報錯
(unexpect count ……)：
tifffetchshortpair()其呼叫的是
tifffetchshortarray()
。正常情況，
count≤2
，流程呼叫的是函式中
(dir->tdir_count <= 2)
的分支；而惡意時，
count>2
，執行流程又轉入了
tifffetchdata()。
tifffetchshortarray()函式呼叫
tifffetchdata ()處:
在tifffetchdata()
函式中，
tif->tif_size
為檔案大小，
dir->tdir_offset
為dotrange
資料的起始位置，
cc是資料真實長度，那
dir->tdir_offset + cc
也就是dotrange
資料的結束位置，如果資料的結束位置超過了開啟
tiff
檔案的大小，那也將會輸出錯誤資訊。這一點在構造惡意
tiff
時非常重要，
dotrange
標籤中的
count
值並不是大於
2的任意數值都可以，要保證惡意資料的結束位置≤
tiff
檔案尺寸，否則就算更改了數值，也可能因位置驗證錯誤而覆蓋失敗。tifffetchdata()函式呼叫了
memcpy()處：
緩衝區溢位的發生處是 「_tiffmemcpy(cp, tif->tif_base + dir->tdir_offset, cc);
」。_tiffmemcpy
包裝了乙個
memcpy
，將從tif->tif_base + dir->tdir_offset
，即dotrange
資料起始處開始的
cc位元組的資料拷貝到
cp指定的記憶體。
cc是惡意構造的、驗證後的
count
值，而cp
指向的正是
tifffetchshortpair()
中的棧變數
uint16 v[4]
的基位址。
從上面的分析可知，惡意資料覆蓋的是tifffetchshortpair()
的棧幀結構。只要覆蓋了
tifffetchshortpair()
的返回位址，讓其跳轉到我們的
shellcode
執行就可以想做你想做的任何事了。
CVE 2014 6332除錯分析
這個漏洞是乙個ie瀏覽器裡，vbs方面的漏洞，yuange首先放出了這個漏洞的完整dve的利用，接下來各個安全團隊都出了比較好的分析報告。這個漏洞本身的原理算是比較傳統，但是利用技術非常巧妙。置位safemode後，shellcode相當於用指令碼語言直接編寫，通用性穩定性極強。閒暇之餘，也忍不住除...
CVE2014 6287分析報告
cssembly 2014 09 29 11 30 在烏雲zone裡看到了 hfs 2.3x 遠端命令執行 抓雞黑客末日 的文章，以前只是分析二進位制漏洞，這種命令注入漏洞還是第一次分析，從網上下了hfs 2.3.279這個版本，執行起來之後，執行poc，四個calc就執行起來了。複製 ps 分析到...
IE漏洞除錯之CVE 2013 3893
前言 windows平台的漏洞挖掘和安全研究中，ie始終是繞不開的話題。ie漏洞就跟adobe系列一樣經典，是學習exploit shellcode的絕佳途徑。在ie漏洞中，uaf即use after free是最為經典的一類。uaf可以這樣簡單理解 a先後呼叫b c d三個子函式，b會把a的某個資...