# OTel Collector の confighttp および configgrpc におけるセキュリティ脆弱性（CVE-2024-36129）

Site [llms.txt](/ja/llms.txt)

---

卒業に向けた取り組みの中で、OpenTelemetry プロジェクトは現在、[CNCF](https://www.cncf.io/) がスポンサーし、[OSTIF](https://ostif.org/) が仲介し、[7ASecurity](https://7asecurity.com/) が実施するセキュリティ監査を受けています。
このプロセスの中で、[OpenTelemetry Collector のバイナリ](https://github.com/open-telemetry/opentelemetry-collector-releases/releases)を作成する際に特定のコンパイラフラグを使用するなど、改善できる点についていくつかの提案を受けました。
2024年5月31日、[より深刻な報告](https://github.com/open-telemetry/opentelemetry-collector/security/advisories/GHSA-c74f-6mfw-mm4v)を受けました。
悪意のあるユーザーが、特別に細工した HTTP または gRPC リクエストを使用してサービス拒否（DoS）を引き起こす可能性があるというものです。
このアドバイザリには、CVE 識別子 CVE-2024-36129 が割り当てられました。

圧縮されたペイロードを含む HTTP リクエストを送信する場合、Collector は圧縮されたペイロードが一定の制限を超えているかどうかのみを検証し、展開後のバージョンは検証していませんでした。
そのため、悪意のあるペイロードとして「[圧縮爆弾](https://en.wikipedia.org/wiki/Zip_bomb)」を送信することで、Collector をクラッシュさせることが可能でした。

同様に、zstd 圧縮を使用した gRPC リクエストを送信する場合、展開メカニズムが gRPC によって課された制限を遵守せず、悪意のあるペイロードの展開中に Collector がクラッシュする原因となっていました。

報告を受けてから営業時間にして数時間後の2024年6月3日、Collector の開発者は HTTP に関連する報告を再現することができ、共同で修正に取り組みました。
その修正は[同日中にマージされました](https://github.com/open-telemetry/opentelemetry-collector/pull/10289)。
このイシューのスコアが高かったため、同日に予定されていたリリースを保留し、かわりに2024年6月4日に[リリースを完了しました](https://github.com/open-telemetry/opentelemetry-collector-releases/releases/tag/v0.102.0)。

リリース後、zstd を使用した gRPC も影響を受けることが確認されました。
確認から数営業時間以内に修正に取り組み、こちらも[同日中にマージされました](https://github.com/open-telemetry/opentelemetry-collector/pull/10323)。
その直後に [v0.102.1 をリリースしました](https://github.com/open-telemetry/opentelemetry-collector-releases/releases/tag/v0.102.1)。

## 影響を受けるかどうか {#am-i-affected}

この脆弱性の影響を受けるのは、パブリックポートで1つ以上の HTTP または gRPC レシーバー（たとえば、「HTTP」または「gRPC」プロトコルが有効になっている OTLP レシーバーで、通常はそれぞれポート4318および4317）を持つ OpenTelemetry Collector を使用しており、かつ、そのレシーバーのバージョンが0.102.0以下である場合です。
この脆弱性は、HTTP/gRPC エンドポイントにペイロードを送信できる攻撃者によってのみ悪用可能です。
これは通常、ポートがパブリックインターネットまたは攻撃者がアクセス可能な別のネットワークセグメントに公開されている必要があることを意味します。

認証を要求している場合、攻撃者が HTTP プロトコルを使用してこの脆弱性を悪用するには、有効な認証情報が必要になります。
gRPC の場合、悪用可能なコードは認証の前に実行されます。

## 自分にとっての影響 {#what-does-it-mean-to-me}

パブリックインターネットへのインターフェイスを持つ Collector を管理している場合、できるだけ早くアップグレードし、OTLP レシーバーなどの HTTP レシーバーで `max_request_body_size` パラメーターをワークロードに適した値に設定することを検討してください。
v0.101.0 までは、この設定はクライアントが送信するペイロードサイズにのみ適用され、多くの場合圧縮されていました。

v0.102.0 以降、この設定は非圧縮、圧縮、および展開後のペイロードサイズに適用されるようになり、デフォルト値として20 MiB を設定しています。
この新しいデフォルトは破壊的変更となります。20 MiB を超えるペイロードを送信するクライアントはエラーを受け取るようになるためです。
ほとんどの正当なリクエストはこの制限内に十分収まると考えられますが、このアップデート後に Collector のエラー率が増加していないか監視することを推奨します。
以下は、このフィールドに異なる制限を設定する設定例です。

```yaml
receivers:
  otlp:
    protocols:
      http:
        endpoint: localhost:4318
        max_request_body_size: 10485760 # 10 MiB
```

gRPC レシーバーについては、v0.102.1 にアップグレードするだけで十分です。メッセージサイズにはすでにデフォルト値の4 MiB が適用されています。

Collector インスタンスが自社のアプリケーションなど信頼できるクライアントからのみデータを受信している場合でも、最新の Collector バージョンへのアップグレードを推奨しますが、通常のペースで行っていただいて問題ありません。

カスタムディストリビューションを使用しており、[OpenTelemetry Collector Builder（ocb）](/docs/collector/extend/ocb/)でビルドしている場合は、[confighttp](https://pkg.go.dev/go.opentelemetry.io/collector/config/confighttp) および [configgrpc](https://pkg.go.dev/go.opentelemetry.io/collector/config/configgrpc) Go モジュールの最新バージョンを指す ["replaces"](https://github.com/open-telemetry/opentelemetry-collector/tree/d25efc7e2f31a3ba5347d0725a22d7bed1b4015d/cmd/builder?from_branch=main#configuration) エントリを追加できます。
ベースの Collector バージョンが v0.96.0 以上であれば、最新バージョンにバンプするだけで互換性の問題は発生しないと想定しています。

## 得られた教訓 {#lessons-learned}

このプロセスの中で、Collector のテレメトリーと、Collector 管理者に提供しているオプションにいくつかのギャップがあることがわかりました。
具体的には、Collector が受信するリクエストサイズの分布を確認する良い方法がないことに気づきました。
これは、この変更が特定の Collector のクライアントを壊すかどうかを判断するのに役立ったはずです。
また、管理者が圧縮を完全に無効にする方法を提供していないことにも気づきました。
これは、Collector をアップグレードせずに攻撃を軽減するための良い方法となるはずです。
今後のリリースでこれらのギャップを埋めるべく取り組んでいます。

また、すべての Collector エンドポイントのデフォルトの公開範囲を縮小するために、`component.UseLocalHostAsDefaultHost` フィーチャーゲートの安定化にも取り組んでいます。
このフィーチャーゲートは、以前の [Go 標準ライブラリにおける類似の脆弱性](https://github.com/advisories/GHSA-4374-p667-p6c8)をきっかけに作られたもので、数か月間アルファ版として提供されています。
安定化に関する議論は [issue 8510](https://github.com/open-telemetry/opentelemetry-collector/issues/8510) で追うことができます。

## 謝辞 {#acknowledgements}

このイシューは、7ASecurity の [Miroslav Stampar](https://github.com/stamparm/) 氏によって特定されました。
この脆弱性の責任ある報告について、7ASecurity に感謝いたします。