4.4.x
5.x.x
6.x.x
7.0.x
7.1.x
7.2.x
7.3.x
7.4.x
7.5.x
7.6.x before 7.6.14 (the fixed version for 7.6.x)
7.7.x
7.8.x
7.9.x
7.10.x
7.11.x
7.12.x
7.13.x before 7.13.5 (the fixed version for 7.13.x)
8.0.x before 8.0.3 (the fixed version for 8.0.x)
8.1.x before 8.1.2 (the fixed version for 8.1.x)
8.2.x before 8.2.3 (the fixed version for 8.2.x)
./bin/setenv.bat ファイル内の set JVM_SUPPORT_RECOMMENDED_ARGS= の値を修正します（Linux では ./bin/setenv.sh も同様）。set JVM_SUPPORT_RECOMMENDED_ARGS=-agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=5005
Remote JVM Debug を作成し、host と port を localhost:5005 に設定し、Command line aguments for remote JVM に次のように指定します。-agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=*:5005
./bin/config.bat（Linux では ./bin/config.sh）を実行し、「Jira home」を自分の Jira home ディレクトリに変更します。
./bin/start-jira.bat（Linux では ./bin/start-jira.sh）を実行します。起動できない場合は、Java のバージョン、ポート 8080 と 5005 が空いているか確認してください。
プライベートモードを選択します
この手順では、メールを受信できるメールアドレスを使用してください :)
設定とテスト接続をしっかり行ってください
http://localhost:8080/secure/admin/EditApplicationProperties!default.jspa で Contact Administrators Form 機能を有効にします
ビルド時の注意点をいくつかメモしました。詳細は building jira from source を参照してください。
Advisory を読むと、このバグが ContactAdministrators と SendBulkMail にあることがわかります（SendBulkMail は認証が必要なため省略します）。そこで、ContactAdministrators 機能をテストしてリクエストを取得しました。
/secure/ContactAdministrators.jspa へのリクエストを確認したので、./atlassian-jira/WEB-INF/web.xml を見て、このリクエストがどのクラスに転送されるかを調べました
つまりリクエストは JiraWebworkActionDispatcher で処理されます。そこでこのクラスの init と server にブレークポイントを設定してデバッグを実行しました。
プログラムは server 関数で停止し、しばらくトレースすると ContactAdministrators.doExecute() に入りました。
次に send に進みます。ここでプログラムは稼働中の管理者アカウントを列挙します。
その後、プログラムは sendTo 関数に進みます。ここで MailQueueItem を作成し、それを mailQueue に追加しているのがわかります。
プログラムは EmailBuilder.withSubject 関数を呼び出します。ここで、メールの subject 文字列（攻撃者から送信されたもの）が String から TemplateSources に変換され、EmailBuilder の subjectTemplate パラメータに割り当てられます。
renderLater 関数では、プログラムは EmailRenderer を作成し、それを使用して RenderingMailQueueItem を作成します。
ここから ContactAdministrators.sendTo 関数に戻ります。MailQueueItem の作成後、プログラムはアイテムを mailQueue に追加し、doExecute 関数に戻ってリダイレクトします。このデバッグフローに従うと、プログラムがメールをレンダリングする部分に到達できないため、テンプレートインジェクションが発生する箇所に到達できません。では、メール処理を追跡するにはどうすればよいのでしょうか？
EmailRenderer には renderNow 関数があることに気づきました（プログラムは renderLater しか呼び出しません）。キュー内のメールがレンダリングのために呼び出される際も renderNow と同じフローをたどるだろうと推測し、renderNow 関数からトレースすることにしました。
renderNow から、プログラムは EmailRenderer.render() を呼び出します。ここにブレークポイントを設定し、再度リクエストして、実際にここまで実行されるか確認しました。
幸運なことに、プログラムは予想どおりの流れで動きました。次に、プログラムは renderEmailSubject を呼び出します。
次に、プログラムは DefaultVelocityTemplatingEngine.render(this.subjectTemplate) を呼び出します。
DefaultVelocityTemplatingEngine.applying と DefaultVelocityTemplatingEngine.asPlainText に進みます。
続いて asPlainText(Writer writer) を呼び出します。
toWriterImpl に進みます。渡した writer が Fragment であるため、プログラムは else に分岐します。
private void toWriterImpl(Writer writer, boolean attachCartridge) throws IOException {
if (this.source instanceof File) {
File template = (File)this.source;
if (attachCartridge) {
this.context.attachEventCartridge(DefaultVelocityTemplatingEngine.this.createDefaultCartridge());
}
DefaultVelocityTemplatingEngine.this.velocityManager.writeEncodedBody(writer, template.getPath(), "", DefaultVelocityTemplatingEngine.this.applicationProperties.getEncoding(), this.context);
} else if (this.source instanceof Fragment) {
Fragment fragment = (Fragment)this.source;
if (attachCartridge) {
this.context.attachEventCartridge(DefaultVelocityTemplatingEngine.this.createDefaultCartridge());
}
DefaultVelocityTemplatingEngine.this.velocityManager.writeEncodedBodyForContent(writer, fragment.getContent(), this.context);
}