オープンソースソフトウェアソースコードセキュリティ脆弱性分析レポート

——ブロックチェーン特集

国立インターネット緊急センター研究所
2016年10月

目次

1 概要……
2 テスト済みのオープンソースソフトウェア…………………………………………………………………………………………………………………………………… 2
3 テスト内容…… ...
3.1 セキュリティ脆弱性の種類…………………………………………………………………………………………………………. 4
3.2 セキュリティ脆弱性レベル………………………………………………………………………………………………………………. 6
4 オープンソースブロックチェーンソフトウェアプロジェクトのセキュリティ上の脆弱性…… ...
4.1 セキュリティ脆弱性の概要…………………………………………………………………………………………………… 7
4.2 高リスクのセキュリティ脆弱性の分布………………………………………………………………………………………….. 9
4.3 セキュリティ脆弱性の全体的な分布…… ...
5 本報告書に関する注記………………………………………………………………………………………………………………………… 15

1 概要

ソフトウェア技術の急速な発展により、オープンソースソフトウェアは世界中で広く使用されるようになりました。データによると、2012 年以降、商用ソフトウェアの 80% 以上がオープン ソース ソフトウェアを使用しています。オープンソース ソフトウェアのコードにセキュリティ上の問題が発生すると、必然的に広範囲にわたる深刻な影響が生じます。当研究所では、オープンソースソフトウェアのセキュリティ状況を把握するために、広く普及している著名なオープンソースソフトウェアのソースコードセキュリティ脆弱性分析を継続的に実施し、四半期ごとにセキュリティ脆弱性分析レポートを発行しています。

現在、ブロックチェーン技術は間違いなく科学技術と金融の分野で最もホットな新技術となっています。ブロックチェーン技術は、分散型かつ信頼のない方法で信頼性の高いデータベース（台帳）を共同で維持するためのソリューションです。ブロックチェーン技術は、その高い効率性、利便性、セキュリティにより、金融業界で広く注目を集めています。今年のワシントン国際金融年次会議で、連邦準備制度理事会はブロックチェーンが「支払い、清算、決済の分野における長年で最も重要な発展を表す可能性がある」とコメントした。

世界中の大手金融企業がブロックチェーン技術の分野に積極的に参入していると報じられています。大手の証券取引所や商品取引所は、試験や投資を通じてブロックチェーンを積極的に調査している。例えば、ナスダック取引所は昨年秋にブロックチェーンプロジェクト「Linq」を立ち上げた。ナスダックは昨年12月30日早くもブロックチェーン技術プラットフォームに基づく初の証券取引を完了した。私の国を含む世界中の中央銀行も、ブロックチェーン技術に関する研究や応用のパイロットを積極的に実施しています。今年1月、JPモルガン・チェース、シティグループ、ドイツ証券取引所グループなど世界トップクラスの投資銀行数社が、より効率的で安全なブロックチェーン関連の金融商品ポートフォリオの企画・構築を目指し、ブロックチェーンプロジェクトに共同投資した。さらに、バークレイズ銀行やクレディ・スイス・グループを含む世界のトップ銀行9行は、銀行業界でブロックチェーン技術を利用するための業界標準とプロトコルの開発を開始しています。 2017年までに、世界の銀行業界によるブロックチェーン技術開発への投資は10億米ドルを超え、すべてのエンタープライズソフトウェア分野の開発速度をリードすると予測されています。

今年6月、中国の代表者を含む90カ国の中央銀行や規制当局の代表者がワシントンの連邦準備銀行本部に集まり、ブロックチェーン技術の開発と応用について議論した。金融規制当局によってブロックチェーンの重要性が認識され、ブロックチェーンに対する世界的な関心が特定の機関に限定されなくなり、大規模な共同探究が始まっていることがわかります。ブロックチェーン技術のセキュリティは重要な懸念事項です。関連するソフトウェアに抜け穴があると、莫大な財産損失が発生します。

