Một lỗ hổng bảo mật được phát hiện gần đây trong Helm , trình quản lý gói phổ biến của Kubernetes , đã gây ra cuộc thảo luận sôi nổi trong cộng đồng nhà phát triển về tính thực tiễn của cuộc tấn công và những tác động bảo mật rộng lớn hơn. Lỗ hổng này, đã được vá trong Helm v3.18.4 , cho phép kẻ tấn công thực thi mã tùy ý bằng cách kết hợp các tệp Chart.yaml được chế tạo đặc biệt với các tệp Chart.lock được liên kết symlink.
Các Bước Khắc Phục:
- Cập nhật lên Helm v3.18.4 hoặc phiên bản mới hơn
- Xác minh các tệp Chart.lock không phải là symlink trước khi cập nhật dependencies
- Xem xét các chart từ nguồn không đáng tin cậy để tìm các symlink đáng ngờ
Cách thức hoạt động của cuộc tấn công
Lỗ hổng này khai thác quy trình cập nhật phụ thuộc của Helm theo cách khéo léo nhưng phức tạp. Khi kẻ tấn công tạo ra một tệp Chart.yaml độc hại chứa mã thực thi và thay thế tệp Chart.lock bằng một symlink trỏ đến các tệp hệ thống nhạy cảm như .bashrc hoặc các script khởi động shell, việc chạy helm dependency update sẽ ghi nội dung độc hại vào tệp được nhắm mục tiêu. Mã này sau đó sẽ thực thi khi nạn nhân mở shell tiếp theo hoặc chạy script được nhắm mục tiêu.
Cộng đồng đã tranh luận về những tác động thực tiễn của vector tấn công này. Nhiều nhà phát triển đặt câu hỏi về các tình huống thực tế mà lỗ hổng này có thể bị khai thác, vì nó đòi hỏi kẻ tấn công phải có một mức độ truy cập hệ thống tệp nhất định để tạo symlink ngay từ đầu.
Yêu cầu lỗ hổng bảo mật:
- Tệp Chart.yaml độc hại có chứa nội dung thực thi
- Tệp Chart.lock được thay thế bằng symlink đến tệp hệ thống (ví dụ: .bashrc)
- Nạn nhân chạy cập nhật phụ thuộc trên chart độc hại
- Tệp được nhắm mục tiêu phải được thực thi sau đó để mã có thể chạy
Đặt câu hỏi về kịch bản tấn công
Một phần đáng kể của cuộc thảo luận tập trung vào tính thực tiễn của lỗ hổng này. Các nhà phát triển bối rối về những tình huống hợp pháp mà kẻ tấn công có thể tạo symlink nhưng không thể trực tiếp sửa đổi các tệp hệ thống. Cuộc tấn công đòi hỏi nạn nhân phải chạy cập nhật phụ thuộc trên một chart chứa cả nội dung độc hại và symlink có sẵn, khiến một số người tự hỏi liệu điều này có thể hiện mối lo ngại bảo mật thực sự hay chỉ là một trường hợp đặc biệt với tác động thực tế hạn chế.
Sự nhầm lẫn một phần xuất phát từ mô hình phân phối của Helm . Các chart thường được chia sẻ dưới dạng gói, và việc bao gồm các symlink trỏ đến các tệp hệ thống sẽ làm cho các chart không thể sử dụng được trên các máy khác. Điều này đặt ra câu hỏi về cách các chart độc hại như vậy thực sự có thể tiếp cận nạn nhân trong thực tế.
Vấn đề Symlink rộng lớn hơn
Lỗ hổng này làm nổi bật một vấn đề lâu dài hơn với cách xử lý symlink của Helm . Cuộc thảo luận cộng đồng tiết lộ rằng Helm đã vật lộn với bảo mật symlink trong nhiều năm, trước đây đã giải quyết những lo ngại tương tự vào năm 2019. Bản sửa lỗi hiện tại nhắm mục tiêu cụ thể vào các tệp Chart.lock, nhưng các nhà phát triển đang đặt câu hỏi liệu một cách tiếp cận toàn diện hơn - chẳng hạn như cấm tất cả các symlink bên ngoài trong các chart được phân phối - có thể cần thiết hay không.
Một chart không thể chứa bất kỳ symlink nào bên ngoài thư mục gốc của nó đề xuất một thành viên cộng đồng, đề xuất một cách tiếp cận hạn chế hơn sẽ ngăn chặn các vấn đề tương tự trên tất cả các thành phần chart.
Các lệnh Helm bị ảnh hưởng:
helm dependency update- Vector tấn công chínhhelm dependency build- Có thể ghi các tệp khóa khi không tồn tại- Helm SDK downloader Manager - Ảnh hưởng đến việc sử dụng theo chương trình
Phản hồi cộng đồng và bài học kinh nghiệm
Lỗ hổng này cũng đã kích hoạt các cuộc thảo luận rộng lớn hơn về định dạng tệp cấu hình và thực tiễn bảo mật. Trong khi một số nhà phát triển chỉ trích YAML là có vấn đề về bản chất, những người khác chỉ ra rằng vấn đề cụ thể này xuất phát từ logic của Helm chứ không phải từ chính YAML . Cuộc tranh luận phản ánh những căng thẳng đang diễn ra trong cộng đồng phát triển về việc cân bằng giữa khả năng sử dụng và bảo mật.
Bản sửa lỗi được triển khai trong Helm v3.18.4 ngăn chặn việc ghi vào các tệp Chart.lock được liên kết symlink, mặc dù một số nhà phát triển tranh luận về các biện pháp bảo vệ toàn diện hơn. Hiện tại, người dùng có thể tự bảo vệ mình bằng cách đảm bảo các tệp Chart.lock không phải là symlink trước khi cập nhật phụ thuộc, mặc dù rủi ro thực tế đối với hầu hết người dùng có vẻ hạn chế do các điều kiện cụ thể cần thiết để khai thác.
Tham khảo: Chart Dependency Updating With Malicious Chart.yaml Content And Symlink