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, có một lỗ hổng mới và 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 và hậu quả tương đương với 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 sửa lỗi trị giá 500.000 đô la từ SUI vì đã phát hiện ra lỗ hổng bảo mật lớn này. CoinDesk, một phương tiện truyền thông có thẩm quyền trong ngành công nghiệp Hoa Kỳ, đã đưa tin về sự kiện này, và sau đó các phương tiện truyền thông lớn cũng đưa tin liên quan sau báo cáo của nó.
Lỗ hổng bảo mật này được gọi một cách sinh động là "Hamster Wheel": 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 hiện đã biết. Kẻ tấn công chỉ cần gửi một tải trọng khoảng 100 byte để kích hoạt vòng lặp vô hạn trong nút xác minh Sui, khiến nó không phản hồi đến 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ể tiếp tục 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 không thể xử lý các giao dịch mới giống như chuột đồng chạy không ngừng trên bánh xe. Do đó, chúng tôi gọi kiểu tấn công độc đáo này là cuộc tấn công "bánh xe chuột đồng".
Sau khi phát hiện ra lỗi, CertiK đã báo cáo cho Sui thông qua chương trình tiền thưởng lỗi của Sui. Sui cũng đã phản hồi hiệu quả ngay lần đầu tiên, 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 ra mắt mạng chính. Ngoài việc khắc phục lỗ hổng cụ thể này, Sui cũng thực hiện các biện pháp giảm thiểu phòng ngừa để giảm thiểu 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ì sự tiết lộ có trách nhiệm của họ, Sui đã trao cho nhóm CertiK khoản tiền thưởng 500.000 USD.
Chi tiết về lỗ hổng nghiêm trọng này sẽ được tiết lộ ở cấp độ kỹ thuật bên dưới, đồng thời nguyên nhân gốc rễ và tác động tiềm ẩn của lỗ hổng sẽ được làm rõ.
Giải thích về lỗ hổng
Vai trò chính của trình xác thực trong Sui
Đối với các chuỗi khối dựa trên ngôn ngữ Move như Sui và Aptos, cơ chế bảo vệ để 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 thực cung cấp một loạt trình kiểm tra để đảm bảo tính chính xác về cấu trúc và ngữ nghĩa, chỉ sau khi vượt qua kiểm tra xác minh, hợp đồng mới được đưa vào máy ảo Move để được thực thi.
Các mối đe dọa tải trọng độc hại trên Move Chain
Chuỗi Sui cung cấp một bộ mô hình lưu trữ và giao diện mới trên máy ảo Move ban đầu, vì vậy Sui có một phiên bản tùy chỉnh của máy ảo Move. Để hỗ trợ các nguyên mẫu lưu trữ mới, Sui tiếp tục giới thiệu một loạt các phương pháp kiểm tra bổ sung và 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à các chức năng truy cập lưu trữ toàn cầu. Cá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 cá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 trọng của Sui
Như thể hiện trong hình trên, hầu hết các kiểm tra trong trình xác minh đều thực hiện xác minh bảo mật cấu trúc đối với CompiledModule (đại diện cho việc thực thi 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 từng trường trong tải trọng thời gian chạy nằm trong giới hạn mục nhập tối đa được phép.
Ngoài kiểm tra 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.
Hiểu Trình thông dịch trừu tượng của Move: Phân tích tuyến tính và lặp
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 quy trình xác minh chi tiết và chính xác hơn, đồng thời mỗi trình xác thực được phép xác định trạng thái trừu tượng duy nhất của chúng để phân tích.
Khi khởi động, trình thông dịch trừu tượng 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 các CFG này duy trì một tập hợp các trạng thái, "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 thực hiện khối cơ bản, 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 thực hiện khối cơ bản.
Khi trình thông dịch trừu tượng không gặp phải bước nhảy ngược (hoặc vòng lặp) trong biểu đồ luồng điều khiển, nó sẽ tuân theo nguyên tắc thực thi tuyến tính đơn giản: lần lượt từng khối cơ bản được phân tích và lệnh trước đó được tính toán theo 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ề trạng thái của từng khối cơ bản trong quá trình thực thi chương trình, giúp xác minh các thuộc tính bảo mật của chương trình.
Quy trình làm việc của trình thông dịch trừu tượng Move
Tuy nhiên, quá trình 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 chu trình có nghĩa là đồ thị luồng điều khiển chứa cạnh nhảy lùi. Nguồn của cạnh nhảy lùi 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 bước nhảy cạnh sau là một phân tích trước đó. 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 lùi.
Nếu trạng thái hợp nhất được tìm thấy 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 sẽ tiếp tục cho đến khi trạng thái trước 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 thấy quá trình phân tích chu trình đã hoàn tất.
Trình xác thực Sui IDLeak: Phân tích diễn giải trừu tượng tùy chỉnh
Không giống như thiết kế Move ban đầu, nền tảng chuỗi khối 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" duy nhất. Một đặ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 trữ trên chuỗi dưới dạng chỉ mục) phải có loại ID làm 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 đối tượng 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 thuộc tính này, Sui đã xây dựng một bộ logic phân tích tùy chỉnh 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 để phân tích. Nó có AbstractDomain độc đáo của riêng nó, được gọi là AbstractState. Mỗi AbstractState bao gồm AbstractValue tương ứng với nhiều biến cục bộ. Trạng thái của từng biến cục bộ được theo dõi bởi AbstractValue để theo dõi xem biến ID có phải là thương hiệu 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 hoàn toàn mới vào cấu trúc. Bằng cách trừu tượng hóa phân tích diễn giải, trình xác thực IDLeak có thể theo dõi triệt để 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.
Tình trạng bảo trì trình xác thực Sui IDLeak không nhất quán
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 AbstractState::join. Chức năng này đóng một 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 AbstractState::join, hàm lấy một AbstractState 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ộ (mặc định là AbstractValue::Other nếu không tìm thấy). Nếu hai giá trị không bằng nhau, nó sẽ đặt cờ "đã thay đổi" làm cơ sở để biết 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 AbstractValue::join.
Trong AbstractValue::join, hàm so sánh giá trị của nó với một AbstractValue 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 nhau, trả về AbstractValue::Other.
Tuy nhiên, logic duy trì trạng thái này chứa một vấn đề không nhất quán tiềm ẩn. Mặc dù AbstractState::join sẽ trả về kết quả cho biết rằng 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ị mới và cũ, giá trị trạng thái được cập nhật đã hợp nhất có thể vẫn không thay đổi.
Vấn đề không nhất quán này là do thứ tự của các thao tác: quyết định thay đổi trạng thái trong AbstractState::join xảy ra trước khi cập nhật trạng thái (AbstractValue::join) và quyết đị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 AbstractValue::join, AbstractValue::Other đóng vai trò quyết định trong kết quả của việc hợp nhất. Ví dụ: nếu giá trị cũ là AbstractValue::Other và giá trị mới là AbstractValue::Fresh, giá trị trạng thái được cập nhật vẫn là AbstractValue::Other, ngay cả khi giá trị cũ và mới khác nhau, bản thân trạng thái vẫn không thay đổi sau khi cập nhật.
Ví dụ: Sự không mạch lạc của 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 trạng thái của một khối cơ bản được đánh giá là "đã thay đổi", nhưng bản thân giá trị trạng thái đã hợp nhất không thay đổi. Trong quá trình phân tích diễn giải trừu tượng, những mâu thuẫn như vậy có thể gây ra những 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 một chu kỳ xảy ra trong biểu đồ luồng điều khiển (CFG):
Khi gặp phải một vòng lặp, trình thông dịch trừu tượng sử dụng một 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 lùi và 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 sai kết quả hợp nhất trạng thái là "thay đổi", trong khi thực tế giá trị của biến nội bộ của trạng thái không thay đổi, thì nó sẽ dẫn đến phân tích lại vô tận, dẫn đến một vòng lặp vô tận.
Việc khai thác thêm sự không nhất quán sẽ kích hoạt mộ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 kiểm soát độc hại để đánh 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ố ý giới thiệu một bước nhảy lùi từ BB3 đến BB2 để tạo một vòng lặp.
Trạng thái CFG+ độc hại có thể dẫn đến một vòng lặp vô hạn nội bộ 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 ::Other. Sau khi thực hiện BB2, luồng chuyển sang BB3 trong đó biến tương tự được đặt thành ::Fresh. Hết BB3 có back jump edge nhảy sang BB2.
Sự mâu thuẫn nói trên đóng một vai trò quan trọng trong việc giải thích trừu tượng của ví dụ này. Khi cạnh nhảy lùi được xử lý, trình thông dịch trừu tượng cố gắng kết nối trạng thái đặt hàng sau của BB3 (với biến "::Fresh") với trạng thái đặt hàng trước của BB2 (với biến "::Other"). Hàm AbstractState::join thông báo sự khác biệt giữa giá trị cũ và 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 chi phối của "::Other" trong AbstractValue::join có nghĩa là sau khi AbstractValue được hợp nhất, giá trị thực của biến trạng thái BB2 vẫn là "::Other" và kết quả của việc hợp nhất trạng thái không thay đổi .
Vì vậy, một khi quá trình theo chu kỳ này bắt đầu, tức là khi trình xác thực 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ế tiếp của nó (trong trường hợp này là BB3), thì quá trình này sẽ tiếp tục vô thời hạn. Vòng lặp vô hạn sử dụng tất cả các chu kỳ CPU có sẵn, khiến nó không thể xử lý và phản hồi các giao dịch mới, điều này vẫn tồn tại trong quá trình khởi động lại trình xác thực.
Bằng cách khai thác lỗ hổng này, các nút xác thực sẽ chạy vô tận như những chú chuột hamster trên bánh xe trong một vòng lặp vô hạn, không thể xử lý các giao dịch mới. Do đó, chúng tôi gọi kiểu tấn công độc đáo này là cuộc tấn công "bánh xe chuột đồng".
Cuộc tấn công “bánh xe chuột đồng” có thể khiến các trình xác thực của Sui rơi vào bế tắc một cách hiệu quả, do đó có thể đánh sập toàn bộ mạng lưới của Sui.
Sau khi hiểu nguyên nhân của lỗ hổng và quá trình kích hoạ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 bảo mật 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ả quá trình xử lý giao dịch mới và gây ra sự từ chối dịch vụ trên mạng Sui.
Cuộc tấn công "Bánh xe chuột" trong mạng Sui gây hại dai dẳng
Chương trình tiền thưởng lỗi của Sui có các quy định nghiêm ngặt về việc đá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. Các lỗ hổng đáp ứng xếp hạng "nguy cấp" phải tắt toàn bộ mạng và ngăn chặn hiệu quả các xác nhận giao dịch mới, đồng thời yêu cầu một hard fork để khắc phục sự cố; lỗ hổng (trung bình)” hoặc “rủi ro cao (cao)”.
Lỗ hổng "bánh xe chuột đồng" do nhóm CertiK Skyfall phát hiện có thể tắt toàn bộ mạng Sui và yêu cầu phát hành phiên bản mới chính thức để nâng cấp và sửa chữa. Sui cuối cùng đã đánh giá lỗ hổng này là "Nghiêm trọng" dựa trên mức độ nghiêm trọng của nó. Để hiểu rõ hơn về tác động nghiêm trọng do cuộc tấn công "hamster wheel" gây ra, 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 xuất bản hoặc nâng cấp giao dịch trên chuỗi.
Tổng quan về các 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 giao diện người dùng và được chuyển đến các dịch vụ phụ trợ 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 các 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 thành chứng chỉ giao dịch (chứa thông tin giao dịch và 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, trước khi chúng có thể được tải lên chuỗi, nút xác minh sẽ gọi trình xác minh 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. 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ở hiệu quả 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. Thêm vào đó, tình trạng này vẫn tiếp diễn sau khi nút 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à không đủ. Một khi lỗ hổng được kích hoạt, sẽ có "thiệt hại liên tục" và để lại tác động lâu dài đến toàn bộ mạng Sui.
Giải pháp của Sui
Sau khi có phản hồi từ CertiK, Sui đã kịp thời xác nhận lỗ hổng và phát hành 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 khi thay đổi, loại bỏ tác động nghiêm trọng của cuộc tấn công "bánh xe chuột đồng".
Để loại bỏ sự không nhất quán đã nói ở 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ả của việc hợp nhất trạng thái trước khi thực thi AbstractValue::join. Thay vào đó, hãy thực thi hàm AbstractValue::join để hợp nhất trạng thái trước và thiết lập việc hợp nhất bằng cách so sánh kết quả cập nhật cuối cùng với giá trị trạng thái ban đầu (cũ _value) Cờ cho các thay đổi.
Theo 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 bản cập nhật thực và vòng lặp vô hạn sẽ không xảy ra trong quá trình phân tích.
Ngoài việc khắc phục lỗ hổng cụ thể này, Sui cũng triển khai các biện pháp giảm thiểu để giảm tác động của các lỗ hổng trình 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ố loại 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, Sui đang chạy trước khi ký phát hành hoặc nâng cấp gói tx trình xác thực, trong khi danh sách từ chối sẽ ngăn trình xác thực chạy và loại bỏ tx độc hại, việc tạm thời từ chối 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ụ cho những người cố gắng phát hành hoặc nâng cấp mã).
Ngẫu nhiê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 trình xác thực" được báo cáo trước đây của bạn. Với cơ chế này, chúng tôi sẽ linh hoạt hơn trước 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 người xác thực quên đi 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 để cấm xuất bản/nâng cấp, do đó ngăn chặn việc tạo ra giao dịch tấn công độc hại mới. Cảm ơn vì đã 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" hạn chế (khác với gas) để xác minh mã byte trước khi ký giao dịch và nếu tất cả mã byte được cấp trong giao dịch không thể được xác minh trong nhiều tích tắc này, trình xác thực sẽ từ chối ký giao dịch, ngăn chặn nó khỏi thực thi trên mạng. Trước đây, việc đo lường chỉ áp dụng cho một tập hợp các lượt xác thực phức tạp đã chọn. Để chống lại điều này, chúng tôi mở rộng đo lường cho từng trình xác thực để đảm bảo 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 thực của mỗi lần đánh dấu. 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ừ các nhà phát triển Sui về sửa lỗi
Nói chung, Denylist cho phép trình xác thực tạm thời tránh khai thác lỗ hổng 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 thiểu 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 chúng.
Tóm tắt
Trong bài viết này, chúng tôi chia sẻ các chi tiết kỹ thuật của cuộc tấn công "Hamster Wheel" được phát hiện bởi nhóm CertiK Skyfall, giải thích cách loại tấn công mới này khai thác các lỗ hổng chính để gây ra sự tắt hoàn toàn của mạng Sui. Ngoài ra, chúng tôi cũng đã nghiên cứu kỹ lưỡng về phản ứng kịp thời của Sui để khắc phục sự cố nghiêm trọng này, đồng thời chia sẻ cách khắc phục lỗ hổng và các phương pháp giảm thiểu tiếp theo cho các lỗ hổng tương tự.
Xem bản gốc
Nội dung chỉ mang tính chất tham khảo, không phải là lời chào mời hay đề nghị. Không cung cấp tư vấn về đầu tư, thuế hoặc pháp lý. Xem Tuyên bố miễn trừ trách nhiệm để biết thêm thông tin về rủi ro.
Phân tích chuyên sâu về lỗ hổng mới nhất "hamster wheel" chi tiết kỹ thuật của chuỗi công khai Sui
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, có một lỗ hổng mới và 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 và hậu quả tương đương với 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 sửa lỗi trị giá 500.000 đô la từ SUI vì đã phát hiện ra lỗ hổng bảo mật lớn này. CoinDesk, một phương tiện truyền thông có thẩm quyền trong ngành công nghiệp Hoa Kỳ, đã đưa tin về sự kiện này, và sau đó các phương tiện truyền thông lớn cũng đưa tin liên quan sau báo cáo của nó.
Lỗ hổng bảo mật này được gọi một cách sinh động là "Hamster Wheel": 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 hiện đã biết. Kẻ tấn công chỉ cần gửi một tải trọng khoảng 100 byte để kích hoạt vòng lặp vô hạn trong nút xác minh Sui, khiến nó không phản hồi đến 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ể tiếp tục 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 không thể xử lý các giao dịch mới giống như chuột đồng chạy không ngừng trên bánh xe. Do đó, chúng tôi gọi kiểu tấn công độc đáo này là cuộc tấn công "bánh xe chuột đồng".
Sau khi phát hiện ra lỗi, CertiK đã báo cáo cho Sui thông qua chương trình tiền thưởng lỗi của Sui. Sui cũng đã phản hồi hiệu quả ngay lần đầu tiên, 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 ra mắt mạng chính. Ngoài việc khắc phục lỗ hổng cụ thể này, Sui cũng thực hiện các biện pháp giảm thiểu phòng ngừa để giảm thiểu 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ì sự tiết lộ có trách nhiệm của họ, Sui đã trao cho nhóm CertiK khoản tiền thưởng 500.000 USD.
Chi tiết về lỗ hổng nghiêm trọng này sẽ được tiết lộ ở cấp độ kỹ thuật bên dưới, đồng thời nguyên nhân gốc rễ và tác động tiềm ẩn của lỗ hổng sẽ được làm rõ.
Giải thích về lỗ hổng
Vai trò chính của trình xác thực trong Sui
Đối với các chuỗi khối dựa trên ngôn ngữ Move như Sui và Aptos, cơ chế bảo vệ để 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 thực cung cấp một loạt trình kiểm tra để đảm bảo tính chính xác về cấu trúc và ngữ nghĩa, chỉ sau khi vượt qua kiểm tra xác minh, hợp đồng mới được đưa vào máy ảo Move để được thực thi.
Các mối đe dọa tải trọng độc hại trên Move Chain
Chuỗi Sui cung cấp một bộ mô hình lưu trữ và giao diện mới trên máy ảo Move ban đầu, vì vậy Sui có một phiên bản tùy chỉnh của máy ảo Move. Để hỗ trợ các nguyên mẫu lưu trữ mới, Sui tiếp tục giới thiệu một loạt các phương pháp kiểm tra bổ sung và 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à các chức năng truy cập lưu trữ toàn cầu. Cá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 cá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 trọng của Sui
Như thể hiện trong hình trên, hầu hết các kiểm tra trong trình xác minh đều thực hiện xác minh bảo mật cấu trúc đối với CompiledModule (đại diện cho việc thực thi 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 từng trường trong tải trọng thời gian chạy nằm trong giới hạn mục nhập tối đa được phép.
Ngoài kiểm tra 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.
Hiểu Trình thông dịch trừu tượng của Move: Phân tích tuyến tính và lặp
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 quy trình xác minh chi tiết và chính xác hơn, đồng thời mỗi trình xác thực được phép xác định trạng thái trừu tượng duy nhất của chúng để phân tích.
Khi khởi động, trình thông dịch trừu tượng 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 các CFG này duy trì một tập hợp các trạng thái, "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 thực hiện khối cơ bản, 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 thực hiện khối cơ bản.
Khi trình thông dịch trừu tượng không gặp phải bước nhảy ngược (hoặc vòng lặp) trong biểu đồ luồng điều khiển, nó sẽ tuân theo nguyên tắc thực thi tuyến tính đơn giản: lần lượt từng khối cơ bản được phân tích và lệnh trước đó được tính toán theo 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ề trạng thái của từng khối cơ bản trong quá trình thực thi chương trình, giúp xác minh các thuộc tính bảo mật của chương trình.
Quy trình làm việc của trình thông dịch trừu tượng Move
Tuy nhiên, quá trình 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 chu trình có nghĩa là đồ thị luồng điều khiển chứa cạnh nhảy lùi. Nguồn của cạnh nhảy lùi 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 bước nhảy cạnh sau là một phân tích trước đó. 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 lùi.
Nếu trạng thái hợp nhất được tìm thấy 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 sẽ tiếp tục cho đến khi trạng thái trước 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 thấy quá trình phân tích chu trình đã hoàn tất.
Trình xác thực Sui IDLeak: Phân tích diễn giải trừu tượng tùy chỉnh
Không giống như thiết kế Move ban đầu, nền tảng chuỗi khối 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" duy nhất. Một đặ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 trữ trên chuỗi dưới dạng chỉ mục) phải có loại ID làm 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 đối tượng 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 thuộc tính này, Sui đã xây dựng một bộ logic phân tích tùy chỉnh 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 để phân tích. Nó có AbstractDomain độc đáo của riêng nó, được gọi là AbstractState. Mỗi AbstractState bao gồm AbstractValue tương ứng với nhiều biến cục bộ. Trạng thái của từng biến cục bộ được theo dõi bởi AbstractValue để theo dõi xem biến ID có phải là thương hiệu 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 hoàn toàn mới vào cấu trúc. Bằng cách trừu tượng hóa phân tích diễn giải, trình xác thực IDLeak có thể theo dõi triệt để 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.
Tình trạng bảo trì trình xác thực Sui IDLeak không nhất quán
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 AbstractState::join. Chức năng này đóng một 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 AbstractState::join, hàm lấy một AbstractState 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ộ (mặc định là AbstractValue::Other nếu không tìm thấy). Nếu hai giá trị không bằng nhau, nó sẽ đặt cờ "đã thay đổi" làm cơ sở để biết 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 AbstractValue::join.
Trong AbstractValue::join, hàm so sánh giá trị của nó với một AbstractValue 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 nhau, trả về AbstractValue::Other.
Tuy nhiên, logic duy trì trạng thái này chứa một vấn đề không nhất quán tiềm ẩn. Mặc dù AbstractState::join sẽ trả về kết quả cho biết rằng 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ị mới và cũ, giá trị trạng thái được cập nhật đã hợp nhất có thể vẫn không thay đổi.
Vấn đề không nhất quán này là do thứ tự của các thao tác: quyết định thay đổi trạng thái trong AbstractState::join xảy ra trước khi cập nhật trạng thái (AbstractValue::join) và quyết đị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 AbstractValue::join, AbstractValue::Other đóng vai trò quyết định trong kết quả của việc hợp nhất. Ví dụ: nếu giá trị cũ là AbstractValue::Other và giá trị mới là AbstractValue::Fresh, giá trị trạng thái được cập nhật vẫn là AbstractValue::Other, ngay cả khi giá trị cũ và mới khác nhau, bản thân trạng thái vẫn không thay đổi sau khi cập nhật.
Ví dụ: Sự không mạch lạc của 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 trạng thái của một khối cơ bản được đánh giá là "đã thay đổi", nhưng bản thân giá trị trạng thái đã hợp nhất không thay đổi. Trong quá trình phân tích diễn giải trừu tượng, những mâu thuẫn như vậy có thể gây ra những 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 một chu kỳ xảy ra trong biểu đồ luồng điều khiển (CFG):
Khi gặp phải một vòng lặp, trình thông dịch trừu tượng sử dụng một 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 lùi và 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 sai kết quả hợp nhất trạng thái là "thay đổi", trong khi thực tế giá trị của biến nội bộ của trạng thái không thay đổi, thì nó sẽ dẫn đến phân tích lại vô tận, dẫn đến một vòng lặp vô tận.
Việc khai thác thêm sự không nhất quán sẽ kích hoạt mộ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 kiểm soát độc hại để đánh 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ố ý giới thiệu một bước nhảy lùi từ BB3 đến BB2 để tạo một vòng lặp.
Trạng thái CFG+ độc hại có thể dẫn đến một vòng lặp vô hạn nội bộ 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 ::Other. Sau khi thực hiện BB2, luồng chuyển sang BB3 trong đó biến tương tự được đặt thành ::Fresh. Hết BB3 có back jump edge nhảy sang BB2.
Sự mâu thuẫn nói trên đóng một vai trò quan trọng trong việc giải thích trừu tượng của ví dụ này. Khi cạnh nhảy lùi được xử lý, trình thông dịch trừu tượng cố gắng kết nối trạng thái đặt hàng sau của BB3 (với biến "::Fresh") với trạng thái đặt hàng trước của BB2 (với biến "::Other"). Hàm AbstractState::join thông báo sự khác biệt giữa giá trị cũ và 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 chi phối của "::Other" trong AbstractValue::join có nghĩa là sau khi AbstractValue được hợp nhất, giá trị thực của biến trạng thái BB2 vẫn là "::Other" và kết quả của việc hợp nhất trạng thái không thay đổi .
Vì vậy, một khi quá trình theo chu kỳ này bắt đầu, tức là khi trình xác thực 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ế tiếp của nó (trong trường hợp này là BB3), thì quá trình này sẽ tiếp tục vô thời hạn. Vòng lặp vô hạn sử dụng tất cả các chu kỳ CPU có sẵn, khiến nó không thể xử lý và phản hồi các giao dịch mới, điều này vẫn tồn tại trong quá trình khởi động lại trình xác thực.
Bằng cách khai thác lỗ hổng này, các nút xác thực sẽ chạy vô tận như những chú chuột hamster trên bánh xe trong một vòng lặp vô hạn, không thể xử lý các giao dịch mới. Do đó, chúng tôi gọi kiểu tấn công độc đáo này là cuộc tấn công "bánh xe chuột đồng".
Cuộc tấn công “bánh xe chuột đồng” có thể khiến các trình xác thực của Sui rơi vào bế tắc một cách hiệu quả, do đó có thể đánh sập toàn bộ mạng lưới của Sui.
Sau khi hiểu nguyên nhân của lỗ hổng và quá trình kích hoạ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 bảo mật 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ả quá trình xử lý giao dịch mới và gây ra sự từ chối dịch vụ trên mạng Sui.
Cuộc tấn công "Bánh xe chuột" trong mạng Sui gây hại dai dẳng
Chương trình tiền thưởng lỗi của Sui có các quy định nghiêm ngặt về việc đá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. Các lỗ hổng đáp ứng xếp hạng "nguy cấp" phải tắt toàn bộ mạng và ngăn chặn hiệu quả các xác nhận giao dịch mới, đồng thời yêu cầu một hard fork để khắc phục sự cố; lỗ hổng (trung bình)” hoặc “rủi ro cao (cao)”.
Lỗ hổng "bánh xe chuột đồng" do nhóm CertiK Skyfall phát hiện có thể tắt toàn bộ mạng Sui và yêu cầu phát hành phiên bản mới chính thức để nâng cấp và sửa chữa. Sui cuối cùng đã đánh giá lỗ hổng này là "Nghiêm trọng" dựa trên mức độ nghiêm trọng của nó. Để hiểu rõ hơn về tác động nghiêm trọng do cuộc tấn công "hamster wheel" gây ra, 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 xuất bản hoặc nâng cấp giao dịch trên chuỗi.
Tổng quan về các 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 giao diện người dùng và được chuyển đến các dịch vụ phụ trợ 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 các 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 thành chứng chỉ giao dịch (chứa thông tin giao dịch và 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, trước khi chúng có thể được tải lên chuỗi, nút xác minh sẽ gọi trình xác minh 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. 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ở hiệu quả 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. Thêm vào đó, tình trạng này vẫn tiếp diễn sau khi nút 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à không đủ. Một khi lỗ hổng được kích hoạt, sẽ có "thiệt hại liên tục" và để lại tác động lâu dài đến toàn bộ mạng Sui.
Giải pháp của Sui
Sau khi có phản hồi từ CertiK, Sui đã kịp thời xác nhận lỗ hổng và phát hành 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 khi thay đổi, loại bỏ tác động nghiêm trọng của cuộc tấn công "bánh xe chuột đồng".
Để loại bỏ sự không nhất quán đã nói ở 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ả của việc hợp nhất trạng thái trước khi thực thi AbstractValue::join. Thay vào đó, hãy thực thi hàm AbstractValue::join để hợp nhất trạng thái trước và thiết lập việc hợp nhất bằng cách so sánh kết quả cập nhật cuối cùng với giá trị trạng thái ban đầu (cũ _value) Cờ cho các thay đổi.
Theo 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 bản cập nhật thực và vòng lặp vô hạn sẽ không xảy ra trong quá trình phân tích.
Ngoài việc khắc phục lỗ hổng cụ thể này, Sui cũng triển khai các biện pháp giảm thiểu để giảm tác động của các lỗ hổng trình 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ố loại 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, Sui đang chạy trước khi ký phát hành hoặc nâng cấp gói tx trình xác thực, trong khi danh sách từ chối sẽ ngăn trình xác thực chạy và loại bỏ tx độc hại, việc tạm thời từ chối 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ụ cho những người cố gắng phát hành hoặc nâng cấp mã).
Ngẫu nhiê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 trình xác thực" được báo cáo trước đây của bạn. Với cơ chế này, chúng tôi sẽ linh hoạt hơn trước 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 người xác thực quên đi 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 để cấm xuất bản/nâng cấp, do đó ngăn chặn việc tạo ra giao dịch tấn công độc hại mới. Cảm ơn vì đã 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" hạn chế (khác với gas) để xác minh mã byte trước khi ký giao dịch và nếu tất cả mã byte được cấp trong giao dịch không thể được xác minh trong nhiều tích tắc này, trình xác thực sẽ từ chối ký giao dịch, ngăn chặn nó khỏi thực thi trên mạng. Trước đây, việc đo lường chỉ áp dụng cho một tập hợp các lượt xác thực phức tạp đã chọn. Để chống lại điều này, chúng tôi mở rộng đo lường cho từng trình xác thực để đảm bảo 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 thực của mỗi lần đánh dấu. 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ừ các nhà phát triển Sui về sửa lỗi
Nói chung, Denylist cho phép trình xác thực tạm thời tránh khai thác lỗ hổng 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 thiểu 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 chúng.
Tóm tắt
Trong bài viết này, chúng tôi chia sẻ các chi tiết kỹ thuật của cuộc tấn công "Hamster Wheel" được phát hiện bởi nhóm CertiK Skyfall, giải thích cách loại tấn công mới này khai thác các lỗ hổng chính để gây ra sự tắt hoàn toàn của mạng Sui. Ngoài ra, chúng tôi cũng đã nghiên cứu kỹ lưỡng về phản ứng kịp thời của Sui để khắc phục sự cố nghiêm trọng này, đồng thời chia sẻ cách khắc phục lỗ hổng và các phương pháp giảm thiểu tiếp theo cho các lỗ hổng tương tự.