アカウント名:
パスワード:
char buf[BUFSIZE]; . . .
} Q.何年も前からわかっていながら、なぜ対処しないのですか。 A.このようなコードを書いてある本が存在するからという説と わざと入れているという説があります。 Q.信じられません。自分のプログラムに穴をあけるなんて。 A.一部のプログラマーは、これを指摘すると「仕様です」というので 間違いありません。意図的にやっているのです。 Q.彼らの目的は何なのです
こういういいかげんな対応がバッファオーバーフローの元だという事に、たいがいで気付きましょう。 バッファから溢れた部分を切り捨てる場合でも、内部の処理によっては不正なコードの実行を許す温床と成り得ます。
「バッファが溢れる」という事象が確認できるのは、実際にデータを取って来てたり、データをコピーするというかなり下位の部分でしょ。 だけど、その対応はもっと上位の部分でたとえばセッション丸ごと捨てるとか、
失敗したようですね。 って言うかもうバグ治った? Slashcodeはサブジェクトが長すぎる場合、「溢れたら捨てる」という方法を無思慮に行っているの
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
吾輩はリファレンスである。名前はまだ無い -- perlの中の人
質問形式でお送りします (スコア:3, おもしろおかしい)
A.不定長のデーターに対して下のようなコードを書くからです。
void func()
{
}
Q.何年も前からわかっていながら、なぜ対処しないのですか。
A.このようなコードを書いてある本が存在するからという説と
わざと入れているという説があります。
Q.信じられません。自分のプログラムに穴をあけるなんて。
A.一部のプログラマーは、これを指摘すると「仕様です」というので
間違いありません。意図的にやっているのです。
Q.彼らの目的は何なのです
Re:質問形式でお送りします (スコア:3, すばらしい洞察)
このQAは表面しか見ていません。BUFSIZEを定義していることが、バッファーオーバーフローに直結するわけではありません。
問題はBUFSIZEを限界チェックをしていなことです。限界チェックをしないのなら、#defineする必要もないはずです。
BUFSIZEという形式だけを見て、その目的まで覚えなかった、学習者のミスです。
Re:質問形式でお送りします (スコア:3, おもしろおかしい)
A.サイズをチェックするのは、みんな気がついている思います。問題はその後です
Q.scanfを使うなとか fgets(buf,BUFSIZE,fp)ですか
A.それほど簡単な問題ではありません。bufに収まらなかった時の処理が必要です。
Q.それはどんなものがありますか
A.
1.切り捨てる
2.さらに大きなバッフアーを確保する
3.ループで順次処理する
1の切り捨てるのは乱暴なようですが、背に腹は代えられません。
2の方法はmallocを使って確保
Re:質問形式でお送りします (スコア:0)
ネタにマジレスするのは、礼儀です。
Q.ではどうしたらいいんでしょう?
A.パフォーマンスが落ちるからという理由で、たまたま知っているルーチンで処理をおこなうのがいけないのです。じっくり読み込んでいけば、バッファーオ
Re:質問形式でお送りします (スコア:0)
A.たとえば最初の例だとbuf[2][BUFSIZE]というようにバッフアーを二つとります。
そして、データを奇数バッフアー、偶数バッフアーの交互に読み取ります。
Q.なぜそんな面倒なことをするのですが
A.BUFSIZEで切断されたデーターの前後をみたいからです。たとえば2バイト文字コードのとか。分断されたキーワードとかです。圧縮されたデーターなどでは11bitとかの半端なビット長がまたがっていることもあります。
Q.文字列処理ばりばりのコンパイラならいざしらず、滅多にないようなデーターに対して、おおがかりすぎませんか。
A.そういうことであれば、c++にしてクラスライブラリを使うとか、perlやrubyで前処理をするとか、cを離れて考えましょう。
Q.組み込み機器にはそんなもの走りませんが
A.なら、BUFSIZEを超えたデーターは捨てましょう。たいしたものではないんでしょう。
Q.mallocとreallocの組み合わせに対して人気がないのはなぜでしょう。
A.かっこ悪いからです(ウソ)。これらの関数はメモリー確保ができなかったときのことを考えなければなりません。それはそれでめんどうです。
Q.1文字づつ処理すれば悩まないのでは
A.速度上の問題がなければそれはそれで問題ありません。実際にバッフアー処理だけを行って1文字ずつ取り出すライブラリもあります。
Q.速度を考えて処理をわけて考えたらだめですか。たとえば、大きなときはヒープにとるとか。
A.同じ処理を違う箇所でやることになってバグの危険性大です。将来、片方だけしか修正しないということが起こりえます。
滅多にないデーターに対してチェックが甘くなったりしないでしょうか。
しかも、例外的にmallocをつかうのであれば、悪いところをすべて集めたようなプログラムになってしまいます。
Re:質問形式でお送りします (スコア:0)
>A.なら、BUFSIZEを超えたデーターは捨てましょう。たいしたものではないんでしょう。
こういういいかげんな対応がバッファオーバーフローの元だという事に、たいがいで気付きましょう。
バッファから溢れた部分を切り捨てる場合でも、内部の処理によっては不正なコードの実行を許す温床と成り得ます。
Re:質問形式でお送りします (スコア:1, 参考になる)
たとえば組み込み機器で考えると、携帯PDA端末なんかであれば以下のような攻撃が予想されます
1.ping of deathのような場合
巨大なパケットを意図して送ってきてますから返事を返さなくていいです。
2.mp3プレイヤーなどで曲名に異様に長い曲名が入っている場合。
十分な長さが確保できていれば、曲名が途中で切れていても文句は出ないでしょう。
3.WEBブラウザーでhttpヘッダーがとんでもなく長い場合
捨てたデーターの中に大事なものがあるかもしれません。
プログラムを中断して「このページは表示できません」というエラーを出すべきでしょう。
必死にがんばって何が何でも処理することがよいこととは限らないです。
要は「たとえ死んでも悪の手先にはならない。」ということでは。
Re:質問形式でお送りします(溢れたら捨ててしまいまし (スコア:0)
・・・切れなかったらどうしよう・・・
↓切られる前のタイトル
Re:質問形式でお送りします(溢れたら捨ててしまいましょうよ。どうせたいした物じゃないんだし
明示的に「溢れたら捨てる」のはいい加減でも何でもないですよ。
Re:質問形式でお送りします (スコア:0)
「バッファが溢れる」という事象が確認できるのは、実際にデータを取って来てたり、データをコピーするというかなり下位の部分でしょ。
だけど、その対応はもっと上位の部分でたとえばセッション丸ごと捨てるとか、
Re:質問形式でお送りします (スコア:0)
Re: 質問形式でお送りします(溢れたら捨ててしまいま (スコア:0)
失敗したようですね。
って言うかもうバグ治った?
Slashcodeはサブジェクトが長すぎる場合、「溢れたら捨てる」という方法を無思慮に行っているの
本日のつぼ (スコア:0)
# とACに対するマイナスモデが無効な例を出してみる