米国 CISA FBI、オーストラリアACSC カナダ CCCS 選択したオープン・ソース・ソフトウェア（OSS）におけるメモリ安全性リスクの規模に関する調査結果 (2024.06.26)

こんにちは、丸山満彦です。

米国 CISA FBI、オーストラリアACSC カナダ CCSCが、選択したオープン・ソース・ソフトウェア（OSS）におけるメモリ安全性リスクの規模に関する調査結果を公表していますね...

興味深いですね...

● Cybersecurity & Infrstracture Security Agency; CISA

・2024.06.26 Exploring Memory Safety in Critical Open Source Projects

Exploring Memory Safety in Critical Open Source Projects	重要なオープンソースプロジェクトにおけるメモリ安全性を探る
CISA, in partnership with the Federal Bureau of Investigation, Australian Signals Directorate’s Australian Cyber Security Centre, and Canadian Cyber Security Center, crafted this joint guidance to provide organizations with findings on the scale of memory safety risk in selected open source software (OSS). This guide builds on The Case for Memory Safe Roadmaps by providing a starting point for software manufacturers to create memory safe roadmaps, including plans to address memory safety in external dependencies which commonly include OSS. Exploring Memory Safety in Critical Open Source Projects also aligns with the 2023 National Cybersecurity Strategy and corresponding implementation plan, which discusses investing in memory safety and collaborating with the open source community—including the establishment of the interagency Open Source Software Security Initiative (OS3I) and investment in memory-safe programming languages.	CISA は、連邦捜査局（FBI）、オーストラリア信号局（Australian Signals Directorate）のオーストラリア・サイバー・セキュリティ・センター（Australian Cyber Security Centre）、カナダ・サイバー・セキュリティ・センター（Canadian Cyber Security Center）と共同で、選択したオープン・ソース・ソフトウェア（OSS）におけるメモリ安全性リスクの規模に関する調査結果を組織に提供するために、この共同ガイダンスを作成した。この手引きは、「メモリ安全ロードマップの事例」に基づき、ソフトウェア・メーカーがメモリ安全ロードマップを作成するための出発点を提供するもので、OSSをよく含む外部依存関係におけるメモリ安全性に対処する計画も含まれている。クリティカルなオープンソースプロジェクトにおけるメモリ安全性の探求は、2023年国家サイバーセキュリティ戦略および対応する実施計画とも整合しており、メモリ安全性への投資およびオープンソースコミュニティとの協業（省庁間オープンソースソフトウェアセキュリティイニシアティブ（OS3I）の設立やメモリ安全なプログラミング言語への投資を含む）について議論している。
CISA encourages all organizations and software manufacturers to review the methodology and results found in the guidance to:	CISAは、すべての組織とソフトウェア・メーカーに対し、本ガイダンスに記載されている方法論と結果を検討することを推奨する：
・Reduce memory safety vulnerabilities;	・メモリ安全性の脆弱性を減らす；
・Make secure and informed choices;	・安全で十分な情報に基づいた選択を行う；
・Understand the memory-unsafety risk in OSS;	・OSSのメモリ安全性リスクについて理解する；
・Evaluate approaches to reducing this risk; and	・このリスクを低減するためのアプローチを評価する。
・Continue efforts to drive risk-reducing action by software manufacturers.	・ソフトウェアメーカーによるリスク低減のための取り組みを継続する。
To learn more about taking a top-down approach to developing secure products, visit CISA’s Secure by Design webpage.	セキュアな製品を開発するためのトップダウン・アプローチについての詳細は、CISAのセキュア・バイ・デザインのウェブページを参照のこと。

・[PDF] Exploring Memory Safety in Critical Open Source Projects - 508c

目次...

Executive Summary	エグゼクティブサマリー
Background	背景
Recent Efforts	最近の取り組み
Report Terminology	報告書の用語
Methodology and Results	方法論と結果
Dependencies	依存関係
Discussion	ディスカッション
Disclaimer	免責事項
Annex	附属書

エグゼクティブサマリー...

