新城＠筑波大学情報です。こんにちは。

In article <c1fl9o$dl5$1@news2.rim.or.jp>
        dohzono@hf.rim.or.jp (Kazuo Fox DOHZONO) writes:
> 確認しておきますが, strlcpy によってバッファオーバーフローが「起こらな
> くなる」ケースでは間違ったプログラムを前提としているわけであり, それは 
> strlcpy を使っても依然として間違ったプログラムであることに変わりありま
> せん.

まあね。例外を探すといろいろあるでしょうか。

それより重要なことは、間違いには２種類あるということです。

（Ａ）セキュリティ上の弱点に繋がる間違い
（Ｂ）セキュリティ上の弱点には繋がらない間違い

strlcpy() を使うと、（Ａ）は出てきません。この性質を有りがた
いと思う人は、多いでしょう。

> 人的ミスならそういうものを持ち込ませない, 或は, 万が一持ち込まれてもテ
> スト等で発覚するような設計にするべきで (Java を使うってのもこの辺に入っ
> てくるわけでしょう), 「持ち込まれても strlcpy で」っていうのは問題に対
> 処するベクトルがずれている気がするんです. 新人君に教える心得としても甚
> だ不適当なものでしょう.

最後の部分、同意できませんね。人間は間違う、だから、間違った
としても安全側に倒れるように作るようにプログラムは作るべしと。

> そういうのも「不適当なバッファを適当にとること (たとえば, FILE * と無
> 関係な場所で BUFSIZ を使ってみたりとか)」の弊害でしょう. 過不足なく 
> (過…なく, がミソ) 確保するようにして, 仕様上の最大長やその数倍程度を
> 入れてみれば大抵発覚するのではないですか. 私の経験上はそんな感じ.

その経験は、「バッファ・オーバーフローは、次々見つかる、しか
も深刻なセキュリティ上の問題を引き起すものとして見つかること
が多い」という現実とはずれています。CERT でも Bugtraqq でも
見てみて下さい。

> …とはいえやっぱりテストに頼るような設計にはしないなぁ. 今やってる仕事
> で grep したら strcpy が 200 個くらい出てきましたけど, バッファ長とか
> はプログラムで算出させてチェックは上位層でやってるし. もちろんテストも
> やってますけど.

そのプログラムを明日誰かが直したとして、その直した誰かがバッ
ファ・オーバーフローのバグを入れないという保証は、できないでしょ。
バグを入れた人の責任だと言うのは簡単だけど、最初からセキュリ
ティ上のバグが出にくいような作りになっていたら、それに越した
ことはありません。

> で, これを全部 strlcpy にして一々チェックを入れて「どういうアクション
> を起こすか (起こりもしないのに)」と考えるのは, 馬鹿げてるでしょ?

いいえ。

> > #define       Strlcpy(dst, src, size) if( (strlcpy((dst),(src),(size))>=(size)) ) \
> >                                   error("buffer over flow.")
> この error とやらはその時その時の状況に応じて事象の巻き戻しから何から
> 面倒をみてくれる魔法の仕組みなんですか? 

そういう仕組みが使える時には、使うべきでしょう。トランザクショ
ンとか longjmp とか。

> # 戻り値に対する不等号も気持ち悪いなぁ. 

あれは、FreeBSD のマニュアルに書いてある通りです。気持悪いの
を見たくなければマクロを使えばよろし。

＼＼　新城　靖　（しんじょう　やすし）　＼＼
＼＼　筑波大学　電子・情報　　　　　　　＼＼