Một lỗ hổng bảo mật mới được phát hiện trong Redis đã châm ngòi cho những cuộc thảo luận sôi nổi trong cộng đồng an ninh mạng, không chỉ vì tác động kỹ thuật của nó, mà còn vì điểm CVSS hoàn hảo 10.0 gây tranh cãi mà nó nhận được. Lỗ hổng này, được đặt tên là RediShell và theo dõi với mã CVE-2025-49844, khai thác một lỗi use-after-free 12 năm tuổi trong công cụ scripting Lua của Redis để thực hiện remote code execution. Trong khi Wiz Research đã gán cho nó mức độ nghiêm trọng cao nhất có thể, nhiều chuyên gia bảo mật đang đặt câu hỏi liệu điểm số này có phản ánh chính xác mối đe dọa trong thế giới thực hay không.
Chi tiết lỗ hổng bảo mật
- CVE ID: CVE-2025-49844
- Điểm CVSS: 10.0 (Nghiêm trọng)
- Vector tấn công: Script Lua độc hại thông qua mạng
- Điều kiện tiên quyết: Quyền truy cập sau xác thực
- Tác động: Thực thi mã từ xa, thoát khỏi sandbox
- Thành phần bị ảnh hưởng: Công cụ scripting Lua
Tranh Cãi Về Điểm Số CVSS
Cuộc tranh luận sôi nổi nhất tập trung vào việc liệu một lỗ hổng post-authentication có xứng đáng với điểm CVSS tối đa 10.0 hay không. Các chuyên gia bảo mật chỉ ra rằng xếp hạng này đặt lỗi Redis cùng hàng với những lỗ hổng nghiêm trọng nhất từng được phát hiện, bên cạnh những mối đe dọa hoàn toàn không yêu cầu xác thực. Những người chỉ trích cho rằng các lỗ hổng nổi tiếng như Shellshock, nhận được điểm 9.5 và có tác động rộng lớn hơn nhiều, cho thấy sự không nhất quán trong việc chấm điểm CVSS.
Tranh cãi này làm nổi bật một vấn đề cơ bản với chính hệ thống CVSS. Nhiều chuyên gia coi nó như một công cụ marketing hơn là một đánh giá kỹ thuật đáng tin cậy. Việc chấm điểm dường như ưu tiên tác động tối đa về mặt lý thuyết hơn là các kịch bản khai thác thực tế, dẫn đến những xếp hạng thổi phồng không phù hợp với rủi ro thực tế.
Tác Động Thực Tế Hạn Chế
Bất chấp những tiêu đề báo động, mối đe dọa thực tế từ lỗ hổng này có vẻ hạn chế hơn so với điểm số hoàn hảo đề xuất. Việc khai thác yêu cầu kẻ tấn công gửi các script Lua độc hại đến một instance Redis, có nghĩa là họ đã cần một mức độ truy cập nào đó vào hệ thống. Hầu hết các triển khai có ý thức bảo mật sử dụng Redis cho các script đáng tin cậy do developer viết thay vì cho phép thực thi code tùy ý của người dùng.
Lỗ hổng về cơ bản cho phép kẻ tấn công thoát khỏi Lua sandbox của Redis, nhưng điều này giả định rằng các tổ chức đang dựa vào sandbox đó để bảo mật ngay từ đầu. Trên thực tế, rất ít triển khai Redis cho phép người dùng không đáng tin cậy upload và thực thi code Lua tùy ý, khiến tác động của lỗ hổng mang tính lý thuyết hơn là thực tế đối với hầu hết các cài đặt.
Lua sandbox: Một tính năng bảo mật hạn chế những gì các script Lua có thể làm, ngăn chúng truy cập tài nguyên hệ thống hoặc thực hiện các hoạt động có hại.
Các Mức Độ Đánh Giá Rủi Ro
- Rủi Ro Nghiêm Trọng: Các phiên bản được tiếp xúc với Internet + không có xác thực
- Rủi Ro Cao: Tiếp xúc mạng nội bộ mà không có xác thực
- Rủi Ro Thấp Hơn: Các phiên bản được bảo mật đúng cách với xác thực và kiểm soát mạng
- Rủi Ro Tối Thiểu: Các triển khai không sử dụng các script Lua do người dùng gửi
 |
