トレンドトピック
#
Bonk Eco continues to show strength amid $USELESS rally
#
Pump.fun to raise $1B token sale, traders speculating on airdrop
#
Boop.Fun leading the way with a new launchpad on Solana.
セキュリティを重視する Solidity 開発者として、これはチェックされていないブロックやインライン アセンブリを使用するときに非常に注意する必要があるサインです。
0.8.0以降では、コンパイラはアンダー/オーバーフローを自動的に処理します。しかし、オーバーフローを許可された変数が yul で使用されるとどうなりますか?
EVM には実際には狭い型の概念がないため、低レベルの yul コードは完全な 256 ビット ワード サイズで動作します。これがどこに向かっているのか、まだわかりますか?
現在の@CyfrinAuditsエンゲージメントで遭遇したこの非常に単純化されたシナリオでは、length変数はチェックされていないブロック内でuint8をサイレントにオーバーフローし、期待どおりに254にラップします。
ただし、後続のインラインアセンブリブロック内で配列のサイズを変更するために使用すると、ダーティな上位ビットは、オーバーフローが発生しなかったかのように保持されます。
これにより、配列の長さは、長さ変数で表される最大値をモジュロに制限されていると予想される場合でも、予想よりもかなり大きくなります。
ファウンドリデバッガとキャスト--to-base <0xfe|0x01fe>decを使用すると、仮定が正しくなく、長さをメモリに書き込むときに上位ビットが実際にダーティのままであることを確認できます。
この例はさらに単純化できますが、重要なポイントは、チェックされていない/アセンブリブロックを常に非常に疑い、割り当てのような単純なものであっても、狭い型の上位ビットがどのように汚れるかを考慮することです。
これは、EVM と Solidity コンパイラの内部に関する深い知識がなければ発見できない難解なバグのように感じることもあるので、何が起こっているのかを理解すると、この具体的な例が非常に役に立ちました。
ご質問がございましたら、以下にコメントをお寄せくださいが、お役に立てば幸いです。




7.75K
トップ
ランキング
お気に入り