Executive Summary	エグゼクティブサマリー
In December 2023, the Cybersecurity and Infrastructure Security Agency (CISA), the National Security Agency (NSA), the Federal Bureau of Investigation (FBI), and international cybersecurity authorities from Australia, Canada, New Zealand, and the United Kingdom, published The Case for Memory Safe Roadmaps. This joint publication notes that memory safety vulnerabilities are among the most prevalent classes of software vulnerability and generate substantial costs for both software manufacturers and consumers related to patching, incident response, and other efforts. It further recommends software manufacturers create memory safe roadmaps, including plans to address memory safety in external dependencies, which commonly include open source software (OSS).	2023年12月、Cybersecurity and Infrastructure Security Agency（CISA）、National Security Agency（NSA）、Federal Bureau of Investigation（FBI）、およびオーストラリア、カナダ、ニュージーランド、イギリスの国際的なサイバーセキュリティ当局は、「The Case for Memory Safe Roadmaps」を発表した。この共同出版物は、メモリ安全性の脆弱性がソフトウェアの脆弱性の中で最も一般的なクラスの一つであり、パッチ適用、インシデント対応、その他の取り組みに関連する多大なコストをソフトウェアメーカーと消費者の双方に生じさせていることを指摘している。さらに、ソフトウェアメーカーに対し、オープンソースソフトウェア（OSS）を含む外部依存関係におけるメモリ安全性への対応計画を含む、メモリ安全ロードマップの作成を推奨している。
This joint report, authored by CISA, FBI, the Australian Signals Directorate’s Australian Cyber Security Center (ASD’s ACSC), and the Canadian Centre for Cybersecurity (CCCS), provides a starting point for these roadmaps by investigating the scale of memory safety risk in selected OSS. To understand the state of memory unsafety in OSScode, we explored a set of critical open source projects to determine the extent to which they are written in memoryunsafe languages.[1] Memory-unsafe languages require developers to properly manage memory use and allocation. Mistakes, which inevitably occur, can result in memory-safety vulnerabilities such as buffer overflows and use after free. Successful exploitation of these types of vulnerabilities can allow adversaries to take control of software, systems, and data. Memory-safe languages shift the abstraction layer and responsibility for writing memory-safe code from the developer to the compiler or interpreter, vastly reducing opportunities to introduce memory-safety vulnerabilities.	CISA、FBI、Australian Signals Directorate's Australian Cyber Security Center (ASD's ACSC)、Canadian Centre for Cybersecurity (CCCS)が執筆したこの共同報告書は、特定のOSSにおけるメモリ安全性リスクの規模を調査することで、これらのロードマップの出発点を提供する。OSSコードにおけるメモリ非安全状態を理解するために、私たちは一連の重要なオープンソースプロジェクトを調査し、それらがどの程度メモリ非安全言語で書かれているかを調べた[1]。メモリ非安全言語は、開発者がメモリの使用と割り当てを適切に管理することを要求する。必然的に発生するミスは、バッファ・オーバーフローやuse after freeのようなメモリ安全性の脆弱性を引き起こす可能性がある。このような脆弱性の悪用に成功すると、敵はソフトウェア、システム、データを制御できるようになる。メモリ安全言語は、抽象化レイヤとメモリ安全コードを書く責任を開発者からコンパイラやインタプリタに移し、メモリ安全性の脆弱性を導入する機会を大幅に減らす。
Upon analyzing a list of 172 projects derived from the Open Source Security Foundation (OpenSSF) Securing Critical Projects Working Group’s List of Critical Projects,[2] we observe that:	Open Source Security Foundation (OpenSSF) Securing Critical Projects Working Group's List of Critical Projects[2]から派生した172のプロジェクトのリストを分析したところ、以下のことがわかった：
•       52% of the projects contain code written in a memory-unsafe language.	・プロジェクトの52%にメモリ非安全言語で書かれたコードが含まれている。
•       55% of the total lines of code (LoC) for all projects were written in a memory-unsafe language.	・全プロジェクトの総コード行数（LoC）の55％がメモリ非安全言語で書かれている。
•       The largest projects are disproportionately written in memory-unsafe languages. Of the ten largest projects by total LoC, each has a proportion of memory unsafe LoC above 26%. The median proportion using memory-unsafe languages across the ten projects is 62.5% and four of the ten project proportions exceed 94%.	・最大規模のプロジェクトは、メモリ非安全言語で書かれている割合が高い。LoCの合計が最も大きい10個のプロジェクトのうち、メモリ非安全なLoCの割合が26％を超えている。10プロジェクト全体のメモリ非安全言語を使用する割合の中央値は62.5%で、10プロジェクトのうち4プロジェクトの割合が94%を超えている。
•       Dependency analysis of three projects written in memory-safe languages demonstrated that each one depended on other components written in memoryunsafe languages.	・メモリ非安全言語で書かれた3つのプロジェクトの依存関係を分析したところ、それぞれのプロジェクトがメモリ非安全言語で書かれた他のコンポーネントに依存していることがわかった。
Hence, we determine that most critical open source projects analyzed, even those written in memory-safe languages, potentially contain memory safety vulnerabilities. This can be caused by direct use of memory-unsafe languages or external dependency on projects that use memory-unsafe languages. Additionally, low-level functional requirements to disable memory safety may create opportunities for memory safety vulnerabilities in code written in otherwise memory-safe languages. These limitations highlight the need for continued diligent use of memory safe programming languages, secure coding practices, and security testing.	したがって、分析したほとんどの重要なオープンソース・プロジェクトは、メモリ安全言語で書かれたものであっても、潜在的にメモリ安全の脆弱性を含んでいると判断される。これは、メモリ非安全言語を直接使用したり、メモリ非安全言語を使用するプロジェクトに外部依存したりすることによって引き起こされる可能性がある。さらに、メモリ安全を無効にするための低レベルの機能要件が、そうでなければメモリ安全な言語で書かれたコードに、メモリ安全の脆弱性を生む機会を作り出すかもしれない。これらの制限は、メモリ安全プログラミング言語の継続的な使用、安全なコーディングプラクティス、セキュリティテストの必要性を強調している。
We encourage additional efforts to understand the scope of memory-unsafety risks in OSS and continued discussion of the best approaches to managing and reducing this risk. These discussions should not only consider the risk reduction of a given approach, but also resource constraints, performance requirements, and direct and indirect costs of implementation. We note that while memory safety vulnerabilities are the most prevalent class of vulnerabilities, there is important work to be done to reduce other systemic classes of vulnerabilities.[3] Please read further recommendations to address memory safety in the joint document, The Case for Memory Safe Roadmaps and CISA’s Technical Advisory Council of CISA’s Cybersecurity Advisory Committee report on memory safety.	我々は、OSSにおけるメモリ非安全リスクの範囲を理解するためのさらなる努力と、このリスクを管理し低減するための最善のアプローチについての継続的な議論を奨励する。これらの議論は、与えられたアプローチのリスク低減だけでなく、リソースの制約、性能要件、実装の直接的・間接的コストも考慮すべきである。メモリ安全性の脆弱性は最も一般的な脆弱性のクラスであるが、他のシステム的なクラスの脆弱性を低減するために行うべき重要な作業があることに留意する[3]。メモリ安全に対処するための更なる推奨事項については、共同文書であるメモリ安全ロードマップの事例と、メモリ安全に関するCISAのサイバーセキュリティ諮問委員会の技術諮問委員会の報告書を参照されたい。

