C言語のセキュリティや、組み込みからクラウド利用まで「Linux Security Summit 2018」レポート

2018年8月29～31日、カナダのバンクーバーで「Open Source Summit North America 2018」が開催されました。また、その開催に先立ち、8月27～28日に同会場で「Linux Security Summit 2018」が開催されました。

Linux Security Summit 2018は、主にLinuxのカーネル周りのセキュリティについて新しい機構の提案や既存の機構のアップデート情報を発表し、会場に集まった専門家たちと情報交換や意見をもらう場となっています(今回は220名が参加)。

今回、筆者もLinux Security Summit 2018に参加したので(2日目は午前中のセッションのみ)、各セッションをダイジェストで紹介します。

なお、発表に使用された資料は下記のURLからダウンロードできます。

●Linux-Security-Summitのサイト
https://events.linuxfoundation.org/events/linux-security-summit-north-america-2018/program/slides/

●セッションの動画(YouTube)
https://www.youtube.com/playlist?list=PLbzoR-pLrL6rOT6m50HdJFYUHyvA9lurI

●Security in Zephyr and Fuchsia , Stephen Smalley / James Carter

発表資料はこちら

NSAのStephen Smalley氏とLinux Security Summit 2018のオーガナイザーでMicrosoft社のJames Carter氏がより、RTOS用途の組み込み系OSに関するセキュリティとして「Zephyr」と「Fuchsia」でのセキュリティ実装に関して解説されました。

ZephyrはLinux Foundationがスポンサーとなり開発が行われているIoTデバイス用のRTOSです。このようなOSは一般的なサーバ／ユーザ向けのOSとは異なり、リソースが極端に限られていることや実行速度が厳格に求められること、またマルチユーザの必要性がないことから、下記のような違いがあります。

• 全てのスレッドは特権で動作している
• メモリ保護機能もメモリ仮想化もない
• とにかくフットプリントやオーバーヘッドを気にしている
• セキュリティに関しては起動後にアプリケーションを入れたり大きく変更したりすることがないため、出荷前の開発時のセキュリティや静的解析によるコード検査、暗号化、セキュアなアップデートの方法等がターゲットとなっている

このようなRTOSはボード開発と密接に関係して行われることが多く、今回のZephyrも開発者のほとんどがIntelやLinaro、Synopsys等から来ているそうです。その中で

• Kernel APIへの変更を最小にする
• ローエンドのボードへの影響を少なくする

等を考慮した彼らのコントリビューションとして、

• 基本的なメモリ保護機能の追加
• ユーザスペースの追加
• アプリケーションで共有されるメモリの保護機能の追加

等を紹介していました。

FuchsiaはGoogleで開発されているLinuxではない新しいOSです。一時期FuchsiaがGitHubに公開されたため、Googleで以降のメインOSになるのではと噂されていました。

Fuchsiaでは、セキュリティを実現する要素として

• ケーパビリティ
• ネームスペース
• サンドボックス

が使われています。今回は「Fuchsiaが今後どのように扱われるか」というような情報は特にありませんでしたが、Fuchsiaで今まで扱われていたケーパビリティベースのセキュリティ以外に、今後SELinuxのようなMACを搭載していく予定であるとの話がありました。

Making C Less Dangerous – Kees Cook, Google

発表資料はこちら

Kernel Security Protection Project(KSPP)のKees Cook氏より、Linux KernelをC言語の観点からより安全にしていく取り組みが紹介されました。

現在Linux KernelはC/C++をメインに開発されていますが、C言語の特性として「きちんと記述しないとどのように振る舞うかわからないため、どのようなことでも起きうる」ことから、Linux Kernelにはたびたび脆弱性が見つかっています。このプレゼンテーションでは

• Variable Length Array(可変長変数)が起こす問題
• switch～case文できちんとbreakを記述しなかったために起こる問題(CWE-484 “Omitted Break Statement in Switch”)では、注意を促すようにkernel中でコメントを付けていく

