Tiết lộ bảo mật: Lỗ hổng bảo mật trong hệ thống chống gian lận lạc quan

Tác giả: Ed Felten, đồng sáng lập Offchain Labs Nguồn: Medium Dịch: Shan Oppa, Golden Finance

Vào ngày 22 tháng 3, nhóm Offchain Labs đã tiết lộ với nhóm OP Labs hai vấn đề nghiêm trọng mà chúng tôi đã phát hiện ra trong hệ thống chống gian lận Optimism được triển khai trên mạng thử nghiệm. . Chúng tôi đã cung cấp mã khai thác demo của cuộc tấn công cho nhóm OP Labs. Vào ngày 25 tháng 3, OP Labs đã xác nhận tính xác thực của hai vấn đề này.

Chúng tôi điều phối việc tiết lộ thông tin của mình với nhóm OP Labs. OP Labs đã yêu cầu chúng tôi tạm dừng tiết lộ công khai những lỗ hổng này cho đến khi chúng được giải quyết. Cuối ngày hôm qua (25 tháng 4), mạng thử nghiệm Optimism đã được cập nhật và hôm nay chúng tôi đã tiết lộ những lỗ hổng này lần đầu tiên.

Các lỗ hổng này cho phép kẻ độc hại buộc cơ chế chống gian lận OP Stack chấp nhận lịch sử chuỗi gian lận hoặc ngăn cơ chế chống gian lận OP Stack chấp nhận chuỗi chính xác lịch sử. Những vấn đề này xuất phát từ một lỗ hổng trong bộ tính giờ xử lý thiết kế chống gian lận của OP.

Kết quả là các hệ thống ngăn chặn gian lận không cải thiện được tính bảo mật so với phương pháp chỉ dựa vào sự can thiệp khẩn cấp của Hội đồng Bảo an.

Bản chất của lỗ hổng

Bộ hẹn giờ là khía cạnh tinh vi nhất của hoạt động chống gian lận tương tác thiết kế một. Đối thủ có thể không thực hiện hành động nào trong trò chơi thử thách, vì vậy tại một thời điểm nào đó, giao thức cần tuyên bố rằng những người chơi không di chuyển sẽ thua khi hết thời gian chờ. Nhưng đối thủ cũng có thể sử dụng các cuộc tấn công kiểm duyệt chống lại chuỗi L1 gốc (ví dụ: Ethereum) để ngăn chặn các bên trung thực tham gia vào trò chơi.

Nếu thời gian trôi qua mà người chơi không di chuyển, giao thức sẽ không có cách nào để biết liệu người chơi có đang bị kiểm duyệt hay không, hay là kẻ xấu giữ im lặng và giả vờ làm vậy được kiểm duyệt. (Trong cả hai trường hợp, giao thức chỉ nhìn thấy "sự im lặng vô tuyến" của người chơi.) Do đó, giao thức phải cho những người chơi trung thực có đủ thời gian để họ không bị lỗi do kiểm duyệt, đồng thời ngăn chặn những người chơi độc hại trì hoãn giao thức quá lâu.

Ví dụ: trong giao thức thử thách một chọi một trong đó có người chơi ở cả hai bên tranh chấp, giao thức hiện được Arbitrum triển khai sử dụng một cách tiếp cận điều đó hoạt động rất tốt. Đây là một cách trực quan để hiểu phương pháp này: Mỗi người chơi kiếm được "điểm thời gian" khi đến lượt người chơi khác di chuyển và nếu một người chơi tích lũy được 7 ngày điểm thời gian, thử thách sẽ thắng theo thời gian. Ý tưởng là nếu một người chơi "trễ" tổng cộng 7 ngày, thì sẽ không có gì vô lý khi sự chậm trễ này hoàn toàn là do kiểm duyệt và do đó người chơi có thể bị coi là không trung thực - do đó tuyên bố người chơi là kẻ thua cuộc một cách an toàn. . Điều này giúp cho các thỏa thuận một-một không bị xem xét trong tối đa bảy ngày.

Phương pháp này hoạt động tốt khi chỉ có một người chơi ở cả hai bên tranh chấp. Nhưng khi bạn cho phép nhiều người chơi tham gia, như Optimism đã làm, thì cách quản lý điểm thời gian sẽ ít rõ ràng hơn. Thật dễ dàng để chia người chơi thành hai đội, mỗi bên tranh chấp, mỗi bên có điểm thời gian. Nhưng bạn cần phải cẩn thận, vì kẻ phản bội tấn công, kẻ ác giả vờ thành thật một lúc, chỉ để đâm sau lưng “đồng đội” lương thiện vào thời điểm tồi tệ nhất có thể.

