Vì sao chậm cập nhật Chromium ảnh hưởng đến bảo mật

Chromium xử lý đầu vào không tin cậy từ trang web, ảnh, phông chữ, media, script, tiện ích và giao thức mạng. Sandbox cùng các lớp phòng vệ giảm tác động của lỗi, nhưng không làm build có lỗ hổng trở nên an toàn để giữ vô thời hạn. Hướng dẫn cập nhật bảo mật của Chromium nói gần như mọi bản cập nhật Chrome đều có sửa bảo mật và cảnh báo lỗ hổng đã vá có thể dễ bị khai thác hơn trên bản cài chưa cập nhật.

Điều này có hệ quả quan trọng cho mọi trình duyệt xây từ Chromium: duy trì mã nền là một phần của duy trì sản phẩm.

Độ trễ cập nhật thực sự đo gì

Người ta thường so ngày phát hành trình duyệt phái sinh với Chrome upstream. Cách đó hữu ích nhưng chưa đủ. Bản vá chưa có hiệu lực chỉ vì nhà cung cấp đã build hoặc công bố.

Dòng thời gian thực tế ít nhất gồm:

Mốc	Bằng chứng cần giữ
Upstream phát hành	Phiên bản, nhánh, giờ phát hành chính xác và thông báo bảo mật được theo dõi
Sản phẩm phái sinh tiếp nhận	Commit hoặc bản ghi tương đương bản vá cho biết đã tích hợp gì
Bản ứng viên sẵn sàng	Kết quả build tái lập được, kiểm thử tự động và hồi quy bảo mật
Cho phép phát hành	Metadata có chữ ký, digest artefact, chữ ký nền tảng và bản ghi phê duyệt
Artefact có sẵn	Công bố thành công đến từng kênh cập nhật được hỗ trợ
Thiết bị đã cài	Kết quả cài được xác minh theo phiên bản và nền tảng
Build đã vá đang chạy	Xác nhận mở lại trình duyệt hoặc thay tiến trình

Khoảng phơi nhiễm của thiết bị kết thúc ở dòng cuối, không phải dòng đầu. Nếu tải cập nhật thứ Ba nhưng tiến trình có lỗ hổng chạy đến thứ Sáu, thiết bị vẫn có thêm ba ngày trễ thực tế.

Từ đó có ba phép đo riêng:

1. Độ trễ nhà cung cấp: từ bản phát hành upstream liên quan đến artefact phái sinh có chữ ký.
2. Độ trễ phân phối: từ công bố bản phái sinh đến cài thành công.
3. Độ trễ kích hoạt: từ sẵn sàng cài đến lúc trình duyệt đã vá trở thành tiến trình đang dùng.

Báo cáo cả ba. Một số trung bình có thể che kênh phát hành bị kẹt, lỗi ký riêng nền tảng hoặc nhóm thiết bị kéo dài không bao giờ mở lại.

Vì sao thời gian nguy hiểm hơn sau khi có bản vá

Ghi chú bảo mật không công khai mọi chi tiết triển khai ngay. Chromium nói có thể giữ chi tiết lỗi hạn chế đến khi bản vá đến phần lớn người dùng; FAQ bảo mật giải thích nhiều báo cáo được công khai sau đó. Công bố phối hợp giảm rủi ro không cần thiết, nhưng không giữ bí mật mãi.

Khi bản vá công khai, nhà nghiên cứu và kẻ tấn công có thể so mã cũ, mới, xem kiểm thử, quan sát hành vi thay đổi và nghiên cứu metadata phát hành. Chromium gọi tấn công bản cài cũ sau khi có bản vá là khai thác n-day. Hướng dẫn cho trình duyệt dựa trên Chromium khuyến nghị phát hành trong vài ngày sau mỗi Chrome Stable, không chờ chu kỳ tính năng hằng tháng riêng.

Kho Chrome Releases cho thấy vì sao chỉ theo phiên bản lớn là chưa đủ. Các đợt cập nhật Stable giữa mốc lớn mang bản vá bảo mật; một số chi tiết vẫn hạn chế trong lúc triển khai. Nhà cung cấp chỉ theo dõi chuyển nhánh lớn có thể bỏ lỡ bản vá đã có trên nhánh ổn định hiện tại.

Số phiên bản là dấu hiệu, chưa phải chứng minh đầy đủ

Phiên bản Chromium là tín hiệu khởi đầu mạnh vì xác định nhánh và mức vá upstream. Nhưng tự nó không trả lời mọi câu hỏi.

Trình duyệt phái sinh có thể:

• mang nhãn phiên bản mới nhưng thiếu bản vá liên quan bảo mật;
• dùng nhánh cũ có backport được ghi rõ;
• có bản sửa trong mã nhưng chưa đưa đến một nền tảng;
• cài tệp mới trong khi tiến trình cũ vẫn chạy; hoặc
• quay lại build làm tái xuất hiện lỗ hổng.

Backport cần bản ghi tương đương nối bản vá upstream với thay đổi phái sinh và bằng chứng kiểm thử. Chromium cảnh báo một số cải tiến bảo mật phụ thuộc thay đổi kiến trúc, không thể backport gọn. Cũng không thể an toàn coi ghi chú phát hành là nguồn ưu tiên hoàn chỉnh. FAQ cập nhật bảo mật Chrome đề xuất áp dụng trọn bản cập nhật, không chờ đánh giá riêng lỗ hổng được mô tả công khai.

Vì vậy người đánh giá không chỉ hỏi “Đây là Chromium phiên bản nào?”. Hãy hỏi “Build bao phủ bản bảo mật upstream nào, và đã xác minh phạm vi đó trên nền tảng của tôi thế nào?”.

Độ trễ phía sản phẩm phái sinh tích lũy ở đâu

Tập bản vá riêng quá lớn

Mỗi thay đổi sâu vào Chromium tạo công việc hợp nhất về sau. Thay đổi có thể xung đột với tái cấu trúc upstream, phụ thuộc giao diện bị xóa hoặc làm kiểm thử không còn hợp lệ. Chi phí lặp lại ở mỗi đợt vá bảo mật. Tập bản vá nhỏ hơn, được rà soát giúp nhóm có khả năng tiếp nhận việc upstream khẩn cấp.

Chỉ đếm bản vá chưa đủ. Một sửa đổi dịch vụ mạng có thể khó bảo trì hơn nhiều thay đổi thương hiệu tách biệt. Theo dõi người phụ trách, ranh giới bảo mật bị ảnh hưởng, xung đột hợp nhất, phạm vi kiểm thử và điều kiện bỏ từng bản vá riêng.

Kiểm thử bắt đầu quá muộn

Bảo mật và tương thích nên dùng chung đường phát hành đã sẵn sàng. Bắt đầu đợt thử ứng biến sau thông báo upstream khẩn cấp tạo chậm trễ tránh được và khuyến khích ngoại lệ không an toàn.

Quy trình được duy trì có sẵn kiểm thử đại diện cho trình duyệt, hồ sơ, tiện ích, proxy, cập nhật, quay lại và khôi phục để chạy với mỗi ứng viên. Nhóm thử nhỏ trước Stable có thể phát hiện thay đổi tương thích trước khi bản ổn định tới. Hướng dẫn cập nhật doanh nghiệp Google cũng phân biệt: thử theo đợt có thể cùng tồn tại cập nhật tự động, nhưng bản cập nhật chờ vẫn cần mở lại trình duyệt mới có hiệu lực.

Lỗi ký và công bố

Tệp thực thi đã biên dịch chưa phải bản cập nhật phát hành được. Chữ ký nền tảng, công chứng khi áp dụng, metadata cập nhật, hash artefact và manifest kênh đều thuộc ranh giới bảo mật. Nếu một phần thiếu hoặc không nhất quán, người dùng có thể ở lại build cũ hoặc nhận artefact không được cho phép.

Thiết kế bộ cập nhật Chromium có khôi phục khi bộ cập nhật hỏng hoặc quá cũ. Trình duyệt phái sinh cần bằng chứng tương đương cho bản phân phối riêng: artefact xác thực, bộ cập nhật tự phục hồi, phục hồi sau cập nhật gián đoạn và cách dừng đợt xấu mà vẫn phát được bản sửa tiếp.

Triển khai mãi không hoàn tất

Phân phối theo đợt kiểm soát rủi ro hồi quy, nhưng một đợt không phải đích cuối. Mỗi lần triển khai cần tiêu chí chuyển giai đoạn rõ, thời gian chờ tối đa, người được quyết định dừng và khả năng thấy nhóm còn dùng phiên bản có lỗ hổng.

Quay lại phiên bản cũ cũng cần cẩn thận. Khôi phục build hoạt động nhưng có lỗ hổng có thể lấy lại tính sẵn sàng đồng thời mở lại điểm yếu đã biết. Bản ghi phát hành phải xác định hậu quả và kích hoạt build thay thế, không âm thầm coi quay lại là xong.

Các lỗi đáng kiểm thử

Chương trình cập nhật cần thử đường lỗi trước khi đợt khẩn cấp phụ thuộc vào chúng:

