第7章 既知の問題

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

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

Fuse 7.7 では、以前の (脆弱な) バージョンの Guava を簡単に使用できないようにするため、デフォルトですべてのコンテナーが Guava 27 を選択するよう、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 インスタンスをデシリアライズしないようにすることが特に重要です。

スタンドアロンの Fuse アプリケーションを Amazon Web Services にデプロイする場合は、hawtio.disableProxy システムプロパティーを true に設定し、Fuse Console のプロキシーサーブレットを無効にする必要があります。この要件は、サポートされるすべてのスタンドアロン環境 (Spring Boot 1.x および 2.x、Karaf、および Red Hat JBoss Enterprise Application Platform) に適用されます。

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