アカウント名:
パスワード:
char buf[BUFSIZE]; . . .
こういういいかげんな対応がバッファオーバーフローの元だという事に、たいがいで気付きましょう。 バッファから溢れた部分を切り捨てる場合でも、内部の処理によっては不正なコードの実行を許す温床と成り得ます。
「バッファが溢れる」という事象が確認できるのは、実際にデータを取って来てたり、データをコピーするというかなり下位の部分でしょ。 だけど、その対応はもっと上位の部分でたとえばセッション丸ごと捨てるとか、
失敗したようですね。 って言うかもうバグ治った? Slashcodeはサブジェクトが長すぎる場合、「溢れたら捨てる」という方法を無思慮に行っているの
そこら中に char buf[1024] などというコードが散乱していることが多い、というのが現状ではないでしょうか。
CPUが6811って言えば解る人には解る目的か?
でも、マジでヤバイんでAC
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
ハッカーとクラッカーの違い。大してないと思います -- あるアレゲ
質問形式でお送りします (スコア:3, おもしろおかしい)
A.不定長のデーターに対して下のようなコードを書くからです。
void func()
{
}
Q.何年も前からわかっていながら、なぜ対処しないのですか。
A.このようなコードを書いてある本が存在するからという説と
わざと入れているという説があります。
Q.信じられません。自分のプログラムに穴をあけるなんて。
A.一部のプログラマーは、これを指摘すると「仕様です」というので
間違いありません。意図的にやっているのです。
Q.彼らの目的は何なのですか。
A.考えてみてください。われわれの周りにどれほどコンピューターがあるか
DVDプレイヤー、カーナビ、携帯電話、自動販売機、パチンコ、ATM
これらを自由に操ってみたいと思いませんか。
実際には、パソコン以外には一般の人にはプログラムを作ることは許されていません。
Q.それはバックドアという犯罪なのではないですか
A.いいえ、問い詰められたら、バグということにします。
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を使って確保したバッフアーならreallocできます。
3の方法はプログラムがかなり複雑になります。本質ではない部分に多くの力を注がねばなりません。
Q.1はかっこ悪いし2は使えないし3は大変です。ほかに方法はありませんか
A.気づかなかったふりをして、チェックしないという方法をとる人もいます。
Q.最低ですね
A.世渡り上手と言ってください
Re:質問形式でお送りします (スコア:0)
ネタにマジレスするのは、礼儀です。
Q.ではどうしたらいいんでしょう?
A.パフォーマンスが落ちるからという理由で、たまたま知っているルーチンで処理をおこなうのがいけないのです。じっくり読み込んでいけば、バッファーオ
Re:質問形式でお送りします (スコア:0)
A.たとえば最初の例だとbuf[2][BUFSIZE]というようにバッフアーを二つとります。
そして、データを奇数バッフアー、偶数バッフアーの交互に読み取ります。
Q.なぜそんな面倒なことをするのですが
A.BUFSIZEで切断されたデーターの前後をみたいからです。たとえば2バイト文字コードのとか。分断されたキーワードとかです。圧縮されたデーターなどでは11bitとかの半端なビット長がまたがっていることもあります。
Q.文字列処理ばりばりのコンパイラならいざしらず、滅多にないようなデーターに対して、おおがかりすぎませんか。
A.そ
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に対するマイナスモデが無効な例を出してみる
Re:質問形式でお送りします (スコア:1)
(´д`;)
Re:質問形式でお送りします (スコア:0)
え?そんな人にCode書かせていいの?
Re:質問形式でお送りします (スコア:1)
まあでも入門書とかもあまり良いのがないような気がするな。
# バッファ長を考慮しない gets() や sprintf() がある
# というのも問題といえば問題かな?
(´д`;)
Re:質問形式でお送りします (スコア:0)
素直にポインタだけにしておけば自分で管理しなきゃならんって気がつくだろうに、あんな配列なんてBASICだのCOBOLだのから流れてきたやつはみんなしくじるよ。
Re:質問形式でお送りします (スコア:1)
#次はギガ単位でmallocしてNULL検査しない奴が増えそう。。。
wild wild computing
Re:質問形式でお送りします (スコア:0)
世の中のホールの半分くらいは、無知が原因なのではなくて
うっかりミスが原因でしょう。
自動的に strict な境界チェックするようなライブラリを
用意しない限り、この手の穴は防げません。
Re:質問形式でお送りします (スコア:0)
Re:質問形式でお送りします (スコア:0)
それはとらえ方が違うんじゃないか?
char buf[1024]
と
#define BUFSIZE 1024
char buf[BUFSIZE]
では大きく違うぞ。
前者は仕様変更があった場合に穴になりやすかろう。
(まさか違いがわからんとか言わないだろうな)
気安く動的確保すんな(喝 (スコア:1)
もともとメモリが少ない上に仮想メモリが存在しないんで、
ちょっとしたフラグメンテーションがすぐ動作不安定につながる。
こんな環境では、ヒープをスタック気味に使っていけるような
設計にせなあかん。
確保したメモリをいつでも再配置できるような設計にしてもいい
けど、こんなバイオレンスな設計が必要なほどデンジャラスな
仕事はハナから手をつけずに蹴り返すが吉。
大抵のゲームはリアルタイム性が要求されますからねぇ。
しかも、マルチプロセスの上にバックグラウンドでDMAが飛び交って
いるような最近の環境でそれやらかすのは自殺行為。
# ACなのでAC
Re:質問形式でお送りします (スコア:0)
不勉強なもので知らないが,Pascal系(またはALGOL系,または
Wirth系)の処理系は自動チェックのオプションがついている
ものが多い. これは言語仕様で規定されているのでは無い
Re:質問形式でお送りします (スコア:1)
BASIC とか。(Subject out of range エラーだったっけ?)
Re:質問形式でお送りします (スコア:0)
Re:質問形式でお送りします (スコア:0)
A.コンシューマーゲーム機はCPU速度、メモリ容量ともに非常に制限されており
エラーチェックルーチンなんぞ、入れる余裕がないからです。
ゲームの場合、ユーザー入力などほとんど無く、必要性も認められません。
#今回は起動時のBI
Re:質問形式でお送りします (スコア:1, 参考になる)
A.認めるわけではないのですが、気持ちはわかります。
たとえば近年発見されたBufferOverflowの例としては
zlib
libpng
Apple QuickTime ActiveX v5.0.2
Apple Quicktime/Darwin MP3 Broadcaster
IE4.0
など、本来は絵や音を取り扱うプログラムがあります。
これらのソフトにとってはバッフアーオーバーを起こした文字列処理の部分はまったく本質でないわけです。
そもそもBufferOverrunという報告書のもとになった事件はフィンランドのOUSPGグループが
Outlook ExpressとNetscape Messengerで長いファイル名のファイルを添付するというものでした。
手を抜いてはいけないのですが、手を抜きたくなる気持ちはわかります。
Q.でもSendMailなんかは、テキストを扱うプログラムですが、ひどいものですよ。
A.SendMailの歴史はセキュリティの歴史といっても過言ではないでしょう。BufferOverflowなんてSendMailには小さなことです。
でも、彼らを攻めないでください。必要以上に複雑になったあのプログラムをメンテし続けているというだけで私は頭が下がります。
Re:質問形式でお送りします (スコア:0)
悪事を働いたわけではありません。むしろその逆。
後から読むとOUSPGが悪いみたいに読めますね。失礼しました。
ワザとやった覚えがあるなぁ (スコア:0)
CPUが6811って言えば解る人には解る目的か?
でも、マジでヤバイんでAC
Re:質問形式でお送りします (スコア:0)
いや、実際にこういうコード書くヤツがいたりするから、マジで疑問なんだけど。
# 元ネタACさんを煽るつもりはない。
Re:質問形式でお送りします (スコア:0)
A.stdio.hぐらい読みましょう。
#include <stdio.h>はおまじないではありません。
Re:質問形式でお送りします (スコア:0)
そもそも、ps2 のようなゲーム機用の開発環境でも、
stdio.h は提供されているのですか?
個人的には、ゲーム機なら gets() のような
問題を多く含む関数は捨てるという意味で
stdio.h は提供しない方が、安全なゲームが生産されると思います。
Re:質問形式でお送りします (スコア:0)
(前略)
/* Default buffer size. */
#ifndef BUFSIZ
# define BUFSIZ _IO_BUFSIZ
#endif
(後略)
これがわからない人は、コーディングしない方がいいと思います。(もちろんその先は長いでしょうけれど。)stdio.hにはここしか出てきてませんよー
Re:質問形式でお送りします (スコア:0)
>stdio.h は提供されているのですか?
ありますよ。
サターン、プレステ、ドリキャス、PS2、すべてGNU-Cです。
普通のCにあるライブラリはすべて提供されてます。
PS2からはC++も提供されてます。(最適化がへぼいらしいけど)
任天堂は知りません。
Re:質問形式でお送りします (スコア:0)
「仕様か?」と問えば「バグです」と答える。
おいおい、プログラマーは嘘つき島の住人か。
プログラマーAとプログラマーBがいます。
一方が嘘つき島住人で一方は正直島住人です。
どちらのプログラマーがどちらの島の住人なのかは分か