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

コンパイラは現代のコンピュータシステムの基本的な構成要素の一つです。これは高級プログラミング言語をコンピュータが実行可能な命令に変換するプログラムです。開発者やセキュリティ専門家は通常、アプリケーションコードのセキュリティに注目しますが、コンパイラ自体のセキュリティも同様に重要です。

コンパイラはコンピュータプログラムとしてもセキュリティホールが存在する可能性があり、特定の状況下では深刻なセキュリティリスクをもたらすことがあります。例えば、ブラウザがJavaScriptコードを解析・実行する際に、JavaScriptエンジンの脆弱性が原因で、ユーザーが悪意のあるウェブページにアクセスする際に攻撃を受け、最終的には攻撃者が被害者のブラウザやさらにはオペレーティングシステムを制御することにつながる可能性があります。

Solidityコンパイラも例外ではありません。Solidity開発チームのセキュリティ警告によると、複数のバージョンのSolidityコンパイラにセキュリティの脆弱性が存在します。

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

Solidityコンパイラの脆弱性

Solidityコンパイラの役割は、スマートコントラクトコードをEthereum仮想マシン(EVM)命令コードに変換することです。これらのEVM命令は取引を通じてEthereumにパッケージされてアップロードされ、最終的にEVMによって実行されます。

Solidityコンパイラの脆弱性とEVM自体の脆弱性を区別する必要があります。EVMの脆弱性は、仮想マシンが命令を実行する際のセキュリティの脆弱性を指し、これはEthereumネットワーク全体に影響を与える可能性があります。一方、Solidityコンパイラの脆弱性は、SolidityをEVMコードに変換する際の問題を指します。

Solidityコンパイラの脆弱性はEthereumネットワークに直接影響を与えませんが、生成されたEVMコードが開発者の期待と一致しない可能性があります。スマートコントラクトは通常、暗号資産を含むため、コンパイラによって引き起こされるバグはユーザーの資産損失を引き起こす可能性があり、深刻な結果をもたらします。

監査契約のソースコードだけでは、コンパイラの脆弱性を見つけることは難しい。特定のコンパイラバージョンとコードパターンを組み合わせて分析する必要があり、そうすることで契約がコンパイラの脆弱性の影響を受けているかどうかを確認できる。

Solidityコンパイラの脆弱性の例

以下は、具体的な形式、原因、及び危害を示したいくつかの実際のSolidityコンパイラの脆弱性の例です。

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

この脆弱性は、古いバージョンのSolidityコンパイラ(>=0.1.6 <0.4.4)に存在します。

以下のコードを考慮してください:

ソリディティ コントラクトC { uint32 a = 0x12345678; uint32 b = 0; function run() は (uint256) { を返します。 a = a + 1; bを返す; } }

storage変数bは変更されておらず、run()関数はデフォルト値0を返すべきです。しかし、脆弱性のあるコンパイラバージョンでは、run()は1を返すことになります。

この期待に反する状況は、b変数が権限検証や資産の記録などに使用される場合、深刻な結果を引き起こす可能性があります。

この現象の原因は、EVMが32バイトサイズのスタック要素とストレージスロットを使用し、Solidityがuint32などの小さいデータ型をサポートしているためです。コンパイラはこれらの型を処理する際に上位ビットをクリアする必要がありますが、整数オーバーフローの際に正しく処理されず、結果として上位ビットの1がストレージに書き込まれ、b変数を上書きしました。

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を返します。

SOL-2022-6 AbiReencodingHeadOverflowWithStaticArrayCleanup

この脆弱性は、バージョン0.5.8以上0.8.16未満のコンパイラに影響を与えます。

以下のコードを考慮してください:

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

通常、このコードはa変数の値"aaaa"を返すべきです。しかし、脆弱性のあるバージョンでは空の文字列""が返されます。

これは、Solidityがcalldataタイプの配列に対してabi.encode操作を行う際に、特定のデータを誤ってクリアしたために、隣接するデータが変更され、エンコード・デコード後のデータが一致しなくなることが原因です。

Solidityは外部呼び出し中にabi.encodeを暗黙的に実行し、イベントを出力するため、このタイプの脆弱性の範囲は予想以上に広がる可能性があることに注意することが重要です。

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

セキュリティ提案

Solidityコンパイラの脆弱性脅威モデルの分析と過去の脆弱性の整理に基づいて、開発者とセキュリティ担当者に以下の提案を行います:

開発者向け###:

1. より新しいバージョンのSolidityコンパイラーを使用してください。新しいバージョンは通常、既知のセキュリティ問題を修正しています。

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

3. インラインアセンブリや複雑なABIのエンコードおよびデコードなどの操作は避けてください。ほとんどの歴史的な脆弱性はこれらの複雑な特徴に関連しています。

セキュリティスタッフへ:

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

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

3. コンパイラーの脆弱性について過度に心配する必要はありません。ほとんどの脆弱性は特定のコードパターンでのみ発生し、具体的な状況に応じて実際の影響を評価する必要があります。

実用リソース:

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

まとめ

この記事では、Solidityコンパイラの脆弱性の概念を紹介し、実際のEthereum開発において引き起こす可能性のあるセキュリティリスクを分析し、開発者やセキュリティ担当者に実用的なセキュリティアドバイスを提供します。コンパイラの脆弱性の特徴と影響を理解することで、スマートコントラクトの安全性をよりよく確保することができます。

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