脆弱性

3.7.0 未満のすべてのバージョン

中

以前のバージョンの Wrapper では、JVM へのバックエンド接続を確立する際に、ローカル環境で実行されているプロセスに対して、ある程度の信頼を前提としていました。接続は認証されていましたが、コマンドラインで公開されたキーに依存していました。悪意のあるプロセスがこのキーを傍受し、JVM よりも先に接続することで競合状態に勝つことができる、ごくわずかな時間的猶予が存在していました。

Windows では、キーは同じユーザーアカウントで実行されているプロセス、または管理者権限を持つプロセスにのみ公開されるため、キーの不正取得のリスクは限定的でした。しかし、パイプスクワッティングというリスクがありました。攻撃者が Wrapper より先に名前付きパイプを作成し、正当な接続の確立を妨害する可能性があったのです。

これらの脆弱性は、主に信頼できないユーザーがローカル実行権限を持つマルチユーザーシステム、または既に侵害されている環境において懸念されます。悪用された場合、ローカル攻撃者はサービス拒否（JVM の接続を阻止する）を引き起こしたり、Wrapper と JVM 間でやり取りされる機密データを傍受したり、場合によっては偽のプロセスID（PID）を送信して、意図しないプロセスを終了させるように Wrapper を騙したりする可能性があります。

Wrapper ver. 3.7.0以降、Wrapper はより厳格なセキュリティ対策を採用し、信頼できるローカル環境を前提としなくなりました。JVM との真に安全な通信チャネルを確立するため、チャネルの作成から認証、データ整合性の検証に至るまで、バックエンド通信のいくつかの側面が再設計されています。

最も注目すべき変更点は以下のとおりです。

• デフォルトのバックエンド接続タイプが「PIPE」に変更されました。PIPE は、プロセス間1対1通信において、TCP/IP ソケットよりも本質的に安全です。

• Windows では、追加の保護機能によってパイプスクワッティングやサービス拒否（DoS）攻撃が防止されおり、ピアプロセス認証時の PID および SID（セキュリティ識別子）の検証によって、その防御がさらに強化されています。

• すべての接続タイプにおいて、以前はコマンドラインシステムプロパティ（-Dwrapper.key）として渡されていた認証キーは、起動されたJavaプロセスにのみ渡され、より強力な暗号エントロピーで生成されるため、漏洩や推測のリスクが軽減されます。

• 接続ライフサイクルが再設計され、不正な接続試行を拒否してスキップし（正当なプロセスが確実に接続できるように）、JVM を再起動する必要がある場合は正常にリセットされるようになりました。

• 確立された接続を介して受信した、報告されたクライアント PID（およびプロフェッショナル版の場合は子プロセスの PID）の整合性が厳密に検証され、不正なプロセス終了が防止されるようになりました。

• Unix システムでは、バックエンドチャネルのファイルディスクリプターは無関係なサブプロセスに継承されなくなったため、干渉の潜在的な経路が排除されました。

• Wrapper を 3.7.0 以上のバージョンにアップグレードしてください。

• アップグレードが実施できるまでの間、Unix システムにおいては、以下の対策を検討してください。

  • Wrapper のバージョン3.6.0 以降（#13 を参照）を実行する場合は、［wrapper.backend.type=PIPE］を使用してください。匿名パイプは子プロセスに排他的に継承されるファイルディスクリプタに依存するため、認証キーが公開されている場合でも、接続は本質的に無関係なローカルプロセスから保護されます。

  • OS レベルのセキュリティ強化設定で、権限のないユーザーからプロセスコマンドラインを非表示にするように設定されていることを確認してください。設定方法はプラットフォームによって異なります（例：Linux では /proc に対してhidepid、FreeBSD ではsecurity.bsd.see_other_uids=0 sysctl）。なお、一部のオペレーティングシステムでは、この可視性がデフォルトで制限されていることに注意してください。

