Tác giả: CertiK
Trước đây, nhóm CertiK đã phát hiện ra một loạt lỗ hổng từ chối dịch vụ trong chuỗi khối Sui. Trong số các lỗ hổng này, nổi bật nhất là một lỗ hổng mới có mức độ ảnh hưởng cao. Lỗ hổng này có thể khiến các nút mạng Sui không thể xử lý các giao dịch mới, dẫn đến việc tắt hoàn toàn toàn bộ mạng.
Mới thứ Hai tuần trước, CertiK đã nhận được khoản tiền thưởng SUI trị giá 500.000 USD khi phát hiện ra lỗ hổng bảo mật lớn này. CoinDesk, phương tiện truyền thông có thẩm quyền trong ngành Hoa Kỳ, đã đưa tin về vụ việc, sau đó các phương tiện truyền thông lớn đã theo dõi báo cáo của họ và đưa ra những tin tức liên quan.
Lỗ hổng bảo mật này được gọi một cách sinh động là "bánh xe hamster": phương thức tấn công độc đáo của nó khác với các cuộc tấn công đã biết hiện nay. Kẻ tấn công chỉ cần gửi tải trọng khoảng 100 byte để kích hoạt một vòng lặp vô hạn trong nút xác minh Sui, khiến nó không thể thực hiện được. để đáp ứng các giao dịch mới.
Ngoài ra, thiệt hại do cuộc tấn công gây ra có thể tồn tại sau khi mạng được khởi động lại và có thể tự động lan truyền trong mạng Sui, khiến tất cả các nút giống như một con chuột lang chạy không ngừng trên bánh xe không thể xử lý các giao dịch mới. Đó là lý do tại sao chúng tôi gọi kiểu tấn công độc đáo này là đòn tấn công "bánh xe hamster".
Sau khi phát hiện ra lỗ hổng, CertiK đã báo cáo cho Sui thông qua chương trình thưởng lỗi của Sui. Sui cũng phản hồi hiệu quả sớm nhất có thể, xác nhận mức độ nghiêm trọng của lỗ hổng và tích cực thực hiện các biện pháp tương ứng để khắc phục sự cố trước khi mạng chính được tung ra. Ngoài việc khắc phục lỗ hổng cụ thể này, Sui đã thực hiện các biện pháp giảm thiểu phòng ngừa để giảm thiệt hại tiềm ẩn mà lỗ hổng này có thể gây ra.
Để cảm ơn nhóm CertiK vì đã tiết lộ thông tin có trách nhiệm, Sui đã trao cho nhóm CertiK khoản tiền thưởng 500.000 USD.
Các chi tiết kỹ thuật sau đây của lỗ hổng nghiêm trọng này sẽ được tiết lộ để làm rõ nguyên nhân gốc rễ và tác động tiềm ẩn của lỗ hổng bảo mật.
Giải thích chi tiết về các lỗ hổng
Vai trò chính của người xác nhận trong Sui
Đối với các blockchain dựa trên ngôn ngữ Move như Sui và Aptos, cơ chế đảm bảo ngăn chặn các cuộc tấn công tải trọng độc hại chủ yếu là công nghệ xác minh tĩnh. Thông qua công nghệ xác minh tĩnh, Sui có thể kiểm tra tính hợp lệ của tải trọng do người dùng gửi trước khi hợp đồng được phát hành hoặc nâng cấp. Trình xác nhận cung cấp một loạt trình kiểm tra để đảm bảo tính chính xác của cấu trúc và ngữ nghĩa. Chỉ sau khi vượt qua các bước kiểm tra và xác minh, hợp đồng sẽ vào máy ảo Move để thực thi.
Các mối đe dọa tải trọng độc hại trên chuỗi Move
Chuỗi Sui cung cấp một bộ mô hình và giao diện lưu trữ mới trên máy ảo Move ban đầu, do đó Sui có phiên bản tùy chỉnh của máy ảo Move. Để hỗ trợ các phương thức lưu trữ cơ bản mới, Sui còn giới thiệu thêm một loạt các biện pháp kiểm tra bổ sung, tùy chỉnh để xác minh bảo mật cho các tải trọng không đáng tin cậy, chẳng hạn như bảo mật đối tượng và quyền truy cập lưu trữ toàn cầu. Các bước kiểm tra tùy chỉnh này phù hợp với các tính năng độc đáo của Sui, vì vậy chúng tôi gọi những bước kiểm tra tùy chỉnh này là trình xác thực Sui.
Lệnh kiểm tra tải của Sui
Như được hiển thị trong hình trên, hầu hết các bước kiểm tra trong trình xác thực đều thực hiện xác minh bảo mật cấp cấu trúc đối với CompiledModule (đại diện cho lần chạy tải trọng hợp đồng do người dùng cung cấp). Ví dụ: sử dụng "Trình kiểm tra trùng lặp" để đảm bảo rằng không có mục nhập trùng lặp nào trong tải trọng thời gian chạy; sử dụng "Trình kiểm tra giới hạn" để đảm bảo rằng độ dài của mỗi trường trong tải trọng thời gian chạy nằm trong giới hạn mục nhập được phép.
Ngoài kiểm tra cấp độ cấu trúc, kiểm tra tĩnh của trình xác minh vẫn yêu cầu các phương pháp phân tích phức tạp hơn để đảm bảo tính mạnh mẽ của tải trọng không đáng tin cậy ở cấp độ ngữ nghĩa.
Tìm hiểu về trình thông dịch trừu tượng của Move:
Phân tích tuyến tính và lặp lại
Trình thông dịch trừu tượng do Move cung cấp là một khung được thiết kế đặc biệt để thực hiện phân tích bảo mật phức tạp trên mã byte thông qua diễn giải trừu tượng. Cơ chế này làm cho quá trình xác minh trở nên tinh tế và chính xác hơn, đồng thời mỗi người xác minh được phép xác định trạng thái trừu tượng duy nhất của mình để phân tích.
Khi bắt đầu chạy, trình thông dịch trừu tượng sẽ xây dựng biểu đồ luồng điều khiển (CFG) từ các mô-đun đã biên dịch. Mỗi khối cơ bản trong CFG này duy trì một tập hợp các trạng thái, cụ thể là "trạng thái đặt hàng trước" và "trạng thái đặt hàng sau". "Trạng thái đặt hàng trước" cung cấp ảnh chụp nhanh trạng thái chương trình trước khi khối cơ bản được thực thi, trong khi "trạng thái đặt hàng sau" cung cấp mô tả về trạng thái chương trình sau khi khối cơ bản được thực thi.
Khi trình thông dịch trừu tượng không gặp phải bước nhảy (hoặc vòng lặp) nào trong biểu đồ luồng điều khiển, nó tuân theo nguyên tắc thực thi tuyến tính đơn giản: mỗi khối cơ bản được phân tích lần lượt và lệnh trước đó được tính toán dựa trên ngữ nghĩa của từng lệnh trong khối. trạng thái tuần tự và trạng thái hậu tuần tự. Kết quả là một ảnh chụp nhanh chính xác về từng trạng thái cấp khối cơ bản của chương trình trong quá trình thực thi, giúp xác minh các thuộc tính bảo mật của chương trình.
Di chuyển quy trình làm việc của trình thông dịch trừu tượng
Tuy nhiên, quá trình này trở nên phức tạp hơn khi có các vòng lặp trong luồng điều khiển. Sự xuất hiện của một vòng lặp có nghĩa là biểu đồ luồng điều khiển chứa cạnh thoát ra tương ứng với trạng thái tiếp theo của khối cơ bản hiện tại và khối cơ bản đích (đầu vòng lặp) của cạnh thoát ra đã được phân tích trước đó. Trạng thái đặt trước của khối cơ bản, do đó trình thông dịch trừu tượng cần hợp nhất cẩn thận các trạng thái của hai khối cơ bản liên quan đến bước nhảy.
Nếu trạng thái đã hợp nhất được phát hiện khác với trạng thái đặt hàng trước hiện có của khối cơ bản đầu vòng lặp, trình thông dịch trừu tượng sẽ cập nhật trạng thái của khối cơ bản đầu vòng lặp và khởi động lại phân tích bắt đầu từ khối cơ bản này. Quá trình phân tích lặp đi lặp lại này tiếp tục cho đến khi trạng thái trước của vòng lặp ổn định. Nói cách khác, quá trình này được lặp lại cho đến khi trạng thái đặt hàng trước của khối cơ bản ở đầu vòng lặp không còn thay đổi giữa các lần lặp. Đạt đến một điểm cố định cho biết quá trình phân tích vòng lặp đã hoàn tất.
Trình xác thực Sui IDLeak:
Phân tích giải thích trừu tượng tùy chỉnh
Không giống như thiết kế Move ban đầu, nền tảng blockchain của Sui giới thiệu một mô hình lưu trữ toàn cầu tập trung vào “mục tiêu” độc đáo. Đặc điểm đáng chú ý của mô hình này là bất kỳ cấu trúc dữ liệu nào có thuộc tính khóa (được lưu dưới dạng chỉ mục trên chuỗi) đều phải có loại ID là trường đầu tiên của cấu trúc. Trường ID là bất biến và không thể chuyển sang các mục tiêu khác vì mỗi đối tượng phải có một ID duy nhất trên toàn cầu. Để đảm bảo các đặc tính này, Sui đã xây dựng một bộ logic phân tích tùy chỉnh bên trên trình thông dịch trừu tượng.
Trình xác minh IDLeak, còn được gọi là id_leak_verifier, hoạt động cùng với trình thông dịch trừu tượng để thực hiện phân tích. Nó có tên miền Tóm tắt duy nhất của riêng mình, được gọi là Tóm tắt. Mỗi trạng thái trừu tượng bao gồm giá trị trừu tượng tương ứng với nhiều biến cục bộ. Theo dõi trạng thái của từng biến cục bộ thông qua Tóm tắtValue để theo dõi xem biến ID có mới hay không.
Trong quá trình đóng gói cấu trúc, trình xác thực IDLeak chỉ cho phép đóng gói ID mới vào cấu trúc. Thông qua phân tích diễn giải trừu tượng, trình xác thực IDLeak có thể theo dõi toàn diện trạng thái luồng dữ liệu cục bộ để đảm bảo rằng không có ID hiện có nào được chuyển sang các đối tượng cấu trúc khác.
Vấn đề không nhất quán về bảo trì trạng thái của trình xác nhận Sui IDLeak
Trình xác thực IDLeak được tích hợp với trình thông dịch trừu tượng Move bằng cách triển khai hàm Tóm tắt::join. Chức năng này đóng vai trò không thể thiếu trong quản lý trạng thái, đặc biệt là trong việc hợp nhất và cập nhật các giá trị trạng thái.
Kiểm tra các chức năng này một cách chi tiết để hiểu hoạt động của chúng:
Trong Tóm tắt::join, hàm lấy một Trạng thái trừu tượng khác làm đầu vào và cố gắng hợp nhất trạng thái cục bộ của nó với trạng thái cục bộ của đối tượng hiện tại. Đối với mỗi biến cục bộ ở trạng thái đầu vào, nó so sánh giá trị của biến đó với giá trị hiện tại của nó ở trạng thái cục bộ (nếu không tìm thấy, giá trị mặc định là Tóm tắt::Khác). Nếu hai giá trị không bằng nhau, nó sẽ đặt cờ "đã thay đổi" làm cơ sở cho việc kết quả hợp nhất trạng thái cuối cùng có thay đổi hay không và cập nhật giá trị biến cục bộ ở trạng thái cục bộ bằng cách gọi Tóm tắtValue::join.
Trong Tóm tắtValue::join, hàm so sánh giá trị của nó với một giá trị Tóm tắt khác. Nếu chúng bằng nhau, nó sẽ trả về giá trị được truyền vào. Nếu không bằng, giá trị trả về là abstractValue::Other.
Tuy nhiên, logic duy trì trạng thái này ẩn chứa một vấn đề không nhất quán. Mặc dù Tóm tắtState::join sẽ trả về kết quả cho biết trạng thái được hợp nhất đã thay đổi (JoinResult::Changed) dựa trên sự khác biệt giữa giá trị cũ và giá trị mới, giá trị trạng thái được cập nhật được hợp nhất có thể vẫn không thay đổi.
Sự cố không nhất quán này là do thứ tự thực hiện: việc xác định trạng thái đã thay đổi trong Tóm tắtState::join xảy ra trước khi cập nhật trạng thái (AbstractValue::join) và việc xác định này không phản ánh kết quả cập nhật trạng thái thực.
Ngoài ra, trong Tóm tắtValue::join, Tóm tắtValue::Khác đóng vai trò quyết định đến kết quả của việc sáp nhập. Ví dụ: nếu giá trị cũ là Tóm tắtValue::Khác và giá trị mới là Tóm tắtValue::Fresh thì giá trị trạng thái được cập nhật vẫn là Tóm tắtValue::Khác, ngay cả khi giá trị cũ và mới khác nhau thì bản thân trạng thái đó không thay đổi sau khi cập nhật.
Ví dụ: Sự không mạch lạc trong các kết nối trạng thái
Điều này gây ra sự không nhất quán: kết quả của việc hợp nhất các trạng thái khối cơ bản được đánh giá là "đã thay đổi", nhưng bản thân giá trị trạng thái được hợp nhất không thay đổi. Trong quá trình giải thích và phân tích trừu tượng, việc xuất hiện những mâu thuẫn như vậy có thể gây ra hậu quả nghiêm trọng. Chúng tôi xem xét hành vi của trình thông dịch trừu tượng khi các vòng lặp xảy ra trong biểu đồ luồng điều khiển (CFG):
Khi gặp một vòng lặp, trình thông dịch trừu tượng sử dụng phương pháp phân tích lặp để hợp nhất trạng thái của khối cơ bản mục tiêu nhảy với khối cơ bản hiện tại. Nếu trạng thái hợp nhất thay đổi, trình thông dịch trừu tượng sẽ phân tích lại bắt đầu từ mục tiêu nhảy.
Tuy nhiên, nếu hoạt động hợp nhất của phân tích diễn giải trừu tượng đánh dấu nhầm kết quả hợp nhất trạng thái là "đã thay đổi" trong khi trên thực tế giá trị của biến nội bộ của trạng thái không thay đổi, nó sẽ dẫn đến việc phân tích lại vô tận và tạo ra một vòng lặp vô hạn .
khai thác thêm sự không nhất quán
Kích hoạt vòng lặp vô hạn trong trình xác thực Sui IDLeak
Khai thác sự không nhất quán này, kẻ tấn công có thể xây dựng biểu đồ luồng điều khiển độc hại để lừa trình xác thực IDLeak vào một vòng lặp vô hạn. Biểu đồ luồng điều khiển được xây dựng cẩn thận này bao gồm ba khối cơ bản: BB1 và BB2, BB3. Điều đáng chú ý là chúng tôi đã cố tình đưa cạnh nhảy từ BB3 lên BB2 để xây dựng một vòng lặp.
Trạng thái CFG+ độc hại có thể dẫn đến vòng lặp vô hạn trong trình xác thực IDLeak.
Quá trình bắt đầu với BB2, trong đó giá trị trừu tượng của một biến cục bộ cụ thể được đặt thành ::Khác. Sau khi thực thi BB2, quy trình sẽ chuyển sang BB3, trong đó biến tương tự được đặt thành ::Fresh. Cuối BB3 có cạnh nhảy nhảy tới BB2.
Trong quá trình giải thích và phân tích trừu tượng ví dụ này, sự mâu thuẫn được đề cập trước đó đóng một vai trò quan trọng. Khi cạnh thoát được xử lý, trình thông dịch trừu tượng cố gắng kết nối trạng thái thứ tự sau của BB3 (biến là "::Fresh") với trạng thái thứ tự trước của BB2 (biến là "::Other"). Hàm Tóm tắt::join nhận thấy sự khác biệt giữa giá trị cũ và giá trị mới và đặt cờ "thay đổi" để cho biết rằng BB2 cần được phân tích lại.
Tuy nhiên, hành vi chủ yếu của "::Other" trong Tóm tắtValue::join có nghĩa là sau khi Hợp nhất giá trị trừu tượng, giá trị thực của biến trạng thái BB2 vẫn là "::Khác" và kết quả của hợp nhất trạng thái không thay đổi.
Vì vậy, khi quá trình tuần hoàn này bắt đầu, tức là khi người xác nhận tiếp tục phân tích lại BB2 và tất cả các nút khối cơ bản kế nhiệm của nó (BB3 trong trường hợp này), nó sẽ tiếp tục vô thời hạn. Vòng lặp vô hạn tiêu tốn tất cả các chu kỳ CPU có sẵn, khiến nó không thể xử lý phản hồi cho các giao dịch mới và tình trạng này vẫn tiếp diễn sau khi khởi động lại trình xác thực.
Bằng cách khai thác lỗ hổng này, nút xác nhận lặp lại không ngừng nghỉ giống như một con chuột lang chạy không ngừng trên bánh xe, không thể xử lý các giao dịch mới. Đó là lý do tại sao chúng tôi gọi kiểu tấn công độc đáo này là đòn tấn công "bánh xe hamster".
Một cuộc tấn công "bánh xe hamster" có thể khiến trình xác thực Sui rơi vào tình trạng bế tắc một cách hiệu quả, do đó làm tê liệt toàn bộ mạng Sui.
Sau khi hiểu nguyên nhân và quá trình kích hoạt lỗ hổng bảo mật, chúng tôi đã xây dựng một ví dụ cụ thể bằng cách sử dụng mô phỏng Move bytecode sau đây và đã kích hoạt thành công lỗ hổng trong mô phỏng trong môi trường thực:
Ví dụ này cho thấy cách kích hoạt lỗ hổng trong môi trường thực thông qua mã byte được xây dựng cẩn thận. Cụ thể, kẻ tấn công có thể kích hoạt một vòng lặp vô hạn trong trình xác thực IDLeak, sử dụng tải trọng chỉ khoảng 100 byte để tiêu thụ tất cả các chu kỳ CPU của nút Sui, ngăn chặn hiệu quả các giao dịch mới được xử lý và gây ra tình trạng từ chối dịch vụ trên mạng Sui. .
Tác hại dai dẳng của cuộc tấn công "hamster Wheel" trong mạng Sui
Chương trình tiền thưởng lỗi của Sui có các quy định nghiêm ngặt về đánh giá mức độ dễ bị tổn thương, chủ yếu dựa trên mức độ gây hại cho toàn bộ mạng. Một lỗ hổng đáp ứng xếp hạng "nghiêm trọng" phải đóng cửa toàn bộ mạng và ngăn chặn hiệu quả việc xác nhận các giao dịch mới, đồng thời yêu cầu một hard fork để khắc phục sự cố nếu lỗ hổng chỉ có thể khiến một số nút mạng từ chối dịch vụ thì sẽ bị như vậy; được đánh giá ở mức dễ bị tổn thương là "rủi ro trung bình" (trung bình) hoặc "cao".
Lỗ hổng "hamster Wheel" được nhóm CertiK Skyfall phát hiện có thể làm tắt toàn bộ mạng Sui và yêu cầu phát hành chính thức phiên bản mới để nâng cấp và sửa lỗi. Dựa trên mức độ nghiêm trọng của lỗ hổng, Sui cuối cùng đánh giá nó là "nghiêm trọng". Để hiểu rõ hơn về tác động nghiêm trọng của cuộc tấn công "hamster Wheel", chúng ta cần hiểu kiến trúc phức tạp của hệ thống phụ trợ của Sui, đặc biệt là toàn bộ quá trình phát hành hoặc nâng cấp giao dịch trên chuỗi.
Tổng quan về tương tác để gửi giao dịch trong Sui
Ban đầu, các giao dịch của người dùng được gửi qua RPC mặt trước và được chuyển đến dịch vụ mặt sau sau khi xác minh cơ bản. Dịch vụ phụ trợ Sui chịu trách nhiệm xác thực thêm tải trọng giao dịch đến. Sau khi xác minh thành công chữ ký của người dùng, giao dịch được chuyển đổi thành chứng chỉ giao dịch (chứa thông tin giao dịch cũng như chữ ký của Sui).
Các chứng chỉ giao dịch này là một phần cơ bản trong hoạt động của mạng Sui và có thể được phổ biến giữa các nút xác minh khác nhau trong mạng. Đối với các giao dịch tạo/nâng cấp hợp đồng, nút xác minh sẽ gọi trình xác thực Sui để kiểm tra và xác minh tính hợp lệ của cấu trúc hợp đồng/ngữ nghĩa của các chứng chỉ này trước khi nó có thể được đưa vào chuỗi. Chính trong giai đoạn xác minh quan trọng này, lỗ hổng “vòng lặp vô hạn” có thể được kích hoạt và khai thác.
Khi lỗ hổng được kích hoạt, nó sẽ khiến quá trình xác minh bị gián đoạn vô thời hạn, cản trở khả năng xử lý các giao dịch mới của hệ thống và khiến mạng ngừng hoạt động hoàn toàn. Tệ hơn nữa, tình trạng này vẫn tồn tại sau khi nút được khởi động lại, điều đó có nghĩa là các biện pháp giảm thiểu truyền thống là chưa đủ. Một khi lỗ hổng này được kích hoạt, “thiệt hại liên tục” sẽ xảy ra, để lại tác động lâu dài đến toàn bộ mạng Sui.
Giải pháp của Sui
Sau phản hồi từ CertiK, Sui đã nhanh chóng xác nhận lỗ hổng và đưa ra bản sửa lỗi để giải quyết lỗ hổng nghiêm trọng. Bản sửa lỗi đảm bảo tính nhất quán giữa các thay đổi trạng thái và cờ sau thay đổi, loại bỏ tác động nghiêm trọng của các cuộc tấn công "bánh xe hamster".
Để loại bỏ sự không nhất quán ở trên, bản sửa lỗi của Sui bao gồm một điều chỉnh nhỏ nhưng quan trọng đối với hàm abstractState::join. Bản vá này loại bỏ logic xác định kết quả hợp nhất trạng thái trước khi thực thi Tóm tắtValue::join Thay vào đó, trước tiên, nó thực thi hàm Tóm tắt::join để thực hiện hợp nhất trạng thái và đặt xem việc hợp nhất có xảy ra hay không bằng cách so sánh kết quả cập nhật cuối cùng với trạng thái ban đầu. giá trị (old_value). Thay đổi dấu.
Bằng cách này, kết quả của việc hợp nhất trạng thái sẽ nhất quán với kết quả của cập nhật thực và không có vòng lặp vô hạn nào xảy ra trong quá trình phân tích.
Ngoài việc sửa lỗ hổng cụ thể này, Sui đã triển khai các biện pháp giảm thiểu tác động của các lỗ hổng xác thực trong tương lai. Theo phản hồi của Sui trong báo cáo lỗi, việc giảm thiểu liên quan đến một tính năng có tên là Danh sách từ chối.
"Tuy nhiên, trình xác thực có tệp cấu hình nút cho phép họ tạm thời từ chối một số danh mục giao dịch nhất định. Cấu hình này có thể được sử dụng để tạm thời vô hiệu hóa việc xử lý các bản phát hành và nâng cấp gói. Do lỗi này, cần phải chạy Sui trước khi ký bản phát hành hoặc gói nâng cấp tx trong khi danh sách từ chối sẽ ngăn trình xác thực chạy và bỏ tx độc hại, tạm thời từ chối liệt kê các loại tx này là một biện pháp giảm thiểu hiệu quả 100% (mặc dù nó sẽ tạm thời làm gián đoạn dịch vụ đối với bất kỳ ai cố gắng phát hành hoặc nâng cấp mã).
Nhân tiện, chúng tôi đã có tệp cấu hình danh sách từ chối TX này được một thời gian nhưng chúng tôi cũng đã thêm một cơ chế tương tự cho các chứng chỉ như một biện pháp giảm thiểu tiếp theo đối với lỗ hổng "vòng lặp vô hạn của trình xác thực" mà bạn đã báo cáo trước đây. Với cơ chế này, chúng tôi sẽ linh hoạt hơn với cuộc tấn công này: chúng tôi sẽ sử dụng cấu hình danh sách từ chối chứng chỉ để làm cho trình xác thực quên các chứng chỉ xấu (phá vỡ vòng lặp vô hạn) và cấu hình danh sách từ chối TX để vô hiệu hóa các bản phát hành/nâng cấp, từ đó ngăn chặn việc tạo ra các giao dịch tấn công độc hại mới. Cảm ơn đã khiến chúng tôi suy nghĩ về điều này!
Trình xác thực có số lượng "tích tắc" giới hạn (không giống như gas) để xác minh mã byte trước khi ký giao dịch, nếu tất cả mã byte được phát hành trong giao dịch không thể được xác minh trong nhiều tích tắc như vậy, trình xác thực sẽ từ chối ký giao dịch, ngăn không cho nó thực hiện thực thi trên mạng. Trước đây, việc đo lường chỉ hoạt động đối với một tập hợp các thẻ xác thực phức tạp được chọn. Để giải quyết vấn đề này, chúng tôi mở rộng việc đo lường cho từng trình xác thực để đảm bảo rằng có một hạn chế đối với công việc mà trình xác thực thực hiện trong quá trình xác minh từng dấu tích. Chúng tôi cũng đã sửa lỗi vòng lặp vô hạn tiềm ẩn trong trình xác thực rò rỉ ID. "
--Hướng dẫn từ nhà phát triển Sui về cách sửa lỗi
Nhìn chung, Denylist cho phép người xác thực tạm thời tránh các hoạt động khai thác trong trình xác thực và ngăn chặn hiệu quả thiệt hại tiềm ẩn do một số giao dịch độc hại gây ra bằng cách vô hiệu hóa quá trình phát hành hoặc nâng cấp. Khi các biện pháp giảm nhẹ của Denylist có hiệu lực, các nút đảm bảo rằng chúng có thể tiếp tục hoạt động bằng cách hy sinh các chức năng hợp đồng xuất bản/cập nhật của chính mình.
Tóm tắt
Trong bài viết này, chúng tôi chia sẻ chi tiết kỹ thuật của cuộc tấn công "hamsterwheel" do nhóm CertiK Skyfall phát hiện, giải thích cách cuộc tấn công mới này khai thác các lỗ hổng chính khiến mạng Sui ngừng hoạt động hoàn toàn. Ngoài ra, chúng tôi cũng xem xét kỹ hơn phản ứng kịp thời của Sui để khắc phục sự cố nghiêm trọng này và chia sẻ cách sửa lỗ hổng cũng như các phương pháp giảm thiểu tiếp theo cho các lỗ hổng tương tự.