今四半期、ラボはブロックチェーン分野の有名なオープンソースソフトウェアに焦点を当てます。この脆弱性分析レポートは、脆弱性スキャン ツールと手動監査の結果を組み合わせて作成されました。この検出により、コード レベルで合計746の高リスクのセキュリティ脆弱性とセキュリティ リスクが見つかりました。結果から判断すると、オープンソースのブロックチェーン ソフトウェアには無視できない重大なセキュリティ リスクがあります。

2 オープンソースソフトウェアのテスト

研究室では、ユーザー数、注目度、更新頻度などを考慮して、代表的なブロックチェーンソフトウェア25を選定しました。表 1 に、この調査でテストされたオープンソース ブロックチェーン ソフトウェア プロジェクトの概要を示します。今回テストしたソフトウェアは、C、C++、Java、Python、PHPなどのプログラミング言語を網羅しています。これらのオープンソースソフトウェアプロジェクトは、国際的にも国内的にも知名度が高く、幅広いユーザーを抱えており、著名なソフトウェア企業によって開発されているものも多数あります。これらのソフトウェアのほとんどは資産や通貨の取引に関連しているため、抜け穴が発生すると、財産の損失という重大なリスクにつながる可能性があります。

表1 テストされたオープンソースソフトウェアプロジェクトの概要

1一般的に、プロジェクトの星の数が高いほど、開発者の注目度が高まり、影響力も大きくなると考えられています。



3 テスト内容

3.1 セキュリティ脆弱性の種類

このテストでは、さまざまな一般的なセキュリティの脆弱性をカバーします。セキュリティの脆弱性の原因、悪用される可能性、引き起こされる被害の程度、解決の難しさに基づいて、一般的なセキュリティの脆弱性は次の 9 つのカテゴリに分類できます。

1)入力の検証と表現

入力検証と表現の問題は、通常、特殊文字、エンコード、デジタル表現によって発生します。これらの問題は入力に対する信頼によって発生します。これらの問題には、バッファオーバーフロー、クロスサイトスクリプティング、SQL インジェクション、コマンドインジェクションなどが含まれます。

2) APIの不正使用

API は、呼び出し元と呼び出し先の間の合意です。ほとんどの API の不正使用は、呼び出し側が契約の目的を理解していないことが原因で発生します。 API が不適切に使用されると、セキュリティ上の問題も発生する可能性があります。

3)セキュリティ機能:このカテゴリには、主に認証、アクセス制御、機密性、パスワードの使用、権限管理における脆弱性が含まれます。

4)メモリ管理は、メモリ操作に関連する脆弱性のクラスを表す一般的な用語です。一般的な脆弱性には、メモリ リーク、解放後の使用、二重解放などがあります。このタイプの脆弱性は通常、システム パフォーマンスの低下、プログラムのクラッシュなどを引き起こします。これは、C/C++ 言語で一般的なタイプの脆弱性です。

5)時間と状態分散コンピューティングは時間と状態に関連しています。スレッドとプロセス間の相互作用やタスク実行の時間順序は、多くの場合、セマフォ、変数、ファイル システムなどの共有状態によって決まります。分散コンピューティングに関連する脆弱性には、競合状態、ブロッキングの誤用などがあります。

6)エラーおよび例外処理の欠陥 (エラー)このタイプの脆弱性は、エラーおよび例外処理に関連しています。最も一般的な脆弱性は、エラーが適切に処理されない (またはエラーが処理されない) ため、プログラムが予期せず終了することです。もう 1 つの脆弱性は、生成されたエラーによって潜在的な攻撃者に過剰な情報が提供されてしまうことです。

7)コードの品質

コードの品質が悪いと、予期しない動作が発生する可能性があります。攻撃者にとって、不適切に書かれたコードは予期しない方法でシステムを侵害する可能性があります。このカテゴリの一般的な脆弱性には、デッドコード、ヌルポインターの参照解除、リソース漏洩などがあります。

