なぜ OS のセキュリティ脆弱性は深刻となりうるのか

〜脆弱性を狙う攻撃からシステムを守る基本〜

ある一定以上の複雑さを持つソフトウェアは既知であるか未知であるかに関わらず、セキュリティ上の脆弱性を懸念する必要があります。脆弱性はソフトウェアのリリース時に攻撃可能であるとは限らず、時代の変化により過去には脆弱性とされていなかった挙動が脆弱性として認識されるようになることもあります。そのためソフトウェアは運用が続く限り、さまざまな攻撃経路を警戒して外部の攻撃からシステムを守る必要があります。

オペレーティングシステム (OS) は多種多様なソフトウェアコンポーネントを含むため、セキュリティ研究者はしばしばそういったソフトウェアの脆弱性を研究しており、新しく見つかった脆弱性が広範で深刻な影響を持っていることがあります。当記事では過去に発見された脆弱性、特に長年そのソフトウェアに内在されていながら、近年になって発見された脆弱性を実例として挙げ、OS の継続的なアップデートが必要であること、コアコンポーネントの脆弱性が深刻となりうることを解説します。

例 1: CVE-2014-0160(Heartbleed)

CVE-2014-0160 は 2014 年に OpenSSL という SSL/TLS ライブラリに発見された脆弱性です。OpenSSL の他にも GnuTLS、wolfSSL などの SSL/TLS ライブラリの実装が存在しますが、OpenSSL は他のライブラリよりも広く使われおり脆弱性が発見されると、非常に多くのアプリケーションに影響を及ぼします。

CVE-2014-0160 は Heartbleed という名称でも知られています、これは TLS プロトコルの Heartbeat という拡張機能の実装にバグがあったため、細工されたパケットを送ることによって、リモートからメモリ上の情報の漏洩が起こってしまうという脆弱性です。このバグがより一層深刻な脆弱性として認識されたのは、OpenSSL が暗号技術に関するライブラリであったためです、攻撃者から脆弱性を攻撃された場合、秘密鍵などのセキュリティ・プライバシー保護に関わる機密性の高い情報が漏洩する可能性がありました。またこの脆弱性が世間で問題となったことをきっかけとして、OpenBSD プロジェクトは LibreSSL というフォークプロジェクトを、Google は BoringSSL というフォークプロジェクトを開始しました、これらのプロジェクトはコードのリファクタリングや Google のニーズに合わせてコードをメンテナンスすることを目標としています。

Heartbleed logo

[Heartbleed logo, licensed under CC0]

例 2: CVE-2021-4034(Pwnkit)

CVE-2021-4034 は polkit というソフトウェアに発見された脆弱性です、polkit は権限を持たないアプリケーションに対して、ポリシー定義に従って別のユーザーとしてコマンド実行を許可するツールです。仕組み上、polkit は root 権限で動作し、CVE-2021-4034 は polkit の中の pkgexec というコンポーネントで容易に悪用可能な権限昇格が可能でした。言い換えればこの脆弱性が修正されていないシステムでは pkgexec を起動できるプロセスは任意のコマンドを root 権限で実行可能な状態にあったということです。この脆弱性単体ではリモートから攻撃することはできませんが、他の脆弱性と組み合わせれば深刻な攻撃が可能です。

例 3: CVE-2016-5195 (Dirty COW)

CVE-2016-5195 は 2016 年に Linux カーネルに発見された、メモリの COW(Copy-On-Write) 実装のレースコンディションのバグを利用して、メモリ破壊を行うことにより特権昇格が可能となる脆弱性です。この脆弱性は 2007 年にリリースされた Linux カーネル 2.6.22 から存在したことで特に注目を集めました、9 年間修正されていなかったということは、多くのシステムがこの脆弱性から攻撃可能であることを意味します、その中には EoL を迎えている OS を利用しているシステムも含まれます。当然 EoL を迎えている OS にはセキュリティ修正が提供されません。

OS のセキュリティ脆弱性が深刻になりうる理由

これらの脆弱性に共通する点は、それぞれ発見されたソフトウェアがオペレーティングシステムの中核に位置するコンポーネントであり、発見された脆弱性の影響が広範囲に及ぶことです。OS にはリングプロテクションという階層構造を持った情報の保護機能があります、通常のアプリケーションは CPU モードの中で最も低い権限である Ring 3、カーネルのような低レイヤーで動作するソフトウェアは最も高い権限である Ring 0 で動作し、容易に悪意あるコードがセキュリティ侵害を起こせないように設計されています。

Privilege rings for the x86

[Privilege rings for the x86, licensed under CC-BY-SA 3.0]

一方、カーネル自身に重大な脆弱性があった場合、さまざまな経路で侵入可能で、高い特権で実行され、自身のセキュリティ保護機能を回避できるという性質上、保護が困難な攻撃が実行される可能性があります。また Ring 3( ユーザースペースとも呼ばれます ) で動作するアプリケーション向けにもセキュリティ保護機能 ^※1 は存在し、悪意ある攻撃からシステムを守っています。しかし日々発見される攻撃手法は、時にセキュリティ保護機能による制限を回避します。

脆弱性を狙う攻撃からシステムを守るには？

こういった日々発見される脆弱性を狙う攻撃からシステムを守るには、どうするべきでしょうか？もっとも良い方法は日々OS をアップデートし、既知の脆弱性 ( 前述したような広く知られた脆弱性以外も含みます ) をついた攻撃はできないようにすることでしょう。迅速にアップデートができない場合、多層防御によって攻撃を防ぎ、アップデートまでの時間の猶予を作ることも選択肢に入ります。もっとも良くない管理方法は何も計画せずシステムを放置することです。OS の継続的なアップデートを予定しておくことはシステムを守るために望ましい計画です。

脆弱性への対策にあたっては、日々発見される脆弱性情報を把握することと、利用しているソフトウェアの脆弱性管理に対応することが重要です。サイバートラストでは、脆弱性管理ツール MIRACLE Vul Hammer や、MIRACLE LINUX 技術サポート、CentOS 技術サポートを提供しています。

本記事に関連するリンク

注記

※1: LSM(Linux Security Module) ^※2 や Capability(7)、seccomp(2)、ASLR(Address Space Layout Randomization) などが代表的です。
※2: Linux Security Module は実装としてはいくつかのバリエーションがあり、メインラインにある SELinux や AppArmor、TOMOYO、SMACK、Yama など複数の選択肢が存在します。最も基本的な対策の一つとして、LSM は有効な状態でシステムを運用することを推奨します。( プロファイルなどの関係により Linux ディストリビューションによって利用できる LSM は限られていることがあります。)