自拍偷在线精品自拍偷,亚洲欧美中文日韩v在线观看不卡

深入考察解釋型語言背后隱藏的攻擊面,Part 1(上)

安全 應(yīng)用安全
在本文中,我們將與讀者一起深入考察解釋型語言背后隱藏的攻擊面。

在本文中,我們將與讀者一起深入考察解釋型語言背后隱藏的攻擊面。

[[356901]]

簡(jiǎn)介

攻擊面就像一層蛋糕。我們通常將軟件攻擊面定義為任何對(duì)攻擊者控制的輸入做出反應(yīng)或受其影響的東西。在開發(fā)高級(jí)解釋型語言應(yīng)用程序時(shí),很容易做出這樣的假設(shè):語言本身的運(yùn)行時(shí)系統(tǒng)或代碼庫中的底層代碼是可靠的。

經(jīng)驗(yàn)證明,這種假設(shè)是錯(cuò)誤的。

通常情況下,在高級(jí)語言的內(nèi)存管理功能的實(shí)現(xiàn)代碼中,往往存在著相對(duì)脆弱的基于C/C++的攻擊面。這種問題可能存在于語言本身的核心實(shí)現(xiàn)中,也可能存在于將向高級(jí)語言提供基于C/C++的庫的第三方語言生態(tài)系統(tǒng)中。

這些第三方庫通常是通過顯式外部函數(shù)接口(FFI)或其他形式的API轉(zhuǎn)換包裝器來提供其功能的,因?yàn)檫@些API轉(zhuǎn)換包裝器便于從較低級(jí)別代碼中使用較高層的對(duì)象,或反之。它們通常被稱為本機(jī)模塊、擴(kuò)展或FFI首字母縮寫的某種形式,這樣的攻擊面的特點(diǎn)在于,在高級(jí)應(yīng)用程序的安全上下文中,將與C/C++代碼相關(guān)的各種內(nèi)存管理漏洞都暴露給了攻擊者。

在本系列文章中,我們將探討在高級(jí)語言應(yīng)用程序上下文中有時(shí)被忽略的C/C++攻擊面的例子,其中,有些示例是很久之前的,有些是當(dāng)前發(fā)現(xiàn)的。在第一部分中,我們將為解釋語言的低級(jí)別攻擊面提供相應(yīng)的背景知識(shí),并展示一些跨語言的安全漏洞。在以后的文章中,我們將介紹針對(duì)現(xiàn)代解釋語言生態(tài)系統(tǒng)的新型攻擊技術(shù),以及哪些特征傾向于使這些表面上看是輕微的編程錯(cuò)誤成為實(shí)際可利用的安全漏洞。

本系列文章主要面向希望在如何、為何以及在何處將攻擊面暴露給潛在的惡意輸入等方面做出明智決定的開發(fā)人員,因此,我們將在需要時(shí)對(duì)軟件漏洞的利用理論給出相應(yīng)的解釋。

為了便于討論,我們對(duì)軟件漏洞利用的定義大致如下:利用輸入內(nèi)容的影響,將目標(biāo)進(jìn)程從其預(yù)期的狀態(tài)空間轉(zhuǎn)移到非預(yù)期的狀態(tài)空間的過程。

擺放餐具

在判斷某個(gè)代碼問題“只是”一個(gè)軟件bug,還是一個(gè)安全漏洞時(shí),完全取決于相應(yīng)的上下文。一個(gè)bug被判定為安全漏洞,應(yīng)滿足下列條件:它們應(yīng)以某種狀態(tài)、方式或形式幫助攻擊者發(fā)動(dòng)進(jìn)攻。這本身是高度依賴于上下文的,尤其是在處理核心語言問題時(shí)。受影響的API如何以及在何處暴露于攻擊者的輸入,決定了是否可以將其視為安全漏洞。

在解釋型語言的上下文中,存在兩種主要的攻擊方案。在第一種情況下,攻擊者可以在目標(biāo)解釋器上運(yùn)行其自己的程序,通常,他們的目標(biāo)是破壞解釋器本身的安全措施,以誘使托管解釋器的進(jìn)程跨越某種安全邊界。

