Khai thác lỗi sét là sự lựa chọn hợp đạo đức

Đây là một bài xã luận quan điểm của Shinobi, một nhà giáo dục tự học trong không gian Bitcoin và người dẫn chương trình podcast Bitcoin theo định hướng công nghệ.

Lần thứ hai trong khoảng một tháng, btcd/LND đã bị khai thác một lỗi khiến chúng đi chệch khỏi sự đồng thuận so với Bitcoin Core. Một lần nữa, Burak là nhà phát triển đã kích hoạt lỗ hổng này – lần này rõ ràng là có chủ ý – và một lần nữa, đó là vấn đề với mã phân tích giao dịch Bitcoin phía trên lớp đồng thuận. Như tôi đã thảo luận trong phần về lỗi trước mà Burak đã kích hoạt, trước Taproot, đã có các giới hạn về mức độ lớn của tập lệnh và dữ liệu nhân chứng trong một giao dịch. Với việc kích hoạt Taproot, các giới hạn đó đã bị xóa, chỉ còn lại các giới hạn về giới hạn kích thước khối để giới hạn các phần này của các giao dịch riêng lẻ. Vấn đề với lỗi cuối cùng là mặc dù thực tế là mã đồng thuận trong btcd đã được nâng cấp đúng cách để phản ánh thay đổi này, nhưng mã xử lý truyền ngang hàng – bao gồm phân tích dữ liệu trước khi gửi hoặc khi nhận – đã không được nâng cấp đúng cách. Vì vậy, các khối xử lý mã và giao dịch trước khi nó thực sự được chuyển đi để xác thực sự đồng thuận đã làm dữ liệu bị lỗi, không bao giờ được chuyển đến logic xác thực đồng thuận và khối được đề cập không bao giờ được xác thực.

Một điều tương tự đã xảy ra lần này. Một giới hạn khác trong phần ngang hàng của cơ sở mã là thực thi hạn chế đối với dữ liệu nhân chứng không chính xác, giới hạn ở mức tối đa là 1/8 kích thước khối thay vì kích thước khối đầy đủ. Burak đã tạo ra một giao dịch với dữ liệu nhân chứng chỉ là một đơn vị trọng lượng vượt quá giới hạn nghiêm ngặt và một lần nữa các nút btcd và LND bị đình trệ ở độ cao khối đó. Giao dịch này là giao dịch không chuẩn, có nghĩa là mặc dù nó hoàn toàn hợp lệ theo các quy tắc đồng thuận, nhưng nó không hợp lệ theo chính sách mempool mặc định và do đó các nút sẽ không chuyển tiếp nó qua mạng. Hoàn toàn có thể khai thác nó thành một khối, nhưng cách duy nhất để làm như vậy là cung cấp nó trực tiếp cho người khai thác, đó là những gì Burak đã làm với sự trợ giúp của F2Pool.

Điều này thực sự thúc đẩy quan điểm rằng bất kỳ đoạn mã nào có mục đích phân tích và xác thực dữ liệu Bitcoin đều phải được kiểm tra chặt chẽ để đảm bảo nó phù hợp với những gì Bitcoin Core sẽ làm. Sẽ không có vấn đề gì nếu mã đó là công cụ đồng thuận để triển khai nút hoặc chỉ là một đoạn mã chuyển các giao dịch xung quanh nút Lightning. Lỗi thứ hai này là theo đúng nghĩa đen là ngay phía trên cái của tháng trước trong cơ sở mã. Nó thậm chí còn không được phát hiện bởi bất kỳ ai ở Lightning Labs. AJ Towns đã báo cáo vấn đề này vào ngày 11 tháng 998, hai ngày sau khi lỗi ban đầu được kích hoạt bởi giao dịch đa chữ ký 999 trên 10 của Burak. Nó đã được đăng công khai trên Github trong XNUMX giờ trước khi bị xóa. Sau đó, một bản sửa lỗi đã được thực hiện nhưng không được phát hành với mục đích âm thầm khắc phục sự cố trong bản phát hành tiếp theo của LND.

