リーナス・トーバルズ、キース・クックの疑わしい改変を検知しブロックを命じる 

コンのLinusTorvalds

数日前 異常な事件が起こったLinuxカーネルコミュニティを揺るがした。 Linus Torvalds 氏は、kernel.org 上の Kees Cook 氏のアカウントを即時停止するよう命じた。この開発者の Git リポジトリで操作されたコミットの存在を検出した後。

キース・クック 彼のリーダーシップが認められた Ubuntuのセキュリティチームと、カーネルの12以上のセキュリティ関連サブシステムのメンテナンスに携わった。 事実関係が明らかになるまでの間、一時的に変更の提出を禁止されました。

Kees Cookリポジトリにおける著者と署名の改変

この問題は、変更組み込み要求から発生しました。s 6.16カーネルブランチに、 Linusがリポジトリへの参照を特定した 含まれている 操作されたコミット 彼自身がそうしたわけではないのに、著者および確認者として彼の名前が挙げられている。 最も深刻な例の 1 つは、元のコミットと内容は同一だが SHAXNUMX ハッシュが異なり、Linus Torvalds の署名が誤って含まれていた重複コミットの存在でした。

これらの変更 単なる偶発的なエラーによるものではないgit rebase操作中に、 大規模な改造を伴うため 機密情報には 6.000 件を超える書き換えられたコミットが含まれており、そのうち 330 件には Linus の名前が作成者として記載されていました。

トルバルズ氏の反応:意図的な操作の疑い

リーナス・トーバルズは懸念を隠さなかった そして、これらの出来事は潜在的に悪意のあるものだと述べた。

「1、2回の書き直しは間違いかもしれない。だが、何千回も、しかもその多くは私の偽造署名が入ったものなので、間違いではない」と彼は断言した。

変更の規模と公式カーネルツリーの整合性に対するリスクを考慮すると、 トルバルズはコンスタンチン・リャビツェフに尋ねた。 kernel.org インフラストラクチャ管理者、q状況が明らかになるまでキース・クックのアクセスをブロックする。

に応じて、 キース・クックは最近技術的な問題があったと説明した。 それが事件のきっかけになった可能性があると彼は言った。 コピー操作中にSSDドライブにエラーが発生し、破損が発生しました 複数のリポジトリでこれらのエラーが発生した後、彼はgit rebaseと様々な自動化ツールを使用してリポジトリの状態を回復しようとしました。

しかし、これらの操作は重要な枝に対して実行された。for-next/hardening や for-linus/hardening などの、コミットの作成者の変更など、リポジトリ履歴の偶発的な変更につながるコマンドがありました。 彼の説明にもかかわらず、ライナスは懐疑的だった。:

「これほど多くの改造が施されている中で、どうして偶然の追い越しが起こり得るのか理解できない。」

真犯人:git-filter-repoとb4トレーラー

後のメッセージでは、 キース・クックはエラーの原因を特定した:2つのツールを組み合わせて使用​​すること、 コミット履歴を操作するgit-filter-repoとb4トレーラー コミット内のトレーラー (Signed-off-by: のようなタグ)。

この誤った使用 利益の 何千ものコミットの自動書き換えを引き起こしていただろう著者をデフォルト値(この場合はLinus Torvalds)に置き換えるなど、 キースが当時その誤りに気付かなかったb4ツールの作者であるコンスタンチン・リャビツェフ氏はこの説を裏付け、クック氏に悪意はなかったと主張した。実際、システムはすでに警告を発していたが、無視されていた。

状況が明らかになった後、Kees Cook の kernel.org へのアクセスは回復されました。 予防措置として、ツール b4には新しいセキュリティチェックが含まれます。 これにより、今後は現在のユーザーのIDと一致しないコミットの修正が防止されます。これは、同様のエラーを防ぎ、カーネルソースコードの整合性を保護することを目的としています。

キース氏は、被害を受けた枝を再建することを誓った。 個々のパッチからエラーの原因を特定し、エラーの原因となった手順を詳細に分析します。 この事件によりチーム内の関係は緊張した カーネル開発では、特に Linux カーネルのような重要なプロジェクトでは、履歴書き換えツールを慎重に使用することの重要性も強調されています。

最後に、Linus TorvaldsとKees Cookの間のこの事件は、コミット履歴を操作することの危険性についての警告であり、 迅速な介入のおかげで kernel.orgの責任者とプロセスの透明性について 状況は制御可能になった.

最後に、もっと詳しく知りたい方は、以下の詳細を確認してください。 リンク


Googleで優先ソースとして追加する