這樣的示例包括Web瀏覽器使用的Javascript解釋器中的安全漏洞。這個(gè)主題的變體包括以下場(chǎng)景:攻擊者已在攻擊的第一階段獲得了運(yùn)行任意解釋型代碼的能力,但解釋器本身實(shí)施了某種限制(例如:由于存在嚴(yán)格的PHP配置,使其無法使用命令執(zhí)行功能),從而限制了他們進(jìn)一步開展攻擊的能力。

當(dāng)攻擊者對(duì)目標(biāo)解釋器擁有完全訪問權(quán)限時(shí),通常會(huì)在核心解釋器的實(shí)現(xiàn)中查找漏洞。例如,在各種Javascript解釋器中存在內(nèi)存管理漏洞,通常能演化成Web瀏覽器中可利用的客戶端漏洞。由于攻擊者完全控制了解釋器的狀態(tài),因此,從攻擊者的角度來看,解釋器本身的任何bug都可能是非常有用的。

在第二種情況下,攻擊者可以利用解釋型語言實(shí)現(xiàn)中的某些邏輯,向其提供輸入,但無法直接與解釋器進(jìn)行交互。在這些情形中,攻擊者的攻擊范圍受到他們實(shí)際可以直接或間接向其傳遞數(shù)據(jù)的API的限制。

當(dāng)攻擊者只能控制用高級(jí)語言實(shí)現(xiàn)的目標(biāo)進(jìn)程的輸入時(shí),他們就只能影響接收這些輸入的邏輯,從而限制了他們的選擇余地。在這些情況下,通過深入挖掘找出處理輸入的底層攻擊面,可以發(fā)現(xiàn)從較高級(jí)別邏輯角度看不到的漏洞。

從攻擊者的角度來看,我們的主要目標(biāo)是增加攻擊面的深度。不要橫著挖,而是往下挖!

剝開糖衣

關(guān)于解釋型語言可以在較低級(jí)別進(jìn)行利用的漏洞,已經(jīng)由來已久。在本文中,我們不會(huì)完整的介紹這些漏洞的歷史,但是,我們將深入研究一些有趣的例子——它們?yōu)槲覀冋故玖烁呒?jí)編程語言的bug是如何轉(zhuǎn)化為底層編程語言的安全漏洞的——希望這些“老洞”能夠激發(fā)讀者新的靈感。

歷史上的示例:當(dāng)Perl格式化出錯(cuò)時(shí)

2005年的Perl代碼中存在的格式字符串漏洞是一個(gè)有趣的案例。為了充分理解這個(gè)安全問題,我們首先要快速回顧一下C程序中格式字符串漏洞利用方面的基礎(chǔ)知識(shí)。

C格式字符串漏洞簡(jiǎn)介

雖然許多人認(rèn)為格式字符串錯(cuò)誤由于易于檢測(cè)而在很大程度上已被根除,但它們?nèi)匀徊粫r(shí)出現(xiàn)在意想不到的地方。

從解釋型語言與低級(jí)代碼交互的上下文中考慮格式字符串錯(cuò)誤也很有趣,因?yàn)樗鼈兛赡軙?huì)在較高級(jí)別上預(yù)處理攻擊者控制下的格式字符串,然后直接傳遞給較低級(jí)別的格式化函數(shù)。這種延遲型格式化問題并不少見,尤其是當(dāng)格式串的源和所述格式串的目的地之間存在強(qiáng)烈的邏輯分離時(shí),特別容易出現(xiàn)這種問題。

簡(jiǎn)單地說,格式字符串錯(cuò)誤是一類錯(cuò)誤,其中攻擊者將自己的格式字符串?dāng)?shù)據(jù)提供到格式化函數(shù)中,例如printf(attacker_controll)。然后,他們可以濫用對(duì)受控格式說明符的處理,以實(shí)現(xiàn)對(duì)目標(biāo)進(jìn)程空間的讀寫原語。

對(duì)此類漏洞的實(shí)際攻擊主要依賴于濫用%n和%hn類格式說明符的能力。這些格式符會(huì)命令格式化函數(shù)將打印字符的當(dāng)前運(yùn)行計(jì)數(shù)分別寫入整型(%n)或短整型(%hn)變量中,例如printf(“abcd%n”,&count)將通過指針參數(shù)將值4寫入整型變量count中。

