アカウント名:
パスワード:
長らく +Lhaca のユーザーだった者として、 Windows で圧縮ファイルの取り扱いに迷ったらとりあえず +Lhaca デラックス版を入れておけばよいという気楽さを提供してくれた作者の村山富男さんには感謝しています。
前回の脆弱性 [srad.jp]が見つかるまで +Lhaca 1.20 を使っていましたが、脆弱性への対応の中で
行ったこと:LHA展開処理内に存在したstrcpyをstrncpyに変更し、バッファーのオーバーフローをなくしました。
という記述を見て不安を覚えたので、 +Lhaca を使うのをやめました。
C 言語を知っている人の中には似たような印象を受けた人もいるのではないでしょうか。
どんなライブラリー関数もそうですが、 strncpy は魔法の関数
どんなライブラリー関数もそうですが、 strncpy は魔法の関数ではなく、 strcpy と同様に注意して使わないとセキュリティーホールを生みます。しかも、 strncpy はけっこう間違えやすい関数だということで、「strcpy の安全版」として strncpy を使うことを推奨しない人がたくさんいます。
程度問題らしいですが、strcpy_s等よりstrncpyが間違えやすいってのも分からない。
template <size_t size>inlinechar *strcpy( char (&_Dest)[size], const char *_Source ){ return strcpy_s( _Dest, size, _Source ) == 0 ? _Dest : 0;}
strncpy( dst, src, strlen(src) );strcpy_s( dst, strlen(src), src );
で、+Lhacaの作者の方はわかっている人かそうでないか、というと… strcpy()でバッファオーバーフローを起こしている 「strcpyをstrncpyに変更しました」の発言 から問題の本質を理解できてなく怪しいかも?という主張だと思います。
で、+Lhacaの作者の方はわかっている人かそうでないか、というと…
から問題の本質を理解できてなく怪しいかも?という主張だと思います。
その通りです。本当に作者の村山さんが問題の本質を理解できていないかどうかはわかりませんが、 #1183069 [srad.jp] では僕がそういう印象を受けたという事実とその理由を説明したつもりです。
ついでに、+Lhacaのreadme.txtを読む限りVC6辺りを使用されているようですので、libcにstrcpy_s()が含まれていません。
情報ありがとうございます。なお、 #1183069 の書き方が悪くてわかりにくかったのですが、 strcpy_s や strlcpy の話を持ち出したのは、 strncpy を strcpy の安全版だと思って使うと間違えやすいと考える人は僕以外にもたくさんいる、という裏付けのつもりでした。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
長期的な見通しやビジョンはあえて持たないようにしてる -- Linus Torvalds
「strcpyをstrncpyに変更しました」が意味すること (スコア:4, 興味深い)
長らく +Lhaca のユーザーだった者として、 Windows で圧縮ファイルの取り扱いに迷ったらとりあえず +Lhaca デラックス版を入れておけばよいという気楽さを提供してくれた作者の村山富男さんには感謝しています。
前回の脆弱性 [srad.jp]が見つかるまで +Lhaca 1.20 を使っていましたが、脆弱性への対応の中で
という記述を見て不安を覚えたので、 +Lhaca を使うのをやめました。
C 言語を知っている人の中には似たような印象を受けた人もいるのではないでしょうか。
どんなライブラリー関数もそうですが、 strncpy は魔法の関数
Re:「strcpyをstrncpyに変更しました」が意味すること (スコア:1, 興味深い)
strncpyが間違えやすい関数とは?
伝聞だけで疑心暗鬼に陥り、不安になっているのでしょうか。
程度問題らしいですが、strcpy_s等よりstrncpyが間違えやすいってのも分からない。
「LHA展開処理内に存在したstrcpyをstrcpy_sに変更し、バッファーのオーバーフローをなくしました。」なら安心なのか?
# そもそもバイナリデータならstrcpy/strncpyじゃなくてmemcpy使えよ!と突っ込みたいAC
Re:「strcpyをstrncpyに変更しました」が意味すること (スコア:1)
strncpy()はコピーする文字数、つまり送り側のサイズと言えばいいでしょうか。
対するstrcpy_s()は受け側のバッファサイズです。しかもstrcpy_s()はバッファオーバーフローを検出すると最終的にプロセスを停止します。
こういうのはやりだすと止まらないらしく なんてのがstring.hに入ってます。
# 正確にはこう展開されるためのマクロです。これを止めるためのマクロも用意されています。
ライブラリ側がどんなに頑張っても、わかっていない人に とかやられたらいっしょです。
ついでに、+Lhacaのreadme.txtを読む限りVC6辺りを使用されているようですので、libcにstrcpy_s()が含まれていません。
で、+Lhacaの作者の方はわかっている人かそうでないか、というと…
- strcpy()でバッファオーバーフローを起こしている
- 「strcpyをstrncpyに変更しました」の発言
から問題の本質を理解できてなく怪しいかも?という主張だと思います。Re:「strcpyをstrncpyに変更しました」が意味すること (スコア:1)
その通りです。本当に作者の村山さんが問題の本質を理解できていないかどうかはわかりませんが、 #1183069 [srad.jp] では僕がそういう印象を受けたという事実とその理由を説明したつもりです。
情報ありがとうございます。なお、 #1183069 の書き方が悪くてわかりにくかったのですが、 strcpy_s や strlcpy の話を持ち出したのは、 strncpy を strcpy の安全版だと思って使うと間違えやすいと考える人は僕以外にもたくさんいる、という裏付けのつもりでした。
Re:「strcpyをstrncpyに変更しました」が意味すること (スコア:0)
違います。
もちろん、strcpy_s()は有用です。適切な局面で適切に使いましょう。
> から問題の本質を理解できてなく怪しいかも?という主張だと思います。
主張は自由ですが、その主張の根拠はありません。
理解できている根拠はありませんが、理解できていない根拠もありません。
根拠無く誹謗するのはほめられる行為ではありません。