Backtracking regular expression trong Symfony JsonPath có thể gây từ chối dịch vụ

Symfony là một framework PHP dành cho các ứng dụng web và console, đồng thời là một tập hợp các component PHP có thể tái sử dụng. Từ 7.3.0-BETA1 cho đến trước 7.4.12 và 8.0.12, component JsonPath biên dịch trực tiếp các filter pattern match() và search() do attacker kiểm soát vào preg_match() mà không có giới hạn độ dài, giới hạn i-regexp hoặc giới hạn backtracking, cho phép các expression gây catastrophic backtracking ghim CPU của worker và gây từ chối dịch vụ. Vấn đề này được khắc phục trong các phiên bản 7.4.12 và 8.0.12.

• symfony/json-path và component JsonPath của symfony/symfony bị ảnh hưởng trong phạm vi >= 7.3.0-BETA1, < 7.4.12. Bản vá tương ứng là 7.4.12.
• Các package và component nêu trên cũng bị ảnh hưởng trong phạm vi >= 8.0.0-BETA1, < 8.0.12. Bản vá tương ứng là 8.0.12.
• Advisory của Symfony liệt kê cùng các phạm vi và bản vá cho cả symfony/json-path và symfony/symfony.
• Changelog của repository cũng ghi nhận bản sửa trong dòng 8.1.x, nhưng bằng chứng hiện có không cung cấp ranh giới bị ảnh hưởng hoặc bản vá chính xác cho dòng đó. Không nên suy luận trạng thái an toàn của bản build 8.1.x nếu chưa xác minh riêng.

Component JsonPath nhận biểu thức JSONPath do caller cung cấp và đưa pattern của các hàm match() hoặc search() vào preg_match(). Hàm transformJsonPathRegex() chỉ thực hiện escaping mang tính hình thức, không giới hạn độ dài pattern, không giới hạn pattern vào tập con i-regexp của RFC 9485 và không giới hạn backtracking. Một biểu thức regular expression có độ phức tạp bất thường có thể gây catastrophic backtracking khi được đánh giá trên dữ liệu JSON không tầm thường. Mỗi lần đánh giá như vậy có thể giữ một core CPU trong thời gian dài, còn một số request đồng thời có thể làm cạn worker pool. Các lệnh gọi preg_match() được đặt sau toán tử @, nên lỗi do giới hạn backtracking của PCRE có thể bị che giấu và không tạo log tương ứng. Bản vá chuyển việc so khớp sang helper tạm thời đặt pcre.backtrack_limit ở mức giới hạn, sau đó khôi phục giá trị trước đó. Điều kiện phơi nhiễm phụ thuộc vào việc ứng dụng có thực sự đánh giá JSONPath bị attacker chi phối hay không; bản ghi không chứng minh mọi cách sử dụng JsonPath đều cho phép điều khiển này.

Lỗ hổng có thể bị khai thác qua mạng khi một endpoint, query parameter hoặc trường API cho phép attacker đưa JSONPath vào ứng dụng và ứng dụng đánh giá biểu thức đó bằng JsonCrawler. Điều kiện cần là biểu thức phải chứa filter match() hoặc search() bị kiểm soát bởi attacker và được áp dụng lên dữ liệu JSON không tầm thường. Bản ghi chuẩn hóa mô tả rằng không cần đặc quyền và không cần tương tác người dùng ở cấp độ lỗ hổng, nhưng quyền truy cập ở tầng ứng dụng vẫn có thể giới hạn khả năng chạm tới chức năng này. Bản ghi đánh dấu chưa có public exploit và không xác định trạng thái khai thác đã biết; điều đó không chứng minh rằng việc khai thác là không thể hoặc chưa từng xảy ra. Không có campaign, nạn nhân hoặc exploit cụ thể nào được bằng chứng hiện có nêu tên.

Khi điều kiện phơi nhiễm tồn tại, attacker có thể khiến quá trình xử lý regular expression tiêu tốn CPU bất thường và giữ worker lâu hơn dự kiến. Nếu số request đồng thời đủ lớn, worker pool có thể bị chiếm dụng, làm tăng latency, gây timeout hoặc khiến dịch vụ từ chối các request hợp lệ. Tác động được giới hạn ở tính sẵn sàng theo bằng chứng hiện có; không có bằng chứng trong bản ghi cho thấy lỗ hổng cho phép đọc dữ liệu, thay đổi dữ liệu hoặc vượt quyền. Mức độ ảnh hưởng thực tế phụ thuộc vào kích thước dữ liệu JSON, cấu hình worker và việc endpoint có cho phép attacker điều khiển expression hay không.

Ứng dụng Symfony cho phép người dùng hoặc hệ thống bên ngoài cung cấp JSONPath có thể bị suy giảm tính sẵn sàng khi các request buộc worker thực hiện regular expression có chi phí backtracking rất lớn. Một request có thể giữ CPU worker trong thời gian dài, còn nhiều request đồng thời có thể làm cạn worker pool, tăng độ trễ hoặc làm request thất bại. Điều này có thể ảnh hưởng đến API, web application hoặc dịch vụ xử lý console nếu chúng dùng cùng component và cùng dữ liệu đầu vào có thể bị kiểm soát. Bản ghi không thiết lập việc lộ dữ liệu hoặc sửa đổi dữ liệu; hậu quả được mô tả chủ yếu là trên tính sẵn sàng.

1. Nâng symfony/json-path hoặc bộ symfony/symfony lên đúng bản vá của nhánh đang sử dụng: 7.4.12 cho nhánh bị ảnh hưởng bắt đầu từ 7.3.0-BETA1, hoặc 8.0.12 cho nhánh bị ảnh hưởng bắt đầu từ 8.0.0-BETA1.
2. Sau khi cập nhật, xác nhận dependency thực tế trong composer.lock và thư mục vendor đã trỏ tới bản vá, rồi triển khai lại toàn bộ worker xử lý request để không còn tiến trình cũ trong bộ nhớ.
3. Nếu đang dùng dòng 8.1.x, xác minh build cụ thể với hướng dẫn của Symfony trước khi kết luận đã được bảo vệ, vì advisory được kiểm tra ở đây không nêu đầy đủ ranh giới của dòng này.
4. Nếu chưa thể cập nhật, hạn chế hoặc loại bỏ khả năng để dữ liệu không tin cậy cung cấp JSONPath cho JsonCrawler, đặc biệt với các filter match() và search(). Đây là biện pháp giảm thiểu theo điều kiện sử dụng, không thay thế bản vá.

• Kiểm kê dependency từ composer.lock, thư mục vendor và hệ thống build để xác định việc sử dụng symfony/json-path hoặc bộ package symfony/symfony trong các nhánh bị ảnh hưởng.
• Kiểm tra mã nguồn và luồng dữ liệu xem JsonCrawler có nhận JSONPath từ query parameter, request body, trường API hoặc nguồn dữ liệu do người dùng kiểm soát hay không.
• Tập trung rà soát các lời gọi liên quan đến filter match() và search(), đặc biệt khi pattern được truyền tiếp vào quá trình tìm kiếm trên tài liệu JSON.
• Theo dõi CPU worker, thời gian xử lý request, worker pool bị cạn và lượng request chờ như biện pháp giám sát bổ sung. Đây là dấu hiệu vận hành có thể phù hợp với tình trạng bị khai thác, không phải IOC đã được xác nhận.
• Không coi việc thiếu lỗi PCRE hoặc thiếu log là bằng chứng an toàn, vì toán tử @ có thể che giấu lỗi backtrack-limit.