パスワードを忘れた? アカウント作成
15792 story

+Lhaca 1.21の修正は不十分 45

ストーリー by Acanthopanax
strcpy 部門より

Anonymous Coward曰く、

+Lhaca 1.20 の脆弱性が報告され、修正版をダウンロードした方も多いと思いますが、どうぞ、最新の修正版 1.23を使っているかどうか確認してください。1.21には別の脆弱性が見つかっています(ITmedia記事)。ただし、1.23はまだ詳細な動作確認が終わっておらず、正式リリースではないそうですから、人柱になりたいとか、どうしても +Lhaca を今すぐ使わなければならないとかいう場合以外は他のアーカイバを使うのがよいでしょう。

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • 修正版を正式版ではありませんと公開したところに賢明さがあったなあと思いました。

    慌てて修正して「直しました」とかアナウンスしちゃうような人だって多いような気がします。自分だったらそうしちゃうかも。

    --
    LIVE-GON(リベゴン)
  • by Anonymous Coward on 2007年07月02日 14時15分 (#1183168)
    前エントリをざっと見て出ていないのが不思議なのですが、
    +Lhacaには、破損lzhファイルを解凍した時、一切エラーを出さずに正常終了する問題があるように思うのですが?

    試しにバイナリエディタで一部を書き換えたものと、ファイル末尾を切り落としたものを用意し、+Lhaca(Ver1.20)で解凍したところ、エラー無しで正常終了しました。できあがったファイルは当然、破損しています。
    LHUTや7-zipで解凍するとちゃんと破損ファイルと表示されます。

    +Lhacaは手軽で素晴らしいソフトなのですが、破損検出が無いという一点のために、(少なくとも解凍用としては)使い物になりません
    ファイル送付先でLhacaを使っていたため、ファイル破損に気づかず、何度泣いたことか…(ρ_;)
    送付したファイルを送り返してもらって初めて破損に気づくとか勘弁して欲しい。
    • by Anonymous Coward on 2007年07月02日 15時29分 (#1183210)
      圧縮するときにも、圧縮できなかったファイルについてアーカイブに含まれないことがあるのですが、まったくメッセージを出さない仕様となっております。
      親コメント
      • by Anonymous Coward on 2007年07月02日 19時32分 (#1183338)
        そういう意見要望があるなら、ここで愚痴っているのではなくちゃんと作者に伝えてあげるのが宜しいかと。 言わないけれど、分かってくれってのは無理な相談でっせ。
        親コメント
        • 分かって欲しいのは作者じゃなくて、使う側なのでは?
          それなら、ここに書くことも間違えではない。
        • ファイル展開時のCRCチェックや終端/長さチェックなどは、アーカイバ作るなら常識としてチェックするものだと思うんです。
          これだけ有名なアーカイバなのにそれらのチェックが抜けているのは、悪意があるとまでは言いませんが、悪質な手抜きではあると思うんですよね…。
          ポリシーとしてそうしているなら、ドキュメントに記載すべきです。(破損していても可能な限り解凍して欲しいという需要はあります。)

          プログラムの製造/試験時に、破損ファイルの解凍試験などは当然行うと思います。
          故に、作者がこの「破損ファイル解凍時、エラーを出さずに正常終了する」という挙動を、バグではなく仕様と認識してると推測できます。
          ※本当に気づいていないとしたら驚きです。私は素直に謝ります。

          それに、バグだとしたら、こんな分かりやすい現象の報告が1件も行ってないとは思えないんですが…。

          一応作者にメールした方がいいですかね?
    • by Anonymous Coward on 2007年07月04日 2時48分 (#1184244)
      >前エントリをざっと見て出ていないのが不思議なのですが、

      Lhacaおよび+Lhacaがかなりダメなソフト(アーカイバとして信頼できない)というのは、
      割と有名だと思っていたんですが・・・
      ずいぶん大勢の人が使ってたみたいで、不思議でたまりません。

      作者の姿勢にも以前から疑問を感じていました。
      DLL不要というコンセプトの良し悪しはともかく、参考にしたソース、あるいは流用したソースがあるなら、
      それについて書くべきだし、ライセンスにも従うべきだと思います。
      スクラッチで作ったとしても、各圧縮形式のどのバージョンに対応しているのかは公表すべきだと思います。
      それらについて一切言及していないのは、身勝手で無責任に思えるのですが。

      #というか、単に常識の通用しない人なのか?

      親コメント
  • 長らく +Lhaca のユーザーだった者として、 Windows で圧縮ファイルの取り扱いに迷ったらとりあえず +Lhaca デラックス版を入れておけばよいという気楽さを提供してくれた作者の村山富男さんには感謝しています。

    前回の脆弱性 [srad.jp]が見つかるまで +Lhaca 1.20 を使っていましたが、脆弱性への対応の中で

    行ったこと:LHA展開処理内に存在したstrcpyをstrncpyに変更し、バッファーのオーバーフローをなくしました。

    という記述を見て不安を覚えたので、 +Lhaca を使うのをやめました。

    C 言語を知っている人の中には似たような印象を受けた人もいるのではないでしょうか。

    どんなライブラリー関数もそうですが、 strncpy は魔法の関数ではなく、 strcpy と同様に注意して使わないとセキュリティーホールを生みます。しかも、 strncpy はけっこう間違えやすい関数だということで、「strcpy の安全版」として strncpy を使うことを推奨しない人がたくさんいます。「strcpy の安全版」としては、例えば Visual C++ では strcpy_s 関数 [microsoft.com]が、あちこちの Unix では strlcpy 関数 [wikipedia.org]が用意されています (もっとも、これらの関数だって注意して使う必要があるのですが。必要な注意力の程度の差の問題です)。

    なので、「strcpy が危険なら、 strncpy に変えれば安全だろう」と思っているとも受け取れる記述を見ると、不安を覚えずにはいられません。ソースコードが公開されていないので、安全かどうかを自分で確認するのも難しいです。不安を感じながら無理に使うこともないと思ったので、使うのをやめたというわけです。なので、僕の印象としては、今後さらに +Lhaca に脆弱性が見つかったとしても驚くに値しません。

    まあ実際にはちゃんと修正されていて安全なのかもしれませんし、それ以前に、アーカイバーに信頼できないファイルを食わせたときの安全性をどこまで要求するかは人によって違うでしょうから、今後も +Lhaca を使い続けるという選択をする人はそれでいいと思います。

    • by Anonymous Coward on 2007年07月02日 12時53分 (#1183143)
      >「strcpy が危険なら、 strncpy に変えれば安全だろう」と思っているとも受け取れる記述

      あなたがどう受け取ろうと自由ですが、私もこの記述が村山氏への侮辱としか受け取れません。
      中身も確認せずに関数を置き換えて修正版リリース、なんてどこかの初心者の笑える失敗談ですか?

      >もっとも、これらの関数だって注意して使う必要があるのですが。必要な注意力の程度の差の問題です

      注意力の程度の差、という意味がわかりません。
      プログラミングをする際に故意に「手抜き」をするという習慣があるのですか?
      あなたにが今までもこれからもソフトウェアの開発に関わらないという選択をされることを祈ります。
      親コメント
      • by Anonymous Coward on 2007年07月02日 14時11分 (#1183167)
        fcpさん> 不安を覚えたので、 +Lhaca を使うのをやめました。

        strcpyとstrncpyの差は非常に大きく本質的ですが、
        strncpyとstrlcpyの差はそれに比べ小さい瑣末な問題です。

        10年以上の経験を持ち、strncpyを熟知している人間が、strncpyをstrlcpyに
        置き換えることでバグの低減に有意な効果を見込めるとは思えませんし、使い
        慣れないAPIに乗り換えることによる一時的なケアレスミスの発生上昇リスク
        を、セキュリティフィックスの場面では避けるというのは正しい判断の一つで
        しょう。

        本質を押さえ、必要な要件をきちんとカバーした対処に対し、全く問題になら
        ない可能性のある瑣末な問題を、それも自分の想像上の仮定を導入して非難す
        るのはちょっといただけないですね。

        fcpさん>「strcpy が危険なら、 strncpy に変えれば安全だろう」と思っているとも受け取れる記述
        ACさん> あなたがどう受け取ろうと自由ですが、私もこの記述が村山氏への侮辱としか受け取れません。

        まあ、ソースを公開していない以上、やったことが誤解無く伝わって利用者が
        安心できるように丁寧に説明するべきだと思います。#1183143のACさんや私や
        他の多くの人たちにはあれでも十分だと思いますが、fcpさんには不十分だっ
        たということでしょう。どこまで書けばfcpさんも判ってくれるかは判りませ
        んが、もう少し丁寧に書いてもよかったとは思います。

        余談ですが、#1183143のACさんは言葉の選び方が少々攻撃的ですが、とてもまっ
        とうなこと書いているのに、「フレームのもと」は行きすぎだと思いました。
        ・・・とここまで書いてたら、「すばらしい洞察」に変わってました。;-)
        親コメント
      • >「strcpy が危険なら、 strncpy に変えれば安全だろう」と思っているとも受け取れる記述

        あなたがどう受け取ろうと自由ですが、私もこの記述が村山氏への侮辱としか受け取れません。

        作者を侮辱するつもりはありませんでしたが、「僕はこの記述から作者のセキュリティーに関する技術力に不安を覚えた、だからそのソフトを使うのをやめた」と発言するのが侮辱なら、侮辱だと思います。

        >もっとも、これらの関数だって注意して使う必要があるのですが。必要な注意力の程度の差の問題です

        注意力の程度の差、という意味がわかりません。
        プログラミングをする際に故意に「手抜き」をするという習慣があるのですか?

        なるべく楽にプログラムを書けるように、言語を選んだり実装方法を考えたりしますが、僕はそれを手抜きとは呼びません。注意力が必要な部分はなるべく減らしたいです。

        親コメント
        • strcpyを使うのは誤りです。strncpyを使うのは誤りではありません。
          その違いは判りますか?多くの人が指摘していますね。

          問題の解決に比べて些少な事を指して「使う気が無くなるほど技術力に不安を覚えた」と
          根拠も無く乱暴な言葉で煽り立てるのは人によっては侮辱と受け取られてもしょうがないでしょう。

          貴方が「strncpyよりよい代替物を用いるべきである」と主張したいのなら、
          最初からそう言えばよく、誰かを貶める必要はないのです。
          そうすればこのようにフレームが起こることは無かったでしょう。
    • by Anonymous Coward on 2007年07月03日 21時18分 (#1184062)
      +Lhaca 1.21 の脆弱性の修正情報。 http://vuln.sg/lhaca121-jp.html [vuln.sg]
      親コメント
    • by Anonymous Coward on 2007年07月02日 10時14分 (#1183077)
      # 別に貴方が使用中止するのは勝手ですが。

      どんなライブラリー関数もそうですが、 strncpy は魔法の関数ではなく、 strcpy と同様に注意して使わないとセキュリティーホールを生みます。しかも、 strncpy はけっこう間違えやすい関数だということで、「strcpy の安全版」として strncpy を使うことを推奨しない人がたくさんいます。

      strncpyが間違えやすい関数とは?
      伝聞だけで疑心暗鬼に陥り、不安になっているのでしょうか。

      程度問題らしいですが、strcpy_s等よりstrncpyが間違えやすいってのも分からない。
      「LHA展開処理内に存在したstrcpyをstrcpy_sに変更し、バッファーのオーバーフローをなくしました。」なら安心なのか?

      # そもそもバイナリデータならstrcpy/strncpyじゃなくてmemcpy使えよ!と突っ込みたいAC
      親コメント
      • strncpyが間違えやすい関数とは?
        Cはあまり詳しくないのですが、strncpyとstrlcpyで検索してみたところ、
        strncpy(3)よりもstrlcpy(3) [hatena.ne.jp]というタイトルのBLOGエントリーが出てきました。
        曰く、
        strncpy(3)は、(本来文字数を指定するところに)ついうっかりバッファサイズを指定すると、不正なC文字列になってしまうので要注意です。
        だそうで。
        もしこの理由があたっているなら、「ついうっかり」やりやすそうなミスに見えますから、
        伝聞だけで疑心暗鬼に陥り、不安になっているのでしょうか。
        とまで言う必要はないように見えますけど、どうでしょう?
        間違いなく、しっかり実装していれば問題ないという主張はわからなくもないですが、「ミスりやすいものを使っているってことは、大丈夫?」と思ってしまうのも、致し方ないのではないかと。
        親コメント
        • by Anonymous Coward on 2007年07月02日 11時57分 (#1183124)
          ついうっかりは感覚的にも分かりやすい話ですが、
          C言語は、strなんちゃらという関数だからといって、char型の配列でNULL文字が終端ということの正当性を保障する挙動を示すわけではないし、保障されると使いづらくなる場合もある。
          データ構造に関しての正当性は、あくまで作る人が、割ける範囲のコストで行わなければならない言語なんだ、ということを念頭におけるかどうかじゃないでしょうか。

          推奨として、strlcpyを適切に使うのはありですが、だからといって置き換えればよいってモノでもないってことかと。
          親コメント
          • OpenBSD由来のstrlcpyやstrlcat、glibc由来のasprintf、mallocよりも整数値オーバーフローチェックつきのcallocを使うコード規約にすれば安全になると盲信するのは危険ですが、この規約にすることで確実に攻撃しにくくなっていると思いますよ。プログラマーは必ずミスをしますからついうっかりチェックを忘れたり、ついうっかり'\0'を入れ忘れたりするのは十分ありえることで、その場合でも安全にしておく方が良いと思いますから。

            strlcpyやstrlcatについての詳しい説明は下記の論文にまかせますが、#1183107の引用が気になったのでその点だけ指摘します。
            | strlcpy and strlcat--Consistent, Safe, String Copy and Concatenation,
            | Todd C. Miller and Theo de Raadt,
            | Proceedings of the 1999 USENIX Annual Technical Conference (FREENIX TRACK)
            | http://www.usenix.org/events/usenix99/millert.html [usenix.org]

            #1183107の引用にて、
            | strncpy(3)は、(本来文字数を指定するところに)ついうっかりバッファサイズを指定すると、
            | 不正なC文字列になってしまうので要注意です。
            と説明されていますが、上で紹介した論文のCommon Misconceptionsにある通り、『多くのプログラマーはstrncpyを使うと'\0'が終端記号として入っていることを想定しているが、その想定はコピー元のサイズがコピー先のサイズより小さい場合だけしか正しくない。また、strncpyを使った場合のコストはstrcpyよりも'\0'をつける処理の分高い』とちゃんと書くべきです。バッファサイズを指定するかバッファサイズ-1を指定するかは本質的な問題ではありません。strncpyではコピー元の方がコピー先よりも大きかったら、最後に'\0'が入らないので文字として扱ったときにバッファを越えてアクセスしてしまうというのが問題なわけです。

            親コメント
      • by Anonymous Coward on 2007年07月02日 10時39分 (#1183088)
        > # そもそもバイナリデータならstrcpy/strncpyじゃなくてmemcpy使えよ!と突っ込みたいAC

        問題があったのはファイル名処理なのでstrcpyでいいかと。
        親コメント
      • 程度問題らしいですが、strcpy_s等よりstrncpyが間違えやすいってのも分からない。
        わかってる人はセキュリティ的にはstrcpy_s()の有用性がわかっているのですが、わかっていない人はどちらでも同じです。
        strncpy()はコピーする文字数、つまり送り側のサイズと言えばいいでしょうか。
        対するstrcpy_s()は受け側のバッファサイズです。しかもstrcpy_s()はバッファオーバーフローを検出すると最終的にプロセスを停止します。

        こういうのはやりだすと止まらないらしく
        template <size_t size>
        inline
        char *strcpy( char (&_Dest)[size], const char *_Source ){
            return strcpy_s( _Dest, size, _Source ) == 0 ? _Dest : 0;
        }
        なんてのがstring.hに入ってます。
        # 正確にはこう展開されるためのマクロです。これを止めるためのマクロも用意されています。

        ライブラリ側がどんなに頑張っても、わかっていない人に
        strncpy( dst, src, strlen(src) );
        strcpy_s( dst, strlen(src), src );
        とかやられたらいっしょです。

        ついでに、+Lhacaのreadme.txtを読む限りVC6辺りを使用されているようですので、libcにstrcpy_s()が含まれていません。
        で、+Lhacaの作者の方はわかっている人かそうでないか、というと…
        • strcpy()でバッファオーバーフローを起こしている
        • 「strcpyをstrncpyに変更しました」の発言
        から問題の本質を理解できてなく怪しいかも?という主張だと思います。
        親コメント
        • で、+Lhacaの作者の方はわかっている人かそうでないか、というと…

          • strcpy()でバッファオーバーフローを起こしている
          • 「strcpyをstrncpyに変更しました」の発言

          から問題の本質を理解できてなく怪しいかも?という主張だと思います。

          その通りです。本当に作者の村山さんが問題の本質を理解できていないかどうかはわかりませんが、 #1183069 [srad.jp] では僕がそういう印象を受けたという事実とその理由を説明したつもりです。

          ついでに、+Lhacaのreadme.txtを読む限りVC6辺りを使用されているようですので、libcにstrcpy_s()が含まれていません。

          情報ありがとうございます。なお、 #1183069 の書き方が悪くてわかりにくかったのですが、 strcpy_s や strlcpy の話を持ち出したのは、 strncpy を strcpy の安全版だと思って使うと間違えやすいと考える人は僕以外にもたくさんいる、という裏付けのつもりでした。

          親コメント
        • > strncpy()はコピーする文字数、つまり送り側のサイズと言えばいいでしょうか。

          違います。

          もちろん、strcpy_s()は有用です。適切な局面で適切に使いましょう。

          > から問題の本質を理解できてなく怪しいかも?という主張だと思います。

          主張は自由ですが、その主張の根拠はありません。
          理解できている根拠はありませんが、理解できていない根拠もありません。
          根拠無く誹謗するのはほめられる行為ではありません。
    • by Anonymous Coward on 2007年07月02日 11時48分 (#1183118)
      Windowsな人はこっちもどうぞ。つ strsafe.h
      親コメント
    • よくわからんが、Rubyで書き直せばOK?

      で、Exerb [osdn.jp]などで配布、と。
    • 私は貴方のコメントを見て、まだまだ勉強したてのひよっこだなぁと
      感じずにはいられませんでした。
      リファクタリングとか言って、無駄にstrcpyを別関数に置き換えてそうですね。
      strcpyをする前段階で安全なデータにしておくというのが普通の対策です。
    • それ以前に str* 系の関数って普通に使うものなの? 自分は使ったこと無いのだけど。
  • by Anonymous Coward on 2007年07月02日 13時52分 (#1183163)
    作者がちゃんと対応しないといけない時代になったんだなあってしみじみ。
    世の中に流通させたら責任が生じて速やかな対応が迫られる。

    #まあバイナリだけの流通なので作者だけががんばらなきゃいけないっていう面もかわいそうなきもするけど。
    • > #まあバイナリだけの流通なので作者だけががんばらなきゃいけないっていう面もかわいそうなきもするけど。

      バイナリだけを流通させるって決めたのは作者の自由意志ですけどね。
  • by Anonymous Coward on 2007年07月02日 6時12分 (#1183049)
    >テスト用コードが残っていたためにファイルが解凍されないケースがあり

    もうこれは普通にだめでしょ。
    +lhacaオワタ
  • 感想 (スコア:0, 余計なもの)

    by Anonymous Coward on 2007年07月02日 18時06分 (#1183290)
    ・国産ソフトは信用しない。本質的にリスクを伴う代物だと意識して使う。 ・gcc4以降ならFORTIFY SOURCEで防げたのにね。
    • by Anonymous Coward
      >・国産ソフトは信用しない。
      ruby?シイラ?namazu?mecab?Seasar?Hinemos?w3m?stone?zebra?

    • by Anonymous Coward
      では即刻スラッシュコードJPなんて信用するのを止めましょう。
      2chもニコニコ動画も利用できないね。ニートには辛かろう。
  • by Anonymous Coward on 2007年07月02日 21時48分 (#1183413)
    デラックス版の事はわかりました。
    0.7xや0.9xは無事なのかそうでないのかをそろそろはっきりして下さい
typodupeerror

人生の大半の問題はスルー力で解決する -- スルー力研究専門家

読み込み中...