RunCに関しての脆弱性( CVE-2016-9962 )のPoCとSELinuxによるリスクの軽減
セミナー情報
こんにちは。SIOS OSSエバンジェリスト/セキュリティ担当の面です。
01/11/2017に、RunCに関しての脆弱性情報 ( CVE-2016-9962 )が出ましたが、この脆弱性を緩和するためにSELinuxが使用できるのではないかという話がこちらのサイトに出ていました。これに関してのPoCとSELinuxでどの程度守れるかについてを実際に行った記事が有りますので紹介します。
PoC記事のサイト
PoC初回(SELinuxで防げないと思われた回): http://www.secureoss.jp/post/omok-selinux-docker-20170118/
PoC二回目(SELinuxで防げた回): http://www.secureoss.jp/post/omok-selinux-docker-20170123/
CVE-2016-9962の説明
今回のCVE-2016-9962の問題を簡単に説明すると、runcでコンテナXを動かした時に、別のターミナルで”runc exec X sh”すると、その起動するタイミングでベースOSのファイルにアクセスできちゃうという問題になります。
実際にはrunc execのタイミングで行わなければならないのでハードルがそこそこ高いです。また、別のプロセスの情報を読まなくてはならないため、CAP_SYS_PTRACEのケーパビリティをコンテナに与える必要が有りますので、これも現実にはハードルになります。
PoC
PoCの方法はリンク先の最初のブログ記事に載っています（英語ですがわかりやすいと思います）。
具体的には
PoCのため”runc exec X sh”がすぐに完了しないようにruncのソースを書き換えて待ち時間をわざと作る。
コンテナにCAP_SYS_PTRACEを与えて起動するようにする。
ターミナルを”runc run X”で最初に起動する。
別のターミナルで”runc exec X sh”を実行する
最初のターミナルで”runc exec”の情報をたどるとホストOSのファイルにたどり着ける
これらホストOSの情報を見たり触ったりすることで危険です！！
というものになります。
PoC結果とSELinuxの効力
第一回目のブログを見ていただいてわかる通り、PoC自体は成功してホストOSの情報が読める状態になっていました。当初はSELinuxの効力が発揮されてないように見受けられました。
その後、SELinuxの本家MLなどで話をして、runcのSELinuxポリシ自体がPoCのような状況（ターミナルから直接runcを実行する状況）は考慮しておらず、systemdなどで起動する一般のやり方を対象にポリシが書かれていることがわかりました。
そのため、第二回目ではSELinuxのポリシを追加し、PoC専用で、ターミナルからruncを直接実行する場合でもSELinuxの支配を受けるようにしました。
結果として、SELinuxのポリシをPoC専用に追加した場合には、SELinuxの支配下になるため、ホストOSの重要なファイルにアクセスできない（lsなどの結果すら出力されない）状態になるという事がわかりました。
まとめ
今回のPoCで、SELinuxを有効にした場合であれば、runcの脆弱性を利用された場合でも、重要なファイルへのアクセスが出来ないため、悪用される度合いを軽減できることがわかりました。
これを参考に、皆様の環境のLinuxサーバでもSELinuxを有効にして頂ければと思います。特にDockerやコンテナ環境では、セキュリティを担保するためにSELinuxは有効な手段になります。