Solidityコンパイラの脆弱性解析と対策

コンパイラは現代のコンピュータシステムの基本コンポーネントの一つであり、その役割は高級プログラミング言語のソースコードをコンピュータが実行可能な命令コードに変換することです。ほとんどの開発者やセキュリティ担当者は通常アプリケーションコードの安全性に注目しますが、しばしばコンパイラ自体の安全性を無視します。実際、コンパイラはコンピュータプログラムの一種としても安全な脆弱性を持つ可能性があり、特定のシナリオでは深刻な安全リスクを引き起こすことがあります。

例えば、ブラウザがJavaScriptコードをコンパイルして実行する際、JavaScriptエンジンの脆弱性により、ユーザーが悪意のあるウェブページにアクセスすると、攻撃者がその脆弱性を利用してリモートコード実行を実現し、最終的に犠牲者のブラウザやオペレーティングシステムを制御する可能性があります。別の研究でも、C++コンパイラのバグがリモートコード実行などの深刻な結果を引き起こす可能性があることが示されています。

Solidityコンパイラにもセキュリティホールが存在します。Solidity開発チームのセキュリティ警告によると、複数のバージョンのSolidityコンパイラにセキュリティホールが存在します。Solidityコンパイラの役割は、スマートコントラクトコードをEthereum仮想マシン(EVM)の命令コードに変換することであり、これらの命令は最終的にEthereumにアップロードされ、EVMによって実行されます。

Solidityコンパイラの脆弱性とEVM自体の脆弱性を区別する必要があります。EVMの脆弱性は、仮想マシンが命令を実行する際に発生するセキュリティ問題を指し、Ethereumネットワーク全体に影響を与える可能性があります。一方、Solidityコンパイラの脆弱性は、SolidityをEVMコードに変換する際の問題を指し、直接的にEthereumネットワークに影響を与えることはありませんが、生成されたEVMコードが開発者の期待と一致しない原因となる可能性があります。

Solidityコンパイラの脆弱性の一つは、生成されたEVMコードがスマートコントラクト開発者の期待と一致しない可能性があることです。スマートコントラクトは通常、ユーザーの暗号通貨資産に関連しているため、コンパイラによって引き起こされるバグはユーザーの資産損失を引き起こし、深刻な結果をもたらす可能性があります。

開発者や監査人はしばしば契約のロジックや一般的なセキュリティ問題に重点を置きますが、コンパイラの脆弱性はコード監査で発見するのが難しいです。特定のコンパイラバージョンとコードパターンを組み合わせて分析する必要があり、そうでなければスマートコントラクトがコンパイラの脆弱性の影響を受けているかどうかを特定することができません。

! 【Solidityコンパイラの脆弱性解析と対策】(https://img-cdn.gateio.im/webp-social/moments-7d1e882c0b106528437910218bf21f82.webp)

以下は、いくつかの実際のSolidityコンパイラの脆弱性の例です:

1. SOL-2016-9 ハイオーダーバイトクリーンストレージ

この脆弱性は、古いバージョンのSolidityコンパイラ(>=0.1.6 <0.4.4)に存在します。次のコードを考えてください:

ソリディティ コントラクトC { uint32 a = 0x12345678; uint32 b = 0; 関数 f() public { a = a + 1; } パブリック ビュー run()関数は (uint32) { を返します。 bを返す; } }

理論的にはb変数は変更されていないため、run()関数は0を返すべきです。しかし、脆弱性のあるバージョンのコンパイラが生成したコードでは、run()は1を返します。これはEVMが32バイトサイズのスタック要素を使用し、Solidityがuint32などの小さいデータ型をサポートしているためです。コンパイラは処理中に上位ビットを(clean up)する必要がありますが、加算オーバーフロー時に正しく処理されず、上位ビットの1がb変数に書き込まれました。

2. SOL-2022-4 インラインアセンブリメモリ副作用

この脆弱性は、0.8.13から0.8.15バージョンのコンパイラに存在します。以下のコードを考慮してください:

ソリディティ コントラクトC { function f() public pure は (uint) { を返します。 アセンブリ { mstore(0, 0x42) } uint x; アセンブリ { x := mload(0) } xを返す; } }

コンパイラは最適化のために、一見無駄なメモリ書き込み操作を削除しますが、誤ってアセンブリブロックを跨いだメモリアクセスも最適化してしまいました。これにより、f()関数が正しい0x42ではなく0を返します。

3. SOL-2022-6 Abi再エンコーディングヘッドオーバーフローと静的配列クリーンアップ

この脆弱性は、0.5.8から0.8.16バージョンのコンパイラに影響します。次のコードを考えてください:

ソリディティ コントラクトC { 関数 f(string[1] calldata a) external pure は (string memory) { を返します。 abi.decode(abi.encode(a)、 (string[1]))[0]; } }

通常、この関数は入力された文字列を返すべきです。しかし、脆弱性のあるバージョンでは空の文字列を返します。これは、コンパイラーがcalldata配列をabiエンコードする際に、特定のデータを誤ってクリアしたため、エンコードとデコードされたデータが一致しなくなったからです。

! 【Solidityコンパイラの脆弱性解析と対策】(https://img-cdn.gateio.im/webp-social/moments-c97428f89ed62d5ad8551cdb2ba30867.webp)

Solidityコンパイラの脆弱性に対して、Coboブロックチェーンセキュリティチームは以下の提案を行いました:

開発者向け:

1. より新しいバージョンのSolidityコンパイラを使用すると、既知のセキュリティ問題が通常少なくなります。

2. ユニットテストケースを充実させる。ほとんどのコンパイラレベルのバグは、コードの実行結果が期待とは異なる原因となるため、テストカバレッジを向上させることでこのような問題を回避することができる。

3. インラインアセンブリや複雑なABIエンコード/デコードなどの操作を避け、新しい機能や実験的な機能を盲目的に使用しないでください。ほとんどのコンパイラの脆弱性は、これらの複雑な操作に関連しています。

セキュリティ担当者へ:

1. 監査時にコンパイラが引き起こす可能性のあるセキュリティリスクを無視しないでください。関連チェック項目はSWC-102: 古いコンパイラバージョンです。

2. 開発プロセスにおいて、開発チームにコンパイラのバージョンをアップグレードするよう促し、CI/CDにバージョン自動チェックを導入することができます。

3. コンパイラの脆弱性について過度に心配する必要はありません。ほとんどの脆弱性は特定のコードパターンでのみ発生し、プロジェクトに応じてセキュリティへの影響を評価する必要があります。

いくつかの実用的なリソース:

• Solidity公式セキュリティアラート:
• 公式のSolidityバグリスト:
• 各バージョンコンパイラのバグリスト:
• Etherscanの契約ページ右上隅にある警告マークは、現在のバージョンのコンパイラに存在するセキュリティ脆弱性を示すことができます。

! 【Solidityコンパイラの脆弱性解析と対策】(https://img-cdn.gateio.im/webp-social/moments-84f5083d8748f2aab71fd92671d999a7.webp)

要するに、開発者とセキュリティ担当者はSolidityコンパイラーの脆弱性がもたらす可能性のあるセキュリティリスクを重視し、リスクを低減するための適切な措置を講じて、スマートコントラクトの安全性を確保すべきです。