• ローカル変数が初期化されていないことが原因の問題(CWE-200 “Information Exposure”, CWE-457 “Use of Uninitialized Variable”)に関してはgccのオプションとして”-finit-local-vars”を加えてWarningを出すようにする
• switch～caseでローカル変数の初期化が呼ばれないケースではwarningを出す

等を行って、C言語の使用方法から来る危険を減らしていく取り組みが紹介されました。

また、オーバーフロー検知が行えるようにClangやgccのオプションのサポート、境界値チェックやCFI(Control Flow Integrity)を用いた取り組みも紹介され、現時点でのLinux Kernelでの進捗度合いが示されました。

Azure Sphere: Fitting Linux Security in 4 MiB of RAM - Ryan Fairfax, Microsoft

発表資料はこちら

Microsoft社のRyan Fairfax氏より、Azure Sphereと呼ばれるMSのMCU(組み込み用のマイクロプロセッサー)を軸としたIoTソリューションのセキュリティが紹介されました。

Azure Sphere OSのKernelはカスタマイズされたLinux Kernelで、同時にメインラインにもたくさんのコミットをしているようです。その中で非常に大きいLinux KernelのサイズをIoTデバイス(最大で4MBのRAMを装備)に合わせるため、不要な部分をカットしたり様々な努力をしたりしているようです。

Kernelのサイズをコンパクトにまとめるため、セキュリティ実装でもかなり気を使っているそうです。パーミッションを直接staticなものとしてファイルシステムに定義したり、LSMを使うとサイズが大きすぎるため「AppID」「NetworkID」「ケーパビリティ」を定義したセキュリティモデルを新たに作って実装したりしているようです。

また、ユーザランドはアプリケーションを個々に切り分け、それぞれのアプリケーションで独自にファイルシステムを持てるコンテナのような形になっており、アップデートも個別にできるよう設計されているそうです。

中でも印象的だったのは「機能を削減していくにしたがって、攻撃表面（Attack Surface）が減っていく」ことです。これはセキュリティの世界では一般常識ですが、今回Microsoftによって改めて言われることで、より多くの方々に認識を新たにしてもらいたいところです。

fs-verity: Native File-based Authenticity - Michael Halcrow & Eric Biggers, Google

発表資料はこちら

GoogleのMichael Halcrow氏とEric Biggers氏が「fs-verity」について解説しました。こちらはLinux Security Summit 2017でARM社のプレゼンに使用されたAndroid上での“DM-verity(パーティションの4kブロックごとのハッシュからハッシュツリーを形成してシステムの改変を検知する機構)”をファイルシステムに発展させ、ファイルの改変を検知・防止しようという機能です。

今後はこの機能をIMAと連携してチップセットの暗号化鍵を使用したり、対応するファイルシステムを増やしたりすることを考えているようです。会場からは「パフォーマンスの劣化がどの程度なのかが気になる」という意見が出ていました。

Open System Firmware Projects - Elaine Palmer, IBM Research

発表資料はこちら

IBM Research社のElaine Palmer氏をモデレーターに、Linux BootのRon Minnich氏、Open Compute Platform SecurityのNate Klein氏、Open EDKIIのBryan Kelly氏らによるパネルディスカッションが行われました。

Year in Review: Android Kernel Security - Jeff Vander Stoep & Sami Tolvanen, Google

発表資料はこちら

Google社のJeff Vander Stoep氏とSami Tolvanen氏がAndroidを含むLinuxシステムの脆弱性の傾向と、CFI(Code Flow Integration)について紹介しました。

2017年以降に公開されたAndroidの非特権プロセスからKenrelに攻撃を加えることができる脆弱性は、攻撃表面(Attack Surface)を削減していることから、それほど多くないということです。

例えば、SELinuxやUnix Permission、Capabilityなどを使うことで、User Spaceからくる攻撃表面はどんどん小さくなっています。

一方で、User Space以外の攻撃元としてFirmware等による入り口やUSB等があり、根本の原因は境界チェックの漏れや整数オーバーフロー等が挙げられます。また、メモリの境界外読み込み・書き込み・アクセスなどもKernelの脆弱性としてよく出てきます。

