Bitcoin Core kết thúc lệnh cấm kéo dài một năm đối với các lỗ hổng dễ phát hiện

Bitcoin Core đang kết thúc khoảng thời gian chờ đợi một năm để vá các lỗ hổng bảo mật mà một mô hình ngôn ngữ có thể tìm lại chỉ trong một lần nhắc nhở. Một thay đổi đối với chính sách tiết lộ bảo mật của dự án, được hợp nhất vào ngày 22 tháng Mười, tạo ra một lớp lỗ hổng “dễ dàng phát hiện” và hướng dẫn các người duy trì triển khai phiên bản điểm và thông báo công khai “ngay khi có thể” — bỏ qua thời gian giữ kín tiêu chuẩn kéo dài khoảng một năm đối với các lỗi có mức độ trung bình hoặc cao.

Cơ chế kích hoạt là thô sơ. Các nhà duy trì đang nhận được nhiều báo cáo hơn về các lỗi liên tục được phát hiện lại, vì các mô hình ngôn ngữ đã giảm bớt nỗ lực cần thiết để tìm ra chúng. Antoine Poinsot, một đóng góp viên của Bitcoin Core tại Chaincode Labs, đã công bố thay đổi này trên Danh sách thư Phát triển Bitcoin cùng ngày yêu cầu kéo được hợp nhất.

“Chúng tôi gần đây đã ghi nhận sự gia tăng số lượng báo cáo về các lỗ hổng bảo mật có thể dễ dàng được phát hiện lại,” Poinsot viết. “Điều này chủ yếu là do các mô hình LLM làm giảm đáng kể rào cản để phát hiện các loại vấn đề nhất định hoặc xác định các bản vá ẩn.”

Chính sách trước đây của Bitcoin Core liên kết thời gian tiết lộ với mức độ nghiêm trọng. Các lỗ hổng mức độ thấp được công khai hai tuần sau khi phiên bản chính tiếp theo được phát hành. Các lỗ hổng mức độ trung bình và cao được giữ bí mật cho đến hai tuần sau khi phiên bản bị ảnh hưởng cuối cùng kết thúc vòng đời — một khoảng thời gian mà chính sách này mô tả là “khoảng một năm sau khi phiên bản chính chứa bản vá được phát hành lần đầu tiên.”

Lịch trình đó tồn tại vì một lý do. Bitcoin Core là bản triển khai tham chiếu chạy phần lớn các nút mạng Bitcoin, và các người vận hành nút nâng cấp chậm. Một lệnh cấm kéo dài được đưa ra nhằm cung cấp thời gian cho mạng lưới vá lỗi trước khi chi tiết được công bố công khai. Sự đánh đổi là các bản vá thường không được áp dụng ngược lại, nên một người vận hành trên phiên bản cũ sẽ phải chờ phiên bản chính tiếp theo, mà dự án nhắm đến việc phát hành khoảng sáu tháng một lần.

Sự cảnh báo này mang tính cấu trúc hơn là vô tình. Những thay đổi đồng thuận như bản nâng cấp Taproot của bitcoin được thực hiện theo một lộ trình chậm và thận trọng nhằm đảm bảo các nhà vận hành có thể áp dụng chúng theo lịch trình riêng của mình.

“Do bản chất của dự án chúng tôi, kết hợp với văn hóa nâng cấp chậm, chính sách bảo mật của chúng tôi ưu tiên thời gian giữ kín dài hơn,” Poinsot viết. “Điều này thường có nghĩa là các bản vá bảo mật không thể được áp dụng ngược lại, mà chỉ có sẵn cho người dùng cùng với phiên bản lớn tiếp theo.”

AI phá vỡ sự đánh đổi đó. Nếu một lỗi có thể được phát hiện lại bằng cách quét đơn giản bằng LLM, thì giấu nó chẳng mang lại lợi ích gì, vì lỗ hổng đã nằm trong tầm với của bất kỳ ai sở hữu một chatbot. “Đối với những vấn đề dễ tìm thấy này, đây là sự đánh đổi sai lầm. Thời gian giữ kín không mang lại nhiều lợi ích nhưng lại làm chậm việc phát hành bản sửa lỗi,” Poinsot viết.

Theo chính sách đã sửa đổi, đồng hồ tiết lộ hiện có thêm một thiết lập thứ ba. Một lỗ hổng có thể được đánh dấu là “dễ phát hiện” trong quá trình phân loại — được định nghĩa là lỗ hổng “có thể được phát hiện với nỗ lực tối thiểu, chẳng hạn thông qua một lệnh LLM đơn giản.” Nhãn này không giới hạn riêng cho các lỗi do AI phát hiện: nó phản ánh mức độ nỗ lực tối thiểu cần thiết để phát hiện lại, chứ không phải công cụ nào đã tìm ra lỗi.

Đối với những lỗi này, phản hồi thay đổi trên mọi trục. Thay vì một bản sửa lỗi duy nhất được đưa vào phiên bản chính tiếp theo, các nhà duy trì sẽ backport bản sửa lỗi đến tất cả các phiên bản chính đang được hỗ trợ — ba nhánh theo quy tắc của Bitcoin Core hỗ trợ ba phiên bản mới nhất của nó — và phát hành các bản điểm càng nhanh càng tốt. Một thông báo bảo mật sẽ được công bố cùng với phần mềm đã được vá.

Thang độ nghiêm trọng vẫn chi phối mọi thứ khác. Các lỗ hổng độ nghiêm trọng thấp vẫn giữ lịch trình hai tuần. Các lỗ hổng mức trung bình và cao vẫn tuân theo lịch khoảng một năm. Các lỗ hổng nghiêm trọng — những lỗ hổng có thể đánh cắp coin ở cấp độ giao thức, làm tăng cung tiền hoặc chia tách chuỗi vĩnh viễn — vẫn nằm ngoài chính sách tiêu chuẩn và được xử lý từng trường hợp, như trước đây.

