Chính sách công bố bảo mật của Bitcoin Core đã được cập nhật để các lỗ hổng dễ bị phát hiện bởi các mô hình ngôn ngữ lớn có thể được vá nhanh hơn, chấm dứt các lệnh tạm ngưng kéo dài trước đây áp dụng cho những lỗ hổng như vậy.
Bản cập nhật chính sách bảo mật của Bitcoin Core đã được các người bảo trì hợp nhất vào thứ Năm. Antoine Poinsot, một nhà phát triển tại Chaincode Labs, là tác giả của đề xuất và đã thông báo cho Danh sách thư phát triển Bitcoin về điều đó cùng ngày.
Poinsot nhận xét: “Gần đây chúng tôi đã trải qua 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 (phát hiện lại).” Ông viết: “Điều này phần lớn là do LLM giảm đáng kể rào cản để tìm ra các loại vấn đề nhất định hoặc xác định các bản sửa lỗi ẩn.”
Chính sách hoạt động như thế nào trước đây
Bitcoin Core, chạy trên phần lớn các nút mạng Bitcoin, phân loại từng lỗ hổng được tiết lộ theo mức độ nghiêm trọng và lên lịch công bố tương ứng. Các vấn đề mức độ thấp được phát hành hai tuần sau khi phiên bản chính tiếp theo ra mắt.
Đối với các lỗ hổng mức độ trung bình và cao, lệnh tạm ngưng tiếp tục 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 có thể kéo dài đến một năm.
Các nhà vận hành nút, thường chậm nâng cấp, đã có thời gian nhờ các lệnh tạm ngưng kéo dài để áp dụng các bản vá trước khi các lỗ hổng được công bố. Về mặt thực tế, điều này có nghĩa là các bản sửa lỗi không được phát hành cho các phiên bản cũ đang được bảo trì và chỉ đến với bản phát hành phần mềm chính tiếp theo.
Poinsot cho rằng thỏa hiệp như vậy không hiệu quả đối với các lỗi dễ dàng phát hiện lại. Theo chính sách, “Thời gian tạm ngưng đạt được rất ít nhưng nó làm chậm sự sẵn có của một bản phát hành đã được sửa lỗi.”
Những thay đổi
Trong quá trình phân loại, Bitcoin Core có thể đánh dấu một lỗ hổng là “dễ phát hiện”, một phân loại được chính sách định nghĩa là các vấn đề có thể được xác định “với nỗ lực tối thiểu, chẳng hạn như thông qua một dấu nhắc LLM đơn giản.” Nhãn này cũng có thể áp dụng cho các lỗ hổng được tìm thấy thông qua các phương pháp khác.
Đối với các lỗ hổng trong danh mục này, dự án sẽ backport một bản vá cho tất cả các phiên bản chính đang được bảo trì, phát hành các phiên bản điểm ngay lập tức và công bố một cảnh báo bảo mật với thông tin hạn chế đồng thời với bản sửa lỗi.
Poinsot thừa nhận rằng các bản sửa lỗi này sẽ trải qua ít thử nghiệm hơn trước khi đến tay người dùng.
Các lỗ hổng không được phân loại là dễ phát hiện tiếp tục tuân theo tiến trình dựa trên mức độ nghiêm trọng hiện có. Các vấn đề nghiêm trọng, chẳng hạn như những vấn đề có thể cho phép đánh cắp coin ở lớp giao thức, tăng cung coin một cách nhân tạo hoặc gây ra chia tách chuỗi không thể đảo ngược, vẫn nằm ngoài chính sách tiêu chuẩn và được giải quyết riêng lẻ.
Antoine Riard, một nhà phát triển, ủng hộ một tùy chọn để phát hành bản vá mà không có cảnh báo bảo mật và giữ lại chi tiết theo từng trường hợp. Poinsot từ chối, nói rằng thông báo cho người dùng mà không cung cấp chi tiết cụ thể “có thể tạo ra nhiều rủi ro không cần thiết” bằng cách gây ra sự di chuyển vội vã giữa những người dùng sẽ không bị ảnh hưởng.
Một mùa hè của các báo cáo do AI thúc đẩy
Bản cập nhật chính sách này đến sau nhiều tháng căng thẳng gia tăng đối với các dự án mã nguồn mở của Bitcoin. Vào cuối tháng 7, Bitcoin Red Team, một nhóm tình nguyện gồm 16 nhà phát triển, đã sử dụng các mô hình AI để quét 390 kho lưu trữ bitcoin trong khoảng 24 giờ, ghi nhận 4,962 phát hiện, trong đó 85 được coi là nghiêm trọng.
Trong vòng vài ngày, một lỗ hổng BTCPay Server mà nhóm đã tiết lộ riêng tư đã bị khai thác trên các máy chủ thương mại sản xuất, rút cạn các nút Lightning.
Vào tháng 8, các nhà phát triển Core Lightning khuyên các nhà vận hành nâng cấp hoặc ngắt kết nối sau khi dự án nhận được các báo cáo chính xác do AI tạo ra.
Sáng kiến của Bitcoin Red Team đến sau một vụ khai thác ví phần cứng Coldcard vào ngày 30 tháng 7, nơi những kẻ tấn công đã rút được 594 BTC trong 25 phút. Thiệt hại từ bốn đợt quét riêng biệt lên gần 114 triệu đô la.