Một lỗ hổng (CVE-3-2022) đã được xác định trong quá trình triển khai hàm băm mật mã SHA-37454 (Keccak) được cung cấp trong gói XKCP (Gói mã Keccak eXtends), có thể dẫn đến tràn bộ đệm trong quá trình xử lý một số dữ liệu nhất định. dữ liệu được định dạng. Sự cố xảy ra do lỗi trong mã triển khai SHA-3 cụ thể chứ không phải do lỗ hổng trong chính thuật toán. Gói XKCP được quảng cáo là triển khai chính thức của SHA-3, được phát triển với ý kiến đầu vào từ nhóm phát triển Keccak và được sử dụng làm cơ sở cho các hàm SHA-3 trong các ngôn ngữ lập trình khác nhau (ví dụ: mã XKCP được sử dụng trong hàm băm Python mô-đun, gói thông báo Ruby sha3 và các hàm PHP hash_*).
Theo nhà nghiên cứu đã xác định được vấn đề, anh ta có thể sử dụng lỗ hổng này để vi phạm các thuộc tính mật mã của hàm băm và tìm ra hình ảnh đầu tiên và thứ hai, cũng như phát hiện các xung đột. Ngoài ra, đã có thông báo rằng một nguyên mẫu khai thác sẽ được tạo ra để cho phép thực thi mã khi tính toán hàm băm của một tệp được thiết kế đặc biệt. Lỗ hổng này cũng có thể bị lợi dụng để tấn công các thuật toán xác minh chữ ký số sử dụng SHA-3 (ví dụ: Ed448). Thông tin chi tiết về các phương thức tấn công dự kiến sẽ được công bố sau, sau khi lỗ hổng đã được loại bỏ ở mọi nơi.
Vẫn chưa rõ mức độ ảnh hưởng của lỗ hổng này đến các ứng dụng hiện có trong thực tế, vì để vấn đề tự biểu hiện trong mã, phải sử dụng phép tính băm tuần hoàn trong các khối và một trong các khối được xử lý phải có kích thước khoảng 4 GB (ít nhất 2^32 - 200 byte). Khi xử lý dữ liệu đầu vào cùng một lúc (không tính toán hàm băm tuần tự theo từng phần), vấn đề không xuất hiện. Là phương pháp bảo vệ đơn giản nhất, nó được đề xuất để giới hạn kích thước tối đa của dữ liệu liên quan đến một lần lặp của phép tính băm.
Lỗ hổng này xảy ra do lỗi xử lý khối dữ liệu đầu vào. Do so sánh không chính xác các giá trị có kiểu "int", kích thước của dữ liệu đang chờ xử lý được xác định không chính xác, dẫn đến phần đuôi được ghi vượt quá bộ đệm được phân bổ. Cụ thể, phép so sánh đã sử dụng biểu thức “partialBlock + instance->byteIOIndex”, dẫn đến tràn số nguyên cho các giá trị lớn của các phần cấu thành. Ngoài ra, có một kiểu truyền không chính xác "(unsigned int)(dataByteLen - i)" trong mã, điều này gây ra tình trạng tràn trên các hệ thống có loại size_t 64-bit.
Mã ví dụ gây tràn: import hashlib h = hashlib.sha3_224() m1 = b"\x00" * 1; m2 = b"\x00" * 4294967295; h.update(m1) h.update(m2) print(h.hexdigest())
Nguồn: opennet.ru