• Wrapper をホストするマシンが、信頼できるユーザーのみにローカル実行アクセスを制限するようにしてください。

3.6.3 未満のすべてのバージョン

警告

Wrapper ver. 3.5.16 以降を使用するアプリケーションは、 wrapper.disable_tests を TRUEに設定して、テスト機能の潜在的な誤用をブロックすることができます。 この設定が適用されていない場合、実行を未検証（および潜在的に悪意のある）コードを可能にするアプリケーションの セキュリティリスクは高いです。

「WrapperManager」クラスは、一般的なアプリケーション障害をテストするために設計されたいくつかの方法を公開します。 テストに役立ちますが、これらの方法は、実行時に信頼されていないコードによって呼び出された場合、セキュリティリスクを 引き起こす可能性があります。

Wrapper は、非常に初期のバージョン以来、これらおよびその他の機能へのアクセスを制御するための セキュリティマネージャーrの使用をサポートしています。 ただし、セキュリティマネージャーが開発者が使用することはめったにないため、Java 17 以降は廃止され、その後 Java 24 以降のスタートアップで無効になりました。

別の方法として、［wrapper.disable_tests］プロパティは Wrapper ver. 3.5.16 でテスト方法をグローバルに無効にするために導入されました。 ただし、そのデフォルト値は ver. 3.6.2 より前のすべてのバージョンで「FALSE」でした。 つまり、プロパティを明示的にコンフィギュレーションに追加し、効果的に「TRUE」に設定する必要がありました。

もし、セキュリティマネージャーも［wrapper.disable_tests］プロパティもアクセス制限に使用されない場合、 アプリケーション内で実行される信頼できないコード（悪意のあるプラグインや侵害されたプラグイン、JAR ファイル、 動的に読み込まれたモジュールなど）がこれらのメソッドを呼び出して、速度低下やクラッシュなどの問題を引き起こし、 サービス拒否 (DoS) 状態につながる可能性があります。

Ver. 3.6.3 は、［ wrapper.disable_tests ］のデフォルト値を「TRUE」に変更し、プロパティが明示的に「FALSE」に 設定されたときに警告を記録し、JVM 内のテスト機能の信頼できない実行を防ぐための測定値を追加することにより、 デフォルトのセキュリティ姿勢を改善します。

• （Wrapper バージョンが 3.5.16 以上の場合、） 設定ファイルに［wrapper.disable_tests=TRUE］を追加するか、

• Wrapper を 3.6.3 以上のバージョンにアップグレードしてください。

• 安全なアプリケーション設計の一般的なガイドラインとして、プラグインとモジュールの読み込みを常に 信頼できる検証済みのコードに制限してください。

3.5.8 から 3.5.60 までのバージョン

致命的（機密データがバックエンド経由で渡され（3.5.57版以降のバージョンで可能）、かつバックエンドが「PIPE」に設定されている場合）

［wrapper.backend.type=PIPE］ を使用すると、Wrapper は権限が緩すぎる名前付きパイプを作成します。Windows エディションは影響を受けず、PIPE を安全に使用できます。

［wrapper.app.property］プロパティを使用してバックエンド経由で機密データを渡すと、サーバーにアクセスできるすべてのユーザーがパイプの内容を表示できるため、セキュリティ上の懸念があります。

デフォルトの送信タイプでは SOCKET が使用されるため、この問題は発生しません。

• ［wrapper.backend.type=SOCKET］を使用するか、

• 適切な権限を持つ匿名パイプを使用する Wrapper ver. 3.6.0 以上のバージョンにアップグレードしてください。

3.5.58 未満のすべてのバージョン

警告

旧バージョンの Windows との互換性を確保するため、Microsoft 社は Windows サービスにおいて「SeImpersonatePrivilege」をデフォルトで有効化することを決定しました。この特権は、サービス開始時にサービス コントロール マネージャー（SCM）によって「SERVICE」グループの動的な追加を通じて自動的に付与されます。