Việc loại trừ này tồn tại vì lý do chính đáng. Trong lịch sử của Bitcoin Core, lỗ hổng lạm phát được công bố dưới dạng CVE-2018-17144 vào tháng 9 năm 2018 là loại lỗi justification việc xử lý đặc biệt: nó có thể cho phép tạo ra bitcoin ngoài lịch trình phát hành. Con đường mới “dễ dàng phát hiện” không ảnh hưởng đến cấp độ này — một lỗi nghiêm trọng vẫn sẽ nhận phản hồi theo tình huống, được điều chỉnh dựa trên rủi ro đối với toàn bộ mạng lưới.

Sự thay đổi dễ đọc nhất dưới dạng sự sụp đổ trong cửa sổ tiết lộ. Một lỗi mức độ trung bình được sửa hôm nay thông thường sẽ được giữ riêng tư trong khoảng 52 tuần, chỉ được tiết lộ hai tuần sau khi phiên bản bị ảnh hưởng cuối cùng kết thúc vòng đời. Cùng lỗi đó, một khi được đánh dấu là dễ phát hiện, sẽ được phát hành dưới dạng bản cập nhật điểm “ngay khi có thể” kèm thông báo cảnh báo. Đó là sự khác biệt giữa một năm và, theo cách diễn đạt của chính những người duy trì, thời gian cần để viết, xem xét và kiểm thử một bản vá nhắm mục tiêu.

Cam kết backport là nửa còn lại. Trước khi thay đổi, một bản sửa lỗi thường không đến được người dùng trên nhánh được duy trì cũ hơn; nó xuất hiện cùng với phiên bản chính tiếp theo. Bây giờ, một người vận hành trên phiên bản được hỗ trợ cũ hơn có thể áp dụng bản phát hành điểm nhắm mục tiêu mà không cần áp dụng mọi tính năng và thay đổi hành vi trong phiên bản chính mới nhất. Đối với một mạng lưới nơi các bản nâng cấp diễn ra chậm và cẩn trọng, đó là một thay đổi đáng kể về tốc độ mà một bản vá thực sự có thể được triển khai.

Con đường nhanh hơn có chi phí đi kèm, và Poinsot đã nói rõ điều này trong yêu cầu kéo. “Điều này đặc biệt quan trọng vì theo chính sách này, các biện pháp khắc phục sẽ không có đủ ‘thời gian nướng’ trong các nhánh phát triển trước khi được phát hành cho người dùng,” anh viết. Một bản sửa lỗi được phát hành sau vài ngày sẽ có ít thời gian hơn để được xem xét và kiểm thử so với một bản sửa lỗi đã tồn tại trong nhiều tháng.

Cuộc thảo luận cũng chia rẽ về việc liệu việc tiết lộ thông tin có nên diễn ra nhanh hơn nữa hay không. Một số người đóng góp cho rằng việc mở pull request để vá lỗi có thể tự thân cảnh báo kẻ tấn công, vì việc theo dõi kho lưu trữ tự động là rất dễ dàng, do đó việc tiết lộ có thể cần phải diễn ra không muộn hơn thời điểm vá lỗi, hoặc thậm chí sớm hơn kèm theo hướng dẫn giảm thiểu rủi ro. Một người đóng góp khác đề xuất triển khai các bản vá kèm thông báo tùy chọn hoặc trì hoãn. Poinsot bác bỏ đề xuất này, viết rằng việc cảnh báo người dùng mà không cung cấp chi tiết có thể khiến các nhà vận hành, vốn chưa bao giờ bị ảnh hưởng, vội vàng chuyển đổi.

Sàn giao dịch quan trọng vì nó cho thấy chính sách mới là một con đường trung gian có chủ ý, không phải một lựa chọn rõ ràng. Văn bản được gộp giữ nguyên lời khuyên đồng thời với việc khắc phục và giữ đầy đủ chi tiết, thay vì một cảnh báo chung chung.

Chưa có lỗ hổng nào được đưa vào lớp mới, do đó đây là sự thay đổi quy trình, chứ không phải việc tiết lộ một lỗ hổng đang hoạt động. Kiểm tra thực tế đầu tiên sẽ diễn ra khi các nhà duy trì đánh dấu một vấn đề là “dễ phát hiện” trong quá trình phân loại và phát hành các bản sửa lỗi nhỏ trên tất cả các nhánh được duy trì kèm theo thông báo đồng thời.

Tín hiệu rộng hơn là việc tìm lỗi được hỗ trợ bởi AI đã buộc hệ sinh thái Bitcoin phải thay đổi. Core Lightning đã thông báo với các người vận hành nút mạng đầu năm nay cập nhật hoặc ngắt kết nối sau khi các báo cáo lỗ hổng do AI tạo ra được xác minh là chính xác. Thay đổi chính sách của Bitcoin Core là việc thực thi tham chiếu thực hiện cùng một tính toán ở lớp cơ sở của giao thức: khi việc phát hiện lại có chi phí thấp, sự bí mật mang lại ít lợi ích, và điều duy nhất mà một lệnh cấm kéo dài làm chậm lại là việc phát hành cố định.

Đối với các người vận hành nút mạng, không có gì thay đổi hôm nay. Tần suất nâng cấp vẫn giữ nguyên. Sự khác biệt sẽ xuất hiện vào lần tiếp theo khi một lỗi được coi là dễ phát hiện, khi bản vá và thông báo cảnh báo được triển khai cùng nhau với thời gian thông báo ngắn hơn bất kỳ lúc nào trước đây mà mạng lưới từng có.