The behavior of NetBSD's setenv(3)

成瀬 @nalsh

NetBSDのsetenv(3)ってnameに=を含む引数を許すのか

tnozaki @tnozaki

@nalsh setenv("FOO=bar", "buzz") の場合、environは FOO=buzz になったはず、つまり '=' 以降は無視されるちう感じだったかと

成瀬 @nalsh

@tnozaki なーるほど、じゃあそのようにテスト側を直しときます。ありがとうございます

Takahiro Kambe @_taca_

@nalsh 昨日、気になって簡単なCのコードを書いてました。#NetBSD: setenv("foo1=bar1", "baz1") => foo1=baz1, #FreeBSD: EINVAL

tnozaki @tnozaki

@_taca_ EINVALになるのはPOSIX.1-2001からですが、結局こないだのFreeBSD setenv(3) exploit と同じ問題を孕んでるんですよねー

tnozaki @tnozaki

setenv(3) の name に '=' を含む場合 EINVAL を返すというPOSIX.1-2001の仕様をまじめに実装すると

tnozaki @tnozaki

setenv("FOO=", "bar", 1) でFOOの値がbarで上書きされなくなるので、上書きされることを100%仮定して戻り値をチェックしてないコードがlink loaderとかにあったりすると

tnozaki @tnozaki

こないだのFreeBSD unsetenv(3) exploitと同じ結果になるかもしれないわけでして

tnozaki @tnozaki

ちなみに OpenBSDでは一度は仕様通りに実装したものの、コメント化してNetBSDと同じくエラーにしないようにしてたり

Takahiro Kambe @_taca_

@tnozaki "foo1=bar1"なんて名前の環境変数をセットしようとするのはまずいですが、エラーならないのはまだしも、既存の"foo1"の値が意図せず変えられてしまうっての行けてない。やはりエラーにすべきなのでしょうな。

tnozaki @tnozaki

@_taca_ 逆、そのケースはアプリケーションのバグとして早い時期に発覚しませんかね

tnozaki @tnozaki

エラーにならないと思われていた動作がエラーになる方がソース互換性を失うのでやばい

tnozaki @tnozaki

clarify undefined behavior するなら関数名を変えてしまうのが無難といえば無難

tnozaki @tnozaki

unsetenv(3)のプロト変更といい軽率だとおもいますの、TOG仕事しろ

tnozaki @tnozaki

ソース互換ならコンパイラがエラーチェックを強制する技があるけど、コンパイル済のバイナリには無力

Takahiro Kambe @_taca_

@tnozaki 発覚すればよいのですが、見落とされた上に変にセキュリティの穴の原因にならないかしら?

tnozaki @tnozaki

@_taca_ それはテスト不足なので、正しかったはずのテストが

Takahiro Kambe @_taca_

@tnozaki ?