8)カプセル化と欠陥の隠蔽（カプセル化）適切なカプセル化とは、検証済みのデータと未検証のデータを区別すること、異なるユーザーのデータを区別すること、ユーザーが見ることができるデータと見られないデータを区別することなどを意味します。一般的な脆弱性には、隠しドメイン、情報漏洩、クロスサイトリクエストフォージェリなどがあります。

9)コード実行環境（環境）の欠陥このタイプの脆弱性は、実行環境の構成の問題、機密情報の管理の問題など、ソースコード外部の問題であり、製品のセキュリティにとって依然として重要です。

最初の 8 種類の脆弱性は、ソース コードのセキュリティ上の欠陥に関連しています。これらは悪意のある攻撃の標的になる可能性があり、悪用されると、情報漏洩、権限昇格、コマンド実行などの深刻な結果を引き起こす可能性があります。最後のタイプの脆弱性は、実際のコード外のセキュリティ問題を表し、ソフトウェアの動作異常やデータ損失などの深刻な問題を簡単に引き起こす可能性があります。

3.2 セキュリティ脆弱性レベル

ソース コードのセキュリティの問題は、高、中、低の 3 つのレベルに分類されます。レベルを測定する基準には、信頼性と重大度という 2 つの側面が含まれます。信頼度レベルは、見つかった問題が正確である可能性を示します。たとえば、すべての strcpy() 呼び出しをバッファ オーバーフローの脆弱性としてマークする信頼レベルは非常に低くなります。重大度は、テスト手法が本物であると仮定して検出された問題の重大度を指します。たとえば、バッファ オーバーフローは通常、ヌル ポインタの逆参照よりも深刻なセキュリティ問題です。これら 2 つの要素を組み合わせると、図 1 に示すように、セキュリティ問題のレベルを正確に分類できます。



図1 脆弱性レベル、深刻度、信頼度の関係

オープンソースブロックチェーンソフトウェアプロジェクトの4つのセキュリティ上の脆弱性

このセクションでは、まず、テストされたプロジェクトから検出されたセキュリティ脆弱性の数を示し、テストされたプロジェクトのセキュリティを大まかに評価します。次に、テストされたプロジェクトにおけるセキュリティ脆弱性の分布についてさらに議論し、プロジェクトで頻繁に発生し、見落とされがちなセキュリティ問題を理解します。

4.1 セキュリティ脆弱性の概要

高リスクおよび中リスクのセキュリティ脆弱性は被害の度合いが高く、ソフトウェアで緊急に対処する必要があるセキュリティ問題をより適切に反映できるため、このセクションでは、テスト対象プロジェクトで検出されたこれら 2 つのレベルの脆弱性を示し、テスト対象プロジェクトのセキュリティの大まかな評価を行います。図 2 は、テストされたプロジェクトで検出された中程度および高リスクのセキュリティ脆弱性を示しており、プロジェクトを脆弱性の数で並べ替えています。この図では、赤い折れ線グラフを使用して、1,000 行あたりの脆弱性の数も示しています 2。

2 1000行あたりの脆弱性数の計算方法：脆弱性の総数/コード行数*1000、小数点第2位までの精度

図2 オープンソースソフトウェアプロジェクトにおける高リスクの脆弱性

このことから、今回選定されたブロックチェーンソフトウェアは、いずれも程度の差はあれ、セキュリティ上の問題があることがわかります。このテストでは、これらのプロジェクトで合計 746 件の高リスクの脆弱性と 3,497 件の中リスクの脆弱性が見つかりました。脆弱性の数が多いプロジェクトは、攻撃者に悪用されやすい状態にあり、実際のユーザーは、パッチや更新バージョンをインストールして、緊急に修復およびアップグレードする必要があります。

