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