• thông báo upstream đến ngoài giờ làm;
• nhánh upstream đổi trong lúc chuẩn bị ứng viên phái sinh;
• bản vá riêng xung đột bản sửa bảo mật;
• ứng viên qua unit test nhưng làm hỏng hồ sơ sau mở lại;
• ký thành công trên nền tảng này, thất bại trên nền tảng khác;
• metadata và phiên bản artefact không khớp;
• tải bị gián đoạn hoặc hết dung lượng;
• trình duyệt mở nhiều ngày sau khi chuẩn bị cập nhật;
• dừng triển khai để thiết bị chia giữa hai build đều có lỗ hổng;
• khôi phục bộ cập nhật phải hoạt động từ bản cài cũ; và
• quay lại làm ứng dụng mở được nhưng cũng phục hồi lỗ hổng đã vá.

Các kiểm thử nối bảo mật với khôi phục. Phát ngay mà chưa kiểm tra toàn vẹn hồ sơ có thể làm mất dữ liệu. Trì hoãn không có quy trình giới hạn, quan sát được kéo dài phơi nhiễm. Chất lượng cần hệ thống phát hành làm được cả hai dưới áp lực.

Chỉ số cho thấy khoảng phơi nhiễm thực

NIST xem quản lý bản vá là bảo trì phòng ngừa trong SP 800-40 Sửa đổi 4. Với trình duyệt, bằng chứng hữu ích gồm:

• thời gian từ upstream công bố đến lúc phát hiện;
• thời gian phát hiện đến ứng viên có chữ ký;
• thời gian ứng viên được duyệt đến có sẵn ở từng kênh;
• tỷ lệ đang chạy phiên bản đã vá tại mốc xác định;
• trung vị, phân vị 95 và độ trễ thiết bị lớn nhất;
• tỷ lệ lỗi tải, xác minh, cài và mở lại;
• số lượng, thời gian chờ của thiết bị cần khởi động lại;
• trạng thái tương đương bản vá cho mỗi backport liên quan;
• lý do, thời lượng, nhóm bị ảnh hưởng của dừng triển khai và quay lại; và
• khả năng phục hồi bộ cập nhật từ bản cài cũ nhất còn hỗ trợ.

Công bố cách đo cùng mục tiêu. Nêu sự kiện bắt đầu, kết thúc đồng hồ, nền tảng có trong phạm vi, xử lý thiết bị ngoại tuyến và con số là mục tiêu hay kết quả quan sát. Thiếu định nghĩa, câu “cập nhật trong 24 giờ” có thể chỉ hợp nhất mã, công bố tệp tải hoặc kích hoạt gần toàn bộ thiết bị.

Câu hỏi cho nhà cung cấp trình duyệt Chromium

1. Hỗ trợ nhánh Stable và mở rộng nào, mỗi build đã cài theo nhánh nào?
2. Ai theo dõi bản vá upstream, kể cả phát hành ngoài kế hoạch?
3. Năm bản bảo mật upstream gần nhất mất bao nhiêu ngày đến artefact phái sinh có chữ ký?
4. Sau 24, 48, 72 giờ, bao nhiêu phần trăm thiết bị được hỗ trợ chạy từng build đã vá?
5. Backport được nối với bản sửa upstream thế nào khi số phiên bản khác?
6. Kiểm thử nào bao phủ sandbox, vòng đời hồ sơ, tiện ích, proxy, cập nhật và khôi phục?
7. Bộ cập nhật lỗi có tự sửa mà không cài artefact chưa xác thực được không?
8. Bản cập nhật bảo mật chờ được xử lý thế nào khi trình duyệt vẫn mở?
9. Quay lại tránh tái đưa lỗ hổng đã biết vào bằng cách nào?
10. Kết quả trễ nào đã đo, kết quả nào vẫn là mục tiêu phát hành?

Nhà cung cấp có lý do giữ kín chi tiết lỗ hổng nhạy cảm. Họ vẫn nên chứng minh quy trình, phạm vi phiên bản, bản ghi phát hành có chữ ký, dữ liệu lỗi và chỉ số có phạm vi rõ.

Cập nhật mới không chứng minh điều gì

Cập nhật nhanh không chứng minh trình duyệt bảo mật ở mọi mặt. Bản vá riêng có thể thêm lỗ hổng. Tiện ích không an toàn, hệ điều hành bị xâm phạm, kiểm soát ký yếu, dữ liệu nhập độc hại hoặc sandbox bị tắt có thể phá nền tảng mới. Cập nhật là một lớp cần thiết trong mô hình bảo mật rộng hơn.

Chiều ngược cũng đúng: thương hiệu, cài đặt riêng tư và tính năng cô lập không bù được nền tảng cũ. Nội dung web đi vào bề mặt tấn công Chromium trước khi khác biệt sản phẩm đó có thể giúp.