テストされたすべてのソフトウェアの中で、ブロックチェーン決済ネットワークのリップルは全体的に比較的深刻なセキュリティリスクがあり、高危漏洞223が含まれています。このソフトウェアは、今回テストしたブロックチェーン関連のソフトウェアの中で最も有名で、最も広く使用され、最も広く使用されている可能性が高いことは注目に値します。報道によると、記事執筆時点で、このソフトウェアを所有する会社は、Google、Accentureなどから総額1億ドルの投資を受けているという。同時に、スタンダード・チャータード銀行、ウエストパック銀行、ナショナル・オーストラリア銀行、上海華瑞銀行など、いくつかの大手銀行が同社の決済ネットワークに参加すると発表した。このソフトウェアは金融資産を直接扱い、非常に多くのユーザーが利用していることを考えると、これらの脆弱性がハッカーに悪用されると、計り知れない損失が発生することになります。

全体的なセキュリティリスクで第 2 位にランクされているのは、ブロックチェーン ベースの分散アプリケーション プラットフォーム Ethereum の Java 実装であるEthereumjプロジェクトです。検出の結果、プロジェクトには110高リスクの脆弱性が含まれており、セキュリティ リスクが高いことがわかりました。

テストされたすべてのソフトウェアの中で、最も脆弱性が多いのは、ブロックチェーンベースの金融サービスソフトウェア BitShares です。最新バージョンには、高リスクの脆弱性 4 件と中リスクの脆弱性669を含む、中リスクおよび高リスクの脆弱性が 669 件含まれています。以前のバージョン (BitShares-0.x には 25 件の高リスクの脆弱性と 1,236 件の中リスクの脆弱性が含まれています) と比較すると大幅に改善されていますが、依然として重大なセキュリティ リスクが存在します。

脆弱性分布密度の点では、ブロックチェーン ブラウザ Bitcoin Block Explorer の脆弱性密度が最も高くなっています。このソフトウェアはコード行数がわずか 984 行と比較的小さいですが、平均するとコード行数 11 行ごとに 1 つの高リスクの脆弱性が存在します。なお、このソフトウェアは2015年9月以降は更新と実行が停止しており、現在はソースコードが主に学習や参照用に使用されている。不必要なセキュリティ リスクの導入を避けるため、このプロジェクト (Github スター 141 個) をフォローしている開発者は、そのコード内の潜在的なセキュリティ リスクに注意する必要があります。

テストされたすべてのソフトウェアの中には、Ethereum Wallet と Hlp-candidate (ブロックチェーン ベースのデジタル資産) という、高リスクの脆弱性を持たないソフトウェアが 2 つあります。さらに、デジタル資産および通貨取引プラットフォーム Omni の Java 実装である OmniJ には、リスクの高い脆弱性が 1 つだけあり、全体的なセキュリティは良好です。

4.2 高リスクのセキュリティ脆弱性の分布

このテスト中に、多数の高リスクの脆弱性が発見されました。図 3 は、テストされたプロジェクトにおける高リスクの脆弱性カテゴリの分布を示しています。データによると、ほとんどの脆弱性は「入力の検証と表現」の脆弱性であり、主にユーザー入力の検証が不十分なために発生します。攻撃者が悪意のある入力を作成すると、任意のコマンドの実行や任意のファイルの読み取りなど、重大なセキュリティ問題が発生する可能性があります。クロスサイトスクリプティングなどの従来の「入力検証と表現」の脆弱性に加えて、このタイプの脆弱性の発生率が高い理由の1つは、一部のJavaベースのブロックチェーンソフトウェア（Rippleなど）がJNIフレームワークと他の言語（C、C ++など）を使用してメモリなどのオペレーティングシステムリソースを直接操作し、Javaのメモリ保護メカニズムをバイパスし、プログラムがバッファオーバーフローなどの攻撃に対して脆弱になることです。

「コード品質の問題」の脆弱性も多数存在します。その主な理由は、開発者のセキュリティ意識が欠如しており、コードが標準化された方法で記述されていないことです。このような脆弱性は、メモリ オーバーフローやリソース枯渇などのセキュリティ リスクにつながる可能性があります。深刻な場合には、システムの動作異常やシステムクラッシュを引き起こす可能性があります。ブロックチェーンソフトウェアは金融分野などの重要なシステムで直接実行されることが多いため、システムがクラッシュすると耐え難いほどの大きな損失をもたらします。