Androidでは、これらの脆弱性を利用したコードの再利用攻撃を防ぐために、Code Flow Integrity(CFI) https://source.android.com/devices/tech/debug/cfi (元々は2005年に発表されたMartin Abadi, Mihai Budiu, Úlfar Erlingsson, Jay Ligatti氏らの「Control-Flow Integrity: Principles, Implementations, and Applications」https://www.microsoft.com/en-us/research/publication/control-flow-integrity/?from=http%3A%2F%2Fresearch.microsoft.com%2Fpubs%2F64250%2Fccs05.pdfで、LLVM実装は「Enforcing Forward-Edge Control-Flow Integrity in GCC & LLVM http://www.pcc.me.uk/~peter/acad/usenix14.pdf」を参照) を用いてカーネル中の関節分岐や関節呼び出しの飛び先とリターンアドレスを検証することで、コード再利用攻撃に対抗しようとしています。実際、間接呼び出しの数も55%が5以下の許可されたターゲットを持ち、7%が100以上の許可されたターゲットを持っているので、一定の効果はありそうです。

このCFIが有効になったAndroid Kernelを搭載したAndroid デバイスは、今年の年末までには出るようです。

Linux Audit: Moving Beyond Kernel Namespaces to Audit Container IDs - Richard Guy Briggs, Red Hat

発表資料はこちら

Red Hat社のRichard Guy Briggs氏がコンテナに対応したLinux Auditの開発について解説しました。

Linux AuditはKernelに組み込まれたロギング機能で、通常はSELinuxやそのほかのLSMからログを出力させるために使用されます。また、ファイルやディレクトリを指定し、そこへの書き込みなどのシステムコールが発生した時にログへ出力できるため、システム監査等にも用いられます。

ただ、このLinux Auditは残念ながらコンテナに対応していませんが、様々な規約などの要望からコンテナ内での監査ログを取る必要性が出てきています(Linux Security Summit 2016で既に指摘されていた)。

そのため、各コンテナでAuditログを取れるようなパッチセットがいくつかコミットされています。ここではそれらの取り組みが紹介されました。

Syzbot and the Tale of Thousand Kernel Bugs - Dmitry Vyukov, Google

発表資料はこちら

Google社のDmitry Vyukov氏がGoogleで開発されているLinux Kernelの自動ファジングツール(syzbot)と同様のツール類の紹介と、昨今のLinux Kernelの脆弱性動向について解説しました。

Linuxは現在インフラでも広く使われているOSで、いわゆる「Civil Infrastructure Platform」としての扱いも検討されています。一方でLinux Kernelの脆弱性が日々見つかっており、2017年に公開された453のCVEのうち169がコード実行／125が特権昇格・情報漏えいだったようです。

しかし、「カウント対象となっていない」オフィシャルのバグは多く、2017年には4100のオフィシャルのバグフィックスが行われています。

さらに、Linux Kernelには“Stable Release”があり、先述のCivil Infrastructure Platformとしては、それらもメンテしなくてはならないことから、非常に厄介な状態になっています。例えば、修正をバックポートしたいとき、ある関数に問題があったとしても、その関数が過去バージョンにない(単にないだけではなく、あちこちに点在していただけ)場合には修正が非常に難しくなります。また、多くのカーネル開発者は「最新の機能」の開発が好きなため、バックポートという地味(しかし重要)な作業は手が足りない状態になっています。

これらの問題に対し、Googleでは「バグ検知」「バグ検査」「テストの自動化」というカテゴリでそれぞれツール類を作っています。

1. バグ検知：
   
   • KASAN(KernelAddressSANitizer)
     カーネルのアドレスに着目し、Use-After-FreeやOut of Boundsなどを発見できる。Kernelに組み込まれており、(CONFIG_KASAN=y)のオプションで選択できる。
   • KMSAN(KernelMemorySanitizer)
     初期化されていない値がないかチェックし、information leaksやdata attackなどを発見できる。現在はまだKernelに組み込まれていないが、いずれ組み込まれる予定。
   • KTSAN(KernelThreadSanitizer)
     データの競合状態などをチェックしてTOCTOU(time-of-check-time-of-use)やdouble-free等の脆弱性を発見できる。まだ開発中でgithubにプロトタイプがある。
