Tác giả:Optech
Nguồn: https://bitcoinops.org/zh/newsletters/2024/07/05/
Bài viết này nằm trong phần tin tức của Bản tin Bitcoin Optech số 310. Bản dịch được cung cấp bởi "Nhóm dịch thuật tiếng Trung của Optech ( BitcoinOptechCN )".
Bài viết gốc tóm tắt lỗ hổng bảo mật được tiết lộ gần đây ảnh hưởng đến các phiên bản phần mềm Bitcoin Core trước 0.21.0. Để giúp người đọc dễ dàng xác định tính bảo mật của phiên bản phần mềm mình đang sử dụng, phần mô tả các lỗ hổng đã được sắp xếp lại theo thứ tự ngược với thời gian sửa chữa. Người dùng sử dụng các phiên bản mới hơn sẽ có ít phần nghiêm trọng hơn và cần đọc nhiều hơn.
Chúng tôi nhận thức rõ rằng triết lý soft fork là một phần cốt lõi trong triết lý phát triển Bitcoin, giúp người dùng tự do lựa chọn các quy tắc đồng thuận yêu thích của mình. Do đó, tính bảo mật của các phiên bản phần mềm cũ hơn là điều mà mọi người nên bảo vệ nếu không có nó. , triết lý soft fork và sự tự do tương ứng của nó là lời nói trống rỗng. Tuy nhiên, phần mềm, giống như các sản phẩm khác, có vòng đời được thiết kế sẵn. Việc mong đợi rằng một sản phẩm phần mềm có thể được bảo trì bảo mật bền vững là không thực tế. Do đó, cuối cùng, người vận hành nút đầy đủ phải chịu trách nhiệm đưa ra phán quyết: đánh giá tính bảo mật của một phần mềm trước khi sử dụng và cập nhật đánh giá của họ khi thông tin được tiết lộ.
Tiết lộ các lỗ hổng ảnh hưởng đến các phiên bản Bitcoin Core trước 0.21.0 : Antoine Poinsot đã đăng một liên kết trong nhóm gửi thư Bitcoin-Dev thông báo về 10 lỗ hổng ảnh hưởng đến các phiên bản phần mềm Bitcoin Core đã ngừng hoạt động gần hai năm. Chúng tôi tóm tắt những tiết lộ của chúng tôi như sau:
Phân mảnh mạng do điều chỉnh thời gian quá mức : Các phiên bản cũ hơn của Bitcoin Core đã cho phép đồng hồ của chính nó bị biến dạng theo thời gian báo cáo bởi 200 nút đầu tiên mà nó được kết nối. Các mã này nhằm mục đích cho phép biến dạng không quá 70 phút. Tất cả các phiên bản của phần mềm Bitcoin Core tạm thời bỏ qua các khối có dấu thời gian vượt quá 2 giờ so với giờ địa phương. Sự kết hợp của hai lỗi này cho phép kẻ tấn công đặt đồng hồ của nạn nhân sụp đổ hơn hai giờ, khiến nó bỏ qua các khối có dấu thời gian chính xác. Lỗ hổng này đã được nhà phát triển practicewift tiết lộ một cách nghiêm túc và đã được sửa trong Bitcoin Core 0.21.0.
Xem lại các giao dịch chưa được xác nhận : Nút thường thông báo các giao dịch mới thông qua txid hoặc wtxid của giao dịch. Lần đầu tiên nút nhìn thấy txid hoặc wtxid, nó sẽ yêu cầu giao dịch hoàn chỉnh từ nút đầu tiên để thông báo giao dịch. Trong khi chờ phản hồi từ nút này, nút cũng sẽ theo dõi nút khác đã thông báo cùng txid hoặc wtxid. Nếu nút đầu tiên không trả lời cho đến khi hết thời gian, nút sẽ yêu cầu giao dịch đầy đủ từ nút thứ hai (nếu hết thời gian chờ, nó sẽ chuyển sang thiết nút thứ ba, v.v.).
Trước Bitcoin Core 0.21.0, nút sẽ chỉ theo dõi tối đa 50.000 yêu cầu. Do đó, sau khi nút ngang hàng đầu tiên thông báo một txid, nó có thể trì hoãn yêu cầu của nút trả lời đối với giao dịch hoàn chỉnh, đợi các nút khác của nút thông báo giao dịch và sau đó gửi 50.000 thông báo về các txid khác (tất cả đều có thể là một txid giả). Bằng cách này, khi yêu cầu của nút về một giao dịch đầy đủ từ nút đầu tiên hết thời gian, nó sẽ không yêu cầu một giao dịch đầy đủ từ bất kỳ nút nào khác. Kẻ tấn công (nút đầu tiên) có thể lặp lại cuộc tấn công này vô thời hạn, ngăn chặn vĩnh viễn nút khỏi bị ảnh hưởng bởi giao dịch này. Lưu ý rằng việc kiểm duyệt các giao dịch chưa được xác nhận này có thể ngăn cản việc xác nhận giao dịch nhanh chóng, điều này có thể dẫn đến mất tiền trong các giao thức dựa trên hợp đồng như Lightning Channels. John Newbery đã tiết lộ lỗ hổng một cách có trách nhiệm, trích dẫn sự đồng phát hiện của Amiti Uttarwar. Bản sửa lỗi được phát hành trong Bitcoin Core 0.21.0.
CPU/Bộ nhớ DoS từ Danh sách bị cấm có kích thước vô hạn : Bitcoin Core PR #15617 (lần đầu được đưa vào 0.19.0) thêm mã để kiểm tra các IP bị cấm cục bộ khi nhận được địa chỉ tin nhắn
getaddrP2P, tối đa 2500 lần. Độ dài danh sách không kết nối của nút là không giới hạn và nếu kẻ tấn công kiểm soát lượng lớn địa chỉ IP (ví dụ: địa chỉ IPv6 có được dễ dàng), danh sách có thể tăng lên kích thước khổng lồ. Khi danh sách này trở nên rất dài, mỗi yêu cầugetaddrcó thể tiêu tốn quá nhiều CPU và bộ nhớ, điều này có thể khiến nút không khả dụng hoặc thậm chí bị hỏng. Lỗ hổng này được đánh số CVE-2020-14198 và đã được sửa trong Bitcoin Core 0.20.1.Sự cố bộ nhớ do cố gắng phân tích URI BIP72 : Bitcoin Core trước 0.20.0 đã hỗ trợ giao thức thanh toán BIP70 mở rộng BIP21
bitcoin:URI, sử dụng những người tham gia được BIP72 xác địnhrtham chiếu URL HTTP(S). Bitcoin Core sẽ cố tải xuống tệp từ URL này và lưu trữ tệp đó trong bộ nhớ chờ phân tích cú pháp, nhưng nếu tệp lớn hơn bộ nhớ khả dụng thì Bitcoin Core cuối cùng sẽ chấm dứt. Trong khi nỗ lực tải xuống diễn ra ở chế độ nền, người dùng có thể bỏ đi và do đó không nhận thấy nút bị lỗi và các dịch vụ quan trọng không được khởi động lại. Lỗ hổng này đã được Michael Ford tiết lộ một cách nghiêm túc và được Bitcoin Core 0.20.0 khắc phục bằng cách xóa hỗ trợ BIP70 (xem Báo cáo hàng tuần #70 ).Bộ nhớ DoS từ các tin nhắn
invlớn : Một tin nhắninvP2P có thể chứa danh sách lên tới 50.000 băm Block Header. Trước phiên bản 0.20.0, nút Bitcoin Core mới sẽ trả lời bằng một thông báogetheadersP2P riêng cho từng giá trị băm mà nó không hiểu và kích thước của một thông báo như vậy sẽ vào khoảng 1 kB. Điều này dẫn đến nút lưu trữ khoảng 50 MB tin nhắn trong bộ nhớ, chờ nút hàng nhận chúng. Mỗi nút có thể thực hiện việc này (và số lượng nút mặc định là khoảng 130), sử dụng hơn 6,5 GB bộ nhớ bổ sung ngoài yêu cầu bộ nhớ thông thường của nút- đủ để làm hỏng nhiều nút. Nút bị lỗi có thể không xử lý được các giao dịch nhạy cảm về thời gian cho người dùng giao thức dựa trên hợp đồng, có khả năng khiến người dùng bị mất tiền. John Newbery đã tiết lộ lỗ hổng bảo mật một cách có trách nhiệm và đưa ra cách khắc phục: chỉ trả lời tin nhắninvbằng thông báogetheaders, bất kể tin nhắn sau chứa bao nhiêu hàm băm; bản sửa lỗi đã được đưa vào Bitcoin Core 0.20.0.DoS gây lãng phí CPU thông qua các yêu cầu không đúng định dạng : Trước Bitcoin Core 0.20.0, kẻ tấn công hoặc một nút bị trục trặc có thể gửi tin nhắn
getdataP2P không đúng định dạng, khiến luồng xử lý tin nhắn tiêu thụ 100% CPU. Nút sẽ không còn có thể nhận tin nhắn từ kẻ tấn công trong suốt thời gian kết nối (sau cuộc tấn công), mặc dù nó vẫn có thể nhận tin nhắn từ nút trung thực. Điều này có thể chỉ gây ra những vấn đề nhỏ trên nút có một vài lõi CPU; nó có thể trở thành mối phiền toái ở những nơi khác. John Newbery đã tiết lộ lỗ hổng một cách có trách nhiệm và cung cấp bản sửa lỗi; bản sửa lỗi đã đưa nó vào Bitcoin Core 0.20.0.Độ trễ của CPU DoS và nút do xử lý các giao dịch mồ côi : Nút Bitcoin Core sẽ theo dõi bộ đệm không quá 100 giao dịch cho " giao dịch mồ côi " mà nút chưa có các giao dịch gốc cần thiết trong nhóm giao dịch và thông tin bộ UTXO. Sau khi xác thực một giao dịch mới, nút sẽ kiểm tra xem liệu có bất kỳ giao dịch mồ côi nào có thể xử lý được hay không. Trước Bitcoin Core 0.18.0, lần kiểm tra bộ đệm giao dịch mồ côi, nút sẽ cố gắng sử dụng nhóm giao dịch mới nhất và trạng thái UTXO để xác minh từng giao dịch mồ côi. Nếu 100 giao dịch mồ côi được lưu trong bộ nhớ đệm này được cấu trúc để yêu cầu lượng lớn CPU để xác minh thì nút có thể lãng phí quá nhiều CPU và có thể không xử lý được các khối mới và giao dịch mới trong vài giờ. Cuộc tấn công này về cơ bản là miễn phí: các giao dịch mồ côi được tạo miễn phí vì chúng có thể tham chiếu các giao dịch gốc không tồn tại. Nút bị đình trệ sẽ không thể tạo mẫu khối, vì vậy cuộc tấn công này có thể được sử dụng để ngăn thợ đào kiếm lợi nhuận và có thể được sử dụng để ngăn các giao dịch được xác nhận, có khả năng khiến người dùng giao thức dựa trên hợp đồng như Kênh Lightning để mất tiền của họ. Nhà phát triển sec.eine đã tiết lộ lỗ hổng này một cách nghiêm túc; nó đã được sửa trong Bitcoin Core 0.18.0.
DoS trong bộ nhớ sử dụng Block Header có độ khó thấp : Kể từ Bitcoin Core 0.10, nút sẽ yêu cầu mỗi nút gửi Block Header khối từ blockchain tốt nhất mà họ biết ( blockchain hợp lệ đã tích lũy nhiều Bằng chứng công việc nhất). Một vấn đề đã biết với phương pháp này là một kẻ ngang hàng độc hại có thể bắn phá nút nút lượng lớn Block Header giả có độ khó thấp (ví dụ: độ khó 1). Block Header như vậy rất dễ tạo bằng thiết bị khai thác ASIC tiên tiến. Phương pháp ban đầu của Bitcoin Core là chỉ chấp nhận Block Header trên blockchain khớp với các điểm kiểm tra được mã hóa cứng trong mã. Checkpoint cuối cùng tuy có từ năm 2014 nhưng cũng có độ khó tương đối cao so với tiêu chuẩn ngày nay nên sẽ tốn lượng lớn công sức để tạo ra Block Header giả. Tuy nhiên, một thay đổi mã được giới thiệu trong Bitcoin Core 0.12 đã bắt đầu cho phép nút chấp nhận Block Header có độ khó thấp vào bộ nhớ, có khả năng cho phép kẻ tấn công lấp đầy bộ nhớ bằng Block Header giả. Điều này có thể gây ra thời gian ngừng hoạt động nút và hơn nữa khiến người dùng các giao thức dựa trên hợp đồng (chẳng hạn như Kênh Lightning) bị mất tiền. Cory Fields đã tiết lộ lỗ hổng này một cách có trách nhiệm; nó đã được sửa trong phiên bản 0.15.0.
Lỗ hổng thực thi mã từ xa do miniupnpc : Trong các phiên bản trước Bitcoin Core 0.11.1 (phát hành vào tháng 10 năm 2015), nút sẽ bật UPnP theo mặc định để cho phép các kết nối gửi đến thông qua NAT . Điều này đạt được bằng cách sử dụng thư viện miniupnpc , thư viện này đã được Aleksandar Nikolic phát hiện có nhiều lỗ hổng có thể khai thác từ xa ( CVE-2015-6031 ). Các luồng này đã được sửa trong thư viện ngược dòng, bản sửa lỗi đã đưa nó vào Bitcoin Core và các nhà phát triển đã triển khai bản cập nhật vô hiệu hóa UPnP theo mặc định. Trong khi nghiên cứu lỗi này, nhà phát triển Bitcoin Wladimir J. Van Der Laan đã phát hiện ra một lỗ hổng thực thi mã từ xa khác trong cùng thư viện. Lỗ hổng đã được tiết lộ hợp lệ , được sửa trong thư viện ngược dòng và xâm nhập vào Bitcoin Core 0.12 (phát hành vào tháng 2 năm 2016).
Các tin nhắn lớn từ nhiều nút có thể gây ra sự cố nút : trước Bitcoin Core 0.10.1, yêu cầu về kích thước cho tin nhắn P2P theo nút không vượt quá (xấp xỉ) 32 MB. Và về mặt lịch sử (cho đến nay), nút đã cho phép tối đa 130 kết nối theo mặc định. Nếu mỗi nút hàng gửi tin nhắn có kích thước tối đa gần như cùng một lúc, điều này sẽ yêu cầu nút phân bổ thêm 4 GB dung lượng bộ nhớ ngoài các yêu cầu bộ nhớ khác, nhiều hơn mức mà nhiều nút có thể cung cấp. Lỗ hổng này đã được người dùng Evil-Knievel tiết lộ một cách nghiêm túc trên diễn đàn BitcoinTalk.org, nhận được số CVE-2015-3641 và đã được sửa trong Bitcoin Core 0.10.1. Phương pháp là giới hạn kích thước tin nhắn ở mức dưới 2 MB. (Sau đó, nó đã được tăng lên khoảng 4 MB cho nâng cấp Segregated Witness).
