Tác giả: Kalle Rosenbaum & Linnéa Rosenbaum
Bitcoin được phát triển bởi con người. Con người viết phần mềm, và sau đó vận hành phần mềm đó. Khi lỗ hổng bảo mật hoặc lỗi nghiêm trọng được phát hiện—liệu có thực sự khác biệt?—luôn luôn là con người phát hiện ra chúng; từ đầu đến cuối, đều là chúng ta, bằng xương bằng thịt. Chương này xem xét những gì mọi người đã làm, nên làm và không nên làm khi các lỗ hổng được phát hiện. Phần đầu tiên giải thích ý nghĩa của thuật ngữ "tiết lộ có trách nhiệm ", đề cập đến cách hành động lịch sử sau khi phát hiện ra lỗ hổng để giảm thiểu thiệt hại mà nó gây ra. Các chương còn lại sẽ đưa bạn đi qua một số lỗ hổng nghiêm trọng nhất từng được phát hiện trong phần mềm Bitcoin, và cách các nhà phát triển, thợ đào và người dùng đã xử lý chúng. Trong những ngày đầu của Bitcoin, nhiều thứ không mạnh mẽ như ngày nay.
9.1 Công khai đầy đủ thông tin
Hãy tưởng tượng bạn phát hiện ra một lỗi trong phần mềm Bitcoin Core cho phép ai đó tắt từ xa một nút Bitcoin Core chỉ bằng cách gửi một tin nhắn được tạo ra đặc biệt qua mạng. Bây giờ, giả sử bạn không có ý định xấu và không muốn lỗ hổng này bị khai thác. Bạn sẽ làm gì? Nếu bạn im lặng, người khác cũng có thể phát hiện ra lỗ hổng đó, nhưng người đó có thể không tốt bụng như bạn.
Khi tiết lộ một vấn đề bảo mật, người tiết lộ cần tuân theo quy trình tiết lộ có trách nhiệm . Các nhà phát triển Bitcoin cũng thường xuyên sử dụng thuật ngữ này; Wikipedia giải thích ý nghĩa của nó như sau:
Các nhà phát triển phần cứng và phần mềm thường cần thời gian và nguồn lực để sửa lỗi. Thông thường, những lỗ hổng này được phát hiện bởi hacker có đạo đức [1]. Hacker và các nhà khoa học an ninh máy tính có thể chọn việc nâng cao nhận thức cộng đồng về những lỗ hổng này là trách nhiệm xã hội của họ. Che giấu vấn đề có thể tạo ra cảm giác an toàn giả tạo. Để tránh điều này, các bên liên quan sẽ phối hợp và đàm phán một khoảng thời gian hợp lý để khắc phục lỗ hổng. Khoảng thời gian này có thể kéo dài từ vài ngày đến vài tháng, tùy thuộc vào tác động tiềm tàng của lỗ hổng, thời gian dự kiến cần thiết để phát triển và triển khai các bản vá khẩn cấp hoặc giải pháp thay thế, và các yếu tố khác.
— Wikipedia, mục "Tiết lộ có trách nhiệm"
Điều này có nghĩa là nếu bạn phát hiện ra lỗ hổng bảo mật, bạn nên báo cáo cho đội ngũ chịu trách nhiệm phát triển hệ thống. Nhưng điều này hoạt động như thế nào trong thế giới Bitcoin? Như đã mô tả trong Chương 7.1 ( bản dịch tiếng Trung ), không ai kiểm soát Bitcoin; chỉ có một trọng tâm duy nhất trong quá trình phát triển Bitcoin: kho lưu trữ Bitcoin Core trên GitHub . Những người duy trì kho lưu trữ này chịu trách nhiệm về mã nguồn trong đó, nhưng họ không chịu trách nhiệm về toàn bộ hệ thống Bitcoin—và cũng không ai khác. Hơn nữa, cách làm tốt nhất thường là gửi email đến security@bitcoincore.org .
Trong một email năm 2017 có tiêu đề “Tiết lộ lỗi có trách nhiệm”, Anthony Towns đã cố gắng tóm tắt những gì ông cho rằng thực tiễn tốt nhất. Ông đã thu thập ý kiến từ nhiều nguồn và nhiều người khác nhau để trình bày quan điểm của mình về chủ đề này.
- Các lỗ hổng bảo mật nên được báo cáo thông qua trang bảo mật trên trang web bitcoincore.org [0].
- Các lỗ hổng nghiêm trọng (những lỗ hổng có thể bị khai thác ngay lập tức, hoặc những lỗ hổng đã bị khai thác và gây ra thiệt hại đáng kể) sẽ được xử lý như sau:
- Hãy phát hành bản vá lỗi càng sớm càng tốt.
- Các thông báo rộng rãi cho thấy cần phải nâng cấp(hoặc vô hiệu hóa các hệ thống bị ảnh hưởng).
- Tiết lộ càng ít vấn đề thực tế càng tốt để trì hoãn cuộc tấn công [1][2]
- Các lỗ hổng không nghiêm trọng (vì khó hoặc tốn kém để khai thác) sẽ được xử lý như sau:
- Vá lỗi và xem xét lại trong quy trình phát triển tiêu chuẩn.
- Chuyển các bản sửa lỗi hoặc giải pháp thay thế từ nhánh chính sang bản phát hành hiện tại [2]
- Các nhà phát triển sẽ cố gắng phát hành bản vá mà không tiết lộ bản chất của lỗ hổng. Cách tiếp cận là cung cấp bản vá được đề xuất cho các nhà phát triển có kinh nghiệm nhưng không biết, thông báo cho họ rằng một lỗ hổng đã được khắc phục và yêu cầu họ xác định vị trí của lỗ hổng. [2]
- Trước khi bản vá được phát hành và áp dụng rộng rãi, các nhà phát triển có thể đề xuất các triển khai Bitcoin khác áp dụng bản vá nếu nó có thể ngăn chặn lỗ hổng bị lộ; ví dụ, nếu bản vá có những lợi thế đáng kể về hiệu suất, thì đó có thể là lý do để hợp nhất các mã này [3].
- Trước khi lỗ hổng được tiết lộ, các nhà phát triển thường khuyên các nhà phát triển Altcoin thân thiện nên theo dõi việc khắc phục. Tuy nhiên, điều này chỉ có thể thực hiện được sau khi bản vá đã được triển khai rộng rãi trên mạng Bitcoin. [4]
- Các nhà phát triển thường không thông báo cho các nhà phát triển Altcoin đã từng thể hiện thái độ thù địch trước đó (ví dụ: bằng cách sử dụng các lỗ hổng để tấn công người khác hoặc vi phạm các điều cấm) [5].
- Các nhà phát triển Bitcoin sẽ không tiết lộ các lỗ hổng cho đến khi hơn 80% số nút Bitcoin đã triển khai bản vá. Những người tiết lộ lỗ hổng sẽ được khuyến khích và yêu cầu tuân theo chiến lược tương tự [1][6].
— Anthony Towns, danh sách gửi thư “Tiết lộ đầy đủ các lỗi”, danh sách gửi thư Bitcoin-dev (2017)
Danh sách trên minh họa mức độ thận trọng cần thiết khi phát hành các bản vá lỗi cho Bitcoin, vì các bản vá có thể tiết lộ vị trí của các lỗ hổng. Điểm thứ tư đặc biệt thú vị vì nó giải thích cách kiểm tra xem một bản vá có được che giấu tốt hay không. Trên thực tế, nếu ngay cả một vài nhà phát triển giàu kinh nghiệm cũng không thể tìm thấy lỗ hổng khi họ biết đó là bản vá, thì việc những người khác tìm ra nó sẽ rất khó khăn.
Trước email này, cuộc thảo luận trong chuỗi email xoay quanh việc liệu, khi nào và bằng cách nào nên tiết lộ các lỗ hổng bảo mật cho các nhà phát triển Altcoin và các nhà phát triển triển khai Bitcoin khác. Không có câu trả lời dứt khoát. "Giúp đỡ những người tốt" nghe có vẻ hợp lý, nhưng ai có thể chắc chắn rằng họ không phải là người tốt? Ranh giới được vạch ra ở đâu? Bryan Bishop lập luận rằng việc giúp Altcoin, ngay cả những altcoin gian lận, tự bảo vệ mình khỏi các vi phạm bảo mật là một trách nhiệm đạo đức.
Việc bảo vệ Bitcoin và người dùng của nó khỏi các mối đe dọa tức thời là chưa đủ; còn có một trách nhiệm rộng lớn hơn là bảo vệ tất cả các loại người dùng và các phần mềm khác nhau khỏi nhiều loại mối đe dọa dưới mọi hình thức, ngay cả khi những người dùng đó đang sử dụng phần mềm kém an toàn mà cá nhân bạn không bảo trì, phát triển hoặc khuyến nghị sử dụng. Xử lý thông tin về lỗ hổng bảo mật rất phức tạp, và bạn có thể nhận được thông tin với những hậu quả trực tiếp hoặc gián tiếp nghiêm trọng hơn so với mô tả ban đầu.
— Bryan Bishop, danh sách gửi thư “Công khai lỗi một cách có trách nhiệm”, danh sách gửi thư Bitcoin-dev (2017)
Trước email của Towns là một email khác từ Gregory Maxwell, trong trong đó ông lập luận rằng lỗ hổng bảo mật có thể nghiêm trọng hơn vẻ bề ngoài.
Tôi đã lần chứng kiến cách một vấn đề ban đầu được cho rằng khó khai thác lại hóa ra khá dễ khai thác, miễn là bạn tìm được đúng đối tượng; hoặc cách một vấn đề tấn công từ chối dịch vụ (DoS) nhỏ lại trở thành một vấn đề nghiêm trọng hơn nhiều.
Ngay cả một lỗi hiệu năng đơn giản, nếu được triển khai cẩn thận, cũng có thể được sử dụng để chia tách mạng lưới — thợ đào A và sàn giao dịch B nằm trên một mạng, trong khi những người khác nằm trên một mạng khác, cho phép ai đó chi tiêu nhiều lần.
Và cứ thế tiếp tục. Vì vậy, mặc dù tôi hoàn toàn đồng ý rằng những vấn đề khác nhau nên (và có thể) được xử lý theo những cách khác nhau, nhưng ranh giới không phải lúc nào cũng rõ ràng. Điều quan trọng nhất là phải thận trọng: cho rằng vấn đề nghiêm trọng hơn những gì bạn đã biết.
— Gregory Maxwell, danh sách gửi thư “Tiết lộ lỗi một cách đầy đủ”, danh sách gửi thư Bitcoin-dev (2017)
Do đó, ngay cả khi một lỗ hổng có vẻ khó khai thác, tốt nhất nên giả định rằng nó dễ khai thác—chỉ là bạn chưa tìm ra cách khai thác nó mà thôi.
Gregory cũng lưu ý, "Thật không đúng cho rằng chuỗi email này đang thảo luận về 'tiết lộ'. Tiết lộ ở đây có nghĩa là thông báo cho nhà cung cấp. Chuỗi email này nói về 'công khai thông tin', và ý nghĩa của chúng khác nhau. Công khai thông tin có nghĩa là bạn chắc chắn rằng mình cũng đã thông báo cho một kẻ tấn công tiềm năng." Nhận xét cuối cùng này, về sự khác biệt giữa tiết lộ và công khai thông tin, rất quan trọng. Tiết lộ có trách nhiệm là phần đơn giản hơn; công khai thông tin một cách hợp lý mới là phần khó.
9.2 Chấn thương thời thơ ấu
Ban đầu, Bitcoin là một dự án cá nhân (ít nhất, dựa trên bút danh của người tạo ra nó, đó là một người), và vào thời điểm đó , Bitcoin hầu như không có giá trị. Do đó, việc phát hiện các lỗ hổng và sửa lỗi không được thực hiện một cách nghiêm ngặt như hiện nay.
Wiki Bitcoin duy trì danh sách các lỗ hổng bảo mật đã được công khai (CVE) ảnh hưởng đến Bitcoin . Chương này sẽ giới thiệu một số lỗ hổng bảo mật trong đó , cũng như một số sự cố bất ngờ xảy ra trong những ngày đầu Bitcoin. Chúng ta sẽ không đề cập đến tất cả các lỗ hổng, mà chỉ trong đó chúng ta thấy đặc biệt thú vị.
9.2.1 2010-07-28: Tiêu tiền của người khác (CVE-2010-5141)
Vào ngày 28 tháng 7 năm 2010, một người dùng nặc danh sử dụng biệt danh "ArtForz" đã phát hiện ra một lỗ hổng trong phần mềm bitcoin phiên bản 0.3.4 cho phép bất kỳ ai cũng có thể tiêu tiền của người khác. ArtForz đã báo cáo lỗ hổng này cho Satoshi Nakamoto và một nhà phát triển khác có tên "Gavin Andresen".
Vấn đề là mã lệnh OP_RETURN của script tại thời điểm đó sẽ ngay lập tức chấm dứt quá trình thực thi chương trình. Do đó, nếu khóa công khai của script cho số tiền đã chi tiêu là <pubkey> OP_CHECKSIG và chữ ký của script là OP_1 OP_RETURN , thì chương trình trong khóa công khai của script sẽ không được thực thi. Điều duy nhất xảy ra là giá trị 1 được thêm vào trò chơi, và sau đó OP_RETURN khiến chương trình trong khóa công khai của script bị bỏ qua. Sau khi chương trình kết thúc thực thi, bất kỳ giá trị nào khác 0 ở đầu ngăn xếp đều có nghĩa là điều kiện chi tiêu đã được đáp ứng. Vì phần tử ở đầu ngăn xếp là 1 , chứ không phải 0 , nên việc chi tiêu thành công.
Đây là đoạn mã xử lý OP_RETURN vào thời điểm đó:
case OP_RETURN: { pc = pend; } break; Tác dụng của pc = pend; là bỏ qua phần còn lại của chương trình, nghĩa là bất kỳ tập lệnh nào bị khóa trong khóa công khai của tập lệnh sẽ bị bỏ qua. Một cách khắc phục là thay đổi ý nghĩa của OP_RETURN để nó ngay lập tức xuất ra lỗi (thực thi tập lệnh).
case OP_RETURN: { return false; } break;Satoshi Nakamoto đã thực hiện thay đổi này trong mã nguồn của mình và sau đó biên dịch một tệp nhị phân có thể thực thi bằng phiên bản 0.3.5. Sau đó, ông đăng trên diễn đàn Bitcointalk: "CẢNH BÁO! Nâng cấp lên 0.3.5 CÀNG SỚM CÀNG TỐT (***** THÔNG BÁO *** Nâng cấp lên 0.3.5 CÀNG SỚM CÀNG TỐT)", kêu gọi người dùng cài đặt tệp nhị phân, nhưng không cung cấp mã nguồn của nó.
Vui lòng nâng cấp lên phiên bản 0.3.5 ngay lập tức! Chúng tôi đã sửa một lỗi lập trình cho phép mạng lưới chấp nhận giao dịch giả tạo . Không chấp nhận bất kỳ khoản thanh toán Bitcoin cho đến khi nâng cấp lên phiên bản 0.3.5!
— Satoshi Nakamoto, diễn đàn Bitcointalk (2010)
Tin nhắn gốc đã được chỉnh sửa, và hiện nay hình thức đầy đủ của nó không còn được biết đến. Đoạn trích trên được lấy từ một câu trả lời được trích dẫn . Một số người dùng đã thử chạy tệp nhị phân của Satoshi Nakamoto nhưng gặp sự cố. Ngay sau đó, Satoshi Nakamoto nói :
SVN chưa được cập nhật. Vui lòng chờ phiên bản 0.3.6, phiên bản mà tôi hiện đang phát triển. Trong thời gian chờ đợi, bạn có thể tắt nút của mình.
— Satoshi Nakamoto, diễn đàn Bitcointalk (2010)
(Ghi chú của người dịch: "SVN" ở đây nên được hiểu là "Apache Subversion," một hệ thống quản lý phiên bản mã nguồn mở.)
35 phút sau, anh ấy nói :
SVN đã được cập nhật lên phiên bản 0.3.6.
Tôi đang tải tệp thực thi Windows (phiên bản 0.3.6) lên Sourceforge, sau đó tôi sẽ biên dịch lại tệp thực thi Linux.
— Satoshi Nakamoto, diễn đàn Bitcointalk (2010)
(Ghi chú của người dịch: "Sourceforge" là một trang web nơi bạn có thể tải lên mã nguồn để người khác tải xuống.)
Đến lúc này, anh ấy dường như cũng đã cập nhật bài đăng gốc của mình, thay đổi "0.3.5" thành "0.3.6":
Vui lòng nâng cấp lên phiên bản 0.3.5 ngay lập tức! Chúng tôi đã sửa một lỗi lập trình cho phép giao dịch giả tạo có thể được hiển thị là đã chấp nhận. Không chấp nhận bất kỳ khoản thanh toán Bitcoin nào cho đến khi nâng cấp lên phiên bản 0.3.5!
Nếu bạn không thể nâng cấp lên phiên bản 0.3.6 ngay bây giờ, tốt nhất là nên tắt nút Bitcoin của bạn, nâng cấp, rồi khởi động lại.
Phiên bản 0.3.6 cũng triển khai các thao tác băm nhanh hơn:
- Nhờ có tcatm, việc tối ưu hóa bộ nhớ đệm trạng thái trung gian đã được thực hiện.
- Cảm ơn BlackEye đã bổ sung Crypto++ ASM SHA-256.
Hiệu ứng gia tốc cuối cùng là 2,4 lần.
Trang tải xuống:
http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.6/
Người dùng Windows và Linux: Ngay cả khi bạn đang sử dụng phiên bản 0.3.5, bạn vẫn cần nâng cấp lên phiên bản 0.3.6.
— Satoshi Nakamoto, diễn đàn Bitcointalk (2010)
Xin lưu ý sự khác biệt về cách diễn đạt trong hai tin nhắn: tin nhắn đầu tiên nói "(Giao dịch giả tạo) đã được mạng lưới chấp nhận", trong khi tin nhắn thứ hai nói "Nó đã được hiển thị là đã được chấp nhận". Có lẽ Satoshi Nakamoto đã hạ thấp mức độ nghiêm trọng của vấn đề để tránh thu hút sự chú ý đến vấn đề thực sự. Dù sao đi nữa, những người nâng cấp lên phiên bản 0.3.6 vẫn có thể sử dụng Bitcoin bình thường. Vấn đề đã được giải quyết, và đáng ngạc nhiên là không ai bị mất Bitcoin.
Thông điệp của Satoshi Nakamoto cũng đề cập đến việc tối ưu hóa hiệu suất khai thác. Không rõ tại sao điều này lại được đưa vào bản vá lỗi bảo mật quan trọng, nhưng có thể mục đích là để che giấu vấn đề thực sự. Tuy nhiên, có vẻ hợp lý hơn khi cho rằng ông chỉ đơn giản là phát hành một bản cập nhật trên nhánh phát triển của mã nguồn Subversion (bất kể đó là gì) và trong đó bản vá lỗi bảo mật.
Hồi đó, số người dùng Bitcoin ít hơn nhiều so với hiện nay, và Bitcoin hầu như không có giá trị. Nếu họ phải xử lý những lỗi như thế này ngày nay, nó sẽ được coi là một bộ phim truyền hình dài tập đình đám.
- Satoshi Nakamoto đã phát hành phiên bản 0.3.5, trong đó bao gồm các tệp nhị phân và các bản vá lỗi. Việc thiếu bản vá và mã nguồn có thể được xem là một cách để che giấu vấn đề.
- Phiên bản 0.3.5 thậm chí không thể chạy được .
- Bản sửa lỗi trong phiên bản 0.3.6 thực chất là một hard fork, như đã giải thích trong mục 5.2 ( bản dịch tiếng Trung ).
Một vấn đề gây tranh cãi khác là liệu việc cho phép người dùng vô hiệu hóa nút của chính họ là điều tốt hay điều xấu. Ngày nay điều đó là không thể, nhưng vào thời điểm đó, nhiều người dùng tích cực theo dõi các cập nhật trên diễn đàn và thường khá am hiểu. Do đó, điều đó là khả thi và có lẽ là một biện pháp hợp lý.
9.2.2 Ngày 15 tháng 8 năm 2010: Lỗi tràn giá trị đầu ra khi hợp nhất (CVE-2010-5139)
Vào giữa tháng 8 năm 2010, một người dùng diễn đàn Bitcointalk có tên "jgarzik," hay còn gọi là Jeff Garzik, đã phát hiện ra rằng hai đầu ra của một giao dịch ở Block Height 74638 sở hữu giá trị cao hiếm gặp:
"Kết quả đầu ra" trong khối #74638 rất kỳ lạ:
"out" : [ { "value" : 92233720368.54277039, "scriptPubKey" : "OP_DUP OP_HASH160 0xB7A73EB128D7EA3D388DB12418302A1CBAD5E890 OP_EQUALVERIFY OP_CHECKSIG" }, { "value" : 92233720368.54277039, "scriptPubKey" : "OP_DUP OP_HASH160 0x151275508C66F89DEC2C5F43B6F9CBE0B5C4722C OP_EQUALVERIFY OP_CHECKSIG" } ]92233720368.54277039 BTC? Chẳng phải đó chính là giá trị tối đa của UINT_64 (số nguyên 64 bit không dấu) sao?
— Jeff Garzik, diễn đàn Bitcointalk (2010)
Rất có thể đây là một lỗi khiến tổng của hai giá trị đầu ra — là kiểu int64 (số nguyên 64 bit có dấu) thay vì uint_64 như Garzik cho rằng— bị tràn thành giá trị âm -0.00997538 BTC. Do đó, bất kể giá trị đầu vào là gì, tổng đầu ra luôn nhỏ hơn, khiến giao dịch vẫn được coi là hợp lệ theo mã nguồn tại thời điểm đó.
Trong bối cảnh này, lỗi này đã được công khai thông qua một chiến dịch tấn công chớp nhoáng. Điều không may là chiến dịch này đã tạo ra khoảng 2 x 92 tỷ BTC, làm loãng nghiêm trọng nguồn cung tiền hiện có chỉ khoảng 3,7 triệu BTC.
Trong một bài đăng liên quan, Satoshi Nakamoto tuyên bố rằng ông sẽ rất biết ơn nếu ai đó có thể ngừng khai thác(lúc đó được gọi là " tạo ra ").
Sẽ tốt hơn nếu mọi người ngừng sản xuất. Có lẽ chúng ta cần khai thác một nhánh khác blockchain; mọi người càng sản xuất chậm trên nhánh hiện tại, chúng ta càng có thể xây dựng nhánh kia nhanh hơn.
Bản vá đầu tiên sẽ có trong SVN phiên bản 132. Nó vẫn chưa được tải lên. Tôi vẫn đang đóng góp một số thay đổi nhỏ cần hoàn thành trước, sau đó tôi sẽ tải bản vá lên.
— Satoshi Nakamoto, diễn đàn Bitcointalk (2010)
Kế hoạch của anh ấy là tạo ra một soft fork để vô hiệu hóa các giao dịch như đã đề cập ở trên, từ đó vô hiệu hóa các khối chứa các giao dịch đó (đặc biệt là khối ở độ cao 74638). Chưa đầy một tháng sau, anh ấy đã gửi một bản vá trong bản sửa đổi 132 của mã nguồn Subversion và đăng trên diễn đàn về những gì anh ấy cho rằng người dùng nên làm:
Bản vá đã được tải lên SVN phiên bản 132!
Hiện tại, các bước được khuyến nghị là:
1) Tắt nút.
2) Tải xuống tệp blk "knightmb" (để thay thế các tệp blk001.dat và blkindex.dat của bạn).
3) Nâng cấp phần mềm.
4) Phần mềm sẽ bắt đầu đồng bộ hóa từ khi có ít hơn 74.000 khối. Hãy để nó tải xuống lại các khối còn lại.
Nếu bạn không muốn sử dụng các tệp của knightmb, bạn có thể trực tiếp xóa các tệp blk*.dat của mình (các tệp bắt đầu bằng "blk" và chứa ký tự ",dat"). Tuy nhiên, nếu mọi người tải xuống tất cả các khối cùng một lúc, điều đó sẽ gây ra gánh nặng lớn cho mạng.
Tôi sẽ biên dịch và phát hành phiên bản này sớm thôi.
— Satoshi Nakamoto, diễn đàn Bitcointalk (2010)
Ông ấy muốn mọi người tải xuống dữ liệu khối từ một người dùng cụ thể ("kinghtmb"): người dùng này đã công bố blockchain xuất hiện trên ổ cứng của họ, cụ thể là các tệp blkXXXX.dat và blkindex.dat. Lý do tải xuống dữ liệu khối theo cách này (thay vì đồng bộ hóa lại từ đầu) là để giảm tắc nghẽn băng thông mạng.
Đây là một vấn đề nghiêm trọng: các khối được người dùng tải xuống từ knightmb không được xác minh khi phần mềm Bitcoin khởi chạy; tệp blkindex.dat đã chứa tập hợp UTXO và phần mềm trực tiếp chấp nhận bất kỳ dữ liệu trong đó là đã được xác minh. knightmb có thể can thiệp vào dữ liệu, thêm Bitcoin một cách giả tạo cho chính mình hoặc người khác.
(Ghi chú của người dịch: Khả năng này có tồn tại; tuy nhiên, nó sẽ được phát hiện khi người dùng chạy phần mềm với tùy chọn khởi động được lập chỉ mục lại. Cuối cùng, mặc dù phần mềm sẽ không tự động xác minh lại khi khởi động sau khi người dùng thay thế hai tệp này, người dùng vẫn có thể yêu cầu phần mềm xác minh lại.)
Một lần nữa, dường như lời khuyên đã được lắng nghe, và việc hoàn tác khối không hợp lệ cùng các khối con của nó đã thành công. Thợ đào bắt đầu khai thác sau khối ban đầu ở độ cao khối 74637 , và khối tiếp theo đầu tiên xuất hiện lúc 23:53 UTC, khoảng sáu giờ sau khi sự cố được phát hiện. Đến 08:10 ngày hôm sau (16 tháng 8), ở Block Height 74689, Chuỗi mới đã thay thế Chuỗi cũ, và tất cả nút có phần mềm nâng cấp đã được tổ chức lại để tuân theo Chuỗi mới. Đây là sự tổ chức lại khối sâu nhất trong lịch sử Bitcoin — đạt đến 52 khối.
So với những vấn đề do OP_RETURN gây ra, cách tiếp cận này có thể nói là thông minh hơn nhiều:
- Bản vá lỗi bao gồm nhiều hơn chỉ các tệp nhị phân đã được phát hành.
- Việc phát triển phần mềm mới ra mắt đang đáp ứng đúng kỳ vọng.
- Không có hard fork
Trong quá trình giải quyết vấn đề, người dùng được yêu cầu ngừng khai thác. Chúng ta có thể thảo luận xem đây có phải là một ý kiến hay không, nhưng giả sử bạn là một thợ đào và bạn tin rằng các khối được khai thác sau các khối lỗi cuối cùng sẽ bị xóa trong quá trình tái cấu trúc blockchain sâu rộng: vậy thì tại sao lại lãng phí tài nguyên để khai thác những khối đó?
Bạn cũng có thể cho rằng Satoshi Nakamoto– tải xuống blockchain và bộ UTXO từ ổ cứng của một người lạ – nghe có vẻ hợp lý. Nếu vậy, bạn đúng: điều đó quả thực đáng ngờ. Tuy nhiên, trong tình huống đó, một phản ứng khẩn cấp như vậy cũng là điều hợp lý.
Sự cố này khác biệt đáng kể so với sự cố OP_RETURN ở chỗ lỗ hổng này đã thực sự bị khai thác, cho phép khắc phục trực tiếp hơn. Trong sự cố OP_RETURN, các nhà phát triển phải che giấu các biện pháp khắc phục, và các tuyên bố công khai không thể trực tiếp tiết lộ vấn đề.
9.2.3. 11/03/2013 Vấn đề khóa cơ sở dữ liệu 0.7.2 - 0.8.0 (CVE-2013-3220)
Một vấn đề rất thú vị và mang tính giáo dục đã nảy sinh vào tháng 3 năm 2013. Vào thời điểm đó, blockchain dường như đã bị phân tách sau khi đạt độ cao 225429 (đó chính là ý nghĩa của từ "fork" trong đoạn trích dẫn sau). Chi tiết về sự cố lầnđược tiết lộ trong BIP50 . Tài liệu tóm tắt như sau:
Trong một khối được khai thác và phát sóng, tổng số lượng giao dịch đầu vào đã vượt quá mức tối đa được quan sát trước đó. Nút Bitcoin 0.8 có thể xử lý khối này, nhưng một số nút Bitcoin từ các phiên bản trước 0.8 (pre-0.8) đã từ chối nó, dẫn đến một fork blockchain bất ngờ. Chuỗi không tương thích với 0.8 và các phiên bản trước đó (sau đây gọi là " Chuỗi 0.8") sau đó đã tích lũy được 60% tỷ lệ băm khai thác , khiến cho sự phân tách lần không thể tự động giải quyết được (nếu tỷ lệ băm của Chuỗi pre-0.8 có thể đánh bại Chuỗi 0.8, nó sẽ buộc nút 0.8 phải tập hợp lại trên Chuỗi pre-0.8, do đó tự động giải quyết sự phân tách).
Để khôi phục blockchain được công nhận nhanh nhất có thể, BTCGuild và Slush đã hạ cấp phần mềm nút của họ từ Bitcoin 0.8 xuống 0.7, khiến nhóm khai thác của họ từ chối khối lớn hơn. Điều này cho phép phần lớn tỷ lệ băm quay trở lại Chuỗi mà không cần khối lớn hơn, cuối cùng cho phép nút 0.8 được tổ chức lại trên Chuỗi trước 0.8.
— Một số nhà phát triển Bitcoin Core, BIP50 (2013)
Hành động nhanh chóng của các nhóm khai thác BTCGuild và Sluch trong cuộc khủng hoảng lần thật đáng nể. Họ đã chuyển phần lớn tỷ lệ băm của mình sang nhánh pre-0.8 được tách ra, nhờ đó giúp xây dựng lại sự đồng thuận. Điều này đã cho các nhà phát triển thời gian để phát triển các giải pháp bền vững.
Một vấn đề thú vị không kém trong trường hợp này là phiên bản 0.7.2 không tương thích với chính nó, cũng như các phiên bản trước đó. Điều này được giải thích trong phần "Nguyên nhân gốc rễ" của BIP50 :
Cấu hình khóa BDK không đủ này ngầm trở thành một quy tắc đồng thuận mạng để xác định tính hợp lệ của các khối (mặc dù đây là một quy tắc không nhất quán và không an toàn, vì lượng khóa được sử dụng có thể khác nhau trên nút khác nhau).
— Một số nhà phát triển Bitcoin Core, BIP50 (2013)
Tóm lại, vấn đề là số lượng khóa cơ sở dữ liệu được phần mềm Bitcoin Core sử dụng để xác minh các khối không mang tính xác định. Một nút có thể cần X khóa, trong khi một nút khác có thể cần X+1 khóa. Ngoài ra còn có giới hạn về số lượng khóa mà một nút có thể nắm giữ cho một khối. Nếu số lượng khóa cần thiết vượt quá giới hạn này, khối sẽ bị cho rằng không hợp lệ. Vì vậy, nếu X+1 vượt quá giới hạn, nhưng X thì không, hai nút sẽ tách thành hai nhánh, mỗi nhánh không đồng ý về nhánh nào là hợp lệ.
Ngoài các biện pháp khẩn cấp được thực hiện bởi hai tập đoàn khai thác lớn nêu trên, các giải pháp cuối cùng được lựa chọn cũng bao gồm:
- Trong phiên bản 0.8.1, các khối bị hạn chế không chỉ về kích thước mà còn về số lượng khóa mà chúng chứa.
- Vá các phiên bản cũ hơn (0.7.2 và một số phiên bản cũ hơn) để sử dụng cùng các quy tắc mới, đồng thời tăng cường các hạn chế khóa toàn cục.
Ngoài việc tăng giới hạn khóa toàn cầu như đã đề cập ở điểm thứ hai, các quy tắc này được triển khai như các quy tắc tạm thời, được sử dụng trong một khoảng thời gian đã được xác định trước. Kế hoạch là sẽ loại bỏ các giới hạn này sau khi phần lớn nút đã được nâng cấp.
Việc soft fork này đã giảm đáng kể rủi ro thất bại trong việc đạt được sự đồng thuận, và vài tháng sau, vào ngày 15 tháng 5, các quy tắc tạm thời đã được vô hiệu hóa đồng loạt trên toàn mạng. Lưu ý rằng việc vô hiệu hóa này về cơ bản là một hard fork, nhưng không gây tranh cãi. Hơn nữa, nó được phát hành cùng với soft fork trước đó, vì vậy bất kỳ ai đang sử dụng phần mềm sau soft fork đều biết rằng hard fork này sẽ tiếp theo. Do đó, khi hard fork này được kích hoạt, phần lớn nút vẫn được đồng bộ hóa. Tuy nhiên, một số ít nút chưa được nâng cấp vẫn bị đẩy ra khỏi mạng trong quá trình này.
Bạn có thể tự hỏi: nếu điều này xảy ra ngày nay, liệu chúng ta vẫn có thể xử lý theo cách này không? Bối cảnh khai thác hiện nay phức tạp hơn nhiều; cả hai phía của một sự phân tách đều có thể có tỷ lệ băm băm, khiến việc phát hành các bản vá nhanh chóng như BIP50 trở nên khó khăn. Việc thuyết phục thợ đào trên nhánh "sai" từ bỏ phần thưởng khối của họ cũng sẽ là một thách thức.
9.2.4 BIP66
BIP66 rất thú vị vì nó thể hiện tầm quan trọng của những điều sau:
- Mật mã chọn lọc tốt
- Thông tin đầy đủ
- Triển khai các bản vá lỗi mà không làm lộ lỗ hổng bảo mật.
- Khai thác trên các khối đã được xác minh
BIP66 là một Đề án thắt chặt các quy tắc mã hóa cho chữ ký được đặt trong mã lệnh Bitcoin. Mục đích của Đề án là để cho phép phân tích cú pháp chữ ký bằng các phần mềm và thư viện mã khác ngoài OpenSSL (trước đây, bạn chỉ có thể sử dụng phiên bản OpenSSL mới nhất). OpenSSL là một thư viện mã mật mã đa năng; vào thời điểm đó, Bitcoin Core vẫn đang sử dụng nó.
Bản BIP này đã được kích hoạt vào ngày 4 tháng 7 năm 2015. Tuy nhiên, ngoài nội dung hoàn toàn chính xác đã đề cập ở trên, BIP66 còn khắc phục một vấn đề nghiêm trọng hơn nhiều mà bản BIP gốc không đề cập đến.
Lỗ hổng
Lỗ hổng này chỉ được tiết lộ đầy đủ vào ngày 28 tháng 7 năm 2015, bởi Pieter Wuille trong một email gửi đến danh sách gửi thư Bitcoin-dev :
Xin chào tất cả mọi người,
Tôi muốn tiết lộ một lỗ hổng bảo mật mà tôi đã phát hiện vào tháng 9 năm 2014; lỗ hổng này đã trở nên không thể khai thác được sau khi việc triển khai BIP66 đạt ngưỡng 95% vào đầu tháng này.
Mô tả ngắn gọn
Một giao dịch tạo ra đặc biệt có thể khiến blockchain phân tách thành ba loại nút sau:
- Nút sử dụng OpenSSL trên hệ thống Windows 32-bit và 64-bit
- Nút sử dụng OpenSSL trên các hệ thống 64-bit không phải Windows (Linux, OSX, v.v.)
- Sử dụng một số cơ sở mã không phải OpenSSL để phân tích nút nút chữ ký.
— Pieter Wuille, “Tiết lộ: Một lỗi đồng thuận được giải quyết trực tiếp bởi BIP66”, danh sách gửi thư Bitcoin-dev (2015)
Email này trình bày chi tiết hơn về việc phát hiện ra lỗ hổng và những lý do cụ thể dẫn đến việc đó. Cuối cùng, Pieter cung cấp một dòng thời gian các sự kiện; chúng ta sẽ xem xét một trong đó sự kiện quan trọng nhất, như được hiển thị trong Hình 13, một số sự trong đó đã được thảo luận trước đó.
Hình 13. Trình tự thời gian các sự kiện xung quanh BIP66. Các phần được in đậm đã được thảo luận ở trên.
Trước khi tiết lộ
Trước khi vấn đề này được biết đến, nó có thể đã được giải quyết bằng BIP62, một BIP đã bị rút lại: BIP này đã giảm khả năng bị thao túng giao dịch. Một trong những thay đổi được đề xuất trong BIP62 là thắt chặt các quy tắc đồng thuận liên quan đến mã hóa chữ ký, còn được gọi là "mã hóa DER nghiêm ngặt". Pieter Wuille đã đề xuất một số điều chỉnh cho BIP này vào tháng 7 năm 2014 có thể giải quyết vấn đề này:
- Ngày 18 tháng 7 năm 2014: Để làm cho các quy tắc mã hóa chữ ký của Bitcoin độc lập với các trình phân tích cú pháp OpenSSL cụ thể, tôi đã sửa đổi đề xuất BIP32 sao cho các yêu cầu chữ ký DER nghiêm ngặt của nó cũng được áp dụng cho các giao dịch có số phiên bản là 1. Vào thời điểm đó, không có chữ ký nào không phải DER sẽ được đưa vào khối, vì vậy có thể giả định rằng nó sẽ không ảnh hưởng trực tiếp đến bất kỳ ai. Xem https://github.com/bitcoin/bips/pull/90 và http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2014-July/006299.html để biết chi tiết. Vào thời điểm đó, người ta không biết, nhưng nếu BIP66 được triển khai, lỗ hổng này sẽ được khắc phục.
— Pieter Wuille, “Tiết lộ: Một lỗi đồng thuận được giải quyết trực tiếp bởi BIP66”, danh sách gửi thư Bitcoin-dev (2015)
Do phạm vi bao phủ của BIP này quá rộng, vượt xa khía cạnh "mã hóa DER nghiêm ngặt", nên nó liên tục được sửa đổi và việc triển khai bị trì hoãn. Sau đó, BIP này được kết nối mạng vì "Segregated Witness" BIP141 đã giải quyết vấn đề sụp đổ giao dịch một cách hoàn thiện hơn.
Sau khi tiết lộ
OpenSSL đã phát hành phiên bản phần mềm mới với các bản vá lỗi; việc sử dụng các bản vá lỗi này (phần mềm mới) trong phần mềm Bitcoin ngay từ đầu sẽ giải quyết được vấn đề. Tuy nhiên, việc chỉ đơn giản sử dụng phiên bản OpenSSL mới trong phiên bản Bitcoin Core mới sẽ làm trầm trọng thêm vấn đề. Gregory Maxwell đã giải thích điều này trong một danh sách gửi thư khác vào tháng 1 năm 2015:
Mặc dù việc kiên quyết từ chối một số chữ ký nhất định thường được chấp nhận trong hầu hết các ứng dụng, Bitcoin là một hệ thống đồng thuận, có nghĩa là tất cả những người tham gia nói chung phải đồng ý về tính hợp lệ hoặc không hợp lệ của dữ liệu đầu vào. Nói cách khác, tính nhất quán quan trọng hơn "tính chính xác".
...
Tuy nhiên, bản vá trên chỉ khắc phục một triệu chứng của vấn đề phổ biến này: hành vi của đặc tả đồng thuận dựa trên phần mềm (đặc biệt là OpenSSL) không được thiết kế và phân phối cho mục đích đồng thuận. Do đó, như một cải tiến từng bước, tôi đề xuất thực thi khả năng tương thích DER nghiêm ngặt hơn càng sớm càng tốt bằng một soft fork chuyên dụng, chỉ sử dụng một tập hợp con của BIP62.
— Gregory Maxwell bình luận về nâng cấp OpenSSL, danh sách gửi thư Bitcoin-dev
Ông chỉ ra rằng việc sử dụng mã không nhằm mục đích phục vụ hệ thống đồng thuận tiềm ẩn rủi ro nghiêm trọng và đề xuất Bitcoin nên triển khai mã hóa DER nghiêm ngặt. Đây là một ví dụ tuyệt vời về tầm quan trọng của mật mã chọn lọc — điều mà chúng ta đã thảo luận trong Chương 7.4 ( bản dịch tiếng Trung ).
Những sự kiện này có thể khiến bạn có ấn tượng rằng Gregory Maxwell biết về lỗ hổng mà Pieter Wuille sau đó đã tiết lộ, nhưng muốn che đậy nó dưới chiêu bài "phòng ngừa" để tránh thu hút quá nhiều sự chú ý đến vấn đề thực sự. Điều đó có thể xảy ra, nhưng tất cả chỉ là suy đoán.
Sau đó, theo đề xuất của Maxwell, BIP66 được đưa ra như một tập hợp con của BIP62, chỉ quy định mã hóa DER nghiêm ngặt. BIP này dường như đã được chấp nhận rộng rãi và triển khai vào tháng 7; tuy nhiên, trớ trêu thay, nó vẫn dẫn đến lần sự phân tách blockchain do " khai thác không cần xác thực ". Những sự phân tách này sẽ được thảo luận trong phần tiếp theo.
Điều này dẫn đến một kết luận quan trọng: một BIP (Business Improvement Property) nên có tính chất "nguyên tử" ở mức độ nhất định, nghĩa là nó phải đủ hoàn chỉnh để cung cấp một thứ gì đó hữu ích hoặc giải quyết một vấn đề cụ thể, nhưng đủ nhỏ gọn để được nhiều người dùng chỉ ra. Càng đưa nhiều thứ vào một BIP, khả năng được chấp nhận càng thấp.
Blockchain bị chia tách do khai thác chưa được xác minh.
Thật không may, câu chuyện về BIP66 không kết thúc ở đó. Việc kích hoạt BIP66 đã gây ra sự hỗn loạn tột độ, vì một số thợ đào không xác minh các khối khi nhận được chúng mà thay vào đó bắt đầu khai thác ngay lập tức. Điều này được gọi là "khai thác không xác minh" hoặc " khai thác SPV" (SPV viết tắt của "Simplified Payment Verification," chỉ xác minh Block Header ). Một thông báo cảnh báo đã được gửi đến nút Bitcoin , trong đó với một trang web mô tả vấn đề :
Vào sáng sớm ngày 4 tháng 7 năm 2015, (BIP66) đã đạt đến ngưỡng 950/1000 (95%). Tuy nhiên, ngay sau đó, một thợ đào nhỏ (một trong đó 5% chưa nâng cấp ) đã khai thác một khối không hợp lệ—như dự đoán. Thật không may, hóa ra khoảng một nửa tỷ lệ băm khai thác của mạng lưới đang khai thác với thiết lập xác minh khối không đầy đủ (gọi là " khai thác SPV"), do đó khai thác các khối mới sau khối không hợp lệ này.
— Thông báo cảnh báo từ các nhà phát triển Bitcoin Core trên bitcoin.org (2015)
Trang cảnh báo này hướng dẫn người dùng rằng nếu họ đang sử dụng phiên bản Bitcoin Core cũ hơn, họ nên đợi thêm 30 khối để được xác nhận ngoài yêu cầu xác nhận khối tự nguyện thông thường.
Sự phân tách nói trên xảy ra vào ngày 4 tháng 7 năm 2015, lúc 02:10 UTC, sau khi đạt Block Height363730. Vấn đề đã được giải quyết lúc 03:50 cùng ngày—sau khi sáu khối không hợp lệ được khai thác. Thật không may, vấn đề tương tự lại xảy ra vào ngày hôm sau: lúc 21:50 ngày 5 tháng 7, nhưng lần này, nhánh không hợp lệ chỉ tồn tại trong ba khối.
Các sự kiện dẫn đến việc tạo ra và triển khai BIP66, cùng những sự kiện tiếp theo, cung cấp một nghiên cứu điển hình tuyệt vời, cho thấy lý do tại sao các nhà phát triển Bitcoin phải hết sức thận trọng. Một số kết luận chính từ sự cố BIP66:
- Việc tìm ra sự cân bằng giữa tính minh bạch và việc không tiết lộ các lỗ hổng bảo mật là một vấn đề tế nhị.
- Việc triển khai các bản vá lỗi cho các lỗ hổng chưa được tiết lộ là một việc khá phức tạp.
- Duy trì sự đồng thuận không phải là điều dễ dàng.
- Phần mềm không được thiết kế để hoạt động trong một hệ thống đồng thuận thường tiềm ẩn rủi ro.
- Các BIP nên được phân tách thành các nguyên tử ở một mức độ nào đó.
9.3 Kết luận
Bitcoin có lỗi. Những người phát hiện ra lỗi được khuyến khích báo cáo một cách có trách nhiệm cho các nhà phát triển Bitcoin để họ có thể sửa chữa trước khi lỗi được công khai. Lý tưởng nhất là việc sửa lỗi có thể được ngụy trang dưới dạng cải thiện hiệu suất hoặc một số hình thức đánh lạc hướng khác.
Chúng tôi đã xem xét một số lỗ hổng bảo mật nghiêm trọng hơn đã xuất hiện trong những năm qua, và các hành động đã được thực hiện để khắc phục chúng. Một số lỗ hổng bị phát hiện vì chúng đã bị khai thác, trong khi những lỗ hổng khác đã được công bố và vá lỗi kịp thời trước khi các tác nhân độc hại có cơ hội khai thác chúng.
