本記事は2022年3月30日（米国時間）/2022年3月31日（日本時間）に公開した英語ブログSpring4Shell: What we know about the Java RCE vulnerability (当初は “Is There any Such Thing as Spring4Shell?” 「Spring4Shellなんてあるんですか？」として公開) を日本語化した内容です。(最終更新: 英語版 2022年4月1日0時、日本語版 2022年4月2日13時)
Spring4Shell: このJavaのRCE脆弱性について分かったこと
もうSpring4Shellについてよくご存知ですか？本記事のSpring4Shellへの対応策の項目へ進むか、Spring4Shellの解説記事をご覧になり、このゼロデイのリモートコード実行 (RCE) の仕組みを確認してください。
米国時間の3月30日の未明、同僚のDeveloperSteveがslackチャンネルに「なあ、これ見たことある？」と書きました。それは、大人気のJava の Springフレームワークで『起こりうる』リモートコード実行（RCE）の「事前警告」でした。後で知ったのですが、それより前にSnyk のセキュリティチームは動きはじめていたそうです。後に消去されたツイートをきっかけにして、SpringのRCE脆弱性らしきものの調査を行っていました。
当初の時点では、詳細はよくわからないようでした。スクリーンショット付きのツイートがありましたが、削除されていました。プルリクエスト（PR）への言及がありましたが、分かったのは、最初にアップされたのが2月18日で、マージされたのは3月29日ということでした。
“Spring4Shell” (または単に”SpringShell”) というニックネームを定着させようとする人たちがいて、その一方でSpring Coreのメンテナー（管理者）は「既知のRCEは存在しない」というコメントをPRに残していました。
では、一体何が起きていて、今はどうなっているのでしょうか？
Spring4Shellとは？
もしあなたが ＠Autowired アノテーションを使用したり、コンストラクタ注入の魔法を利用したことがあるなら、Springのエコシステムで依存性注入に遭遇したことがあるはずです。
影響を受けるバージョンでは、HTTP POSTリクエストを作り込むことでClassLoaderを操作し、RCEを実行することができます。
現時点では、Java Runtime Environment (JRE) バージョン9以上およびTomcatバージョン9以上 * の組み合わせでのみ、この悪用が可能であることが確認されています。
(* 訳注 この脆弱性対応としてTomcatの新バージョンがリリースされています。Spring Framework RCE, Mitigation Alternative)
Snykのセキュリティ研究者は、不完全な情報に基づいて行動したくないため、3月30日は一日中、状況を確認することに時間を費やしました。
現時点での我々の結論は、Spring Coreのspring-beansパッケージにはRCEの脅威が確かに存在する、というものです。脆弱性には正式にSpring4Shellという名前がついています。Springエコシステムには公式なSpring Shellというプロジェクトが存在するので、（以前一部で使われていたSpring Shellではなく）この呼び方は理にかなっています。
状況の進展に応じて、Snyk脆弱性データベースを通じて最新情報を引き続き提供します。
Spring4Shellへの対応策
これまでの攻撃を防ぐことができるSpring Frameworkの新バージョンがリリースされました。バージョン5.2.20と5.3.18です。
もしSpring Bootを使っているなら、ちょうどバージョン2.5.12と2.6.6がリリースされました。Spring Frameworkとspring-beansへの変更が含まれています。
以下は修正方法のリストです。より望ましい方法から列記しています。
- 直接Spring Frameworkを使っている場合は、バージョン
5.2.20または5.3.18にアップグレードしてください - Spring Bootを使っていれば、バージョン
2.5.12または2.6.6を使ってください。 - Springをアップグレードできない場合、JREのバージョン8とTomcatのバージョン8の両方、またはいずれかを使って問題を防いでください **
(** 訳注・再掲 この脆弱性対応としてTomcatの新バージョンがリリースされています。Spring Framework RCE, Mitigation Alternative)
Springに対してより多くのアップデートが行われるかもしれないことを申し添えます。追加で、別の脆弱性が見つかる可能性があるからです。今回のような深刻度の高い問題には注目が集まるため、このようなことが起こりがちです (Log4Shellを思い出してください)。
Snykのツールはすでにアップデートされており、あなたのプロジェクトに脆弱性があればそれを報告します。
Snykの無料アカウントにサインアップしてください。そこから (またはコマンドラインで) 自身のプロジェクトをテストして、Spring4Shellの影響を調べることができます。
このブログ投稿を更新し、JREとTomcatのバージョン9以上でのRCEを実証するPoCコードのリポジトリを作成する予定です。最新情報は弊社のブログやSNSでご確認ください。
当初の錯綜についての考察
3月30日早朝、私たちのチームが当初確認したブログ記事のうちの一つが、その後、削除されました。この投稿は、同じく削除されたツイートを参照していました。二重の削除にもかかわらず、デシリアライゼーション（以前にもRCEを引き起こしたJavaの機能 - Log4Shell、聞き馴染みがありますね？）に関連するSpring Core関連のコミットへの検証可能な参照がありました。
このコミットのコメントにはこうあります。
Since SerializationUtils#deserialize is based on Java's serialization
mechanism, it can be the source of Remote Code Execution (RCE)
Vulnerabilities.
日本語訳:
SerializationUtils#deserialize はJavaのシリアライゼーションの仕組みを使うため、リモートコード実行 (RCE) の脆弱性の原因となる可能性がある。
時間が経つにつれ、Spring CoreでRCEが発生しているのではないかという話題が増えました（検証可能な事実はほとんどありませんが）。
さらにコメント欄で、Spring Coreのコミッターが、このコミットは既知のRCEとは無関係であることを述べた別のコメントを肯定しました。
そして実際、このコミットが解決したPRを見ると、最初にオープンされたのは2月18日です。
さて、ここで重要なことがあります。この問題が起きている間、インターネット上ではこの現在進行系の問題と、全く別のプロジェクトの別の既知の問題とが混同されていたのです。Spring Cloud Functionです。この混乱を避けるため、私はこの脆弱性の詳細には触れません。Spring4Shellについて知りたいと思ってSpring Cloudの脆弱性について何か読んでいるのなら、見当違いと言えるでしょう。
要点
この記事で紹介した修正策・緩和策を実施して、Spring4Shellから身を守ってください。Snykのフリーアカウントにサインアップすれば、すぐに修正に取りかかることができます。