接上文《深入考察解釋型語言背后隱藏的攻擊面，Part 1(上)》

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

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

[[357806]]

Perl格式化的幽靈(CVE-2005-3962)

對于解釋型語言來說，提供自己的格式設(shè)置函數(shù)的情況并不少見，特別是Perl通過其較低級別的Perl_sv_vcatpvfn函數(shù)提供格式支持。這些低級C API為高級Perl API提供了許多核心格式化支持。它的格式化支持在語法上與C語言的格式化支持有些相似，因?yàn)樗仓С种苯訁?shù)訪問的概念，在Perl中，該參數(shù)被稱為“精確格式索引”，以及格式標(biāo)識符%n。

當(dāng)我們考慮到存在基于Perl的遠(yuǎn)程服務(wù)應(yīng)用程序明顯易受格式字符串錯誤的影響時，了解Perl內(nèi)置的格式化支持就變得非常有趣。然而，由于沒有辦法在Perl級別上直接利用這些錯誤，因此，安全研究社區(qū)并沒有花太多精力來嘗試?yán)眠@些錯誤，而是通常將它們視為“只不過是一個bug而已”。

大約在2005年，在CVE-2005-3962的作者(Jack Louis)確定這些漏洞的可利用性之后，我對Perl格式字符串漏洞進(jìn)行了更深入的研究。在Webmin中測試Jack Louis發(fā)現(xiàn)的Perl格式字符串錯誤時，他在Perl解釋器中遇到了一些可觀察到的崩潰。

事實(shí)證明，攻擊者確實(shí)可以通過Perl_sv_vcatpvfn中的格式化支持的C級實(shí)現(xiàn)來利用基于Perl的格式字符串漏洞。

Perl格式字符串的參數(shù)存儲在參數(shù)結(jié)構(gòu)指針數(shù)組(稱為svargs)中，并為格式說明符(例如%1$n)提供準(zhǔn)確的格式索引，以使用該索引從參數(shù)數(shù)組檢索適當(dāng)?shù)膮?shù)結(jié)構(gòu)指針。當(dāng)從數(shù)組中檢索關(guān)聯(lián)的參數(shù)結(jié)構(gòu)指針時，Perl將根據(jù)格式字符串可用的參數(shù)數(shù)量，確保所提供的索引不超過數(shù)組的上限。這里的參數(shù)計(jì)數(shù)實(shí)際上保存一個帶符號的整型變量中，即svmax。也就是說，如果將格式字符串傳遞了1個參數(shù)，則svmax的值為1，并且檢查精確格式索引值不超過1。如果攻擊者提供了格式字符串，則不存在任何參數(shù)，這時svmax的值為0。

但是，精確格式索引也是帶符號的32位整數(shù)，并且其值完全由攻擊者提供的格式字符串控制。這意味著您可以將此參數(shù)數(shù)組索引設(shè)置為負(fù)值，這樣也可以通過針對svmax的帶符號上限檢查。

了解這一點(diǎn)后，漏洞的利用就變得相當(dāng)簡單了。人們可以直接通過svargs數(shù)組索引指向任何指向攻擊者控制的數(shù)據(jù)的指針。這種受攻擊者控制的數(shù)據(jù)將被解釋為參數(shù)結(jié)構(gòu)，其中包含指向值字段的指針。與熟悉的%n格式說明符相結(jié)合，攻擊者就能夠?qū)κ芸匚恢脠?zhí)行受控寫入操作。使用這樣的寫原語，就可以覆蓋任何可寫進(jìn)程內(nèi)存的內(nèi)容，而這些內(nèi)容可以通過各種方式用于完整的過程控制中。

這是一個很好的例子，它為我們展示了Perl格式化實(shí)現(xiàn)的bug是如何轉(zhuǎn)化為安全漏洞的。結(jié)合Webmin中的格式字符串漏洞，攻擊者就能夠?qū)ebmin發(fā)動遠(yuǎn)程代碼執(zhí)行(RCE)攻擊。

我們得出的結(jié)論是，即使在較高級語言級別上看起來似乎“只是一個bug”的問題，也需要對錯誤輸入的較低級別處理進(jìn)行深入的考察，因?yàn)樗鼈兒芸赡軙D(zhuǎn)化為一個高危漏洞——即使人們曾經(jīng)認(rèn)為這樣的問題實(shí)際上是不可利用的。

PHP解釋器的無限潛力

