プラットフォーム技術部の佐藤です。

だいぶ前の話になりますが、CentOS7/RHEL7のSELinuxポリシーのバグフィックスで、tomcatプロセスを制限のあるプロセス(confined)として動作させられるようになりました。

以前は制限のないプロセス(unconfined)の状態で、実質SELinuxのアクセス制御を受けない状態でした。
Firewallのルールに例えると、制限なし(unconfined)は最後のルールがallow all、制限あり(confined)は最後のルールがdeny allな状態です。

ただ、実はこのバグフィックスだけではtomcatサービスが起動できない状態になってしまうので、そのまま適用するためには次のバグフィックスまで待つ必要がありました。

これらのバグフィックスを受け、晴れて制限ありプロセスとして動作するようになったtomcatで、Web Application Frameworkの脆弱性であるリモートコード実行(RCE)が防げるようになったのか試してみようと思います。

環境

今回の検証環境は以下になります。

  • CentOS Linux release 7.5.1804
  • tomcat-7.0.76-6.el7.noarch
  • selinux-policy-3.13.1-192.el7_5.3.noarch
  • selinux-policy-targeted-3.13.1-192.el7_5.3.noarch

Web Application FrameworkはStruts 2.5.10を使用します。脆弱性は以下になります。

Web ApplicationはStruts2に同梱されているsturts2-showcase.warを使用します。

実験開始

まずは環境構築

最初にtomcatパッケージをインストールします。unzipはあとでstruts2のサンプルアプリケーション展開に使います。

strutsのサンプルアプリケーションを入手しデプロイします。

tomcatを起動します。

SELinux無効状態でRCE動作確認

SELinux無効化状態でRCEできるか確認してみます。

ではExploit Codeを実行してみます。

はい。意図したとおりコード実行できました。

SELinux有効状態でRCE防げるか確認

では、いよいよSELinuxを有効にしてRCEを防げるか試してみます。

Exploit Codeを実行してみます。

おっと。残念ながら変わらず実行できてしまいました。せっかく制限つきプロセス(confined)になったのにどうしてでしょうか?

制限つきプロセス(confined)とはいっても許可されているものは実行できる状態なので、今回実行したheadコマンドは実行許可されており、/etc/passwdに対する読み込みも許可されているということなのでしょう。
setoolsを使ってtomcatのポリシーを調べてみます。

先ほどのheadコマンドを確認してみます。

タイプはbin_tが付与されています。

tomcat_tに実行権限(execute)が付与されているタイプを調べるとこれだけありました。やはりbin_tは実行が許可されています。

※sesearchの–directオプションで確認できる直接許可されているタイプはtomcat_exec_tとpki_common_tのみです

上記タイプに属さない実行ファイルを探してみます。

dmesgが丁度よさそうです。ちなみにtomcatユーザーにスイッチした対話シェルはunconfinedになりますのでdmesgも実行できます。

でもtomcat_domainで動くtomcatサービスにはdmesgを実行する権限がないのでRCEは防げるはず!

はい。こちらはきちんと実行防止できました。audit.logではSELinuxで拒否された様子が確認できます。

考察

今回の実験では、標準のSElinuxポリシーだけでtomcatで動作するWeb ApplicationのRCEを完全に防ぐには不十分ということがわかりました。 ただ、tomcatの権限はある程度制限されるようになりましたので、それだけでも被害を軽減する効果はあると思います。 例えば、ファイルシステムのパーミッション以上に読み書き可能なディレクトリが制限されていたり(/tmpには書き出せません)、実行可能ファイルもdmesgやpingはダメでしたし。

実は海外には、自分でポリシーを作成してtomcatをより厳しい制限ありプロセスとして動作させている方もいらっしゃます。CentOS 6での記事になりますが。

機会がありましたら、次回は更に厳しいSELinuxポリシーを自作してみたいと思います。

 

この記事が気に入ったら
いいね!しよう

最新情報をお届けします

Twitter で「株式会社アークシステム」をフォローしよう!

【CVE-2017-5638 / S2-045】SELinuxポリシーのバグフィックスでTomcatアプリのRCEは防げるようになったのかhttps://devlog.arksystems.co.jp/wp-content/uploads/2018/06/cat-1199937_1280-1200x798.jpghttps://devlog.arksystems.co.jp/wp-content/uploads/2018/06/cat-1199937_1280-150x150.jpgksatoプラットフォーム技術部システム運用・保守Tomcat,Struts2,SELinuxプラットフォーム技術部の佐藤です。 だいぶ前の話になりますが、CentOS7/RHEL7のSELinuxポリシーのバグフィックスで、tomcatプロセスを制限のあるプロセス(confined)として動作させられるようになりました。 以前は制限のないプロセス(unconfined)の状態で、実質SELinuxのアクセス制御を受けない状態でした。 Firewallのルールに例えると、制限なし(unconfined)は最後のルールがallow all、制限あり(confined)は最後のルールがdeny allな状態です。RHBA-2017:1861 - Bug Fix Advisory Bug 1432083 – tomcat_t domain is in unconfined_domainただ、実はこのバグフィックスだけではtomcatサービスが起動できない状態になってしまうので、そのまま適用するためには次のバグフィックスまで待つ必要がありました。RHBA-2018:0763 - Bug Fix Advisory Bug 1470735 – tomcat fails to start via tomcat-jsvc service startup due to selinux denialsこれらのバグフィックスを受け、晴れて制限ありプロセスとして動作するようになったtomcatで、Web Application Frameworkの脆弱性であるリモートコード実行(RCE)が防げるようになったのか試してみようと思います。 環境 今回の検証環境は以下になります。CentOS Linux release 7.5.1804 tomcat-7.0.76-6.el7.noarch selinux-policy-3.13.1-192.el7_5.3.noarch selinux-policy-targeted-3.13.1-192.el7_5.3.noarchWeb Application FrameworkはStruts 2.5.10を使用します。脆弱性は以下になります。S2-046 - Apache Struts 2 Documentation - Apache Software...ARK Solution Development Division Developers Blog.