Linuxのカーネルに潜む脆弱性をつぶすパッチ

実例で学ぶ脆弱性対策コーディング 第5回

コンパイラの最適化と脆弱性にまつわる事例

　コンパイラの最適化に関する問題は2007年にgccのメーリングリストでも議論を呼びました。以下に当時の投稿を引用します（訳文は著者による）。

　最近興味深い問題に遭遇した。この問題、GNUARMのドキュメントでも触れておくべきではないだろうか。

 

　問題は、gccの最適化レベル2以上でコンパイルすると、一度ポインタの値を使用あるいはテストしたコードの後ろにおかれたNULLポインタのチェックが削除されてしまうというもの。ARM7のようなハードではハードウエア的にメモリ管理を行う仕組みが存在しないため、プログラムはエラーを報告することなく黙って終了してしまう。

 

　以下のコードをみてほしい。

void bad_code(void *a)
{
   int *b = a;
   int c = *b;
   static int d;

   if(b) {
      d = c;
   }
}

　-O2もしくはそれ以上でコンパイルすると、bの条件文はおそらく実行されないだろう（関数に0が渡されようが渡されまいが、d = cが必ず実行される）。

 

　オプティマイザがこのような動作をする理由は、bが最初に使用されるとき（"int c = *b"の行）、もしbの値がゼロであるならばハードウェアフォルトが発行されるはずであり、これに続くテストである"if(b)"は不必要であると仮定して削除するのである。

 

　以下のコンパイルフラグを使うとこの問題を防げる。

-fno-delete-null-pointer-checks

　ARM-7をターゲットに-O2以上でコンパイルする際は常にこのフラグを使う方が良いだろう。

 

出典：

subject: Compiler silently removes null pointer checks - msg#00003

List: gcc.cross-compiling.arm

URL: http://osdir.com/ml/gcc.cross-compiling.arm/2007-10/msg00003.html

オーバーフロー対策での事例

　未定義の動作とコンパイラの最適化の問題には、他にもセキュリティ上の問題につながった事例があります。例えば、

char *buf;
size_t len;

のような型宣言を行い、下記のようにポインタ演算を使ってオーバーフローのチェックを行うコードを書くとどうなるでしょうか。

len = 1<<30;
[...]
if(buf+len < buf) {/* ラップアラウンドのチェック  */
   /* オーバーフロー時の処理を行うコード  */
}

　C/C++では、ポインタと整数との加減算を行った結果は、元のポインタが指している配列のなかの、整数の値だけずれた位置を指しているものと解釈されます。上記コードではbufに非負の値を加算しているわけですから、buf + lenはbufが指しているアドレスよりもずっと先にあるアドレスを意味し、buf + len >= bufが成り立ちます。もし、この計算結果が指しているアドレスが配列の外にはみ出したら未定義の動作となってしまいますから、そのような状況を無視すれば、buf + len >= bufは常に成立し、if文による余計なチェックを削除するという最適化が可能になります。実際、gcc 4.2およびそれ以降のバージョンで上記のコードをコンパイルすると、if文のチェックは最適化により削除されてしまいます。

　このようなプログラマの意図に反する最適化を防ぐためには、

#include <stdint.h>
[...]
if((uintptr_t)buf+len < (uintptr_t)buf)
[...]

のようにオブジェクトの型をchar*というポインタ型からuintptr_tという符号無し整数型にキャストして、整数値の比較を行うコードにする手段があります。符号無し整数型の値に対しては、計算結果がその型で表現できないほど大きくなる場合はラップアラウンドした結果とする、ということが明確に規定されているからです（C99、セクション6.2.5）。なお、厳密に言うならば、uintptr_tはC99では省略可能とされており定義されていない処理系がありうること（C99、セクション7.18.1.4）、また、ポインタ型オブジェクトの表現を整数とみなしたものが単純にメモリアドレスの値になっているという前提はC99で保証されているわけではなく、あらゆるアーキテクチャで同じように動作するとは限らないことにご注意ください。

　コンパイラによる最適化は効率的なコードを得るために重要な機能ではありますが、同時に脆弱なプログラムを生み出してしまう危険もあるので注意が必要です。未定義の動作や処理系定義の動作となる状況にどのようなものがあるかを把握すると共に、自分が使用する処理系の振る舞いについて正しく理解しておくことが重要です。

参考情報

• EXP34-C. NULLポインタを参照しない
• CVE-2009-1897
• Barnaby Jack. Vector Rewrite Attack. May 2007
• Dan Goodin. Clever attack exploits fully-patched Linux kernel. The Register. July 2009.
• Making NULL-pointer reference legal
• Ilja van Sprundel. Unusual bugs
• JVNVU#162289: ある種の範囲チェックを破棄するCコンパイラの最適化の問題
• 情報処理推進機構：情報セキュリティ技術動向調査（2008 年上期） 10 C コンパイラの最適化の問題