從攻擊者的角度來看，他們一直對PHP解釋器的許多版本趨之若鶩。這是因?yàn)?，攻擊者通?？梢詮慕忉屍骺刂平嵌群瓦h(yuǎn)程API輸入角度對其發(fā)動攻擊：對于前者，攻擊者能夠執(zhí)行任意PHP代碼;對于后者，攻擊者可以向潛在易受攻擊的PHP API提供惡意輸入。

利用PHP解釋器的一個更有趣的例子是反序列化攻擊。因?yàn)楣粽咴?jīng)在PHP邏輯級別和核心解釋器級別攻陷過PHP的反序列化API。

人們普遍認(rèn)為，對不受信任的用戶提供的數(shù)據(jù)進(jìn)行反序列化是一個壞主意。在遠(yuǎn)程應(yīng)用程序的上下文中，任意的對象反序列化可能會導(dǎo)致相對簡單的PHP任意執(zhí)行，這取決于應(yīng)用程序命名空間中哪些類是可用的和允許的。這個主題超越了語言的界限，我們在幾乎所有支持反序列化的語言和應(yīng)用程序框架中都看到了同樣的概念。

在攻擊者實(shí)現(xiàn)任意PHP執(zhí)行攻擊后，他們可能會發(fā)現(xiàn)自己受到受限解釋器配置的制約，這時他們通常會探索解除這些限制的方法。歷史上流行的一種方法是濫用PHP解釋器本身的bug。最近在 https://bugs.php.net/bug.php?id=76047中可以找到這類攻擊的一個示例，其中可以利用debugbacktrace()函數(shù)中的釋放后使用(UAF)漏洞來完全控制PHP解釋器本身,并廢除所有配置方面的限制。

有時，即使提供了受控的PHP反序列化原語，由于攻擊者無法獲悉哪些類是可用的，或因應(yīng)用程序命名空間存在某些限制，而無法將其轉(zhuǎn)化為任意PHP執(zhí)行能力。這時，從上層下潛到較低的代碼層，很可能就能找到突破口。

由于PHP的反序列化API中存在大量內(nèi)存管理不善問題，因此，長久以來，它們一直都是模糊測試和解釋器漏洞的熱門研究目標(biāo)。

通過利用反序列化API在解釋器實(shí)現(xiàn)層面的內(nèi)存管理不善問題，一個堅(jiān)定的攻擊者能夠?qū)⒁粋€原本不可利用的漏洞轉(zhuǎn)變成一個完全可利用的漏洞。實(shí)際上，已經(jīng)出現(xiàn)過許多通過該攻擊面遠(yuǎn)程利用PHP應(yīng)用程序的實(shí)際例子。

最近的一個例子出現(xiàn)在Ruslan Habolov撰寫的一篇優(yōu)秀的文章中，其中描述了他們?nèi)绾卫玫图塒HP解釋器錯誤和高級PHP API的交互，對一個著名的現(xiàn)實(shí)目標(biāo)發(fā)動RCE攻擊。

PHP反序列化在較高和較低級別實(shí)現(xiàn)的混合攻擊面是解釋型語言垂直攻擊面的另一個很好的例子。

把C帶入Python中：CVE-2014-1912漏洞

就本文而言，我們的第三個也是最后一個例子是CVE-2014-1912漏洞。這個漏洞存在于Python的socket.recvfrom_into函數(shù)中。

在Python2.5中引入的socket.recvfrom_into的預(yù)期用途是將數(shù)據(jù)接收到指定的Python字節(jié)數(shù)組中。但是，由于該函數(shù)缺乏明確的檢查，所以無法確保接收數(shù)據(jù)的目標(biāo)緩沖區(qū)的大小足以容納指定數(shù)量的傳入數(shù)據(jù)。

例如socket.recvfrom_into(bytearray(256)，512)就會觸發(fā)內(nèi)存損壞問題。

后來，人們通過下面的代碼對其進(jìn)行了修復(fù)：

diff -r e6358103fe4f Modules/socketmodule.c 
--- a/Modules/socketmodule.c    Wed Jan 08 20:44:37 2014 -0800 
+++ b/Modules/socketmodule.c    Sun Jan 12 13:21:19 2014 -0800 
@@ -2877,6 +2877,14 @@ 
         recvlen = buflen; 
     } 
  