[1] Memory-unsafe languages used in this analysis are defined in Table 1.

[2] https://github.com/ossf/wg-securing-critical-projects/tree/main/Initiatives/Identifying-Critical-Projects.

[3] CVE-2022-44228 is an example of an impactful vulnerability that is outside the class of memory safety vulnerabilities: https://www.cisa.gov/news-events/news/apache-log4j-vulnerability-guidance.

参考されているメモリー安全ロードマップ...

・2023.12.06 The Case for Memory Safe Roadmaps

The Case for Memory Safe Roadmaps	メモリー安全ロードマップの事例
Why Both C-Suite Executives and Technical Experts Need to Take Memory Safe Coding Seriously	なぜ経営幹部も技術専門家もメモリー安全コーディングに真剣に取り組む必要があるのか？
The Case for Memory Safe Roadmaps: Why Both C-Suite Executives and Technical Experts Need to Take Memory Safe Coding Seriously details how software manufacturers can transition to memory safe programming languages (MSLs) to eliminate memory safety vulnerabilities. The guidance provides manufacturers steps for creating and publishing memory safe roadmaps that will show their customers how they are owning security outcomes, embracing radical transparency, and taking a top-down approach to developing secure products—key Secure by Design tenets.	メモリー安全ロードマップの事例： C-Suite Executiveと技術専門家の双方がメモリー安全コーディングに真剣に取り組む必要がある理由」では、ソフトウェア製造事業者がどのようにメモリー安全プログラミング言語（MSL）に移行し、メモリー安全性の脆弱性を排除できるかについて詳述している。このガイダンスでは、製造事業者がメモリ安全ロードマップを作成・公開するための手順を示している。このロードマップは、製造事業者がセキュリティの成果をどのように所有し、抜本的な透明性を受け入れ、セキュア・バイ・デザインの主要な信条であるトップダウン方式で安全な製品を開発しているかを顧客に示すものである。

・[PDF] The-Case-for-Memory-Safe-Roadmaps-508c

---

● まるちゃんの情報セキュリティ気まぐれ日記

Memory Safe, メモリー安全

・2023.10.18 Five Eyes、ドイツ、オランダ、ノルウェー、韓国、イスラエル、日本、シンガポール、チェコ他 セキュア・バイ・デザイン原則の改訂

・2023.09.18 米国 CISA オープンソース・ソフトウェア・セキュリティ・ロードマップ

・2023.08.14 米国 CISA他 情報提供依頼： オープンソースソフトウェア・セキュリティ： 長期的な重点分野と優先順位付け

・2023.04.15 CISA他 サイバーセキュリティリスクのバランスを変える：セキュリティ・バイ・デザインとセキュリティ・バイ・デフォルトの原則とアプローチ

・2022.05.07 NISTIR 8320 ハードウェア対応セキュリティ：クラウドおよびエッジ・コンピューティングのユースケースにおけるプラットフォーム・セキュリティへの階層型アプローチの実現

・2021.10.29 NISTIR 8320 (Draft) ハードウェア対応セキュリティ：クラウドおよびエッジ・コンピューティングのユースケースにおけるプラットフォーム・セキュリティへの階層型アプローチの実現（第二次ドラフト）