0
| 本文作者： 楊鯉萍 | 2019-10-30 10:09 |
雷鋒網(wǎng) AI 開發(fā)者按：如今，越來越多的軟件開發(fā)者通過重用問答網(wǎng)站分享的代碼片段來解決一些實際問題，如 Stack Overflow 平臺就包含了大多代碼來源。盡管復(fù)現(xiàn)源代碼有助于快速原型化；然而最近的研究表明，你所用的很多共享代碼片段可能質(zhì)量很低，甚至包含大量漏洞！研究人員通過對 10 年內(nèi)共享堆棧溢出 C++代碼段中的安全漏洞進(jìn)行深入拆解，發(fā)現(xiàn)在堆棧溢出中 69 個易受攻擊的代碼段在 GitHub 上共計 2859 個項目中被重用。
眾包代碼示例中安全漏洞的性質(zhì)和普遍性到底是什么？面對這些漏洞，我們又該如何選擇安全的代碼段？為了幫助提高共享代碼段質(zhì)量，研究者也開發(fā)了一個工具，允許堆棧溢出用戶在將代碼段上載到平臺時檢查其中的漏洞。雷鋒網(wǎng) AI 開發(fā)者將該研究核心內(nèi)容及結(jié)論整理編譯如下，或許能夠給廣大開發(fā)者重用共享代碼時些許啟發(fā)。
一直以來，軟件開發(fā)的一個主要目標(biāo)是以及時和經(jīng)濟(jì)高效的方式交付高質(zhì)量的軟件；所以代碼重用也被視為一種公認(rèn)的實踐方式，共享代碼片段和代碼示例也是一種常見的學(xué)習(xí)方式。新手甚至更高級的開發(fā)人員利用在這些平臺上共享的代碼示例和解釋，學(xué)習(xí)如何執(zhí)行新的編程任務(wù)以及使用某些 API。
其中，這些重用的代碼片段來自許多不同的源代碼和不同的形式，例如：第三方庫、開源軟件和問答（Q&A）網(wǎng)站等。但近來有研究表明，在問答網(wǎng)站以及 GitHub 中托管的開源軟件存儲庫的知識流和知識共享中，一些代碼片段不僅質(zhì)量差，而且還是有病毒的；這些片段甚至還在 GitHub 上共計 2859 個項目中被重用。
安全性是質(zhì)量的一個重要方面，如果易受攻擊的代碼片段從堆棧溢出遷移到應(yīng)用程序，這些應(yīng)用程序?qū)⑷菀资艿焦簟?/p>
此前，有很多研究人員通過對重用代碼片段進(jìn)行檢測，發(fā)現(xiàn)了這些問題：
Xia 等人表明大量開源系統(tǒng)重用過時的第三方庫，這可能會對軟件造成有害影響，因為它們可能會在軟件中引入安全缺陷。
Abdalkareem 等人檢查了 f-droid 存儲庫，并確定了堆棧溢出 post 和 android 應(yīng)用程序之間的克隆。他們發(fā)現(xiàn)，從 so posts 復(fù)制的代碼會對應(yīng)用程序的質(zhì)量產(chǎn)生不利影響。
Yang 等人分析了托管在 GitHub 上的 909k 個非 fork python 項目，其中包含 290m 個函數(shù)定義，以及在堆棧溢出中捕獲的 190 萬個 python 片段，并對塊級代碼克隆堆棧內(nèi)和堆棧間溢出以及 GitHub 進(jìn)行了定量分析。
Akanda Nishi 等人研究了兩種流行的軟件開發(fā)信息源之間的代碼復(fù)制：堆棧溢出問答站點(diǎn)和軟件開發(fā)教程，以了解重復(fù)信息隨時間的演變。
安等人調(diào)查了 399 個 Android 應(yīng)用程序和堆棧溢出帖子之間的克隆。他們發(fā)現(xiàn)了 1226 個代碼片段，這些代碼片段被 68 個 Android 應(yīng)用程序重用。代碼片段的重復(fù)使用導(dǎo)致 1279 例潛在的許可證沖突。
Fischer 等人發(fā)現(xiàn)從堆棧溢出復(fù)制到 196403 個Android 應(yīng)用程序的不安全代碼片段，已在 google play 上發(fā)布。
Zhang 等人通過檢查 API 調(diào)用的誤用，研究了堆棧溢出代碼片段的質(zhì)量。他們報告說，大約 31% 的分析代碼片段可能包含可能導(dǎo)致失敗和資源泄漏的 API 誤用。
Rahman 等人檢測到七種安全氣味，表明 IAC 腳本中存在安全漏洞，并識別出 21201 次安全氣味，包括 1326 次硬編碼密碼。
Zahedi 等人研究了 GitHub 存儲庫中的問題主題，發(fā)現(xiàn)其中只有 3% 與安全性相關(guān)。這些安全問題中的大多數(shù)是密碼問題。
Pletea 等人研究了 GitHub 的安全相關(guān)討論，并報告它們代表 GitHub 的所有討論的大約 10%。他們還報告說，與安全有關(guān)的討論往往與消極情緒有關(guān)。
Acar 等人對活躍的 GitHub 用戶進(jìn)行了一項實驗，以檢驗安全相關(guān)研究中招募便利樣本的有效性。他們發(fā)現(xiàn)，參與者的自我報告狀態(tài)（即學(xué)生或?qū)I(yè)開發(fā)人員）和參與者的安全背景都與他們成功完成安全任務(wù)的能力無關(guān)。
但目前，大多數(shù)在堆棧溢出上的代碼片段安全性方面研究集中于 Java 和 Python；忽略了 C++——最流行的第四種編程語言（https://www.tiobe.com/tiobe-index/）。
它是嵌入式資源受限程序的首選語言，并廣泛應(yīng)用于大型和分布式系統(tǒng)中；因此 C++非常容易出現(xiàn)誤用（例如：內(nèi)存損壞錯誤），這很容易導(dǎo)致易受攻擊的代碼和可開發(fā)的應(yīng)用程序，這表明 C++代碼段中的漏洞可能會產(chǎn)生更嚴(yán)重的影響。本文則旨在填補(bǔ) C++語言代碼共享的安全性研究空白，并幫助更多開發(fā)者了解堆棧溢出時共享的代碼示例中安全漏洞的性質(zhì)和普遍性。
研究人員發(fā)現(xiàn)，堆棧溢出問題是在編程問答（Q&A）社區(qū)被問得最多的。因此，對堆棧溢出的研究在軟件界具有重要意義。為了使得研究結(jié)果更具代表性，研究人員從以下兩個維度對堆棧溢出中共享的代碼示例中的 C++漏洞進(jìn)行了實證研究：
普遍性 主要對堆棧溢出數(shù)據(jù)集中包含的某個稱為 StoTrOrm 的 C++漏洞類型進(jìn)行了深入研究；并分析了它們隨時間，特別是它們遷移到 GitHub 項目中的演化過程。
傳播度 研究如何在 GitHub 存儲庫中重用易受攻擊的代碼片段。
了解在源代碼示例中 C++漏洞的普遍性和傳播度
圍繞源代碼示例中 C++漏洞的普遍性和傳播度兩個維度，研究人員探討了以下問題：
1. 堆棧溢出代碼段中的 C++漏洞有多普遍？
2.GitHub 存儲庫中如何重用易受攻擊的堆棧溢出 C++共享代碼？
案例研究的總體步驟
為了研究堆棧溢出 posts 的演變及其與 github 的關(guān)系，使用了 sotorrent 數(shù)據(jù)集版本 2018-09-23。
這個版本的 sotorrent 包含了從 2008 年到 2018 年的帖子?？偣灿?41472536 個問答帖子和 109385095 個帖子版本，其中 206560269 個帖子版本包含 6039434 個軟件項目鏈接。有 3861573 個鏈接指向公共 GitHub 存儲庫。
Sotorrent 提供對堆棧溢出內(nèi)容十年的版本歷史的訪問。如圖 2 所示，可以獨(dú)立訪問整個 post、單個文本或代碼片段。
Sotorrent 提供的歷史數(shù)據(jù)
最終，研究人員從至少一個 GitHub 項目中重用的 72483 個 C++代碼片段中，發(fā)現(xiàn)了屬于 29 種不同類型的漏洞達(dá)到 69 個；而這 69 個易受攻擊的代碼片段，用于 Github 文件中的有 2589 個，并且從堆棧溢出傳播到 Github 的最常見漏洞是 CWE150。
這里，CWE（Common Weakness Enumeration）是社區(qū)開發(fā)的通用軟件安全弱點(diǎn)列表。它可以作為一個軟件安全工具的測量棒，以及作為識別、緩解和預(yù)防弱點(diǎn)的基線。CWE 的目的是促進(jìn)在程序分發(fā)給公眾之前，有效地使用能夠識別、發(fā)現(xiàn)和解決計算機(jī)軟件中的錯誤和漏洞的工具。
問題一、堆棧溢出代碼段中的 C++漏洞有多普遍？
總體上，所有 C++回答從 2008 到 2018 的分布如下圖所示。2013 年既是 C++回答最多的一年，也是 C++在 GITHUB 項目中遷移最多的時候。
C++中按年份分布的回答
研究人員對代碼片段的手動檢查發(fā)現(xiàn)，69 個回答中存在 99 個易受攻擊的代碼片段。通過查看易受攻擊回答的分布，他們發(fā)現(xiàn)最易受攻擊的答案是在 2011 年創(chuàng)建的，如下圖所示。
每個回答中的 CWE 頻率
代碼片段中 CWE 的頻率如下圖所示，可以看到 CWE-1006 和 CWE-754 是最常見的安全隱患。
代碼片段中 CWE 的頻率
下表說明了已找到的 CWE 列表。有關(guān) CWE 的完整說明，請參見（https://cwe.mitre.org/）。
不同類型的 CWE C++漏洞及其頻率，如我們在堆棧溢出數(shù)據(jù)集中所觀察到的，X 軸上的每一個刻度表示一年的最后一個/兩個字母，例如 2016 對應(yīng) 16，2008 對應(yīng) 8
下面是研究人員所檢查代碼片段中發(fā)現(xiàn)的一些漏洞示例。
漏洞示例一
下面這個代碼片段可能很危險。
顯示由于使用不正確的使用方法的 RAND 函數(shù)而導(dǎo)致的脆弱性（CWE-1006、CWE-477、CWE-193、CWE-754）
具有計數(shù)參數(shù)（如「len」）的函數(shù)應(yīng)將終止的「null」作為額外字符考慮在內(nèi)。但這個函數(shù)實際上是在執(zhí)行 s[len]=0 時寫入字符'len+1'。這就是 CWE-193:OffbyOne 錯誤漏洞，它可能導(dǎo)致不可預(yù)測的行為、內(nèi)存損壞和應(yīng)用程序崩潰。如果產(chǎn)生一個特殊的并且總是在最大長度上傳遞一個小于期望值的數(shù)字，函數(shù)就正常工作，否則就可能崩潰。
CWE-193:OffbyOne 錯誤漏洞
行's[i]=alphanum[rand（）%size of（alphanum）-1]'也有問題，因為'alphanum'的大小是'63'，其中索引第 69 個字符串的最后一個字符是'null'。因此，偶爾會在生成的「隨機(jī)」字符串中包含一個空值。此漏洞可歸類為「CWE-754：異?；虍惓Ｇ闆r的不正確檢查」，其中不正確的數(shù)字可用于返回導(dǎo)致崩潰或其他意外行為的函數(shù)。另一個合適的類別是「CWE-1006：錯誤的編碼實踐」。換句話說，使用此算法生成的隨機(jī)字符串也會使得在字符串中間包含「null」。
CWE-754：異?；虍惓Ｇ闆r的不正確檢查
此外，在 C 和 C++中，「反匯編」是一個過時的函數(shù)。因此，另一個漏洞類別是「CWE-477：使用過時功能」，這是軟件質(zhì)量退化的一個主要原因。還有一個漏洞存在于代碼中，因為開發(fā)人員在調(diào)用函數(shù)之前沒有使用隨機(jī)種子。因此，生成的隨機(jī)數(shù)根本不是「隨機(jī)」的。此外，「rand（）%mod」不是一個好的做法，因為它返回的低位不再是隨機(jī)的。
rand（）%mod：
漏洞示例二
顯示了由于在不檢查返回特殊條件的情況下使用 malloc 函數(shù)而導(dǎo)致的漏洞（CWE-1006、CWE-252、CWE-789、CWE-476）
此回答中的代碼片段使用「malloc」分配內(nèi)存，并將其指針傳遞給 qt 庫中需要有效指針的函數(shù)。如果 malloc 失敗，malloc 返回指針可以設(shè)置為空。因此，即使請求的內(nèi)存量很小，也必須檢查 malloc 的返回指針 [54]。在本例中，不檢查 malloc 的返回值。此漏洞稱為 CWE-252[55]；未經(jīng)檢查的返回值。如果 malloc 失敗，則會發(fā)生空指針取消引用。
malloc 返回指針
CWE-252
漏洞示例三
顯示了由于用戶輸入是 volved 而導(dǎo)致操作系統(tǒng)命令注入的漏洞（CWE-78，CWE-1019）
所示的函數(shù)易受代碼注入（OS 命令注入）攻擊，因為用戶輸入的命令是輸入的，而不是檢查的。換言之，任何具有程序特權(quán)級別的命令都可以在沒有任何錯誤或警告的情況下執(zhí)行。
漏洞示例四
顯示由于此函數(shù)中的第二個參數(shù)可能包含多個由「；」分隔的路徑而導(dǎo)致的漏洞（CWE-754、CWE-252、CWE-426）
以編程方式處理系統(tǒng)路徑，或程序搜索的不同路徑。這個操作很危險，應(yīng)該小心操作。例如，此函數(shù)中的「path」可以包含由「；」分隔的多個路徑，如：「/usr/share/lua/foo/bar/evil/path」。在路徑中有一個不受信任的搜索路徑會產(chǎn)生以程序權(quán)限執(zhí)行任意代碼的可能性，并重定向到可能觸發(fā)崩潰的錯誤文件。此漏洞稱為 CWE-426:不受信任的搜索路徑。搜索可能導(dǎo)致程序執(zhí)行，進(jìn)而導(dǎo)致異?；虍惓Ｇ闆r；即 CWE-754：對異?；虍惓Ｇ闆r的不當(dāng)檢查。此外，不檢查代碼段中函數(shù)的所有返回值。因此，代碼片段還具有 CWE-252：未檢查的返回值。
CWE-426:不受信任的搜索路徑
漏洞示例五
顯示了由于越界讀取和缺少檢查變量大小而導(dǎo)致的漏洞（CWE-20、CWE-125、CWE-1019）
在漏洞示例五所示的代碼中，由于「current index+size of（t）」可能會大于「vec」的大小，而存在 CWE1019:validate inputs 漏洞。此外，當(dāng)索引超過限制時，可能會發(fā)生信息泄漏或 CWE125；存在「越界讀取」漏洞。
漏洞示例六
如果包含空值的輸入字符串（CWE-158，CWE-1019）失敗，則所有定義的函數(shù)都有漏洞
所示關(guān)于如何驗證文件名是否以「.txt」結(jié)尾的代碼中，包含了 answer post 原始代碼片段中六個方法的函數(shù)代碼及其基準(zhǔn)。此代碼段中定義的其他函數(shù)的漏洞與這兩個易受攻擊的函數(shù)完全相同。但如果函數(shù)中的文件名包含空字符，則以上所有方法都將失敗。這是繞過 web 應(yīng)用程序防火墻和文件上傳程序的常見技巧。示例：對于以上所有函數(shù)，驗證「shell.txt\0.php」將返回 true。
問題二、復(fù)制到 GitHub 的易受攻擊的代碼示例頻率
我們發(fā)現(xiàn)的大多數(shù)易受攻擊的代碼段都是函數(shù)或函數(shù)的一部分。因此，研究人員使用了基于 sourcerercc 等克隆檢測工具的一些啟發(fā)式方法，在鏈接的 GitHub 項目中搜索并找到 10 個類似的代碼。
下面給出了兩種方法（選擇關(guān)鍵字和隨機(jī)關(guān)鍵字）的結(jié)果，并將其與基線方法進(jìn)行了比較。
結(jié)果
69 個易受攻擊的答案的 GitHub 文件總數(shù)為 2859 個 GitHub 鏈接，這些鏈接顯示在下表中，由 CWE 定義分隔。研究人員通過相關(guān)的算法發(fā)現(xiàn) 287 個 GitHub 易受攻擊的文件都可能存在安全漏洞。
GitHub 存儲庫中使用所選關(guān)鍵字算法的 CWES 檢測
問題三、修復(fù)復(fù)制的易受攻擊代碼示例的概率
研究人員創(chuàng)建了一個新的 web 應(yīng)用程序，使評審過程更加高效和系統(tǒng)。通過審查系統(tǒng)，他們評估了遷移到 GitHub 的易受攻擊的堆棧溢出代碼段是已修復(fù)還是仍包含該漏洞。
結(jié)果
在被檢查的 287 個 GitHub 文件中，有 34 個文件中的漏洞得到了糾正，其他 253 個 GitHub 文件仍然存在漏洞。如下圖代碼所示，更正了 CWE-789 和 CWE-252 兩個漏洞。
在 GitHub 文件中，堆棧溢出中回答的修復(fù)與部分代碼改進(jìn)
CWE-252
https://cwe.mitre.org/data/definitions/252.html
CWE-789
如下圖代碼所示，對 cwe-125、cwe-category-1019 和 cwe-20 進(jìn)行了更正。
在注釋提到的 GitHub 文件中修復(fù)了代碼
CWE-125
https://cwe.mitre.org/data/definitions/125.html
CWE-category-1019
https://cwe.mitre.org/data/definitions/1019.html
CWE-20
下圖中顯示了一些用戶對其項目中的漏洞的響應(yīng)?？梢钥吹?，有很多開發(fā)者在重用這些代碼片段時，并沒有注意到其中所包含的潛在威脅。
用戶對其代碼中的安全漏洞的響應(yīng)
用戶也針對自動檢測漏洞的有用性，進(jìn)行了個人看法的討論。大部分人都認(rèn)為檢測漏洞是一個非常有用且重用的事情。
用戶對有助于未來開發(fā)的自動漏洞分析的意見
用戶也發(fā)表了對漏洞處理的最佳方法，大多數(shù)實踐者同意使用自動安全機(jī)制來檢測代碼中的漏洞。他們表示，使用瀏覽器擴(kuò)展和脫機(jī)工具運(yùn)行臨時堆棧溢出方法比其他方法更有效，可以將代碼示例中的漏洞告知用戶。
如何告知開發(fā)人員代碼示例中的潛在漏洞意見
解決方案
在我們收到的針對 GitHub 所有者的 117 個問題的 15 個響應(yīng)中，40% 指出了代碼中存在漏洞的可能性，前提是他們的輸入數(shù)據(jù)不是動態(tài)的，13.3% 承認(rèn)代碼中存在漏洞，但不愿意修復(fù)。
GitHub 所有者選擇對其代碼中存在的漏洞進(jìn)行了注釋
為了告知用戶代碼中存在的漏洞，研究人員也開發(fā)了瀏覽器擴(kuò)展。該瀏覽器擴(kuò)展旨在防止開發(fā)人員重用此類易受攻擊的代碼段，并向他們推薦更好的替代方案，即在其他堆棧溢出帖子中使用不易受攻擊的代碼段。
當(dāng)開發(fā)人員訪問堆棧溢出 post 時，擴(kuò)展將被激活。該擴(kuò)展參考堆棧溢出中易受攻擊的 C++代碼片段的數(shù)據(jù)庫，以確定在 POST 中提供的解決方案是否是不安全。如果確實發(fā)現(xiàn)提供的解決方案易受攻擊，則擴(kuò)展將向開發(fā)人員顯示一條警告消息，并解釋代碼片段易受攻擊的原因。
警告消息截圖
然后，擴(kuò)展將推薦來自其他堆棧溢出帖子的不易受攻擊的類似代碼段，以便開發(fā)人員可以重用這些安全代碼段，而不是易受攻擊的代碼段。不過，該擴(kuò)展目前也存在一定的有效性威脅，這也與之前所使用的檢測方法有關(guān)，使用這一啟發(fā)式方法來檢測從堆棧溢出到 GitHub 的易受攻擊的C++代碼片段，可能會存在部分代碼丟失的情況。
因此，在面對復(fù)制而得的代碼時，只有小心嚴(yán)謹(jǐn)才是王道?。。。?/p>
論文地址：
https://arxiv.org/pdf/1910.01321.pdf
瀏覽器擴(kuò)展：
https://github.com/paper-materials-crowd-sourced/materials
相關(guān)資訊：
https://fossbytes.com/copying-codes-from-stack-overflow-leads-to-vulnerable-github-projects/
雷鋒網(wǎng) AI 開發(fā)者
雷峰網(wǎng)原創(chuàng)文章，未經(jīng)授權(quán)禁止轉(zhuǎn)載。詳情見轉(zhuǎn)載須知。
