#xrpledgerpatchesxrpcreationbug
XRP có thể đã được tạo ra từ hư không. Một lỗi tồn tại suốt một thập kỷ giải thích cách thức.
Sổ cái XRP công bố một lỗ hổng nghiêm trọng vào ngày 9 tháng 10. Theo thông tin được đưa ra, lỗi này đã tồn tại từ năm 2015 và có thể cho phép kẻ tấn công tạo ra và sử dụng XRP mà không phải trả đủ giá trị.
Đây là điều khiến tôi chú ý.
Vấn đề liên quan đến lỗi tràn số nguyên trong bộ xử lý thanh toán. Khi một khoản thanh toán sử dụng hàng trăm lệnh chào bán được tạo thủ công đặc biệt, tổng số có thể bị tràn và quay về một giá trị nhỏ hơn nhiều.
Bộ xử lý có thể ghi có tiền cho chủ sở hữu các lệnh chào bán, trong khi chỉ tính phí người mua một khoản thấp hơn nhiều.
Đáng lo ngại hơn, một bước kiểm tra an toàn được thiết kế để phát hiện XRP mới được tạo ra cũng dùng phép tính tương tự và không phát hiện được cùng lỗi tràn số.
Hai cơ chế bảo vệ có thể cùng thất bại nếu chúng mắc chung một điểm yếu nền tảng.
Bản vá đã được phát hành trong xrpld 3.4.1 vào ngày 25 tháng 9. Nhóm XRPL cho biết không có bằng chứng nào cho thấy lỗ hổng này đã bị khai thác trên mạng công khai.
Điều tôi rút ra: bảo mật blockchain không chỉ là tìm ra lỗi. Mà còn phải đảm bảo các cơ chế bảo vệ độc lập không cùng mắc một điểm mù.
Mã nguồn mở, chương trình săn lỗi và hoạt động kiểm toán đều quan trọng. Việc xác minh rằng bản vá thực sự khắc phục được lỗ hổng ban đầu cũng vậy.
Hệ thống bảo mật vững chắc nhất không phải là hệ thống tuyên bố rằng nó không có lỗi. Đó là hệ thống có thể phát hiện, khoanh vùng và khắc phục lỗi trước khi chúng bị khai thác.
Bạn có nghĩ các giao thức tiền mã hóa đầu tư đủ cho những bước kiểm tra bảo mật độc lập không?
$XRP #xrp #XRPledger #CryptoSecurity #BinanceSquare
XRP có thể đã được tạo ra từ hư không. Một lỗi tồn tại suốt một thập kỷ giải thích cách thức.
Sổ cái XRP công bố một lỗ hổng nghiêm trọng vào ngày 9 tháng 10. Theo thông tin được đưa ra, lỗi này đã tồn tại từ năm 2015 và có thể cho phép kẻ tấn công tạo ra và sử dụng XRP mà không phải trả đủ giá trị.
Đây là điều khiến tôi chú ý.
Vấn đề liên quan đến lỗi tràn số nguyên trong bộ xử lý thanh toán. Khi một khoản thanh toán sử dụng hàng trăm lệnh chào bán được tạo thủ công đặc biệt, tổng số có thể bị tràn và quay về một giá trị nhỏ hơn nhiều.
Bộ xử lý có thể ghi có tiền cho chủ sở hữu các lệnh chào bán, trong khi chỉ tính phí người mua một khoản thấp hơn nhiều.
Đáng lo ngại hơn, một bước kiểm tra an toàn được thiết kế để phát hiện XRP mới được tạo ra cũng dùng phép tính tương tự và không phát hiện được cùng lỗi tràn số.
Hai cơ chế bảo vệ có thể cùng thất bại nếu chúng mắc chung một điểm yếu nền tảng.
Bản vá đã được phát hành trong xrpld 3.4.1 vào ngày 25 tháng 9. Nhóm XRPL cho biết không có bằng chứng nào cho thấy lỗ hổng này đã bị khai thác trên mạng công khai.
Điều tôi rút ra: bảo mật blockchain không chỉ là tìm ra lỗi. Mà còn phải đảm bảo các cơ chế bảo vệ độc lập không cùng mắc một điểm mù.
Mã nguồn mở, chương trình săn lỗi và hoạt động kiểm toán đều quan trọng. Việc xác minh rằng bản vá thực sự khắc phục được lỗ hổng ban đầu cũng vậy.
Hệ thống bảo mật vững chắc nhất không phải là hệ thống tuyên bố rằng nó không có lỗi. Đó là hệ thống có thể phát hiện, khoanh vùng và khắc phục lỗi trước khi chúng bị khai thác.
Bạn có nghĩ các giao thức tiền mã hóa đầu tư đủ cho những bước kiểm tra bảo mật độc lập không?
$XRP #xrp #XRPledger #CryptoSecurity #BinanceSquare