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

Microsoft IIS 5.0 のセキュリティバグ(WebDAV 機能)」記事へのコメント

  • by Anonymous Coward on 2003年03月19日 18時24分 (#282517)
    プログラムの基本として、全てのバッファに対してオーバーフロー等が生じないようにコーディングするのが普通だと思うのですが、なぜこんなに、次から次に不具合が見つかるのでしょうか?
    • プログラムの基本として、全てのバッファに対して...
      少なくとも文字列処理について言えば、そもそも自前でバッファを確保して使おうなどとするのが、時代遅れで、無粋で、効率の悪いプログラミングスタイルでしょう。別途入念に作られた汎用文字列操作ライブラリを使うことを考えてみるべきです。

      そうした汎用ライブラリを使うと、文字列格納のためのメモリがヒープ領域にとられ、文字列を連結したりするたびにデータのコピーが発生することになりがちなため、昔気質のプログラマは、実行性能が悪くなること危惧するのかもしれませんが、本当にその部分の遅さがシステムの性能に影響を及ぼすほどのものなのかを考えてみて欲しいところです。(もちろん性能に影響を及ぼす部分はチューニングのため注意深くバッファを操作するのでしょう。)

      親コメント
      • by Anonymous Coward
        C/C++用の入念に作られた汎用文字列操作ライブラリ
        なんて知りませんがな。

        無学なモンで、Win上で使える汎用文字列操作ライブラリっつーたら、
        STLのbasic_string (ロケール対応が貧弱) か
        MFCのCString (色々貧弱) しか思いつきません。

        …きっと素晴らしいライブラリを教えてくれるんだろうと願いつつ。
        • by jbeef (1278) on 2003年03月20日 2時54分 (#282751) 日記
          高機能である必要はありませんし、また、自分で(自プロジェクト内で)作るのでもよいです。そこだけ入念に作るわけです。それによってミスの頻度を減らせるでしょうという簡単な話をしているだけです。それすら行われておらず、そこら中に char buf[1024] などというコードが散乱していることが多い、というのが現状ではないでしょうか。
          親コメント
          • それすら行われておらず、そこら中に char buf[1024] などというコードが散乱していることが多い、というのが現状
            固定長バッファが使われること自体は、バッファオーバーフローの引き起こされ易さと何の関係もない。
            • by miri (12057) on 2003年03月20日 15時01分 (#283059) 日記
              可変長に書いてバッファの長さを意識するようになるだけでもかなりバグが減りそうな気がするが。

              コード中のバッファオーバーフローの可能性のある箇所を列挙するようなプログラムってないんですかね。
              親コメント
            • by jbeef (1278) on 2003年03月21日 15時41分 (#283686) 日記
              固定長バッファが使われること自体は、バッファオーバーフローの引き起こされ易さと何の関係もない。
              「何の関係もない」という日本語の使い方が間違っていませんか? 「固定長バッファを使っていてもバッファオーバーフローしないコードにすることはできる」ならばその通りですが、そのことについてこのスレッドの元のコメント者は「生じないようにコーディングするのが普通だと思うのですが、なぜこんなに、...」と述べています。
              親コメント
              • 「何の関係もない」という日本語の使い方が間違っていませんか?

                間違ってませんね。大元のコメント [srad.jp]は

                プログラムの基本として、全てのバッファに対してオーバーフロー等が生じないようにコーディングするのが普通

                「なのになぜこんなに?」という質問です。それに対しあなたは

                そこら中に char buf[1024] などというコードが散乱していることが多い、というのが現状ではないでしょうか。

                と、固定長バッファを使用したコードはあたかも必ずバッファオーバーフロー

              • by jbeef (1278) on 2003年03月21日 16時34分 (#283712) 日記
                「なのになぜこんなに?」という質問です。それに対しあなたは
                その質問に対しては他の方から「完全な人間なんていないから」というある種の根源的な回答が既に出ていましたから、私は、別の観点からの解決法として、そもそも「バッファを自前で用意しない」という話を持ち出しました。その流れで、 「そこら中に char buf[1024] などというコードが散乱していることが多い、というのが現状」 と発言したものです。
                実際オーバーフローが起きる原因としてバッファが固定長であるかどうかなどは全く関係がない、と指摘しただけです。可変長でも固定長でもオーバーフローが起きるコードは書けるし、オーバーフローを起こさないようなコードも書ける訳ですから。
                全く関係なくはありませんね。頻度について議論しているのですから。
                親コメント
              • 頻度から言えば固定長でバッファオーバーフローしないコードの方が圧倒的多数だと思いますが?

                単に固定長のプログラムが多いから、バッファオーバーフローを指摘されるプログラムも固定長が多いというだけかもしれませんよ?
                そうではないというのであれば、具体的な統計データなり何なり出してください。

              • by jbeef (1278) on 2003年03月22日 18時05分 (#284211) 日記
                頻度から言えば固定長でバッファオーバーフローしないコードの方が圧倒的多数だと思いますが?
                それが何か? 問題のないコードの絶対数を出して何か意味があるのですか?
                単に固定長のプログラムが多いから、
                まさに自前でその都度バッファを確保して自力で操作するようなコードが多いということですね。それだけにミスが絶えないと。 だから、「別途入念に作られた汎用文字列操作ライブラリを使うことを考えてみるべきです」と述べたのですが。まだわかりませんか?
                親コメント
        • >C/C++用の入念に作られた汎用文字列操作ライブラリ
          >なんて知りませんがな。
          入念かどうか、汎用かどうかは別としてD.J.Bernsteinのおっさんみたいに
          人のライブラリを基本的に利用せずに書くっていうポリシもありますね。

          #私はそのポリシって好きではないですけど。
      • あんたマトモなデーモンとか書いたこと無いだろ。
        練習として作ってみましたとかいうオモチャじゃなくて、毎日何万アクセスも受けて365日何年も動き続ける事を前提としたヤツ。
        文字列処理のためにいちいちヒープ取ってやってたら、メモリのスラシングが起きてコピー回数云々とかと比べ物にならない性能低下が発生する。

        ガベージコレクションすればいいって?
        あんなもんは「ゴミ撒き散らしても後で掃除しとけば文句ないんだろう」という下品でだらしない発想の元に用意されたフールプルーフ(バカ避け)機能でしかない。
        実際ガベージコレクションが使われているのはB

        • オフトピだけど。

          >毎日何万アクセスも受けて365日何年も動き続ける事を前提としたヤツ。
          こんなWindows環境が欲しい!ってちょっと思っちゃった:-)
          --
          -- yuno
          親コメント
        • きっと自分と同等以上の能力をメンバ全員に要求する人なんだろうな。
          プロジェクトや、プログラムの規模が大きくなると、バッファオーバーフローの知識を十分に持っているプログラマだけでメンバを構成することが不可能になると思うが。
          親コメント
        • ひとつ確実に言えるのは、すぐにカッカしてしまう人間に慎重なプログラミングなんて無理ってことだろうな:-)
        • 煽り返しって・・・煽りになっていないやん。
          煽りってのは正論が含まれてナイト。
        • あんたマトモなデーモンとか書いたこと無いだろ。
          練習として作ってみましたとかいうオモチャじゃなくて、毎日何万アクセスも受けて365日何年も動き続ける事を前提としたヤツ。
          文字列処理のためにいちいちヒープ取ってやってたら、メモリのスラシングが起きてコピー回数云々とかと比べ物にならない性能低下が発生する。

          なるほど、では文字列を含むほとんどのメモリ管理をヒープ(pool)で行うApacheも練習用として作ってみましたとかいうオ

          • 直接ヒープを利用する訳じゃなく、要求が厳しければ、
            スラッシングや処理効率などの心配が在るからメモリアロケータ
            をオーバーライドして使うのが普通だと思ふ。
            Apacheも、そうしていると思うけど?・・・
          • では文字列を含むほとんどのメモリ管理をヒープ(pool)で行うApacheも練習用として作ってみましたとかいうオモチャなんですね。

            Apacheって最初からスラッシングが起きたりする事の対策を半ばあきらめて、スラッシングが起きる前にそのプロセスを放棄して再フォークするという、まさに

            「ゴミ撒き散らしても後で掃除しとけば文句ないんだろう」とい

        • > 毎日何万アクセスも受けて365日何年も動き続ける事を前提としたヤツ。

          日にたったの数万件程度なら、1アクセスあたり数百ミリ秒~数秒ほどの時間がありますよね。仮にヒープ管理が重いとしても、めちゃめちゃ余裕だと思うのですが。

          あと、「動き続ける」という
          • 日にたったの数万件程度なら、1アクセスあたり数百ミリ秒~数秒ほどの時間がありますよね。

            処理の平均サイクルと応答速度とは別のもの。

            「動き続ける」というのはむしろ動的にメモリを使うほうが当たり前にできる

            mallocとfreeのようなオブジェクトのサイズによる管理を行う場合、効率の良い断片化の

      • >別途入念に作られた汎用文字列操作ライブラリを使うことを考えてみるべきです。

        などとよく言われますが、問題の本質は、
        「今、そこにあるコードが、そのような考慮がされずに、書かれている」ということではないでしょうか? 新しく作るコードがどうのこうのじゃなくて、今見つかっているバッファオーバーフロー脆弱性は、いままでそのような考慮がなされずに作られているからでしょう。だから、これからも次々と「発覚」すると思われます。
        • 今あるコードから自動的に(完璧に)バッファオーバーフロー脆弱性を見つけて、指摘してくれる手法やツールがあればうれしいのですが。
          「完璧に」は無理でしょう。必要以上に警告が出てしまうものになるか、全部は見つけられないがいくらかは見つけてくれるものになるでしょう。研究レベルでは以下などの取り組みがあります。
          • David Wagner, Jeffrey S. Foster, Eric A. Brewer and Alexander Aiken, A First Step Towards Automated Detection of Buffer Overrun Vulnerabilities, Network and Distributed System Security Symposium, Feb 2000.
          • David Larochelle and David Evans, Statically Detecting Likely Buffer Overflow Vulnerabilities, 2001 USENIX Security Symposium, Aug 2001.
          • 中村豪一, 村瀬一郎, 静的解析によるCプログラムのバッファオーバーフロー検出, 情報処理学会プログラミング研究会, Jun 2002.
          親コメント
          • まだまだ研究途上ですか。となると、開発者(およびパッチを開発して配布する部署の担当者)が枕を高くして眠れる日はまだ遠いようですね。でもその分、セキュリティ関連ツール産業(ウイルス対策ソフトとか、パッチ当てるソフトとか)はまだまだ安泰というところでしょうか。まぁ、不景気の今、そういう産業ぐらいは景気よくなっててもらわないと(おいおい)。
    • 完全な人間なんていないから
    • 有名でよく使われているフリーソフトウェアでも、ソース読んでみると
      なんでこんなヘタクソな・・・とか思うことはありますから、
      どこにでも質の悪いコードなんて潜んでいるものじゃないですかね。

      #人のこと言えないのでAC
      • 有名でよく使われているフリーソフトウェアでも、ソース読んでみると
        なんでこんなヘタクソな・・・とか思うことはありますから、
        「hacker」の作品だからでしょうかね。

        リーダーズ英和辞典第2版より:
        hacker
        2 《何をやっても》うまくいかない人, 不器用なやつ, ダメな人, 並の人; #《俗》 ずさんな[しろうとの](コンピューター)プログラマー.

        親コメント
    • まあ、人間は完璧な人はいないってことさ。
      コーディング量が多くなればなるほどバグが潜在する可能性は高くなるし。

      もっとも、初期のBoFの原因はコンパイラのバグが原因だったことも多かったけどな。
    • オーバーフロー等が生じよないうにコーディングするというのもいいが、人間ミスはつきものなので、オーバーフロー等が生じよない言語、開発環境を整えるべきだと思っています。
      #初めてアセンブラでプログラム動かしたらバグってて自身を上書きしやがった!
      • オーバーフロー等が生じよない言語、開発環境を整えるべきだと思っています。
        既にたくさんありますよ。状況によってはそれらを選択すると十分な実行速度が得られないことがあるため、そのときにはそれらが選択されないというだけで。しかし、本当にそれだけの速度がその部分に必要なのかを検討することなしに、危ない言語が選択されていることもあるように思えます。
        親コメント

未知のハックに一心不乱に取り組んだ結果、私は自然の法則を変えてしまった -- あるハッカー

処理中...