【第23回】静的解析やルールチェッカーにできる事

再び、表を色分けしました。今回は静的解析ツールで見つけられそうなものを選びました。

オレンジ色の行は、攻撃者による危険性と言うよりも、そもそも不具合に近いものだろうと思います（CWE-20等は抽象度の高い脆弱性なので不具合と言えないものも含みます）。
プログラム上の不具合であれば、解析ツールやルールチェッカーで見つけられるかもしれません。

セキュリティ関連サイトによると、脆弱性の70%はメモリの安全性に起因するという情報もありますが、その点ではバッファ操作に関するチェックツールは効果的であると言えそうです。

その他の脆弱性の中で多いのは外部から与えられたデータの検証が不十分というものですが、この問題をルールチェッカーで見つけるのは難しそうです。かといって、テストで見つけようとしても、攻撃方法を思いつかなければ見つけられません。

脆弱性を防ぐのは注意深い設計なのだろうと思いますが、設計通りに作られているかどうかを確認するためであれば、テストだけでなく、静的解析ツールも役立つ可能性があります。

例えば、openからcloseまでの処理中に異常が発生しても、確実にclose処理を通るかという確認であれば、補助的な情報は静的解析から得られそうです。外部から与えられた情報が、その内容を検証する処理関数を確実に通過しているかどうかの確認もできそうです。安全ではないライブラリを使用している箇所も見つかります。

攻撃者は次々に新しい攻撃をしてきますので、先回りして防御するのは難しいです。過去の事例を忘れず、CWE等の情報サイトに気を配り、早めの対策を行うWindows Updateのようなメンテナンス活動が必要なのだろうと思います。

最近は脆弱性に配慮したコンパイルオプションを提供するコンパイラもあるようです。
例えばThe Linux Foundationに「CおよびC++のコンパイラ・オプション強化ガイド」という情報があります。

コンパイラはコード生成を行うので、マイコン特有の対策を行うことができるかもしれません。バージョンアップの際など、コンパイルオプションを再確認してみてください。

脆弱性対策は重要ですが、GAIO製だけでなく、他のCコンパイラも自身に関する脆弱性への配慮はあまりしていないと思います。しかし、身を守るテストを全くしていないわけでもありません。

Cコンパイラは、C言語ソースプログラムをバイナリファイルやアセンブリソースに変換する単純な構造のツールですが、コンパイラを攻撃するとしてどんな方法が考えられるでしょうか。

例えば、Cコンパイラにワードファイルやバイナリファイルを与えると、どうなるでしょうか。
山ほどコンパイルエラーが出ます。
それは当然なのですが、コンパイラが落ちたり、終わらなくなったりしたら、いけません。
コンパイラのテストでは、そんなこともしているはずです。GAIO製コンパイラも、開発当初はバイナリファイルを読んで見事に落ちました。

ありえないデータを与えるのも脆弱性の対策になるのではないかと思います。

今回の連続コラムではCWE Top 25 を中心に、脆弱性に関する話を聞いていただきました。
お付き合いいただき、ありがとうございました。