本記事の位置付け

Dirty Pipe（CVE-2022-0847）三部作の最後です。ダークナイト三部作で言うとダークナイトライジングにあたります。ダーティとダークって似てませんか。

spliceを使って高速・省メモリでGzipからZIPを作る
Dirty Pipe（CVE-2022-0847）の発見経緯が面白かった（本記事）

上の1, 2を前提知識として要求します。二作品目であるダークナイトが一番面白いところも同じですね(?)

ダークナイトと比べたダークナイトライジングの評価を思い出しながらこの記事を読んでもらえると優しい気持ちになれると思います。

はじめに

以前Linux カーネルの脆弱性であるDirty Pipe（CVE-2022-0847）の解説記事を書きました。

この記事はなるべく概要を掴んでもらおうと思って書いた記事で、本当は書きたかったことをかなり省略しています。特に報告者のブログに書いてあった発見経緯は個人的に面白かったのですが、その辺はまるっと省きました。今回はその辺を全部書き記しておこうという趣旨です。本家ブログの内容そのままならそっち読めばいいとなるのですが、理解するのに少し時間がかかったのと不明点を報告者にメールして教えてもらったので自分の言葉でまとめ直しておきます。頭を整理するために図も書いています。

発見経緯

以下が報告者によるブログです。自分が間違ったことを言っている可能性もあるので正確な内容はこちらをご確認ください。

報告者の会社ではHTTPのアクセスログを提供しているのですが、顧客からgzipファイルが壊れているという報告があったそうです。サーバを見ると確かにCRCエラーが起きているファイルがありました。その時は原因も分からなかったため手動でCRCを直して終わりにしたそうです。

しかし、数ヶ月経ち再び同じ問題が報告されます。ファイルの中身は正しいのにファイルの最後にあるCRCだけが壊れている状態です。CRC-32はgzipファイルにおいてはtrailerと呼ばれるフッタに含まれているのですが、その部分が壊れていました。図にすると以下です。

この問題は繰り返し起きたため報告者は調査することにしました。

ここで少し脱線し、まずシステム構成を見てみます。このサービスでは各WebサーバがHTTPリクエストのログをUDPでログサーバに送っています。