読者です 読者をやめる 読者になる 読者になる

ローグウェーブソフトウェアのブログ

開発をシンプルに 安全で高品質のコードを 素早くお客様のもとへ

GNU libcの脆弱性について - CodeBuzzから

記事紹介 OpenLogic

ローグウェーブのブログCodeBuzzに投稿された新しい記事をご紹介します。今年の2月にglibc 2.9以降の全てのバージョンでgetaddrinfo() 関数にCVE-2015-7547バッファオーバーフロー脆弱性が発見されました。ローグウェーブのOpenLogicサービスでオープンソースサポートを担当しているAndrew Pomponioがこの件をくわしく解説します。

ブログ記事: GNU libcの脆弱性について

blog.klocwork.com

私たちのビジネスはセキュリティの観点から情報の伝達、ハードウェアの制御にいたるまでLinuxというOSに非常に大きく依存しています。Linuxが機能するためにはGNU Cライブラリが欠かせません。1987年に開発され、短くglibcと呼ばれることもあります。Linux上でCやC++のライブラリとして高い機能を提供し、ついには標準ライブラリとしてlibcを置き換えました。

今年の2月にglibc 2.9以降の全てのバージョンでgetaddrinfo() 関数にCVE-2015-7547バッファオーバーフロー脆弱性が発見されました。ドメイン名のリクエストに脆弱性があり、攻撃者がバッファオーバーフローを発生させてリモートから悪意のあるコードを実行できるようになっていました。もし通信が暗号化されていなかったり、弱い暗号しか使っていなかった場合、この関数は中間者(man in the middle)攻撃に対しても脆弱になります。このgetaddrinfo()はLinuxや他のソフトウェアでGNU Cライブラリを使ってドメイン名を検索する際に使われます。

一部のユーザーはLinux環境のglibcに単にパッチを当てればよいですが、脆弱性のあるバージョンのglibcコンパイルしたアプリケーションはパッチの当たった2.23以降のバージョンでリコンパイルする必要があります。この手続は一晩でできるものではありませんし、テストを行ったり計画を立てる必要も生じます。そのためユーザーは修正がテストされて実装されるまでの間、脆弱性のあるソフトウェアを使わなければなりません。ビジネスへの影響は長期間にわたって適用にコストがかかることでしょう。このバグの影響範囲については、sudoやcurl、セキュアシェル(ssh)などのLinuxユーティリティがglibcコンパイルされていることを考えてみてください。wgetのような単純なユーティリティでさえ、セキュリティ専門家のKenn Whiteによる概念実証(POC)によると脆弱性を持っているようです。

攻撃の詳細

攻撃を実行するには攻撃者は悪意のあるDNSサーバを自分で走らせ、正しいDNSサーバになりすましてクライアントからのリクエストに対して応答します。クライアントがあるホスト名をIPアドレスへと解決するよう依頼すると、この悪意のあるDNSサーバはこの呼出を傍受し、正しいサーバであるかのように装ったレスポンスを返します。ユーザが接続しようとしたDNSサーバになりすますことにより、今度はリクエストを任意の目的地へと発信することができるようになります。つまり攻撃者はそのユーザを自分たちのサーバへと導くことが可能になってしまうのです。

glibcDNSサーバからのレスポンスに備えて2048バイトのスタックメモリを用意して待機しています。もし2048バイトより大きなレスポンスを受け取った時、新しいバッファがヒープ上に用意され、全ての情報が更新されます。設定された条件によってはスタックバッファと新しいヒープとの間にミスマッチが起こる可能性があります。スタックはDNSのレスポンスを保存しようとしますが、そのサイズがスタックのバッファおよび確保されたヒープバッファより大きいため、オーバーフローを起こします。このスタックの最後にはそれぞれIPv4IPv6の2つの未処理のリクエストが置かれます。リクエストが両方同時に処理される場合、スタックオーバーフローが発生します。

今回の脆弱性の原因の一つはDNSの欠陥 - TCPUDPのポートを片方からもう一方へと変更できてしまうによるものです。名前解決でのエラーとリトライはスタブであるglibcではなくキャッシュリゾルバによって取り扱われます。つまりエラーとリトライはglibcに到達しないのです。DNSのリクエストには通常512バイト制限があります。glibcはより大きなバッファ・サイズを宣言するEDNS0リクエストを発行しないため、正しいDNSキャッシュデータがスタックオーバーフローに対してfail状態を作り出すことによって、データはメモリから消えてしまうと考えられていました。攻撃者はTCPのTruncationビットを設定してDNSUDP(キャッシングを行いません)の代わりにTCPを使うように仕向け、このフェイルセーフを回避することができます。通信がこのキャッシュ検査のレイヤーを越えてしまうと、コードはネットワーク上に現れ、正しい通信のように見えてしまいます。現在のところこの脆弱性に対するエクスプロイトの成功例はありませんが、ユーザや組織に対する理論的な影響は甚大です。

チェックしましょう

さまざまな脆弱性Linux OSに存在しますが、そのリストにはここで述べたようなsudoや管理者権限を使ってリモードコードを実行できるようなものは含まれていません。なお悪いことに、この脆弱性を含むコードは2008年の5月から使用されており、8年近くもソフトウェア開発者は脆弱性のあるglibcコンパイルして自分たちのアプリケーションに組み込んで来たのです。もし開発したアプリケーションがglibcを含んでおり2008年5月以降現在までの間に作成されたものなら、ただちにチェックしてライブラリのアップデートや影響を受けそうなソフトウェアをリコンパイルしてください。

OpenLogicの顧客はこの脆弱性について特別にセキュリティのアナウンスを受け取っています。OpenUpdateの無料版に登録すると最新のOSSのリリース情報とセキュリティ更新が届きます。また、オープンソースサポートにご連絡いただければこの脆弱性からアプリケーションを守るためのお力になれると思います。

Andrew Pomponio

その他

以下の日本語まとめ記事も参考になります。 glibcのgetaddrinfo()問題 – CVE-2015-7547: glibc getaddrinfo stack-based buffer overflow | yohgaki's blog

d.hatena.ne.jp

googleのセキュリティブログを見ると、この脆弱性を発見したときの新鮮な驚きやRedHatのエンジニアとの鉢合わせなどが記述されていて興味深いです。

ローグウェーブ セールスエンジニア 柄澤(からさわ)