  |
http://jvn.jp/jp/JVN81094176/index.html Android OS がオープンリゾルバとして機能してしまう問題
ってやつね。
報告者の森下さんが「とある方から私個人宛で報告をいただき」と言っているので、その「とある」人として少し背景を書いてみようと思う。
https://twitter.com/OrangeMorishita/status/581314325853306882
発見のタイミングは、Android 4.2 のソースコードが出て少しして、ぐらい。この時点では、Android全てが修正されていなかった。当時、 CVE-2012-3411 (dnsmasq が libvirt の特定の config で使うときにオープリゾルバとなる) が発表されていて、これと同じ問題があるのでは、と調べた結果だった。Android のテザリングは、framework の指示を netd という daemon が受け取りネットワークの設定を変更して実現されている。で、テザリングのクライアントにDHCPでプライベートアドレスを配りDNSのリゾルバを提供するために、必要に応じて netd から dnsmasq が起動される。
そのころ、Android端末の製品開発で、スケジュールに珍しく余裕があり、わりと好き勝手できる状況だったので、AOSPのソースコードを精査していた。
いくつか、セキュリティ問題をみつけて、ものによって単に修正、修正と並行して Google に会社から報告、あるいは単に Google に会社から報告、ぐらいの対応をした。
この問題は、Google に報告だけ、の対応をとった。なぜかといえば、 次のような事情があった。
で、この報告の結果なのか、他の報告もあったのか分からないが、Android 4.3 のリリースに修正が含まれていた。もっとも、国内のほとんどのスマートフォン端末は Android 4.3 はスキップした。森下さんへの個人的な連絡の最初は、Android 4.3 発表より前。
正直、この問題のリスクは、端末ベンダ、および端末ユーザにとっては相当に低いものに見えた。3GやLTEの国内キャリアで、外から端末へ DNS query を許すところはほとんどないだろう、というのは直感的には思っていた(これが間違っている場合は、影響がケタ違いに大きくなるところだった。上流も下流も Wifi という構成のテザリングをAndroidは持っていないので、上流を Wifi と仮定すると、残るのは USB と Bluetooth だけになる) 。NAT される場合ならなおさら。
ただ、ネットワークインフラにとってのDDoSというのは、個々にとってはリスクが低くても、それが何百万台、何千万台とあれば影響が出てくるんじゃないか、という気もした。ちょうどそのころ、森下さんが DNS リフレクション攻撃に関してベンダ等への啓発を始めていたのが目に留まったので、森下さんに連絡してみた。脆弱性対応としてハンドリングするのがIPA や JPCERT/CC になるとしても、ネットワークインフラへの影響ということであれば、表に出ない話も扱える方が報告したほうが適切だと思った。私は原理的には分かってもネットワーク運用に関しては業界の外にいるからね。
事情は知らないけど。
ひとつの可能性としては、「対応未定」の端末、おそらくは対応しないことになるのだろうけど、それらの現役感がなくなってきたからじゃないかな。Android 4.2系が端末のラインナップとして長生きしすぎたせいで、けっこうOSバージョンアップではなくセキュリティ修正としての対応をする製品が多くなったのかなぁ、という気もするけど。
もうひとつの可能性としては、当初よりもインフラへのリスクが上がっているのかもしれない。Android 4.2系の端末で修正リリースが去年の秋とか、これからの近未来とかのが多い、という状況からするとね…。
10
