冒頭にあるコメントをざっと読んでみた。 ざっとこんな感じ。
ソースを見ただけでは unexploitable に見える vulnerability だよ! GCC の最適化のおかげで exploitable になっちゃった :) それと、SELinux の vulnerability で mmap_min_addr 回避! (SELinux を有効にしてると、カーネルのいろんな脆弱性でリスクが増えちゃうんだね)
2007 年の Cheddar Bay は、不可能を可能に、つまり null ptr dereference を 任意コードの実行に直結させ、SELinux も LSM も完膚なきまでに無効化する 初めての exploit だった! それから 2 年、その屈辱からメインラインに 加えられた null ptr dereference protection には 3、4 の脆弱性が発見され、 カーネル開発者たちは脆弱性をこっそり修正するのが標準手続きになっており、 どこまでを distro kernels や stable tree にバックポートする必要があるのか 自分たちでも混乱するようになっていた。Linux セキュリティのこうした 目覚ましい進歩がある今、Cheddar Bay 作者が何を繰り出すというのか。
という感じで始まり、null ptr dereference protection の回避方法、 trojan data の注入と実行、そして広がる可能性と話は続く。 それから各種情報源に謝辞(null ptr dereference protection bypass はまだあるらしい)。
Greets to Julien Tinnes & Tavis Ormandy for the null ptr dereference protection bypass (of which there are more ;) ) 5th time's the charm? :) also of course to pipacs for helpful ideas and for pointing out the fix for this bug that screamed of suspiciousness ;) also to cloud for the wonderful crab also to #social for being social and to emoflip (under duress so he doesn't stab me next month) to xorl.wordpress.com in the hopes that he reports more on silently fixed Linux kernel vulnerabilities :) funtimeinternet for the curse of Cheddar Bay: http://www.youtube.com/watch?v=l--BvXpaGq4 Be sure to check out the response videos (which funtimeinternet called "AWESOME"): http://www.youtube.com/watch?v=UdkpJ13e6Z0 http://www.youtube.com/watch?v=P7uyCMdAldM Finally to sgrakkyu for his two incredible exploits and nice email chats (and for making me realize the more interesting compiler issue here ;)) http://kernelbof.blogspot.com disabling SELinux remotely with a single dword write is just classy ;)
そして Linux カーネルの時系列。
この vulnerability を引き起こした commit (Feb 6th):
2.6.29 リリースの前に commit されてるけど、(ありがたいことに)2.6.29 には入らなかった。初出現は 2.6.30。
null ptr dereference クラッシュが April 9th に出現:
このバグ commit が RHEL5 test kernel にバックポートされたのが April 15th (この exploit が公表されなかったら次の RedHat kernel update に入ってただろうね)
修正は July 6th:
これを見るとわかるが、問題は NULL な tun 変数で、こいつは直後に if(!tun) チェックがあるから、ソース上では unexploitable なはずだ。 tun->sk の dereference はクラッシュするだけのはず(NULL を mmap してあればクラッシュしないけど)。 じゃあどうしてこのバグが exploitable だったのか、そしてコードを一行ずらしただけで修正されたのか? それは、tun ポインタが !tun チェックの前にもう使用されているので、コンパイラ側で 「tun が NULL だったらもう fault が発生してるはずだから、チェックしなくていいよね」と想定するから。 だから実は、コンパイル済みコードに !tun チェックは存在しない。 ふつうはこれでも大丈夫、だけど NULL に何かが map されてたりしたらアウトというわけ。 それで fix は tun の dereference を !tun チェックの後に持っていっているんだね。 こうすれば !tun チェックは実際にコードに存在するし、vulnerability/exploitability も消える。 この種の問題はこっちに参照資料がある:
こういう、「知らないとソースレベルでは発見不可能な、しかし将来 exploitable になるタイプの脆弱性」 をなくすために、カーネルは -fno-delete-null-pointer-checks を付けてコンパイルするべきだ。
これを書いている時点で、上記の fix は存在しているものの、 おそらく -stable リリースには入らないだろう(少なくとも、この exploit が公開するまでは)。 というのも、Linux kernel development circles によれば「脆弱性が存在せず、単に DoS バグを粛々と直しただけ」だから。 だれもバグを正しく classify する気がなかったり、本気で脆弱性の impact を見極める努力をしなかったり (で、根拠もなく何でも DoS と呼んだり)すると、maintainers さえ何を "stable" kernels に含めるべきかわからず、 結局ユーザを vulnerable なままにして、attackers を こういう beautiful で 100% reliable な vulnerabilities 使い放題なままにしてしまう。
あとは Linus Torvalds が PAE 懐疑派で……とかいう話と、 exploit に対する開発者たちの反応が続き、 本人に何も聞かずにコソコソやってるのを批判したりしてる。
PS では、「exploit も書いたことのないオッサンたちじゃなくて sgrakkyu や Julien みたいなのを雇いなよ」 とか、「public exploit がなければ何でも DoS って呼ぶのはもうやめようぜ」というようなことが書いてある。
cheddar bay って何のことなんだろ。http://www.kotaro269.com/archives/50830003.html を観てもよくわからん。まあどうでもいいけど