SBAT(Secure Boot Advanced Targeting)の定義
- UEFI Secure Bootが最初に策定されたとき、関係者は全体としてやや楽観的だった
- Secure Bootの基本的なセキュリティモデルは、カーネルレベルの権限環境で実行されるすべてのコードが、実行前に検証されなければならないというもの
- これには、脆弱性が見つかった署名済みコンポーネントを失効させる方法が含まれている
- しかし、Secure Bootエコシステムで動作するすべてのLinuxディストリビューションは独自のブートローダーバイナリを作成するため、脆弱性が特定されると失効させるべきバイナリが大量に発生する
- 保存できるハッシュのための領域が限られているため、SBATが開発された
SBATの動作方式
- ブートチェーンのすべての重要なコンポーネントは、署名済みバイナリに含まれたセキュリティ世代を宣言する
- 脆弱性が特定されて修正されると、その世代が増加する
- アップデートによって最小世代を定義できる
- ブートコンポーネントはチェーン内の次の項目を確認し、名前と世代番号をファームウェア変数に保存されたものと比較して、実行するかどうかを決定する
- 多数の個別ハッシュを失効させる代わりに、特定の番号以下のセキュリティ世代を持つgrubバージョンは信頼できないとする1つのアップデートを配信できる
最近の問題の原因
- Microsoftは、特定のレベル以下のセキュリティ世代を持つgrubバージョンを信頼しないようにするWindowsアップデートを配信した
- これは、そのgrubバージョンにWindowsのセキュアブートチェーンを損なう可能性のある実際のセキュリティ脆弱性が存在するため
- 問題は、一部のLinuxディストリビューションが新しいセキュリティ世代のgrubバージョンをまだ提供していなかったこと
- Microsoftの意図は、WindowsのみのシステムにだけSBATアップデートを適用することだったが、これは意図どおりには動作しなかった
要約
- Microsoftは、脆弱なgrubバージョンを使ってWindowsが攻撃されないようにするため、Windowsアップデートを配信した
- このアップデートはデュアルブートシステムには適用されないようになっていたが、無視された
- 一部のLinuxディストリビューションは、grubコードとSBATセキュリティ世代を更新していなかった
- その結果、一部のユーザーはシステムを起動できなくなった
非難されるべき対象
- Microsoftは、デュアルブート構成を正確に識別できるよう、より多くのテストを行うべきだった
- しかし同時に、署名済みブートローダーを提供するディストリビューション側も、それを更新し、セキュリティ世代を更新すべきだった
- なぜなら、それが他のOSを攻撃するために利用されうるベクトルを提供するからだ
結論
- 突然、望むOSを起動できなくなったエンドユーザーが被害者になったのは残念なことだ
- これは決して起きてはならないことだ
- UEFI Secure Bootは大半のエンドユーザーにとって利点がないようにも感じられるが、後になって必要だったと気づくような事態は望ましくないため、デフォルトで有効にしているMicrosoftの選択には共感する
- デュアルブートシステムでアップデートを避けようとした失敗を除けば、Microsoftの選択には共感する
GN⁺の見解
- この出来事は、セキュリティとユーザー体験のあいだでバランスを取ることがどれほど難しいかを示している
- MicrosoftとLinuxディストリビューションはいずれもユーザーを守るために最善を尽くしているが、その過程でユーザー体験が犠牲になることがある
- デュアルブートシステムを使用するユーザーは、このような問題に直面する可能性がより高い
- そのため、デュアルブートを使うユーザーは、両方のOSを最新の状態に保ち、定期的に更新することが重要だ
- 長期的には、LinuxとWindowsコミュニティのあいだで、より良い協力と調整が必要になるだろう
1件のコメント
Hacker Newsの意見