Giao thức OP ban đầu được triển khai trên mạng thử nghiệm rất dễ bị tấn công bởi kiểu tấn công của kẻ phản bội này vì nó cho phép kẻ phản bội nhận được phần thưởng về thời gian không đáng có. Điều này sẽ cho phép kẻ độc hại giành chiến thắng trong trò chơi chống gian lận mà lẽ ra nó phải thua, từ đó chấp nhận lịch sử chuỗi gian lận hoặc từ chối lịch sử chuỗi chính xác.

Đây là những vấn đề khó giải quyết và mặc dù thiết kế ban đầu của OP là một cuộc tấn công tinh vi, nhưng họ đã thực hiện một số thay đổi đối với mã xử lý bộ đếm thời gian của mình để khắc phục các lỗ hổng demo Chúng tôi cung cấp. Chúng tôi chưa thực hiện phân tích bảo mật về giao thức đã sửa đổi của họ.

Xử lý những kẻ hẹn giờ, những kẻ phản bội và các cuộc tấn công khác

Các giao thức chống gian lận, đặc biệt là các giao thức của chúng Các khía cạnh về thời gian rất khó thiết kế. Đó là lý do tại sao giao thức BoLD của chúng tôi đi kèm với một bài viết kỹ thuật cung cấp mô hình mối đe dọa chi tiết và bằng chứng cho thấy giao thức BoLD không dễ bị tổn thương trước các cuộc tấn công phản bội như vậy. Do tính phức tạp và phức tạp của những vấn đề này, chúng tôi tin rằng cần phải có mô hình mối đe dọa rõ ràng và bằng chứng về bảo mật để đảm bảo không có cuộc tấn công tiềm ẩn nào. Trên thực tế, trong quá trình tạo bằng chứng, chúng tôi đã phát hiện và khắc phục nhiều vấn đề trong giao thức BoLD.

Tiết lộ bảo mật ban đầu

Sau đây là thông tin tiết lộ mà chúng tôi đã gửi cho OP Labs vào ngày 22 tháng 3 Đoạn trích nội dung mở rộng:

Chúng tôi (nhóm Offchain Labs) đã phát hiện ra một lỗ hổng hệ thống nghiêm trọng trong phiên bản hiện tại của hệ thống chống sự cố OP Stack. Tài liệu này mô tả những sai sót này và cung cấp mã lỗ hổng mẫu để bạn tham khảo.

Những lỗ hổng này sẽ cho phép đối thủ phá vỡ chuỗi bằng cách yêu cầu giao thức chấp nhận các khiếu nại gian lận, từ chối các khiếu nại chính xác hoặc tạo ra các tranh chấp không thể giải quyết trong phạm vi bảo mật giới hạn L1 Gas và hoạt động. [Lưu ý (26/4): Vấn đề thứ ba (tranh chấp không thể giải quyết) đã được công khai và ghi lại nên chúng tôi sẽ xóa những đề cập tiếp theo.

Chúng tôi tin rằng nếu giao thức hiện tại của bạn được triển khai trên mạng chính, tiền của người dùng sẽ gặp rủi ro rất cao.

Bản chất của lỗi

Một số lỗi xuất hiện xuất phát từ việc quản lý bộ hẹn giờ trong lỗi -cách hệ thống chống thấm. Nói tóm lại, việc kế thừa bộ tính giờ từ các xác nhận quyền sở hữu của ông bà cho phép các xác nhận quyền sở hữu do các tác nhân độc hại đưa ra kế thừa tín dụng tính giờ từ các xác nhận quyền sở hữu do các tác nhân trung thực đưa ra trước đó, do đó thổi phồng một cách giả tạo các khoản tín dụng tính giờ của các xác nhận quyền sở hữu độc hại cho đến khi tác nhân độc hại có thể giành chiến thắng. thử thách. Ví dụ: một tác nhân độc hại có thể sắp xếp để kế thừa điểm tính giờ chỉ thấp hơn một chút so với số điểm cần thiết để giành chiến thắng và sau đó tuyên bố điều đó do hạn chế về thời gian trước khi bất kỳ bên nào khác có thể phản ứng

Ví dụ về cách khai thác

Sau đây là tập hợp các lỗ hổng ví dụ minh họa cho các cuộc tấn công này.

Lỗ hổng đầu tiên ( test_exploit_last_second_challenge) cho phép kẻ tấn công đánh bại các tuyên bố trung thực.

Lỗ hổng thứ hai ( test_exploit_last_second_defend) cho phép kẻ tấn công chấp nhận các khiếu nại gian lận.

Những lỗ hổng này dường như áp dụng cho phiên bản mới nhất của Hệ thống chống gian lận ngăn xếp OP tại thời điểm gửi 96a269bc793fa30c3e2aa1a8afd738e4605fa06e< /code>