「SeImpersonatePrivilege 」を使用すると、プロセスは別のユーザーの ID を借用できます。これは、異なるユーザーコンテキストにおけるプロセスの動作をテストするのに便利ですが、重大なセキュリティリスクも伴います。この特権は、Windows システムで最高レベルの特権を持つ LocalSystem アカウントに昇格することで悪用される可能性があります。

このセキュリティ問題は、「LocalSystem」以外のアカウントで実行するように設定されたサービスにのみ適用されます（それ以外の場合、サービスは既に最高特権を持っています）。ただし、ホスティングシステム上の Java アプリケーションへのアクセスを制限し、逆に他のサードパーティプロセスがアプリケーションや Wrapper ファイルにアクセスするのを防ぐため、専用のサービスアカウントで実行することが推奨される場合が多くあります。

ver. 3.5.58 以降、LocalSystem（NT AUTHORITY\SYSTEM）以外のアカウントで Windows サービスとして実行されている場合、Wrapper は「SeImpersonatePrivilege」を無効にします。ほとんどの Java アプリケーションではこの特権は必要ありませんが、必要な場合は［wrapper.ntservice.impersonation］プロパティを使用して再度有効にすることができます。

• Wrapper を 3.5.58 以上のバージョンにアップグレードするか、

• サービスに必要な権限を設定してください。（要：プロフェッショナル版、ver. 3.5.57 以上）

• ローカルセキュリティポリシー設定を編集することは可能ですが、他のサービスに影響を与えるリスクがありますので、推奨されません。

3.5.58 未満のすべてのバージョン

高（以下の条件に当てはまる場合）

Wrapper Java API は、ユーザーコードから指定されたログレベルでメッセージをログ出力できるようにする WrapperManager.log() メソッドを提供しています。ログ出力メッセージである第 2 引数に「%」文字が含まれている場合、Wrapper がクラッシュし、サービス拒否攻撃が発生する可能性があります。

最終的に WrapperManager.log() メソッドに渡されるユーザー入力を使用する場合、アプリケーションは危険にさらされます。

• Wrapper を 3.5.58 以上のバージョンにアップグレードするか、

• WrapperManager.log() メソッドを呼び出す前に、ログに記録するメッセージ文内の「%」記号を削除してください。

3.5.55

警告

Windows バイナリは署名されていません。

アップグレードされた EV 証明書で署名された Wrapper ver. 3.5.56 を使用してください。

3.5.44、 3.5.45

警告

jar ファイルは、古いコード署名証明書で署名されています（タイムスタンプは 2027-06-27 まで有効ですが、有効期限は 2020-12-15 です）。

jar ファイルは安全に実行できます。

特別な操作は必要ありません。

3.5.44

中

Windows バイナリ（wrapper.exe、wrapperw.exe、wrapper.dll）はデジタル署名されていません。

署名がないことはそれ自体がセキュリティ上の脅威となるわけではありませんが、デジタル署名のないバイナリの真正性と整合性を検証することはできません。そのため、Microsoft Defender SmartScreen は最初の実行をブロックし、セキュリティリスクを警告する場合があります。

• Wrapper を 3.5.45 以上のバージョンにアップグレードしてください。

• 必ず Wrapper バイナリを公式 Java Service Wrapper ウェブサイトからダウンロードし、変更できない安全な場所に保存してください。

3.5.35 から 3.5.40 までのバージョン

高（wrapper.lang.windows.encoding を使用する場合）

Wrapper ver. 3.5.35 より、［wrapper.lang.windows.encoding］ではプロセスで使用されるロケールのエンコーディングを変更できるようになりました。これは、例えばログ出力を「UTF-8」で出力したり、特定のエンコーディングを使用したりする場合に便利です。

［wrapper.lang.windows.encoding］が設定されている場合、Wrapper は JVM 出力を別のモードで読み取ります。このモードには、JVM 出力にパーセント文字「%」が含まれていると Wrapper がクラッシュする可能性があるというバグがあります。

