Định nghĩa SBAT(Secure Boot Advanced Targeting)
- Khi UEFI Secure Boot lần đầu được đưa ra đặc tả, tất cả các bên liên quan đều có phần hơi ngây thơ
- Mô hình bảo mật cơ bản của Secure Boot là mọi mã chạy trong môi trường đặc quyền ở cấp độ kernel đều phải được xác minh trước khi thực thi
- Nó bao gồm cách vô hiệu hóa các thành phần đã ký khi phát hiện lỗ hổng
- Tuy nhiên, mọi bản phân phối Linux hoạt động trong hệ sinh thái Secure Boot đều tự tạo binary bootloader của riêng mình, nên khi xác định có lỗ hổng thì có rất nhiều binary cần phải vô hiệu hóa
- Không gian có thể lưu trữ hash bị giới hạn, vì vậy SBAT đã được phát triển
Cách SBAT hoạt động
- Mọi thành phần quan trọng trong chuỗi khởi động đều khai báo một thế hệ bảo mật được chứa trong binary đã ký
- Khi một lỗ hổng được xác định và khắc phục, thế hệ đó sẽ được tăng lên
- Có thể xác định thế hệ tối thiểu thông qua bản cập nhật
- Thành phần khởi động sẽ kiểm tra mục tiếp theo trong chuỗi, so sánh tên và số thế hệ với thông tin được lưu trong biến firmware để quyết định có thực thi hay không
- Thay vì vô hiệu hóa hàng loạt hash riêng lẻ, có thể đẩy một bản cập nhật duy nhất để tuyên bố rằng các phiên bản grub có thế hệ bảo mật thấp hơn một số cụ thể là không đáng tin cậy
Nguyên nhân của sự cố gần đây
- Microsoft đã phát hành một bản cập nhật Windows để không còn tin cậy các phiên bản grub có thế hệ bảo mật thấp hơn một mức nhất định
- Lý do là các phiên bản grub đó có lỗ hổng bảo mật thực sự có thể làm tổn hại chuỗi Secure Boot của Windows
- Vấn đề là một số bản phân phối Linux vẫn chưa cung cấp phiên bản grub với phiên bản bảo mật mới
- Ý định của Microsoft là chỉ áp dụng cập nhật SBAT cho các hệ thống chỉ có Windows, nhưng điều này đã không hoạt động như dự định
Tóm tắt
- Microsoft đã đẩy bản cập nhật Windows để ngăn việc dùng các phiên bản grub dễ bị tấn công nhằm tấn công Windows
- Bản cập nhật này được thiết kế để không áp dụng cho hệ thống dual-boot, nhưng điều đó đã bị bỏ qua
- Một số bản phân phối Linux đã không cập nhật mã grub và thế hệ bảo mật SBAT
- Kết quả là một số người dùng không thể khởi động hệ thống của mình
Bên nào đáng bị trách
- Microsoft lẽ ra nên thử nghiệm nhiều hơn để nhận diện chính xác các cấu hình dual-boot
- Nhưng các bản phân phối cung cấp bootloader đã ký cũng phải cập nhật chúng và cập nhật cả thế hệ bảo mật
- Vì điều này tạo ra một vector có thể bị dùng để tấn công hệ điều hành khác
Kết luận
- Thật đáng tiếc khi những người dùng cuối đột nhiên không thể khởi động hệ điều hành họ muốn lại trở thành nạn nhân
- Đây là điều tuyệt đối không nên xảy ra
- Dù cảm thấy UEFI Secure Boot không mang lại nhiều lợi ích cho phần lớn người dùng cuối, nhưng cũng không ai muốn chỉ sau khi sự cố xảy ra mới biết rằng mình đã cần nó, nên tôi đồng cảm với lựa chọn bật mặc định của Microsoft
- Ngoại trừ nỗ lực thất bại trong việc tránh áp dụng bản cập nhật trên hệ thống dual-boot, tôi đồng cảm với lựa chọn của Microsoft
Ý kiến của GN⁺
- Sự việc này cho thấy việc cân bằng giữa bảo mật và trải nghiệm người dùng khó đến mức nào
- Cả Microsoft lẫn các bản phân phối Linux đều đang cố gắng hết sức để bảo vệ người dùng, nhưng trong quá trình đó trải nghiệm người dùng có thể bị hy sinh
- Với những người dùng hệ thống dual-boot, khả năng gặp các vấn đề như vậy sẽ cao hơn
- Vì vậy, người dùng dual-boot cần giữ cả hai hệ điều hành ở phiên bản mới nhất và cập nhật thường xuyên
- Về lâu dài, có lẽ sẽ cần sự hợp tác và điều phối tốt hơn giữa cộng đồng Linux và Windows
1 bình luận
Ý kiến trên Hacker News