Bài viết XRPL khắc phục lỗ hổng nghiêm trọng trước mainnet, nhưng các ứng dụng khách vẫn gặp rủi ro đã xuất hiện trên BitcoinEthereumNews.com.
Các trình xác thực của XRP Ledger (XRPL) đã đưa BatchV1_1 vào lộ trình kích hoạt có điều kiện vào lúc 14:06:41 UTC ngày 29 tháng 9, biến một vụ suýt gặp sự cố bảo mật thành một cuộc thử nghiệm thực tế đối với quy trình sửa đổi của mạng lưới và phần mềm xung quanh. Vào ngày 22 tháng 9, xrpldashboard cho thấy 30 trong số 35 trình xác thực đáng tin cậy ủng hộ sửa đổi này, cao hơn ngưỡng 28 phiếu được hiển thị. Sự ủng hộ đa số lần đầu xuất hiện trên sổ cái vào ngày 15 tháng 9. Theo các quy tắc sửa đổi của XRPL, mức ủng hộ phải duy trì trên 80% trong hai tuần. Nếu giảm xuống 80% hoặc thấp hơn thì giai đoạn đa số sẽ kết thúc, vì vậy ngày kích hoạt vẫn có điều kiện. Ngày 29 tháng 9 là lần thử nghiệm sản xuất đầu tiên xem liệu quy trình trình xác thực của XRPL, bản triển khai tham chiếu và hệ sinh thái ứng dụng khách có chuyển đổi một lỗ hổng nguy hiểm trước mainnet thành cơ sở hạ tầng giao dịch nguyên tử có thể sử dụng được hay không. Tường lửa trình xác thực đã hoạt động trước mainnet Sửa đổi Batch ban đầu chưa bao giờ được kích hoạt trên mainnet của XRP Ledger. Vào tháng 2, các nhà nghiên cứu đã phát hiện một lỗ hổng cấp quyền nghiêm trọng khi sửa đổi này vẫn đang trong giai đoạn bỏ phiếu, và các trình xác thực được khuyến nghị bỏ phiếu chống lại nó. Công bố lỗ hổng chính thức của XRPL Labs nêu rõ rằng không có khoản tiền nào gặp rủi ro. Lỗ hổng nằm trong vòng lặp kiểm tra các tài khoản cấp quyền cho một lô giao dịch. Nếu mã gặp một người ký cho một tài khoản mới được tạo có khóa khớp với tài khoản đó, nó sẽ trả về thành công ngay lập tức thay vì tiếp tục qua các người ký còn lại. Kẻ tấn công có thể đặt người ký hợp lệ đó lên đầu, rồi thêm một mục giả mạo nhằm cấp quyền cho tài khoản nạn nhân. Nếu sửa đổi đã được kích hoạt, giao dịch của nạn nhân không được kiểm tra có thể đã được thực thi mà không cần khóa của nạn nhân. Phản ứng của XRPL diễn ra theo hai giai đoạn. Phiên bản 3.1.1 đánh dấu các sửa đổi Batch và fixBatchInnerSigs ban đầu là không được hỗ trợ, chặn việc kích hoạt chúng. BatchV1_1 sau đó thay thế chúng bằng một lộ trình cấp quyền được viết lại và các biện pháp phòng vệ bổ sung. Sự việc này là một thất bại được phát hiện tại ranh giới giữa việc phát hành phần mềm và kích hoạt giao thức. Đặc tả XLS-56 cuối cùng của XRPL Foundation hiện…