クライアントのユーザー入力がログに記録されてしまう場合、アプリケーションは特に危険にさらされ、サービス拒否攻撃に対して脆弱になります。

• Wrapper を 3.5.41 以上のバージョンにアップグレードするか、

• ［wrapper.lang.windows.encoding］をコメント化するか、デフォルト値 (ANSI) に設定してください。

3.5.35

高

［wrapper.lang.windows.encoding］プロパティを使用すると、Wrapper プロセスで使用されるロケールのエンコーディングを変更できます。UTF-8 文字列は、4096 文字の固定サイズバッファーを使用する別の関数で処理されます。この幅を超える JVM 出力はバッファーオーバーフローを引き起こします。

大量のユーザー入力がログに記録されると、Wrapper がクラッシュし、サービス拒否攻撃につながる可能性があるため、アプリケーションは特に危険にさらされます。

［wrapper.lang.windows.encoding］がデフォルト値の「ANSI」のままになっている場合、または UTF-8 以外のエンコーディングが使用されている場合、Wrapper は影響を受けません。

• Wrapper を 3.5.41 以上のバージョンにアップグレードするか、

• 「wrapper.lang.windows.encoding」を「UTF-8」以外の値に設定してください。

3.5.8 から 3.5.11 までのバージョン

致命的

UNIX プラットフォームでは、デーモンプロセスとして実行されているときに、デフォルトの umask は親プロセスから値を継承するのではなく、「0000」に設定されます。

ログファイルおよびその他のファイルは、グローバルな読み取り/書き込みアクセス権を持ちます。

Java プロセスのデフォルトの umask も「0000」であり、Java アプリケーションによって作成されたファイルも、明示的に新しい権限を設定しない限り、すべて「0000」になります。

アンカーファイルが使用されている場合、誰でも削除でき、Wrapper が停止する可能性があります。

• Wrapper を 3.5.12 以上のバージョンへアップグレードするか、

• ［wrapper.umask］プロパティを安全な値に設定してください。

3.3.7 未満のすべてのバージョン

警告

厳格な SELinux セキュリティポリシーにより、Wrapper がライブラリを読み込みできない可能性があります。

この問題は、SELinux が有効になっているシステムで実行する場合にのみ発生します。

• Wrapper を 3.3.7 以上のバージョンにアップグレードしてください。

3.3.0 未満の全てのバージョン

高

64 ビット UNIX では、システムシグナルがトラップされたときにネイティブ同期の問題によってクラッシュが発生する場合があります。参照：バグ #1614010

この脆弱性は、第三者プロセスによってサービス拒否攻撃を試みられる可能性があります。

32 ビットバイナリ、または Windows は影響を受けていません。

• Wrapper を 3.3.0 以上のバージョンへアップグレードするか、

• ［wrapper.ignore_signals=TRUE］を使用してください。（非推奨）

3.0.0 から 3.1.2 まで、または 3.2.2 から 3.2.3 までのバージョン

高

サービスのインストール時にコマンドラインでパスワードを指定した場合、 ［wrapper.ntservice.account］や［wrapper.ntservice.password］の値はレジストリ内にプレーンテキスト形式で保存されていました。

• バグ #1538725

• バグ #1110183

• Wrapper を 3.1.2 以上のバージョンへアップグレードしてください。

• Wrapper を Windows サービスとしてインストールするときに［wrapper.ntservice.account］または［wrapper.ntservice.password］を指定しないでください。

Wrapper ver. 2.2.6 未満のすべてのバージョン

高

JVM 出力内のパーセンテージ記号「%」により Wrapper がクラッシュする可能性があります。

クライアントのユーザー入力がログに記録されてしまう場合、アプリケーションは特に無防備になり、サービス拒否攻撃に対して脆弱になります。

• Wrapper を 2.2.6 以上のバージョンへアップグレードしてください。