Linux カーネルの zero-day exploit コード、リリースされる 34
ストーリー by reo
読売の記事になってるのがびっくりだ 部門より
読売の記事になってるのがびっくりだ 部門より
ある 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 として扱う開発陣の心理にも脆弱性がありそうです。
Re: (スコア:0)
Re:milw0rm (スコア:1)
#p01 削ったら見られた。
マクロの基本は検索置換(by y.mikome)
Re: (スコア:0)
Re: (スコア:0)
いつからクラッシュする欠陥まで DoS と呼ぶようになったのでしょうね．
DoS という言葉が出来た当初は，データの損失を伴いうる欠陥は 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系も注意ですね (スコア:1)
リンク先の情報、大変参考になります。ありがとうございました。一点、教えていただきたいことがあります。 NULL チェックの if 文が Optimized Out される問題 [kernel.org]についてメインに語られています。
もう一方の問題 [cr0.org]についても修正 [kernel.org]がバックポートされるのでしょうか？
Re:2.6.18 というとRedHatやCentOS系も注意ですね (スコア:3, 参考になる)
はい。CVE-2009-1895が影響する各プロダクトについて
修正がバックポートされ、errataとしてリリースされます。
https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2009-1895 [redhat.com]
Re:2.6.18 というとRedHatやCentOS系も注意ですね (スコア:1)
バグ？仕様？ (スコア:1, 参考になる)
と言うことは組み込みへの影響は…(Re:バグ？仕様？ (スコア:2, 興味深い)
これ、gccで-fno-delete-null-pointer-checksしてやらないと、ソースの書き方によっては同じようなexploitやDOSの可能性が出るということですよね？Linuxカーネルにやられるかかれ方のコードがあって、脆弱性が偶然見つかっただけで。
と言うことは、μITronやeCosやVxWorksのような比較的小規模な機械に良く使われているようなカーネルモードとかそういうのがない上にアプリ層をgccでコンパイルする事も多くなってる組み込み系のOS環境ではexploitなコードを突っ込むのが容易になるのでは（怖）
未だ、ハードウェアのMMUにメモリアクセス例外があって、ここのトラップから（元凶のアプリを殺して）回復するような作りのカーネルになってれば救われるし（トラップしたら全リセットだったりしたら立派なDoS…）、カーネルからアプリまで一緒にメモリ上に展開されてそれ以上ネイティブバイナリのアプリが動かないような作りであれば外部からコード突っ込まれる心配ないでしょうけど、下手に補助記憶上のアプリをforkして実行して実行が終わったら解放するような真似をしていたりして主記憶を節約していたりすると…あぁ、想像したくない…
このあおりで (スコア:0)
Linuxガラケ群がハックされてGNUになって俺大歓喜…にならないかな(・∀・)
Re:バグ？仕様？ (スコア:1, 興味深い)
良く分からないなぁ。
tun が NULL なら tun->sk を参照した時点で落ちるんじゃないの？
その時点で後ろの if ブロックが削られようが削られまいが何も問題ないと思うんだけど。
それとも sk のオフセットはメモリアクセスできちゃうエリアに到達するほど大きい値？
なら分からないでもないけど、それだとGCCの問題な気が・・・
Re:バグ？仕様？ (スコア:3, 参考になる)
>tun が NULL なら tun->sk を参照した時点で落ちるんじゃないの？
>その時点で後ろの if ブロックが削られようが削られまいが何も問題ないと思うんだけど。
gccもそう思って最適化しちゃうんだけど、mmapでメモリを割り当てていた場合、落ちずに処理が進む。
進んだときにおかしくなるデータをtun->sk(0x0+offsetof(sk))に仕込んどけはexploitになる。
上記の解説はちょっと変
>コンパイラは 'if' ブロックを外してしまい、カーネルは0x00000000にアクセスしようとし、
アクセスした後で NULLチェックしても常に偽と判断され最適化で消えちゃう、というべきか
Re:バグ？仕様？ (スコア:2)
>上記の解説はちょっと変
>>コンパイラは 'if' ブロックを外してしまい、カーネルは0x00000000にアクセスしようとし、
>アクセスした後で NULLチェックしても常に偽と判断され最適化で消えちゃう、というべきか
原文はまともです。翻訳するときに時間がなかったのでしょう。よくあることです
Re: (スコア:0)
すいません、自己解決。カーネルなら tun が NULL でも tun->sk を参照しても落ちるわけありませんね。
NULL 参照が許されるような環境でそんな最適化を行ってしまう GCC にも問題がある気がします。
どこが問題か考えるとちょっと複雑 (スコア:1, 興味深い)
シロウトの印象だと、必要な処理をすっ飛ばしちゃうGCCの最適化手法が
おかしいんだろうとは思うんですが、ソースコードベースで
ソフトウェアを公開するとなるとけっこうめんどくさい問題ですね、これ。
GCCの挙動がもし「仕様」（速いコードを吐く代わりに妙なところで命令を
すっ飛ばすことがある）だとしたら、コンパイラやコンパイルオプションを選んだ人にも
問題がないわけでもなく、でもそうすると「選んだ人」って誰ということにもなり、
あとはリリースエンジニアリング的なトコにもツッコミどころがあるのかなとか、
いろいろ考えられますよね。
でも少なくとも心情的には「コードが間違ってる」とは言いがたいなあ。
Re:どこが問題か考えるとちょっと複雑 (スコア:2)
通常のユーザープロセスで動かす分には、最近の環境ならNULLアクセスしたら大抵トラップ食らってプログラム終了ですから、そういう前提 (NULLアクセスしたらカーネルが止めてくれる) で最適化している可能性はあるかも。
カーネルコードとか組込み機器とかでは、そもそもNULLアクセスで止まる保証がないわけで、そんなところでGCCの最適化を盲目的に適用するのは危険という教訓になるんですかね。
Re: (スコア:0)
ヌル参照はANSI Cでは未定義になっているわけです。今回の話も仕様に従った正しい動作です。
gccの最適化により潜在的なバグが顕在化したということですから、gccを責めるのはお門違いです。
Re:バグ？仕様？ (スコア:1)
NULLでもカーネルなら落ちないから大丈夫です(キリッ
って感じのコードを書くのそもそもどうかと思うなー。
gccも悪いかもしれないけど、カーネルハカーももう少し注意してコードを書いてほしいと思う。
よくわからんから勘違いしているかもしれんけど、、、
なんかエラーでたけど @つけたら大丈夫でしたっていうphpプログラマや、
try{}catch(...){} で余裕でしたとかいう C++ プログラマーの香りがする。
#間違っていたら突っ込みください。あやまります。ごめんご。
by rti.
Re: (スコア:0)
ANSI CではNULL参照の動作は未定義だから(たぶん)、脆弱性を引き起こすのも仕様に合致している。
gccは悪くない、悪くないよ。
Macの優秀さが証明されました (スコア:1, おもしろおかしい)
皆さんWindowsやLinuxといった糞OSを捨ててMacを使って幸せになろう。
Re:Macの優秀さが証明されました (スコア:1, おもしろおかしい)
マジレスしたくなるが、さすがにこれはネタだろう。
#放置プレイ [google.co.jp]
Re: (スコア:0)
WindowsやLinuxの脆弱性関連のストーリーではお約束のネタなのです。
Re:Macの優秀さが証明されました (スコア:1, おもしろおかしい)
今回は「マックを使っても幸せになれない」というお話かと思います。
Re: (スコア:0)
むしろ、vc使ってビルドされているwindowsが安全という結論に。
Re: (スコア:0)
Windows はやっぱり VC でコンパイルされてるの？
Microsoft って頻繁に紺屋の白袴やってるけど
Re: (スコア:0)
Re: (スコア:0)
Re: (スコア:0)
Macユーザの大半が同じように思っているからMacを使う奴らをまともだと思えないんだ。
Macを所有したときに大変な目に逢ったのでAC
騒ぎすぎ (スコア:0)
というタイトルでlkmlに一連のパッチを投げてるが、
これすべてexploitの餌食だぜ。