Hiện tại, đây là quy trình khá chuẩn đối với một lỗ hổng nghiêm trọng, đặc biệt là với một dự án như Bitcoin Core, nơi một lỗ hổng như vậy thực sự có thể gây ra thiệt hại nghiêm trọng cho mạng/giao thức lớp cơ sở. Nhưng trong trường hợp cụ thể này, nó gây ra rủi ro nghiêm trọng đối với tiền của người dùng LND và thực tế là nó nằm ngay cạnh lỗi trước đó có cùng rủi ro, nên khả năng nó được tìm thấy và khai thác là rất cao, như Burak đã chứng minh. Điều này đặt ra câu hỏi liệu cách tiếp cận bản vá im lặng có phải là hướng đi hay không khi gặp các lỗ hổng như thế này có thể khiến người dùng có nguy cơ bị đánh cắp tiền (vì nút của họ không thể phát hiện các trạng thái kênh cũ và trừng phạt chúng một cách thích hợp).

Khi tôi đi sâu vào phần của mình về lỗi cuối cùng, nếu một tác nhân độc hại đã tìm thấy lỗi trước một nhà phát triển có mục đích tốt, thì họ có thể đã mở các kênh mới một cách chiến thuật tới các nút dễ bị tấn công, chuyển toàn bộ nội dung của các kênh đó về chính họ và sau đó đã khai thác lỗi. Từ đó, họ sẽ kiểm soát số tiền đó và cũng có thể đóng kênh ở trạng thái ban đầu, nhân đôi số tiền của họ theo đúng nghĩa đen. Những gì Burak đã làm khi tích cực khai thác vấn đề này một cách mỉa mai thực sự đã bảo vệ người dùng LND khỏi một cuộc tấn công như vậy.

Sau khi nó bị khai thác, người dùng có thể gặp phải các cuộc tấn công như vậy từ các đồng nghiệp có sẵn mà họ đã có kênh mở, nhưng họ không còn có khả năng bị nhắm mục tiêu cụ thể bằng các kênh mới nữa. Các nút của họ đã bị đình trệ và sẽ không bao giờ nhận ra hoặc xử lý các khoản thanh toán thông qua các kênh mà ai đó đã cố mở sau khi khối khiến nút của họ bị đình trệ. Vì vậy, mặc dù nó không loại bỏ hoàn toàn nguy cơ người dùng bị lợi dụng nhưng nó đã hạn chế rủi ro đó đối với những người đã có kênh cùng họ. Hành động của Burak đã giảm nhẹ nó. Cá nhân tôi nghĩ rằng loại hành động này để ứng phó với lỗi này là hợp lý; nó hạn chế thiệt hại, khiến người dùng nhận thức được rủi ro và dẫn đến việc nó nhanh chóng được vá lỗi.

LND cũng không phải là thứ duy nhất bị ảnh hưởng. chất lỏng quá trình chốt cũng bị hỏng, yêu cầu cập nhật các chức năng của liên đoàn để sửa lỗi. Các phiên bản cũ hơn của Rust Bitcoin cũng bị ảnh hưởng, khiến cho việc ngừng hoạt động ảnh hưởng đến một số phiên bản trình khám phá khối và trình điện tử (việc triển khai máy chủ phụ trợ cho Ví Electrum). Giờ đây, ngoại trừ việc chốt của Liquid cuối cùng đã tiết lộ tiền cho các khóa khôi phục khẩn cấp do Blockstream nắm giữ sau khi hết thời gian - và, thực tế là trong cốt truyện phim theo phong cách trộm cắp nơi Blockstream đã đánh cắp số tiền này, mọi người đều biết chính xác ai sẽ truy lùng - những người khác các vấn đề không bao giờ khiến quỹ của bất kỳ ai gặp rủi ro vào bất kỳ thời điểm nào. Ngoài ra, Rust Bitcoin thực sự đã vá lỗi cụ thể này trong các phiên bản mới hơn, điều này dường như không dẫn đến bất kỳ liên lạc nào với những người bảo trì các cơ sở mã khác để làm nổi bật khả năng xảy ra các vấn đề như vậy. Chỉ có việc khai thác tích cực lỗi trực tiếp trên mạng mới cho thấy sự cố tồn tại trong nhiều cơ sở mã.