2. バグ検査：
   
   • syzkaller
     システムコールのファジングツール。コードカバレッジを見ながら様々に入力値を変えてくれるテストツールです。VM(デフォルトではqemuからKVMを立ち上げる)を用いてテストを自動的に行う(帰国後にUbuntuマシンに因子ストールしたところ、すんなりと動作した)。
3. 自動テスト：
   
   • syzbot
     Kernel/syzkallerのバージョンを自動的に更新し、自動的にテストするツールです。テストマシンの管理やバグのレポートなども可能です。

「これらのテストツールを実行してバグを見つけることと、バグの修正をStableバージョンでも行うために、開発者の皆様の力が必要です」としてセッションは終了しました。

STACKLEAK: A Long Way to the Linux Kernel Mainline - Alexander Popov, Positive Technologies

発表資料はこちら

Positive Technologies社のAlexander Popov氏によるSTACKLEAKの紹介です。STACKLEAKはGrsecurity/PAXで開発されたセキュリティ機構で、システムコールの最後にカーネルスタックを消し、脆弱性を悪用された場合でもカーネルスタックの情報を攻撃者に悪用されないための仕組みです。STACKLEAKを使用した場合と使用してない場合の差は下図のようになります。

システムコールを利用して、初期化されていないカーネルスレッドスタックから重要なデータを取得できる脆弱性は往々にして見られます。ここではCVE-2010-2963がサンプルとして出されています。STACKLEAKを使用するとシステムコールの最後でstackleak_erased()によりカーネルスレッドスタック中のデータが“0x1337”から“-0xBEEF”に書き換えられ、ユーザスペースから初期化されていない値を拾ってきます。しかし、この値はカーネルスペースで使われていないため、脆弱性により情報が漏えいすることはありません。

本セッションでは、STACKLEAKの機能をメインラインカーネルに入れるまでの道のり(特にLinusとの絡み)の部分が(笑いも含めて)語られました。

特にLinusは「きつい口調で」「パッチを送っても無反応で」「たぶん、カーネルハードニングプロジェクトの事をデフォルトで嫌ってるんじゃないか？」といった話と「モチベーションが最低になったけど、奥さんに励まされて何とか回復した」という話が笑いとジョーク交じりで話されました。

最終的には「我々もLinux Kernelコミュニティである」「無視されない様に、どんどんコントリビュートしてくべきだ」という話でまとめられました。

How to Safely Restrict Access to Files in a Programmatic Way with Landlock? - Mickaël Salaün, ANSSI

発表資料はこちら

ANSSI社のMickaël Salaün氏によるLandlockの解説です。今回のセッションではLandlockの機能説明とデモ、現在のステータス(LKMLへのパッチの投稿など)の話がありました。

Landlockの機能については昨年のLinux Security Summit 2017レポートで解説したので割愛します。

Landlockはカーネルに入ってくる可能性が高いセキュリティ機構なので、引き続き注目しておいた方が良いと思われます。

Sub-system Update: AppArmor Update 2018 - John Johansen, Canonical

発表資料はこちら

CanonicalのJohn Johansen氏によるLinux Securityのサブシステムアップデート情報です。まずはAppArmorです。

AppArmorにはあまりアップデート情報がありませんでしたが、Debianの話題と「ロゴが新しくなった」という話題が取り上げられていました。

Sub-system Update: State of SELinux - Paul Moore, Red Hat

発表資料はこちら

Red Hat社のPaul Moore氏によるSELinuxのアップデート情報です。最初に「SELinuxももう18歳。Androidに搭載されて5年になった」と話がありました。

今回の大きな発表は、Reference PolicyがGitHubの“SELinux Project”に置かれるようになったことでしょう。これにより、SELinuxの開発はGitHubの情報だけを見れば良くなりました。

Sub-system Update: Smack Update 2018 - Casey Schaufler, Intel

発表資料はこちら

Intel社のCasey Schaufler氏によるSmackの更新情報です。Smackは現在Automotive LinuxやYocto等で使われています。

