パスワードを忘れた? アカウント作成
この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。

プレステ2の自由利用を可能にするバッファオーバフロー」記事へのコメント

  • 質問形式でお送りします (スコア:3, おもしろおかしい)

    by Anonymous Coward on 2003年08月17日 13時45分 (#380384)
    Q.なぜバッフアーオーバーフローがおこるのですか
    A.不定長のデーターに対して下のようなコードを書くからです。
    void func()
    {

    char buf[BUFSIZE];
    .
    .
    .

    }
    Q.何年も前からわかっていながら、なぜ対処しないのですか。
    A.このようなコードを書いてある本が存在するからという説と
    わざと入れているという説があります。
    Q.信じられません。自分のプログラムに穴をあけるなんて。
    A.一部のプログラマーは、これを指摘すると「仕様です」というので
    間違いありません。意図的にやっているのです。
    Q.彼らの目的は何なのですか。
    A.考えてみてください。われわれの周りにどれほどコンピューターがあるか
    DVDプレイヤー、カーナビ、携帯電話、自動販売機、パチンコ、ATM
    これらを自由に操ってみたいと思いませんか。
    実際には、パソコン以外には一般の人にはプログラムを作ることは許されていません。
    Q.それはバックドアという犯罪なのではないですか
    A.いいえ、問い詰められたら、バグということにします。
    • by Anonymous Coward on 2003年08月17日 18時43分 (#380438)
      反論:
      このQAは表面しか見ていません。BUFSIZEを定義していることが、バッファーオーバーフローに直結するわけではありません。
      問題はBUFSIZEを限界チェックをしていなことです。限界チェックをしないのなら、#defineする必要もないはずです。
      BUFSIZEという形式だけを見て、その目的まで覚えなかった、学習者のミスです。
      親コメント
      • by Anonymous Coward on 2003年08月17日 21時14分 (#380474)
        Q.ネタにマジレスされてますがどうしましょう。
        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.世渡り上手と言ってください
        親コメント
        • ネタにマジレスしたACです。
          ネタにマジレスするのは、礼儀です。

          Q.ではどうしたらいいんでしょう?
          A.パフォーマンスが落ちるからという理由で、たまたま知っているルーチンで処理をおこなうのがいけないのです。じっくり読み込んでいけば、バッファーオ
          • Q.ダブルバッフアーってなんですか
            A.たとえば最初の例だとbuf[2][BUFSIZE]というようにバッフアーを二つとります。
            そして、データを奇数バッフアー、偶数バッフアーの交互に読み取ります。
            Q.なぜそんな面倒なことをするのですが
            A.BUFSIZEで切断されたデーターの前後をみたいからです。たとえば2バイト文字コードのとか。分断されたキーワードとかです。圧縮されたデーターなどでは11bitとかの半端なビット長がまたがっていることもあります。
            Q.文字列処理ばりばりのコンパイラならいざしらず、滅多にないようなデーターに対して、おおがかりすぎませんか。
            A.そ
            • >Q.組み込み機器にはそんなもの走りませんが
              >A.なら、BUFSIZEを超えたデーターは捨てましょう。たいしたものではないんでしょう

              こういういいかげんな対応がバッファオーバーフローの元だという事に、たいがいで気付きましょう。
              バッファから溢れた部分を切り捨てる場合でも、内部の処理によっては不正なコードの実行を許す温床と成り得ます。

              • by Anonymous Coward on 2003年08月18日 19時17分 (#380773)
                捨てるというのは、それほど悪い対処方法ではないです。

                たとえば組み込み機器で考えると、携帯PDA端末なんかであれば以下のような攻撃が予想されます

                1.ping of deathのような場合
                 巨大なパケットを意図して送ってきてますから返事を返さなくていいです。
                2.mp3プレイヤーなどで曲名に異様に長い曲名が入っている場合。
                 十分な長さが確保できていれば、曲名が途中で切れていても文句は出ないでしょう。
                3.WEBブラウザーでhttpヘッダーがとんでもなく長い場合
                 捨てたデーターの中に大事なものがあるかもしれません。
                プログラムを中断して「このページは表示できません」というエラーを出すべきでしょう。

                必死にがんばって何が何でも処理することがよいこととは限らないです。
                要は「たとえ死んでも悪の手先にはならない。」ということでは。
                親コメント
              • 溢れたら捨てるタイプの処理でよく見かける例を、タイトルに実例として挙げておきました。
                ・・・切れなかったらどうしよう・・・

                ↓切られる前のタイトル
                Re:質問形式でお送りします(溢れたら捨ててしまいましょうよ。どうせたいした物じゃないんだし

                明示的に「溢れたら捨てる」のはいい加減でも何でもないですよ。
              • #380737のACですが、何かカン違いなコメントが付いてるみたいなので補足しておく。

                「バッファが溢れる」という事象が確認できるのは、実際にデータを取って来てたり、データをコピーするというかなり下位の部分でしょ。
                だけど、その対応はもっと上位の部分でたとえばセッション丸ごと捨てるとか、

              • ずるいなあ。(笑)
              • >溢れたら捨てるタイプの処理でよく見かける例を、タイトルに実例として挙げておきました。

                失敗したようですね。
                って言うかもうバグ治った?
                Slashcodeはサブジェクトが長すぎる場合、「溢れたら捨てる」という方法を無思慮に行っているの

            • by Anonymous Coward
              ダブルバッファーにしとけば、莫迦でも読み取り長さ指定して、バッファー切り替えしとくだろ。ダブルバッファーで読み取り長さ指定しないようなのは、莫迦以前だ。病気だ。

              # とACに対するマイナスモデが無効な例を出してみる
      • ていうか、C言語は配列の限界のチェックを自分でしなければならない言語だということが分かっていないだけでは?
        --
        (´д`;)
        親コメント
        • > ていうか、C言語は配列の限界のチェックを自分でしなければならない言語だということが分かっていないだけでは?

          え?そんな人にCode書かせていいの?
          • 書かせているからこのたぐいのバグが残ったままのコードが世に出るのでは?

            まあでも入門書とかもあまり良いのがないような気がするな。

            # バッファ長を考慮しない gets() や sprintf() がある
            # というのも問題といえば問題かな?
            --
            (´д`;)
            親コメント
            • C言語の失敗は、中途半端に配列の概念を定義したことだと思うな。
              素直にポインタだけにしておけば自分で管理しなきゃならんって気がつくだろうに、あんな配列なんてBASICだのCOBOLだのから流れてきたやつはみんなしくじるよ。
              • バッファは全部動的確保しろってか?

                #次はギガ単位でmallocしてNULL検査しない奴が増えそう。。。
                --
                wild wild computing
                親コメント
              • 無知に原因のすべてを押しつけるのはちょっと無理があります。
                世の中のホールの半分くらいは、無知が原因なのではなくて
                うっかりミスが原因でしょう。
                自動的に strict な境界チェックするようなライブラリを
                用意しない限り、この手の穴は防げません。
              • セキュリティ関連のタレコミを多くしている者でさえこのコメント [srad.jp]で、
                そこら中に char buf[1024] などというコードが散乱していることが多い、というのが現状ではないでしょうか。
                などと、固定長領域を確保すること自体がいけないかのようなことを書いている有様だしねえ。
              • >固定長領域を確保すること自体がいけないかのようなことを

                それはとらえ方が違うんじゃないか?

                char buf[1024]

                #define BUFSIZE 1024
                char buf[BUFSIZE]
                では大きく違うぞ。

                前者は仕様変更があった場合に穴になりやすかろう。
                (まさか違いがわからんとか言わないだろうな)
              • 逆に却下。
                もともとメモリが少ない上に仮想メモリが存在しないんで、
                ちょっとしたフラグメンテーションがすぐ動作不安定につながる。
                こんな環境では、ヒープをスタック気味に使っていけるような
                設計にせなあかん。

                確保したメモリをいつでも再配置できるような設計にしてもいい
                けど、こんなバイオレンスな設計が必要なほどデンジャラスな
                仕事はハナから手をつけずに蹴り返すが吉。
                大抵のゲームはリアルタイム性が要求されますからねぇ。
                しかも、マルチプロセスの上にバックグラウンドでDMAが飛び交って
                いるような最近の環境でそれやらかすのは自殺行為。
                --


                # ACなのでAC
                親コメント
        • 配列の限界のチェックを自分でしなくてもいい言語というのは
          不勉強なもので知らないが,Pascal系(またはALGOL系,または
          Wirth系)の処理系は自動チェックのオプションがついている
          ものが多い. これは言語仕様で規定されているのでは無い
    • LSB が標準から gets() 落したら、POSIX が文句つけたってのが最近あったな。
    • Q.なぜバッフアーオーバーフローがおこるのですか?
      A.コンシューマーゲーム機はCPU速度、メモリ容量ともに非常に制限されており
      エラーチェックルーチンなんぞ、入れる余裕がないからです。
      ゲームの場合、ユーザー入力などほとんど無く、必要性も認められません。

      #今回は起動時のBI
      • by Anonymous Coward on 2003年08月18日 13時43分 (#380654)
        Q.やはり出ましたね。環境に責任を押し付けてしまう人。
        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には小さなことです。
        でも、彼らを攻めないでください。必要以上に複雑になったあのプログラムをメンテし続けているというだけで私は頭が下がります。
        親コメント
        • OUSPGの名誉のためにつけくわえておきますが、告発したのが彼らであって、
          悪事を働いたわけではありません。むしろその逆。
           後から読むとOUSPGが悪いみたいに読めますね。失礼しました。
    • それも上司の命令で。

      CPUが6811って言えば解る人には解る目的か?

      でも、マジでヤバイんでAC

    • なんでBUFSIZ使わずに、わざわざそっくりな識別子のBUFSIZEを定義するの?
      いや、実際にこういうコード書くヤツがいたりするから、マジで疑問なんだけど。
      # 元ネタACさんを煽るつもりはない。
      • Q.BUFSIZってなんですか
        A.stdio.hぐらい読みましょう。
        #include <stdio.h>はおまじないではありません。
        • stdio.h はかなり読みにくいヘッダだと思いますが…

          そもそも、ps2 のようなゲーム機用の開発環境でも、
          stdio.h は提供されているのですか?

          個人的には、ゲーム機なら gets() のような
          問題を多く含む関数は捨てるという意味で
          stdio.h は提供しない方が、安全なゲームが生産されると思います。

          • (前略)
            /* Default buffer size. */
            #ifndef BUFSIZ
            # define BUFSIZ _IO_BUFSIZ
            #endif
            (後略)

            これがわからない人は、コーディングしない方がいいと思います。(もちろんその先は長いでしょうけれど。)stdio.hにはここしか出てきてませんよー
          • >そもそも、ps2 のようなゲーム機用の開発環境でも、
            >stdio.h は提供されているのですか?

            ありますよ。
            サターン、プレステ、ドリキャス、PS2、すべてGNU-Cです。
            普通のCにあるライブラリはすべて提供されてます。
            PS2からはC++も提供されてます。(最適化がへぼいらしいけど)
            任天堂は知りません。
    • 「バグか?」と問えば「仕様です」と答える。
      「仕様か?」と問えば「バグです」と答える。
      おいおい、プログラマーは嘘つき島の住人か。

      プログラマーAとプログラマーBがいます。
      一方が嘘つき島住人で一方は正直島住人です。
      どちらのプログラマーがどちらの島の住人なのかは分か

ハッカーとクラッカーの違い。大してないと思います -- あるアレゲ

処理中...