JNDIの活用〜Tomcat 6.0.18の脆弱性に思う事〜

Tomcat6.0.18以下に脆弱性があると発表があったのですが、内容を見て少し考えこんでしまいました。

IPAのレポートを要約してみる

IPAによると、Apache Tomcat 6系の6.0.18以下に情報漏えいの脆弱性が発見された模様。同日に公開された脆弱性も共に対策済みの6.0.20が出ているため、該当バージョンを使用している方は6.0.20にアップデートが必要だそうだ。
同レポートによると、4.1.0〜4.1.39、5.5.0〜5.5.27にも影響があり、3.0系・4.0系・5.0系も影響がある可能性がある。
また同レポートは、対応版が出ていない4.1.xと5.5.xを利用している時は、snvからコンパイルするようにアドバイスしている。
また脆弱性の内容は

特定メソッドを利用した実装の時、WEB-INF ディレクトリ配下の情報が漏えい
AJPコネクタでlbワーカを利用している場合、約１分間利用不可能になる

ということで、WEBアプリケーションの実装次第では情報漏洩やDoSの危険性が指摘されている。

JNDIを使えば楽に…ならないんだよね…

WEB-INF下の情報が漏洩すると困るような実装は、JNDIをしっかり使えば退避可能でしょう。
その際に大きく問題になると思われるのは二点。

設定の標準的な管理方法がない
例えばTomcatの場合はJava Mailに対するリソース設定が標準ではない(作ることは可能)など、標準的に使える設定種類が不足している。

詳しく見てみます。

設定の管理方法について

前者…は私の勘違いかもしれないのですが…。
例えばDataSource設定の場合、IPとIDとパスワードといったリソース値を管理する方法が、APサーバによってバラバラで統一感がありません。
それ自体はセキュリティなどに対する標準的なポリシーがAPサーバ毎に違うため致し方ないのですが、値がヤンゴトナキ事情により変更となる場合、大抵APサーバのサービス再起動が必要となるでしょう。
また、GUIなどから値をいじれる場合、その永続化がされる場合とされない場合があったりします。
まずAPサーバがオンラインのままでも設定値が永続化でき、サービス全体を再起動しなくても反映でき、更に設定値の棚卸しに対応できるようなインターフェースを備えた仕組みが、共通的にあるとJNDIが使いやすいのだけど…という、タダのグチです。

リソース設定の標準的な形がない

せめてSMTPの設定くらいはほしいし、欲を言えばSOAPで使用するIDやパスワードなども管理したいわけだけど、出来るAPサーバと出来ないAPサーバがある。
特に商用APサーバを利用する場合、結構開発環境はTomcatだのGlass FishだのJBossだのといった具合で済ませている場合が多く、これらのAPサーバ達(サーブレットコンテナと呼んだほうがイイのかもしれない)が対応してくれないことには、アプリケーション実装者達は使いたがらないだろう。
上流から命令が下れば、何とかするのだろうけど。
# ちなみに私の場合は、自分でやりたかったからやっただけです

JNDIが使いやすければ、もっとよくなるのに

と、今のところ二点の問題があって、JNDIはなかなか設定ファイル代わりとして使用されない状況にあるのではないかと推測しております。
そのあたりを整理が出来たら面白そうなのですが。

それはそうと、Tomcatを利用したアプリケーション…例えばJBossなどを使っている場合は、対応できるまでに時間がかかると考えるべきなのでしょうか。