Điều này đặt ra một số vấn đề lớn khi nói đến các lỗ hổng như thế này trong phần mềm Lớp 2 trên Bitcoin. Đầu tiên, mức độ nghiêm túc của việc kiểm tra các cơ sở mã này để tìm lỗi bảo mật và mức độ ưu tiên của việc đó so với việc tích hợp các tính năng mới. Tôi nghĩ điều đáng nói là bảo mật không phải lúc nào cũng được ưu tiên vì lỗi thứ hai này thậm chí không được tìm thấy bởi những người bảo trì cơ sở mã nơi nó hiện diện, mặc dù theo đúng nghĩa đen, nó nằm ngay cạnh lỗi đầu tiên được phát hiện vào tháng trước. Sau một lỗi lớn khiến tiền của người dùng gặp rủi ro, chẳng phải việc kiểm tra nội bộ đối với cơ sở mã đó đã không được thực hiện sao? Phải mất ai đó từ bên ngoài dự án để phát hiện ra nó? Điều đó không thể hiện mức độ ưu tiên bảo vệ tiền của người dùng so với việc xây dựng các tính năng mới để thu hút nhiều người dùng hơn. Thứ hai, thực tế là vấn đề này đã được vá trong Rust Bitcoin chứng tỏ sự thiếu liên lạc giữa những người bảo trì các cơ sở mã khác nhau liên quan đến các lỗi như thế này. Điều này khá dễ hiểu, vì các cơ sở mã hoàn toàn khác nhau không khiến ai đó tìm thấy lỗi trong đó ngay lập tức nghĩ rằng: “Tôi nên liên hệ với các nhóm khác viết phần mềm tương tự bằng các ngôn ngữ lập trình hoàn toàn khác nhau để cảnh báo họ về khả năng xảy ra lỗi như vậy”. Bạn không tìm thấy một lỗi nào trong Windows và sau đó nghĩ ngay đến việc báo cáo lỗi đó cho những người bảo trì nhân Linux. Tuy nhiên, Bitcoin với tư cách là một giao thức cho sự đồng thuận phân tán trên mạng toàn cầu lại là một con thú rất khác; có lẽ các nhà phát triển Bitcoin nên bắt đầu suy nghĩ theo hướng đó khi nói đến các lỗ hổng trong phần mềm Bitcoin. Đặc biệt là khi phân tích và giải thích dữ liệu liên quan đến sự đồng thuận.

Cuối cùng, có thể khi nói đến các giao thức như Lightning, phụ thuộc vào việc quan sát blockchain mọi lúc để có thể phản ứng với các trạng thái kênh cũ nhằm duy trì tính bảo mật, việc phân tích cú pháp và xác minh dữ liệu độc lập phải được giữ ở mức tối thiểu – nếu không bị xóa hoàn toàn và được ủy quyền cho Bitcoin Core hoặc dữ liệu có nguồn gốc trực tiếp từ nó. Core Lightning được kiến ​​trúc theo cách này, kết nối với một phiên bản của Bitcoin Core và phụ thuộc hoàn toàn vào đó để xác thực các khối và giao dịch. Nếu LND hoạt động theo cách tương tự, cả hai lỗi này trong btcd sẽ không ảnh hưởng đến người dùng LND theo cách khiến tiền của họ gặp rủi ro.

Dù mọi thứ được xử lý theo cách nào - hoặc thuê ngoài hoàn toàn xác thực hoặc đơn giản là giảm thiểu xác thực nội bộ và tiếp cận nó cẩn thận hơn nhiều - sự cố này cho thấy cần phải thay đổi điều gì đó trong việc tiếp cận vấn đề về cách phần mềm Lớp 2 xử lý tương tác với dữ liệu liên quan đến sự đồng thuận. Một lần nữa, mọi người đều rất may mắn khi điều này không bị khai thác bởi một kẻ độc hại mà thay vào đó là một nhà phát triển đã chứng minh được quan điểm. Nói như vậy, Bitcoin không thể trông chờ vào sự may mắn hoặc hy vọng rằng những tác nhân độc hại không tồn tại.

Các nhà phát triển và người dùng nên tập trung vào việc cải thiện các quy trình để ngăn chặn những sự cố như thế này xảy ra lần nữa và không chơi trò đổ lỗi như một củ khoai tây nóng.

Đây là một bài đăng của Shinobi. Các ý kiến ​​được bày tỏ hoàn toàn là của riêng họ và không nhất thiết phải phản ánh ý kiến ​​của BTC Inc hoặc Tạp chí Bitcoin.