同樣,在格式化函數(shù)的輸出對(duì)攻擊者可見的情況下,攻擊者只需提供期望打印變量值(例如printf("%x%x%x%x"))的格式標(biāo)識(shí)符,即可轉(zhuǎn)儲(chǔ)內(nèi)存內(nèi)容。當(dāng)將預(yù)期的目標(biāo)指針值與其%n個(gè)對(duì)應(yīng)值對(duì)齊時(shí),這種“吃掉”堆棧的能力也變得非常重要。

如果攻擊者能夠向格式化函數(shù)的調(diào)用堆棧提供受控?cái)?shù)據(jù)(通常是通過惡意格式字符串本身來實(shí)現(xiàn)的),并禁用所有編譯器緩解措施,則攻擊者可以將對(duì)寫入字符計(jì)數(shù)器的控制與對(duì)%n/%hn將寫入的指針值的控制相結(jié)合,這樣的話,他們就可以將自己控制的值寫入指定的內(nèi)存位置了。

通過使用諸如在格式說明符上設(shè)置精度/寬度等技巧,將寫入字符計(jì)數(shù)器設(shè)置為特定值,并在支持的情況下設(shè)置直接參數(shù)訪問索引,即使是少量的格式的字符串輸入也能轉(zhuǎn)化為攻擊者強(qiáng)大的攻擊原語。

C語言格式化函數(shù)中的直接參數(shù)訪問(DPA)特性,允許我們指定用于格式標(biāo)識(shí)符的參數(shù)的索引。例如printf("%2$s %1$s\n", "first", "second") 將打印“ second first”,因?yàn)榈谝粋€(gè)字符串格式標(biāo)識(shí)符指定了參數(shù) 2 (2$) ,第二個(gè)字符串格式標(biāo)識(shí)符指定了參數(shù)1(1$)。同樣,從攻擊者的角度來看,使用DPA可使您直接偏移到存放給定%n/%hn寫入所需的目標(biāo)指針值的堆棧位置。理解DPA的用途對(duì)于回顧歷史上的Perl示例非常重要。

小結(jié)

通常情況下,在高級(jí)語言的內(nèi)存管理功能的實(shí)現(xiàn)代碼中,往往存在著相對(duì)脆弱的基于C/C++的攻擊面。這種問題可能存在于語言本身的核心實(shí)現(xiàn)中,也可能存在于將向高級(jí)語言提供基于C/C++的庫的第三方語言生態(tài)系統(tǒng)中。本文中,我們?yōu)樽x者介紹了與此緊密相關(guān)的C格式字符串漏洞方面的知識(shí),在下一篇文章中,我們將為讀者介紹這些底層實(shí)現(xiàn)是如何影響解釋型語言的安全性的。

 

責(zé)任編輯:趙寧寧 來源: 嘶吼網(wǎng)
相關(guān)推薦

2020-12-15 13:24:41

攻擊面語言安全漏洞

2021-01-03 10:44:45

攻擊面語言安全漏洞

2020-12-30 10:26:47

攻擊面語言安全漏洞

2021-01-05 09:51:18

攻擊面語言安全漏洞

2021-01-07 09:19:00

攻擊面語言安全漏洞

2020-06-02 09:50:40

信息安全數(shù)據(jù)技術(shù)

2022-04-27 05:36:51

攻擊面網(wǎng)絡(luò)攻擊網(wǎng)絡(luò)安全

2021-01-21 21:07:03

信息安全漏洞治理

2021-07-09 09:09:47

ASM攻擊面管理安全觀察

2022-02-14 17:13:46

攻擊面管理網(wǎng)絡(luò)安全

2022-06-16 10:02:39

EASM攻擊面管理

2022-07-29 12:42:35

攻擊面管理

2018-11-03 05:00:29

微隔離網(wǎng)絡(luò)攻擊漏洞

2020-08-31 10:54:05

勒索軟件漏洞網(wǎng)絡(luò)安全

2021-06-30 10:10:01

企業(yè)攻擊漏洞網(wǎng)絡(luò)安全

2021-11-29 18:13:31

攻擊面漏洞網(wǎng)絡(luò)攻擊

2014-03-19 10:25:14

2023-08-24 12:13:40

2018-11-19 22:59:31

2022-06-16 15:29:16

攻擊面管理ASM
點(diǎn)贊
收藏

51CTO技術(shù)棧公眾號(hào)