■ httpoxy
_ おひさしぶりです。生きてます。
_ 外部から HTTP_PROXY 環境変数を注入される httpoxyという穴。なんで今ごろ話題になってんの。すいません、黙ってましたが前から知ってました。多くの実装で対策済みなことも。既知の問題でも改めてキャッチーな名前をつければ注目を集めることができるということですかね。
_ 環境変数名は大文字を使う慣例だけど、プロクシに関しては http_proxy のように小文字を使うことが多いのはなぜなんだろうという疑問。そしてもうひとつ、bash の shellshock は外部から不正な環境変数を注入できるという脆弱性だったけど、ほかにそういうのがないだろうかという興味。この2点が結びつけば CGI に HTTP_PROXY を注入する攻撃を思いつくのは難しくない。
_ が、いくつか調べてみたら cURL、perl の LWP、ruby の Net::HTTP といずれも対策済みなのを確認。ああ、こりゃ既知の問題でちゃんと対策してるのが当たり前、よほど間抜けな実装でもなければこの穴を踏むことないわ、とそれ以上の調査はしなかったんだよね。なんと python がその間抜けな実装だったというのを今日初めて知って、あのときあと5分調査を続けてれば発見してたんだろうなぁ、とちょっと後悔してる。
_ ただし、途中で調査をやめたとはいえ、間抜けな実装が見つからなかったというわけではない。ちゃんと見つけてた。今回の脆弱性が発表された後も、今のところ修正される動きは見えない。CGI で使われるケースはまず考えられないとはいえ、とっとと直せよ > libfetch
_
なお、cURL は上で対策済みと書いたけど、実は環境によっては脆弱なので注意。どういうことかというと、こういうこと。
Windows では大文字の環境変数を設定しても、小文字で参照できてしまう。ので、HTTP_PROXY は無視して http_proxy だけを見る、というのは Windows 環境で動作することを想定している場合は対策として十分ではない。curl はその不十分な対策しかしていないので、UNIX/Linux では影響ないが、Windows で使う場合には問題あり。perl や ruby は大文字小文字ではなく、CGI に固有の環境変数(REQUEST_METHOD)が存在するかどうかで判定していて、この問題はない。
_ python の修正、 go の修正。どっちの言語も詳しくないんだけど、どちらも REQUEST_METHOD が存在していれば HTTP_PROXY を無視する、という実装になってるように読めるんだけど合ってるかな？ 今回の脆弱性に関してだけならば Windows 環境含めてそれで問題ないけれど、別の問題が発生しそうな。つまり、外部からやってきた不正な HTTP_PROXY だけでなく、元から使われていた正当な http_proxy も同様に無視されてしまい、プロクシを通さないと HTTP アクセスできない環境では CGI が正常に動作しなくなってしまう。LWP や ruby Net::HTTP では CGI_HTTP_PROXY という代替の環境変数に値をセットしておくことでそのような問題を回避できるようになっているが、python や go の修正はそのような配慮がない。python はまだ議論中のようだけど、 go はこのまま正式にリリースされちゃったね…。