「セキュリティ機能」の脆弱性も一定の割合を占めています。これらの脆弱性は主に、ID 認証、権限管理、パスワード管理などの問題に関係します。攻撃者はこれらの脆弱性を利用して不正アクセスを実行し、個人情報を盗む可能性があります。ブロックチェーン ソフトウェアにとって、暗号化はオープン データベース (台帳) 全体のセキュリティを維持するための中核機能です。しかし、このテストの結果によると、複数のソフトウェアに一定数の「安全でない乱数」の問題があり、ソフトウェアの暗号化攻撃に対する抵抗力が著しく低下することになります。

図 4 は、テストされたプロジェクトにおけるさまざまな特定の高リスクのセキュリティ脆弱性の分布をさらに示しています。テストされた 25 のプロジェクトの中で、最も一般的な 2 つのタイプの脆弱性は、安全でない JNI (16.22%、121) と安全でない乱数 (21.72%、162) でした。以下は、これら 2 つの脆弱性の簡単な説明と、いくつかの予防策の提案です。



図4 テスト対象プロジェクトにおける高リスクのセキュリティ脆弱性の分布（特定の脆弱性別）

1) 安全でない JNI (入力検証と表現の脆弱性)
Java アプリケーションが JNI を使用して他のプログラミング言語で記述されたコードを呼び出す場合、不適切な使用により、Java アプリケーションが他の言語のセキュリティ脆弱性に対して脆弱になる可能性があります。 Java にはメモリ保護メカニズムが用意されていますが、この保護メカニズムは、他の言語で記述され、Java Native Interface (JNI) を介してアクセスされるソース コードには適用されません。

予防: Java コードに含まれるネイティブ言語によって実行される操作を慎重にチェックし、厳密な入力検証を実行する必要があります。

2) 安全でない乱数（セキュリティ機能の脆弱性）セキュリティ要件が高い環境では、予測可能な値を生成できる機能をランダムデータソースとして使用すると、システムの暗号化攻撃に対する耐性が低下し、推測しやすいパスワード、予測可能な暗号化キー、セッションハイジャック攻撃、DNSスプーフィングなどの重大な脆弱性につながります。

防止策: 暗号疑似乱数ジェネレータを使用し、情報エントロピーが最大の情報を暗号疑似乱数ジェネレータのシードとして使用する必要があります。エントロピーが利用できない場合は、暗号疑似乱数ジェネレータの使用時にシードを変更することで脅威を軽減できます。

4.3 セキュリティ脆弱性の全体的な分布

上記の記事では、テストされたプロジェクトにおける高リスクの脆弱性の検出に基づいて、プロジェクトのセキュリティ状態を分析します。一般的に、中リスクおよび低リスクの脆弱性は、高リスクの脆弱性と比較して、実際の運用環境での害は比較的少ないですが、プロジェクトのコード品質と、開発者がコードセキュリティの問題に払う注意の度合いをある程度反映することができます。テスト対象プロジェクトのセキュリティ状態をより包括的に把握するために、このセクションでは、中リスクおよび低リスクの脆弱性を含む、すべてのレベルのセキュリティ脆弱性の全体的な分布をさらに示します。

図 5 は、テストされたプロジェクトにおけるセキュリティ脆弱性の主なカテゴリの分布を示しています。高リスクの脆弱性の分布と比較すると、コード品質の問題の割合が大幅に増加しています。具体的な脆弱性の種類を確認すると、プロジェクトには初期化されていない変数、未使用の変数や関数、デッドコード、ヌルポインターの判定の欠如などの問題が多数含まれていることがわかります。これは、これらのソフトウェアのコード品質を早急に改善する必要があることを示しています。このような問題は、直接的に重大なセキュリティ上の脆弱性につながることはありませんが、それでも明らかなセキュリティ上のリスクをもたらします。一度悪用されると、プログラムクラッシュなどの重大なリスクにつながる可能性もあります。コード品質の脆弱性が多数見つかった理由としては、今回テストしたプロジェクトの中にはまだ正式リリースされていない中間バージョンもあるため、コード自体がまだ安定した状態に達しておらず、不完全な「プロセスコード」が大量に残っていることが挙げられます。

