LinuxデスクトップはWindows 10より安全性が低い?
2017年2月5日に開催された「FOSDEM 2017」にて、Linuxディストリビューションの1つである「Gentoo」の開発者が、表題のプレゼンを行いました。プレゼンの資料は、以下を参照してください。
プレゼンのきっかけ
プレゼンは、以下の脆弱性を指摘する内容がきっかけになったとのことです。この内容は、音源チップであるソニーSPC700のエミュレーションを行うソフトウェアに脆弱性があり、ある特定のオペコードを実行すると(細工されたファイルを読み込むと)任意コードを実行してしまう、というものです。
そのソフトウェアとはLinuxデスクトップで広く利用されている「GStreamer」です。
「GStreamer」はオープンソースのマルチメディアフレームワークであり、音声や動画の再生等によく利用されます。
セキュリティーが不十分なディストリビューション
本題です。Linuxデスクトップを提供するディストリビューションの中には、セキュリティーに十分な配慮を行っていないディストリビューションがあり、異論があるかもしれないがそのようなディストリビューションより、Windows 10の方がセキュリティーが上である、とのことです。
いずれもデフォルト状態のOSを比較対象にしています。
デフォルト状態とは、デフォルトで搭載されているソフトウェアだけで構成され、何も変更していない状態のことです。
資料から内容をいくつかピックアップしてみます。
1.GStreamerの脆弱性
まず「GStreamer」の脆弱性です。Tracker + GStreamer
これはLinuxに限らずWindowsでも同様ですが、「Google Chrome」や「Chromium」など一部のブラウザーは、ファイルのダウンロード要求があると自動的にそのファイルをストレージ(~/Downloadsや~/ダウンロード)に保存する機能があります。そして「GNOME」が開発している「Tracker」がインストールされていれば、ユーザーのホームフォルダー以下、すなわち「~/Downloads(~/ダウンロード)」を含むフォルダー内のファイルを検出し、新しく生成されたファイルのインデックスを作成します。
インデックス作成時、ファイルのメタデータを取得するためファイルの解析処理を行います。
この時「Tracker」は、ファイルの解析に様々なライブラリーを活用しています。
- GStreamer
- ffmpeg
- flac
- totem-pl-parser
- tiff
- libvorbis
- taglib
- libpng
- libexif
- giflib
- libjpeg-turbo
- libosinfo
- poppler
- libxml2
- exempi
- libgxps
- ghostscript
- libitpcdata
この中に「GStreamer」が含まれています。
もし自動ダウンロードされたファイルが細工されたファイルだった場合、インデックス作成時に任意コードが実行されることになります。
もちろん他のライブラリーも脆弱性があれば似たような問題が発生します。
Fedora 25での例
以下は「Fedora 25」+「Tracker」による任意コード実行の例です。KDEのBalooにも同種の問題がある
KDE環境では、「Tracker」に相当するソフトウェアが「Baloo」です。ファイルマネージャーの「Dolphin」がサムネイル情報の生成に「Baloo」を利用しています。
この「Baloo」にも同種の問題があります。
サムネイル情報の生成もメタデータの生成と同じ
「Nuatilus」等ファイルマネージャーには、サムネイルを生成する機能があります。上記と同じように同じバックエンドを利用しているなら、同じ現象が発生します。
以下は「Ubuntu 16.04」での任意コード実行の例です。
GStreamerの開発者たちは脆弱性をすぐ修正した
「GStreamer」の開発者は問題をすぐに修正しました。しかし他にも見つかった問題がありますが、その多くは「GStreamer」が利用しているライブラリーの不具合であるとのことです。
2.サンドボックス化
上記で出てきた「Tracker」と「Baloo」ですが、「Tracker」では上記の内容を受け「libseccomp」を利用しサンドボックスの実装が行われました。しかし「Baloo」では、まだサンドボックスの実装が行われていません。
3.Address Space Layout Randomization(ASLR)
「ASLR」は「Linux Kernel 2.6.12」から導入された非常に強力なセキュリティー強度を上げる仕組みです。「ASLR」を適切に導入するには、特定のアドレスに依存しないコードを記述し、バイナリーを「-fpic -pie」でビルドする必要があります。
Linuxディストリビューションは、「ASLR」への適合作業が非常に遅いとのことです。
各ディストリビューションの対応状況
「Ubuntu」では、2016年10月にリリースされた「Ubuntu 16.10」で対応が行われています。「Fedora」では、2016年にリリースされた「Fedora 23」で対応が行われています。
「Debian」は現在作業中であり、2017年にリリース予定の「Stretch」で対応が行われます。
「openSUSE」ではいくつかのパッケージのみ、この対応が行われています。
「Gentoo」では「Hardened Gentoo」でのみ、この対応が行われています。
Ubuntuについて補足
以前紹介した「Ubuntu」で有効なセキュリティー機能の一覧を参照すると、以下の記述が見つかります。汎用レジスタ数が少ないx86アーキテクチャーにおいて「-fPIE -pie」でビルドしたバイナリーは、5%〜10%程度パフォーマンスが低下します。
そのためセキュリティーが重要視される限られたパッケージのみ、「-fPIE -pie」でビルドするよう設定されていました。
一方汎用レジスタ数が十分な「amd64」「ppc64el」「s390x」ではこの問題がないため、「Ubuntu 16.10」以降デフォルトで「-fPIE -pie」によるビルドが行われます。
一方Windowsでは
一方「Windows」では、「Windows Vista」から「ASLR」が導入されました。そして最近の「Windows」では、すでに「Code-Flow Integrity」のようなさらにセキュリティー強度を上げる仕組みを導入しています。
しかしこれらの仕組みを利用するかどうかは、アプリケーションや設定次第になります。
何が言いたいのか?
プレゼンでは最後に「これらセキュリティーの問題を我々は修正しなければならない」と締めくくっています。イベントの主旨やこの言葉から、現状Linuxデスクトップが抱えているセキュリティーの課題を共有し、ソフトウェアの開発者やディストリビューションを提供しているコミュニティーに向けた啓発であることが分かります。
タイトルが刺激的ですが、これはプレゼンで聴衆に強い関心を持ってもらうためによく利用される手法です。
中身を見ずにタイトルだけ文字通りに受け取ってしまうと、誤解することになるでしょう。
あくまでも中身とセットでこのタイトルを採用しているという点に注意してください。