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