さらに、プロジェクトには、文字列処理関数の安全でない使用、特定の API の戻り値の無視など、不適切な API 使用の問題が相当数あります。合意どおりに API を使用しないと、プログラム操作で予期しない例外が発生し、プログラム ロジックの正確性やシステムの安定性に影響を与える可能性があります。

高リスク脆弱性の分布と比較すると、「エラーおよび例外処理」の脆弱性が追加されました。具体的な脆弱性の種類を見てみると、「例外処理コード ブロックが空」や「過度に一般的な例外のキャプチャ」など、プロジェクトに一定の問題があることがわかります。これにより、プログラムは予期しない状況に正しく対応できなくなり、システムが脆弱で不安定になります。システム障害が発生すると、このようなずさんな例外処理により、障害の問題を追跡して解決することが困難になります。実際、システムに対するあらゆる攻撃は、開発者の想定に反する「異常」な状況です。特に、安定性と可用性に対する要件が極めて高い金融システムなどの業界では、システムのセキュリティと安定性を確保するために、適切なエラーおよび例外処理が必須条件となります。

図 6 は、テストされたプロジェクトにおけるさまざまな特定のセキュリティ脆弱性の分布をさらに示しています。検出結果には、「不適切な型変換」、「レガシーデバッグ情報」などのコード品質や API 使用に関する脆弱性など、発生回数が 10 回以下の中・低リスクの脆弱性が 87 件含まれていたことに留意する必要があります。データ表示の便宜上、図ではこれらをまとめて「その他」タイプの脆弱性として分類しています。テストされた 25 のプロジェクトの中で、最も一般的な 2 つの脆弱性は、未使用のローカル変数 (13.94%、1181) と安全でない文字列処理関数 (13.20%、1118) でした。以下は、これら 2 つの脆弱性の簡単な説明と、いくつかの予防策の提案です。

図5 テスト対象プロジェクトにおけるすべてのセキュリティ脆弱性の分布（主要カテゴリ別）

図6 テスト対象プロジェクトにおけるすべてのセキュリティ脆弱性の分布（特定のセキュリティ脆弱性別）

1) 未使用のローカル変数 (コード品質の脆弱性) ローカル変数は、コード内で宣言された後、使用されません。この問題は直接的な損害を引き起こすことはありませんが、通常は、コピー アンド ペースト エラーにより間違った変数が使用されたり、関連する変数割り当てステートメントが誤ってコメント アウトされたりするなど、コード作成プロセスに論理エラーが発生する可能性があることを意味します。

予防策: 開発者はコード ロジックの整合性と正確性を確認し、冗長な変数宣言を削除する必要があります。 2) 安全でない文字列処理関数 (API の誤用脆弱性に関連) C 言語の gets()、strcpy()、strcat()、sprintf()、scanf() など、一部の標準文字列処理関数は厳密な境界チェックを実行せず、重大なバッファ オーバーフローのリスクがあります。

予防策: これらの関数の使用をできるだけ避け、gets() を fgets() に置き換えるなど、より安全な代替関数を使用し、厳密な境界チェックを実行します。

5 このレポートに関する注記

1. このレポートでは、コードの観点からのみ脆弱性を分析します。このレポートでカウントされている脆弱性は、不適切なコード記述により攻撃者に悪用される可能性のあるセキュリティ リスクを指します。実際のシステムでは、実際のソフトウェア導入環境やセキュリティ機器などの制限により、侵入テストでは一部の脆弱性が検証されない場合があります。

2. このレポートの脆弱性は、表 1 に記載されている特定のソフトウェア バージョンにのみ適用されます。ソフトウェア バージョンの更新、変更、または最適化が行われると、このレポートは適用されなくなります。

3. このレポートは、360 Code Guard のデータによって部分的にサポートされており、感謝の意を表します。