reoによる
2009年07月22日 12時30分の掲載
読売の記事になってるのがびっくりだ部門より
読売の記事になってるのがびっくりだ部門より
ある Anonymous Coward 曰く、
Linux カーネルの脆弱性を突いた zero-day exploit がリリースされたそうだ (CNET Japan の記事、YOMIURI ONLINE の記事、本家 /. 記事より) 。
Brad Spengler 氏がリリースしたこのコードを利用すれば NULL ポインタデリファレンスの保護を突破し、root 権限を掌握することが可能という。さらにこのコードは SELinux や AppArmor、また Linux Security Module の監査機能を無効化することもできるとのことで、それらの機能が有効であるかのようにシステムに思い込ませることができるそうだ。この脆弱性は Linux カーネル 2.6.30 及び 2.6.18 にあり、32 ビット版と 64 ビット版共に影響を受けるとのことで、この zero-day exploit のデモ動画も公開されている。
なお、SANS Internet Storm Center でもこの脆弱性に関するレポートが確認できる。
2.6.30.2 で対策 (スコア:4, 参考になる)
19日にリリースされた 2.6.30.2 で対策されていました。2.6.18 系列へのバックポートはおそらく採用しているディストリビューションからリリースされているのでしょう。
commit 76f578b630347be522b6df7917013fd0712612e5
Author: Eugene Teo
Date: Wed Jul 15 14:59:10 2009 +0800
Add '-fno-delete-null-pointer-checks' to gcc CFLAGS
commit a3ca86aea507904148870946d599e07a340b39bf upstream.
Turning on this flag could prevent the compiler from optimising away
some "useless" checks for null pointers. Such bugs can sometimes become
exploitable at compile time because of the -O2 optimisation.
See http://gcc.gnu.org/onlinedocs/gcc-4.1.2/gcc/Optimize-Options.html [gnu.org]
An example that clearly shows this 'problem' is commit 6bf67672.
static void __devexit agnx_pci_remove(struct pci_dev *pdev)
{
struct ieee80211_hw *dev = pci_get_drvdata(pdev);
- struct agnx_priv *priv = dev->priv;
+ struct agnx_priv *priv;
AGNX_TRACE;
if (!dev)
return;
+ priv = dev->priv;
By reverting this patch, and compile it with and without
-fno-delete-null-pointer-checks flag, we can see that the check for dev
is compiled away.
call printk #
- testq %r12, %r12 # dev
- je .L94 #,
movq %r12, %rdi # dev,
Clearly the 'fix' is to stop using dev before it is tested, but building
with -fno-delete-null-pointer-checks flag at least makes it harder to
abuse.
コメントを書く
milw0rm (スコア:2, 参考になる)
一応、milw0rmへのリンクを投下しておきますね。
milwo0rm exploits [milw0rm.com]
# cc のオプションの -fno-stack-protector ってのが今回のミソかしら。
コメントを書く
Re:milw0rm (スコア:4, 参考になる)
わかる範囲で日本語にしてみましたので、こちらもどうぞ：
http://tamo.tdiary.net/20090719.html#p01 [tdiary.net]
mmap することで NULL でもクラッシュしないようにしているらしいですが、
mmap 下限を無視させる方法を、SELinux ありなし 2 種類用意してあるようですね。
SELinux ありのほうが簡単、というかデフォルトで mmap 下限制限なしになってることが多いとか。
また、exploit なしではすぐ単なる DoS として扱う開発陣の心理にも脆弱性がありそうです。
ここに署名はいません
コメントを書く
親コメント
2.6.18 というとRedHatやCentOS系も注意ですね (スコア:2)
たまたま会社で使ってたので見てみたらRedHat系はビンゴでした。
コメントを書く
Re:2.6.18 というとRedHatやCentOS系も注意ですね (スコア:5, 参考になる)
中のひとなのでコメント。
Red Hat Enterprise Linuxのカーネルでこの問題の影響を受けるバージョンは
RHEL5.4のベータに含まれるものだけです。
既に対策は済んでおり、RHEL5.4リリース時には修正されたものが出荷される予定です。
https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2009-1897#c5 [redhat.com]
コメントを書く
親コメント
Re:2.6.18 というとRedHatやCentOS系も注意ですね (スコア:3, 参考になる)
はい。CVE-2009-1895が影響する各プロダクトについて
修正がバックポートされ、errataとしてリリースされます。
https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2009-1895 [redhat.com]
コメントを書く
親コメント
バグ？仕様？ (スコア:1, 参考になる)
コメントを書く
と言うことは組み込みへの影響は…(Re:バグ？仕様？ (スコア:2, 興味深い)
これ、gccで-fno-delete-null-pointer-checksしてやらないと、ソースの書き方によっては同じようなexploitやDOSの可能性が出るということですよね？Linuxカーネルにやられるかかれ方のコードがあって、脆弱性が偶然見つかっただけで。
と言うことは、μITronやeCosやVxWorksのような比較的小規模な機械に良く使われているようなカーネルモードとかそういうのがない上にアプリ層をgccでコンパイルする事も多くなってる組み込み系のOS環境ではexploitなコードを突っ込むのが容易になるのでは（怖）
未だ、ハードウェアのMMUにメモリアクセス例外があって、ここのトラップから（元凶のアプリを殺して）回復するような作りのカーネルになってれば救われるし（トラップしたら全リセットだったりしたら立派なDoS…）、カーネルからアプリまで一緒にメモリ上に展開されてそれ以上ネイティブバイナリのアプリが動かないような作りであれば外部からコード突っ込まれる心配ないでしょうけど、下手に補助記憶上のアプリをforkして実行して実行が終わったら解放するような真似をしていたりして主記憶を節約していたりすると…あぁ、想像したくない…
--暮らしの中に修行あり。
blogはじめました。 [hatena.ne.jp]
コメントを書く
親コメント
Re:バグ？仕様？ (スコア:3, 参考になる)
>tun が NULL なら tun->sk を参照した時点で落ちるんじゃないの？
>その時点で後ろの if ブロックが削られようが削られまいが何も問題ないと思うんだけど。
gccもそう思って最適化しちゃうんだけど、mmapでメモリを割り当てていた場合、落ちずに処理が進む。
進んだときにおかしくなるデータをtun->sk(0x0+offsetof(sk))に仕込んどけはexploitになる。
上記の解説はちょっと変
>コンパイラは 'if' ブロックを外してしまい、カーネルは0x00000000にアクセスしようとし、
アクセスした後で NULLチェックしても常に偽と判断され最適化で消えちゃう、というべきか
コメントを書く
親コメント
Re:バグ？仕様？ (スコア:2)
>上記の解説はちょっと変
>>コンパイラは 'if' ブロックを外してしまい、カーネルは0x00000000にアクセスしようとし、
>アクセスした後で NULLチェックしても常に偽と判断され最適化で消えちゃう、というべきか
原文はまともです。翻訳するときに時間がなかったのでしょう。よくあることです
コメントを書く
親コメント
Re:どこが問題か考えるとちょっと複雑 (スコア:2)
通常のユーザープロセスで動かす分には、最近の環境ならNULLアクセスしたら大抵トラップ食らってプログラム終了ですから、そういう前提 (NULLアクセスしたらカーネルが止めてくれる) で最適化している可能性はあるかも。
カーネルコードとか組込み機器とかでは、そもそもNULLアクセスで止まる保証がないわけで、そんなところでGCCの最適化を盲目的に適用するのは危険という教訓になるんですかね。
コメントを書く
親コメント
Macの優秀さが証明されました (スコア:1, おもしろおかしい)
皆さんWindowsやLinuxといった糞OSを捨ててMacを使って幸せになろう。
コメントを書く