第7章 既知の問題

Velocity テンプレートを変更できる攻撃者は、Servlet コンテナーを実行しているアカウントと同じ権限で、任意の Java コードを実行したり、任意のシステムコマンドを実行したりする可能性があります。これには、バージョン 2.2 までの Apache Velocity Engine を実行する velocity テンプレートを信頼できないユーザーがアップロード/変更できるアプリケーションが該当します。

Fuse 7.9 (およびそれ以降) の依存関係は、このセキュリティー脆弱性から保護する修正された Velocity バージョン (2.3) のみを使用します。アプリケーションコードに Apache Velocity コンポーネントへの明示的な依存関係がある場合は、これらの依存関係をアップグレードして修正されたバージョンを使用することが推奨されます。

Google Guava の 11.0 から 24.1 までのバージョンは、AtomicDoubleArray クラス (Java のシリアライズでシリアル化される場合) および CompoundOrdering クラス (GWT のシリアライズでシリアル化される場合) のバインドされていないメモリー割り当てに対して脆弱です。攻撃者が Guava を使用するアプリケーションを悪用すると、信用できないデータをデシリアライズしてサービス拒否 (DoS) を発生できる可能性があります。詳細は、CVE-2018-10237 を参照してください。

このセキュリティー脆弱性を回避するため、以下を行うことが推奨されます。

Fuse 7.7 (およびそれ以降) では、以前の (脆弱な) バージョンの Guava を簡単に使用できないようにするため、デフォルトですべてのコンテナーが Guava 27 を選択するよう、Maven BOM (Bill of Material) ファイルが設定されています。そのため、Fuse BOM を Maven プロジェクトに組み込み (BOM ファイルの依存関係を POM ファイルの dependencyManagement セクションに 追加)、明示的なバージョンを指定 せずに Guava アーティファクトの依存関係を指定すると、Guava のデフォルトのバージョンは BOM に指定されたバージョン (Fuse 7.7 の BOM ではバージョン 27) になります。

しかし、脆弱なバージョンの Guava の使用を回避できない一般的なユースケースが少なくとも 1 つあります。これは、OSGi アプリケーションが Guava と Swagger を一緒に使用する場合で、Swagger には Guava 20 が必要であるため、そのバージョンを使用する必要があります。ここでは、その理由と、以前の (脆弱な) Guava 20 ライブラリーを元に戻すために POM ファイルを設定する方法について説明します。まず、ダブル OSGi チェーン という概念を理解する必要があります。

ダブル OSGi チェーン

OSGi ランタイムのバンドルは、パッケージ制約 (パッケージ名 + 任意のバージョン/範囲) を使用して ワイヤリング されます (インポートおよびエクスポート)。各バンドルは複数のインポートを持つことができ、通常これらのインポートは指定のバンドルを複数のバンドルでワイヤリングします。以下に例を示します。

BundleA
+-- BundleB
|   +-- BundleCa
+-- BundleCb

この例では、BundleA は BundleB および BundleCb に依存し、BundleB は BundleCa に依存します。BundleCa と BundleCb が同じパッケージをエクスポートする場合、同じバンドルである必要があります。ただし、バージョン (範囲) の制約により、BundleB は BundleA とは異なるリビジョン/バージョンの BundleC を使用 (ワイヤリング) します。

上記の図を書き換えて、アプリケーションに Guava と Swagger の両方の依存関係を含めるとどうなるか反映させます。

org.jboss.qe.cxf.rs.swagger-deployment
+-- Guava 27
+-- Swagger 1.5
    +-- reflections 0.9.11
        +-- Guava 20

このバンドル設定のデプロイを試みると、エラー org.osgi.framework.BundleException: Uses constraint violation が発生します。

Guava 20 に戻す

プロジェクトが直接的または間接的に Guava ライブラリーと Swagger ライブラリーの両方を使用する場合、Guava バンドルインポートに明示的なバージョン範囲を使用するよう、以下のように maven-bundle-plugin を設定する必要があります。

<Import-Package>
    com.google.common.base;version="[20.0,21.0)",
    com.google.common.collect;version="[20.0,21.0)",
    com.google.common.io;version="[20.0,21.0)"
</Import-Package>

この設定により、OSGi アプリケーションは (脆弱性のある) Guava 20 ライブラリーに強制的に戻されます。そのため、この場合には AtomicDoubleArray インスタンスをデシリアライズしないようにすることが特に重要です。

Apache Solr は、Apache Lucene 検索エンジンを使用する一般的なオープンソースの検索プラットフォームです。アプリケーションが Apache Solar と Apache Lucene の組み合わせ (Camel Solr コンポーネントを使用している場合など) を使用する場合、このセキュリティー脆弱性の影響を受ける可能性があります。この脆弱性の詳細と軽減策について、リンク先のセキュリティーアドバイザリーを確認してください。

Apache Mina SSHD の sshd-core の脆弱性により、攻撃者がサーバーをオーバーフローさせ、OutOfMemory エラーが発生する可能性があります。この問題は、Apache Mina SSHD バージョン 2.0.0 以降の SFTP およびポート転送機能に影響します。これは、Apache Mina SSHD 2.7.0 で対処されました。

Apache Mina SSHD のこの脆弱性は、SSHD-1004 により対処されました。これは、この脆弱性を持つ特定の暗号化アルゴリズムを非推奨にします。Fuse 7.10 on Karaf および Fuse 7.10 on JBoss EAP では、これらの非推奨のアルゴリズムは引き続きサポートされます (後方互換性のため)。ただし、非推奨となったアルゴリズムのいずれかを使用している場合は、アプリケーションコードをリファクタリングして、代わりに別のアルゴリズムを使用することが強く推奨されます。

Fuse 7.10 では、デフォルトの暗号化アルゴリズムが以下のように変更されました。

Fuse 7.10 では、デフォルトの鍵交換アルゴリズムが以下のように変更されました。