アカウント名:
パスワード:
これ、gccで-fno-delete-null-pointer-checksしてやらないと、ソースの書き方によっては同じようなexploitやDOSの可能性が出るということですよね?Linuxカーネルにやられるかかれ方のコードがあって、脆弱性が偶然見つかっただけで。
と言うことは、μITronやeCosやVxWorksのような比較的小規模な機械に良く使われているようなカーネルモードとかそういうのがない上にアプリ層をgccでコンパイルする事も多くなってる組み込み系のOS環境ではexploitなコードを突っ込むのが容易になるのでは(怖)
未だ、ハードウェアのMMUにメモリアクセス例外があって、ここのトラップから(元凶のアプリを殺して)回復するような作りのカーネルになってれば救われるし(トラップしたら全リセットだったりしたら立派なDoS…)、カーネルからアプリまで一緒にメモリ上に展開されてそれ以上ネイティブバイナリのアプリが動かないような作りであれば外部からコード突っ込まれる心配ないでしょうけど、下手に補助記憶上のアプリをforkして実行して実行が終わったら解放するような真似をしていたりして主記憶を節約していたりすると…あぁ、想像したくない…
Linuxガラケ群がハックされてGNUになって俺大歓喜…にならないかな(・∀・)
良く分からないなぁ。
struct sock *sk = tun->sk;
tun が NULL なら tun->sk を参照した時点で落ちるんじゃないの?その時点で後ろの if ブロックが削られようが削られまいが何も問題ないと思うんだけど。それとも sk のオフセットはメモリアクセスできちゃうエリアに到達するほど大きい値?
struct sock *sk = &tun->sk;
なら分からないでもないけど、それだとGCCの問題な気が・・・
>tun が NULL なら tun->sk を参照した時点で落ちるんじゃないの?>その時点で後ろの if ブロックが削られようが削られまいが何も問題ないと思うんだけど。
gccもそう思って最適化しちゃうんだけど、mmapでメモリを割り当てていた場合、落ちずに処理が進む。進んだときにおかしくなるデータをtun->sk(0x0+offsetof(sk))に仕込んどけはexploitになる。
上記の解説はちょっと変>コンパイラは 'if' ブロックを外してしまい、カーネルは0x00000000にアクセスしようとし、
アクセスした後で NULLチェックしても常に偽と判断され最適化で消えちゃう、というべきか
>上記の解説はちょっと変>>コンパイラは 'if' ブロックを外してしまい、カーネルは0x00000000にアクセスしようとし、>アクセスした後で NULLチェックしても常に偽と判断され最適化で消えちゃう、というべきか
原文はまともです。翻訳するときに時間がなかったのでしょう。よくあることです
すいません、自己解決。カーネルなら tun が NULL でも tun->sk を参照しても落ちるわけありませんね。NULL 参照が許されるような環境でそんな最適化を行ってしまう GCC にも問題がある気がします。
シロウトの印象だと、必要な処理をすっ飛ばしちゃうGCCの最適化手法がおかしいんだろうとは思うんですが、ソースコードベースでソフトウェアを公開するとなるとけっこうめんどくさい問題ですね、これ。
GCCの挙動がもし「仕様」(速いコードを吐く代わりに妙なところで命令をすっ飛ばすことがある)だとしたら、コンパイラやコンパイルオプションを選んだ人にも問題がないわけでもなく、でもそうすると「選んだ人」って誰ということにもなり、あとはリリースエンジニアリング的なトコにもツッコミどころがあるのかなとか、いろいろ考えられますよね。
でも少なくとも心情的には「コードが間違ってる」とは言いがたいなあ。
通常のユーザープロセスで動かす分には、最近の環境ならNULLアクセスしたら大抵トラップ食らってプログラム終了ですから、そういう前提 (NULLアクセスしたらカーネルが止めてくれる) で最適化している可能性はあるかも。
カーネルコードとか組込み機器とかでは、そもそもNULLアクセスで止まる保証がないわけで、そんなところでGCCの最適化を盲目的に適用するのは危険という教訓になるんですかね。
NULLでもカーネルなら落ちないから大丈夫です(キリッって感じのコードを書くのそもそもどうかと思うなー。gccも悪いかもしれないけど、カーネルハカーももう少し注意してコードを書いてほしいと思う。
よくわからんから勘違いしているかもしれんけど、、、なんかエラーでたけど @つけたら大丈夫でしたっていうphpプログラマや、try{}catch(...){} で余裕でしたとかいう C++ プログラマーの香りがする。#間違っていたら突っ込みください。あやまります。ごめんご。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
最初のバージョンは常に打ち捨てられる。
バグ?仕様? (スコア: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は悪くない、悪くないよ。