SimpleNote.render 関数で context 変数を確認し、何を利用できるかを調べました:

自分の経験から、Utils、Manager、service などのキーワードを含む context/class を重点的に確認します。$jirautils という context（クラス com.atlassian.jira.util.JiraUtils）に、メソッド public static <T> T loadComponent(String className, Class<?> callingClass) が含まれていることに注目しました：

このメソッドの機能と使い方をドキュメントを探して調べました。入力に String className があり、出力がクラスということは、このメソッドがクラスを任意にロードできる可能性が非常に高いです：

• ドキュメントにあるように、この関数はクラスをロードするためのものです :) さっそく、そのメソッドで本当に任意のクラスをロードできるかどうかを確かめます：

System -> Email templates を開き、現在のテンプレートファイルをダウンロードしました。

テンプレートにはさまざまな種類があり、それぞれが異なる通知タイプ専用です。そこで、email\html\includes\header.vm のように、複数の通知タイプで共通利用できるファイルを探しました。

編集したテンプレートファイルをアップロードし、SendBulkMail で通知メールを送信しました。すると、メールに次のような出力が含まれていました：

おそらく、このクラスにはコンストラクタがないか、受け入れられないようです。そこで、コンストラクタ（引数なし）を持つ別のクラスを試してみました：

結果は期待どおりで、クラスの取得に成功しました：

• これで、クラスをほぼ任意にロードできるようになりました。なかなか良いです。しかし、どうすればRCEまで到達できるのでしょうか??? JiraはVelocityテンプレートを使用しており、サンドボックスはかなり充実しています。ブラックリスト化されたパッケージとブラックリスト化されたクラスがあり（後者では、ブラックリスト化されたクラスを継承するすべてのクラスもブロックされます）。インターネット上で公開されているクラスを利用することはほぼ不可能です。そこで、脆弱性のあるバージョンとパッチ適用済みバージョンの差分を確認する必要があります。もちろん全体をdiffするのではなく、Velocityの設定ファイル (\atlassian-jira\WEB-INF\classes\velocity.properties) だけをdiffして、何が更新されたかを確認しました：

3つのクラスがブラックリストに追加されたことがわかります：

各クラスを確認すると、SpelExpressionParser クラスに public SpelExpression parseRaw(String expressionString) という関数があることがわかりました。Googleで少し使い方を調べたところ、おおよそ次のように使えるようです：

ご覧のとおり、parseRaw 関数は org.springframework.expression.spel.standard.SpelExpression クラスのオブジェクトを返すだけで、渡した式を実際にレンダリングするわけではありません。SpelExpression クラスを調べると、getValue メソッドがありました：

入出力を見て、スピリチュアル系の人間である私は、ドキュメントを読まずにすぐ試すことにしました：

結果は次のとおりです：

III) 結論

以上のように、VelocityのサンドボックスをバイパスしてRCEが可能になりました。しかし、このバグを発見した作者の立場に立つと、自分には説明できない疑問がいくつか残ります：

• なぜブラックリストに3つのクラスも追加されたのか？

この3つのクラスを調べると、それらが1つのチェーンを形成できることに気づきました：

もし作者が私と同じように $jirautils を使っていたなら、残りの2つのクラスは必要ないはずです。しかし、作者が $jirautils を使わなかった場合、どうやってComponentAccessorを取得したのでしょうか???

• 作者はどうやって上記の3つのクラスを見つけ出したのか？ これは私が最も関心を持ち、ぜひ知りたい疑問ですが、おそらく作者に直接連絡するしかありません。残念ながら、このバグの作者が誰なのかはわかりません。

IV) パッチをさらにバイパスする