+    /* Check if the buffer is large enough */ 
+    if (buflen < recvlen) { 
+        PyBuffer_Release(&pbuf); 
+        PyErr_SetString(PyExc_ValueError, 
+                        "buffer too small for requested bytes"); 
+        return NULL; 
+    } 
+ 
     readlen = sock_recvfrom_guts(s, buf, recvlen, flags, &addr); 
     if (readlen < 0) { 
         PyBuffer_Release(&pbuf); 

為了利用這個漏洞，應(yīng)用程序必須顯式使用一個大于目標(biāo)字節(jié)數(shù)組長度的長度參數(shù)，向該字節(jié)數(shù)組中讀入比分配給該數(shù)組的空間更多的數(shù)據(jù)。如果未提供長度參數(shù)，則該函數(shù)則默認(rèn)使用目標(biāo)字節(jié)數(shù)組本身的長度，因此，就不會發(fā)生內(nèi)存損壞問題。

如果您使用的開發(fā)語言要求程序員自己負(fù)責(zé)內(nèi)存管理的話，那么對于上述問題肯定不會陌生。您甚至可能認(rèn)為，任何一個心智正常的人都不會做這樣的蠢事。因?yàn)楹苊黠@，您不應(yīng)該讀取比目標(biāo)緩沖區(qū)中可用的數(shù)據(jù)更多的數(shù)據(jù)，對嗎?

這個案例的有趣之處就在這里：提供內(nèi)存管理功能的編程語言的開發(fā)人員，通常會傾向信任該語言的實(shí)現(xiàn)。但是，當(dāng)語言中存在諸如CVE-2014-1912之類的問題時，則可能會出現(xiàn)認(rèn)知失調(diào)。

Python開發(fā)人員可能完全希望能夠在Python解釋器不受內(nèi)存損壞的情況下使用s.recvfrom_into(bytearray(256), 512) 。實(shí)際上，如果您嘗試這個打過補(bǔ)丁后的程序，它現(xiàn)在的表現(xiàn)就像您所期望的那樣：

Traceback (most recent call last): 
  File " 
ValueError: nbytes is greater than the length of the buffer 
>>> 

所以，這個問題的重點(diǎn)在于，使用被認(rèn)為是內(nèi)存安全的語言實(shí)現(xiàn)的函數(shù)，竟然存在內(nèi)存破壞漏洞。但對于一個C程序員來說，面對CVE-2014-1912漏洞，他們多半是這樣理解的：“是的，就是這樣工作的呀，難道不是嗎?”

這給了我們一個教訓(xùn)，即使是在宣稱內(nèi)存安全的高級語言中，也絕對不要認(rèn)為其內(nèi)存管理絕對是安全的。當(dāng)處理顯式操作靜態(tài)長度的可變緩沖區(qū)的API時，檢查你的長度與你的緩沖區(qū)相匹配是永遠(yuǎn)不會有壞處的，即使在由于語言本身的原因不這樣做也可能是安全的情況下也是如此。

從攻擊者的角度來看，對于通常被認(rèn)為是內(nèi)存安全的API進(jìn)行審計(jì)，常常會有意想不到的收獲。

小結(jié)

作為關(guān)于隱藏的C/C++攻擊面的系列文章的第一篇，我們已經(jīng)探討了幾個實(shí)際的例子，為大家展示了內(nèi)存安全的幻覺是如何麻痹開發(fā)人員，從而讓他們放松對應(yīng)用程序中接受的輸入的警惕的。

本文探討的漏洞的變體可能而且確實(shí)存在于所有解釋器API中，這些API一般可以從更高級別訪問，并且其核心是用內(nèi)存不安全語言實(shí)現(xiàn)的。這些漏洞是否可被利用，通常取決于開發(fā)人員為攻擊者提供了多大的回旋余地。

如果開發(fā)人員對輸入類型、大小和值范圍加以嚴(yán)格要求的話，通常能夠挫敗這種漏洞——例如，當(dāng)接收到整數(shù)值時，將該值的范圍顯式地限制在應(yīng)用程序上下文中有意義的范圍內(nèi)，而不是將其開放給變量類型本身的取值范圍，這是一種防御性的編程習(xí)慣，對您將有很大的幫助。

在本系列的下一篇文章中，我們將深入研究解釋型語言的現(xiàn)代C/C++攻擊面，重點(diǎn)介紹流行解釋型語言框架的第三方庫生態(tài)系統(tǒng)，以及針對它們的新型攻擊方法。

本文翻譯自：https://securitylab.github.com/research/now-you-c-me