|---|
| Một sơ đồ mạng minh họa lỗ hổng của máy chủ Redis trong cơ sở hạ tầng mạng |
Mối Quan Ngại Về Phơi Bày Rộng Rãi
Trong khi bản thân lỗ hổng có thể có tác động thực tế hạn chế, nghiên cứu đã tiết lộ những thống kê đáng lo ngại về thực tiễn triển khai Redis. Khoảng 330.000 instance Redis được phơi bày ra internet, với khoảng 60.000 thiếu bất kỳ xác thực nào. Những con số này làm nổi bật một vấn đề bảo mật rộng lớn hơn ngoài lỗ hổng cụ thể này.
Vấn đề một phần xuất phát từ cấu hình mặc định và những sai lầm triển khai phổ biến. Nhiều tutorial Docker và thiết lập container bind các service với tất cả network interface thay vì giới hạn chúng ở localhost, vô tình phơi bày database ra internet công cộng. Điều này tạo ra một cơn bão hoàn hảo nơi một lỗ hổng post-authentication trở nên có thể khai thác mà không cần xác thực.
Thống kê về việc lộ Redis
- Tổng số instance bị lộ trên internet: ~330,000
- Các instance không có xác thực: ~60,000
- Môi trường cloud sử dụng container Redis : 57%
- Tuổi của lỗ hổng: ~12 năm (lỗi use-after-free)
 |
|---|
| Biểu đồ tròn hiển thị tỷ lệ phần trăm các môi trường cloud có khả năng bị ảnh hưởng bởi lỗ hổng Redis |
Bức Tranh Tổng Thể
Tranh cãi này phản ánh những vấn đề sâu xa hơn trong cách ngành an ninh mạng truyền đạt rủi ro. Trong khi nghiên cứu kỹ thuật đằng sau việc phát hiện CVE-2025-49844 có vẻ vững chắc, việc chấm điểm và đặt tên giật gân (RediShell) có thể không phục vụ lợi ích tốt nhất của cộng đồng. Sự ngắt kết nối giữa mức độ nghiêm trọng lý thuyết và tác động thực tế có thể dẫn đến phân bổ tài nguyên sai lệch và mệt mỏi bảo mật.
Các lỗi nhận được bất kỳ điểm CVSS nào mà đội marketing của phòng thí nghiệm nghiên cứu phát hiện muốn chúng có. Nó thực sự giống như một bảng Ouija.
Lỗ hổng Redis cũng chứng minh cách các môi trường cloud hiện đại phụ thuộc nhiều vào các công nghệ mã nguồn mở. Trong khi sự phụ thuộc này tạo ra những rủi ro chung, nó cũng cho phép các nỗ lực bảo mật hợp tác như sáng kiến ZeroDayCloud được các nhà nghiên cứu đề cập.
Các tổ chức sử dụng Redis chắc chắn nên áp dụng các bản vá có sẵn, đặc biệt là cho các instance phơi bày ra internet. Tuy nhiên, thảo luận cộng đồng cho thấy rằng các thực tiễn triển khai phù hợp và kiểm soát bảo mật mạng vẫn quan trọng hơn việc vội vã giải quyết mọi lỗ hổng có điểm CVSS hoàn hảo. Bài học thực sự có thể là về việc cải thiện cấu hình mặc định và hướng dẫn triển khai thay vì coi mọi lỗ hổng có điểm số cao như một mối đe dọa tận thế.
Tham khảo: RediShell: Critical Remote Code Execution Vulnerability (CVE-2025-49844) in Redis, 10 CVSS score