Smackは、もともとシンプルにデザインされ、現在ではもう枯れたものとして新機能は特にありませんでしたが(これはセッション中のネタにもなっている)、OverlayFSのサポートが新機能として挙げられていました。

Sub-system Update: Linux Integrity Status Update - Mimi Zohar, IBM

発表資料はこちら

IBM社のMimi Zohar氏がLinux Integrity(IMA)のアップデート情報を紹介しました。

IMAも枯れたものになるため目立った更新情報はありませんでしたが、諸所の機能更新やevmtestなどテストフレームワークなどの情報が出されました。

Sub-system Update: Kernel Self-Protection Project - Kees Cook, Google

発表資料はこちら

Google社のKees Cook氏がKernel Self-Protection Project(KSPP)の更新情報を紹介しました。

KSPPの進みは遅いものの着実に開発が行われていることから、カメに例えて解説されていました。

Kernel 4.14では先述のStackleakプラグインの追加、4.16ではホワイトリストを用いたusercopyの強化とCONFIG_CC_STACKPROTECTOR_AUTOの追加、4.17と4.18ではSpeculative Store Bypassが修正されています。4.19ではL1TFも修正される予定です。

その他にも、まだ組み込まれていない機能が用意されているとのことです。

Life Behind the Tinfoil: A Look at Qubes and Copperhead - Konstantin Ryabitsev, The Linux Foundation

発表資料はこちら

Linux FoundationのKonstantin Ryabitsev氏が、デスクトップ用のQubes OSとモバイル用途のCOPPERHEAD OSについて解説しました。

Qubes OSはデスクトップをターゲットとしたセキュリティの実装です。仮想ゲスト(通常はXen)を用いて各アプリケーションをそれぞれのドメインのVMで立ち上げ、ドメイン間をアクセス制御することで、ユーザがあるアプリケーションで不用意に変なコードを実行したとしても、他のアプリケーションに影響を与えないようにするものです。筆者が2010年にIPAの研究会で取り上げたもので、歴史的にはかなり枯れた部類のデスクトップOSです。

このセッションではQubes OSの機能概要を解説し、2018年での状況とXen以外のVM(KVM等)のサポートを視野に入れていると話がありました。

また、セッション後半ではAndroid用のAOSP(Android Open Source Project)であるCOPPERHEAD OSを紹介しました。セキュリティを強化したOSで、先述のKSPPを用いたHardened KernelでSELinuxのStrictポリシーにより、かなりきつめのアクセス制御が掛けられています。

このCOPPERHEADは非常にセキュアな作りとなっていますが、反面、アプリケーションを動かすと頻繁に下記のようなエラーを見ることになります。

また、COPPERHEADは5月前後に色々開発元でゴタゴタがあり、現在は旧バージョンのイメージがメンテされない状態になっています。これから使う場合には、新バージョンをインストールする必要があるようです。

Using the TPM NVRAM to Protect Secure Boot Keys in POWER9 OpenPOWER Systems - Claudio Siqueira de Carvalho, IBM

発表資料はこちら

IBM社のClaudio Carvalho氏が、POWER9 OpenPOWER SystemのTPMとセキュアブートについて解説しました。POWER9のBOOTフロー、FirmwareセキュアブートとOSセキュアブートのフローが紹介されました。

このセッションでは、TPMv2 のNVRAM(不揮発性メモリ)で保護されているキーを使用してセキュアブートを行っているという実装面の話が紹介されていました。

まとめ

今回は2日目の午前中までしか参加できませんでしたが、午後にも非常に興味深いセッションが用意されていました。各セッションの内容は発表資料やYoutubeの解説動画によりある程度は掴めると思います。

今回Linux Security Summit 2018に参加して感じたのは、やはり日本人の参加が圧倒的に少ない(数人見かけたアジア系の方々も中国系だった)ことです。これは特に「Linuxのセキュリティ実装部分で日本人が本家のコミュニティに貢献できていないのでは」という心配に繋がっています。今回参加しただけでも、かなりのプロジェクトで参加者を募っていたので、もし興味がある分野があれば積極的に参加してみてはいかがでしょうか。