NestJS @nestjs/microservices bị dừng tiến trình từ xa bởi message pattern lồng quá sâu

Nest là một framework để xây dựng các ứng dụng server-side Node.js có khả năng mở rộng. Trước các phiên bản 11.2.4 và 12.0.2, một message duy nhất có object lồng sâu trong pattern có thể làm một microservice NestJS sử dụng transport TCP hoặc RabbitMQ bị dừng. ServerTCP#handleMessage và ServerRMQ#handleMessage truyền một pattern không phải chuỗi do client kiểm soát vào JSON.stringify để tạo khóa tra cứu handler; mức lồng đủ sâu sẽ ném RangeError: Maximum call stack size exceeded, và unhandled promise rejection không được xử lý sẽ làm Node.js kết thúc theo hành vi mặc định. Kẻ tấn công có thể truy cập cổng TCP hoặc publish vào queue hay exchange mà dịch vụ consume để làm service crash theo yêu cầu; các transport khác không bị ảnh hưởng vì pattern của chúng đến dưới dạng chuỗi. Vấn đề này được khắc phục trong các phiên bản 11.2.4 và 12.0.2.

• Package bị ảnh hưởng là @nestjs/microservices trong Nest:
• < 11.2.4: bị ảnh hưởng; 11.2.4 là phiên bản được xác định đã khắc phục cho nhánh này.
• >= 12.0.0, < 12.0.2: bị ảnh hưởng; 12.0.2 là phiên bản được xác định đã khắc phục cho nhánh này.
• Đường xử lý bị ảnh hưởng là TCP và RabbitMQ transport, cụ thể tại ServerTCP#handleMessage và ServerRMQ#handleMessage.
• Các transport khác không bị ảnh hưởng theo advisory vì pattern của chúng đến dưới dạng chuỗi.
• Không nên suy luận trạng thái của các nhánh song song hoặc phiên bản nằm ngoài các khoảng trên nếu chưa được đối chiếu riêng.

NestJS @nestjs/microservices xử lý message pattern trong ServerTCP#handleMessage và ServerRMQ#handleMessage. Với pattern không phải chuỗi do client kiểm soát, mã dễ bị ảnh hưởng truyền giá trị này vào JSON.stringify để tạo khóa tra cứu handler. Object lồng đủ sâu khiến quá trình serialize đệ quy ném RangeError: Maximum call stack size exceeded; promise rejection phát sinh từ handleMessage không được xử lý và làm tiến trình Node.js kết thúc theo hành vi mặc định. Điều kiện khai thác là kẻ tấn công phải gửi message đến TCP transport hoặc publish message vào queue hay exchange mà dịch vụ RabbitMQ consume. TCP không yêu cầu xác thực theo mặc định, trong khi RabbitMQ vẫn yêu cầu quyền hoặc khả năng publish phù hợp với triển khai. Các transport khác không thuộc đường xử lý này vì pattern của chúng đến dưới dạng chuỗi; bằng chứng hiện có cũng không xác định một ngưỡng nesting an toàn chung cho mọi runtime và hình dạng object.

Lỗi có thể bị khai thác qua mạng và không cần user interaction. Theo bản ghi chuẩn hóa, attack complexity thấp và không yêu cầu privilege; advisory của maintainer nêu rằng TCP transport mặc định không có authentication, còn RabbitMQ yêu cầu khả năng publish vào queue hoặc exchange được dịch vụ consume. Advisory cũng công bố proof of concept và mô tả rằng một message có thể làm service crash, sau đó lặp lại việc này. Bản ghi hiện có xác nhận public exploit nhưng không xác lập tình trạng khai thác trong thực tế, campaign cụ thể hoặc IOC.

Kết quả kỹ thuật là tiến trình microservice có thể bị kết thúc từ xa, gây gián đoạn tính sẵn sàng thay vì truy cập dữ liệu hoặc sửa đổi dữ liệu. Bản ghi mô tả đường tấn công qua mạng, không cần user interaction và không cần authentication bổ sung đối với TCP transport khi vẫn giữ cấu hình mặc định. Với RabbitMQ, kẻ tấn công phải có khả năng publish đến queue hoặc exchange mà dịch vụ consume. Phạm vi ảnh hưởng bị giới hạn ở các microservice dùng TCP hoặc RabbitMQ và process xử lý chúng; các transport khác không đi qua cùng logic serialize pattern. Hậu quả tổ chức có thể gồm request failure, restart workload và message không được xử lý trong thời gian service dừng. Bằng chứng hiện có không xác định tác động đến confidentiality hoặc integrity.

Tác động được xác nhận chủ yếu là mất tính sẵn sàng của microservice: một message bất thường có thể làm process dừng và điều kiện này có thể lặp lại. Hệ thống có thể phải restart hoặc được orchestration khởi động lại, trong thời gian đó các request và message do process xử lý có thể bị gián đoạn. Với RabbitMQ, message gây lỗi không được xử lý thành công trong phiên bản bị ảnh hưởng. Bản ghi không xác định tác động đến tính bí mật hoặc tính toàn vẹn của dữ liệu. Mức độ gián đoạn cụ thể phụ thuộc vào cơ chế health check, restart và phân phối tải của từng triển khai.

1. Nâng cấp @nestjs/microservices lên đúng bản đã được xác nhận cho nhánh đang dùng: 11.2.4 đối với nhánh bị ảnh hưởng dưới 11.2.4, hoặc 12.0.2 đối với nhánh >= 12.0.0, < 12.0.2.
2. Nếu chưa thể nâng cấp, giới hạn quyền truy cập mạng đến TCP transport và giới hạn đường publish đến RabbitMQ queue hoặc exchange để chỉ các peer tin cậy có thể gửi message.
3. Biện pháp tạm thời được advisory nêu là chạy Node.js với --unhandled-rejections=warn để tránh process crash. Cách này vẫn để message không được xử lý và không thay thế cho việc cập nhật bản sửa lỗi.
4. Sau khi thay đổi, xác minh dependency thực tế được nạp ở phiên bản đã chọn và rà soát lại phạm vi exposure của các TCP port, queue và exchange liên quan.

1. Kiểm kê dependency @nestjs/microservices trong từng ứng dụng NestJS và đối chiếu với các khoảng phiên bản bị ảnh hưởng trong affected_summary.
2. Xác định ứng dụng nào thực sự bật TCP transport hoặc RabbitMQ transport, sau đó kiểm tra TCP port có thể truy cập từ mạng nào và principal nào có thể publish vào queue hoặc exchange liên quan.
3. Rà soát log ứng dụng, process supervisor và hệ thống orchestration để tìm RangeError: Maximum call stack size exceeded, unhandled promise rejection hoặc các lần process thoát bất thường xảy ra khi nhận message.
4. Đối với RabbitMQ, xem xét các sự kiện consumer hoặc message failure gần thời điểm process restart như một biện pháp cảnh báo bổ sung, không coi đó là IOC đặc hiệu đã được xác nhận.
5. Việc không thấy lỗi trong log không chứng minh hệ thống an toàn; kiểm tra version và transport là các phép kiểm chính.