349.Tomcat の脆弱性問題
初回：2024/01/31
Apache Tomcatにおける情報漏えいの脆弱性が公開されました。
P子「システムが高度化しているから、脆弱性もなかなか無くならないわね」※1
こういう問題が発生すると、すぐにオープンソースは危険だとか商用システムを使うべきだとかいう話が出ますが、オープンソースだからこそ、多くの情報が集まるという見方もできます。もちろん、商用システムの場合、セキュリティー問題が発生した場合はメーカーから連絡が来ますが、オープンソースの場合はあくまで自己責任で対応する必要があります。商用システムの場合は、知られていないだけで脆弱性が存在しないわけではない事は注意が必要です。
P子「まあ、2重、3重のセキュリティ対策は必要かもね」
1.CVE-2024-21733
《参考資料1》
https://jvn.jp/vu/JVNVU98698305/https://jvn.jp/index.html
JVNVU#98698305
Apache Tomcatにおける情報漏えいの脆弱性
公開日：2024/01/22 最終更新日：2024/01/22
影響を受けるシステム
Apache Tomcat 9.0.0-M11から9.0.43まで
Apache Tomcat 8.5.7から8.5.63まで
想定される影響
不完全なPOSTリクエストを受信した際のエラーレスポンスに、他のユーザが以前にリクエストしたデータが含まれる可能性があります。
対策方法
アップデートする
開発者が提供する情報をもとに、最新版へアップデートしてください。
開発者によると、本脆弱性は次のバージョンで修正されているとのことです。
Apache Tomcat 9.0.44
Apache Tomcat 8.5.64
対策はいたって簡単、アップデートします。
P子「動作検証とか、結構大変よ」
もちろん、脆弱性が見つかって（または報告を受けて）すぐに公開しているわけではないので、普段よりきちんとメンテ（つまりバージョンアップ）していることが重要です。
ちなみに、2024/01/27 時点の Tomcatの最新バージョンは、下記の様になっています。
Apache Tomcat 10.1.18
Apache Tomcat 9.0.85
Apache Tomcat 8.5.98
2.脆弱性レポート 一覧
《参考資料2》
https://jvn.jp/report/index.html
脆弱性レポート 一覧
最新12ヶ月
2024/01/22 JVNVU#98698305:
Apache Tomcatにおける情報漏えいの脆弱性
2023/11/29 JVNVU#96182160:
Apache Tomcatにおけるリクエストスマグリングの脆弱性
2023/10/11 JVNVU#93620838:
Apache Tomcatにおける複数の脆弱性
2023/09/14 JVNVU#96802408:
Apache Tomcat Connectors（mod_jk）における情報漏えいの脆弱性
2023/08/28 JVNVU#93446549:
Apache Tomcatにおけるオープンリダイレクトの脆弱性
2023/06/22 JVNVU#92908681:
Apache Tomcatにおける情報漏えいの脆弱性
2023/03/23 JVNVU#90635957:
Apache Tomcatにおける保護されていない認証情報の送信の脆弱性
2023/02/21 JVNVU#91253151:
Apache TomcatのApache Commons FileUploadにおけるサービス運用妨害（DoS）の脆弱性
改めて見てみると、この1年だけでも結構な数の脆弱性が公開されています。つまり、脆弱性の問題が発覚する都度、対応に追われるのではなく、常に最新バージョンに保っておけるような体制なりテスト方針なりを確立しておく必要があるという事なのかもしれません。
P子「でも直接的に関係のないケースなら、対応も不要じゃないの？」
それを脆弱性の問題が公表されるたびに確認するのは結構大変です。
例えば、前回の脆弱性では、
https://jvn.jp/vu/JVNVU96182160/index.html
2023/11/29 JVNVU#96182160:
Apache Tomcatにおけるリクエストスマグリングの脆弱性
影響を受けるシステム
Apache Tomcat 11.0.0-M1から11.0.0-M10まで
Apache Tomcat 10.1.0-M1から10.1.15まで
Apache Tomcat 9.0.0-M1から9.0.82まで
Apache Tomcat 8.5.0から8.5.95まで
対策方法
アップデートする
開発者が提供する情報をもとに、最新版へアップデートしてください。
開発者によると、本脆弱性は次のバージョンで修正されているとのことです。
Apache Tomcat 11.0.0-M11
Apache Tomcat 10.1.16
Apache Tomcat 9.0.83
Apache Tomcat 8.5.96
の時に対策（アップデート）していれば、今回の脆弱性は対策済みのはずなので、やはり最新への定期的なアップデートが良いと思います。
3.Tomcatのバージョン情報を出さない
Tomcat のデフォルト設定では、エラーページにTomcatのバージョン情報が表示されます。悪意のあるユーザーがわざとエラーを出してTomcatのバージョンを確認して、対象となる脆弱性を突いてくる可能性があるので、バージョン情報を表示しない設定を行う事が良く行われます。
P子「エラーってすぐに出せるの？」
HTTP 404 Not Found なんて、簡単に出せます。出したくないときでも出たりします。
【方法１】
Tomcatのconf/server.xml ファイルで、Hostタグの子要素 に、以下のValve を設定します。
＜Valve className="org.apache.catalina.valves.ErrorReportValve" showReport="false" showServerInfo="false" />
【方法２】
conf/web.xml に、error-page タグを設定し、エラー発生時に処理する jsp 等を指定します。
＜error-page＞
＜!-- ＜exception-type＞java.lang.Exception＜/exception-type＞ --＞
＜exception-type＞java.lang.Throwable＜/exception-type＞
＜location＞/jsp/common/error.jsp＜/location＞
＜/error-page＞
＜error-page＞＜error-code＞400＜/error-code＞＜location＞/jsp/common/error.jsp＜/location＞＜/error-page＞
＜error-page＞＜error-code＞401＜/error-code＞＜location＞/jsp/common/error.jsp＜/location＞＜/error-page＞
＜error-page＞＜error-code＞403＜/error-code＞＜location＞/jsp/common/error.jsp＜/location＞＜/error-page＞
＜error-page＞＜error-code＞404＜/error-code＞＜location＞/jsp/common/error.jsp＜/location＞＜/error-page＞
‥‥
‥‥
こうしておけば、内部処理で、キャッチし損ねたException も別のページに飛ばすことができます。
4.まとめ
セキュリティ対策として、最新版にアップデートするのは重要ですが、アップデートされるたびに更新するというわけにもいかないでしょう。かといって、脆弱性が公開される都度、アップデートの対応に追われるというのも考え物です。
個人的には組織で対応方法のルールを決めて対応するのが良いと思います。
P子「あらかじめ決めておけば、緊急対応が必要な場合でも、慌てなくて済むわね」
ほな、さいなら
======= <<注釈>>=======
※1 P子「システムが高度化しているから、脆弱性もなかなか無くならないわね」
P子とは、私があこがれているツンデレPythonの仮想女性の心の声です。