Được biết đến gần đây thông qua một bài đăng trên blog, kết quả của các công cụ kiểm tra để xác định các lỗ hổng không có bản vá và xác định các vấn đề bảo mật trong hình ảnh vùng chứa Docker bị cô lập.
Thử nghiệm cho thấy 4 trong số 6 máy quét hình ảnh Docker đã biết có lỗ hổng nghiêm trọng cho phép tấn công chính máy quét và chạy mã của nó trên hệ thống, trong một số trường hợp (sử dụng Snyk chẳng hạn) với đặc quyền root.
Đối với một cuộc tấn công, kẻ tấn công chỉ cần bắt đầu kiểm tra Dockerfile của mình hoặc manifest.json, bao gồm siêu dữ liệu được định dạng đặc biệt, hoặc đặt tệp podfile và gradlew bên trong hình ảnh.
Chúng tôi quản lý để chuẩn bị các nguyên mẫu khai thác cho WhiteSource, Snyk, Fossa và các hệ thống neo.
Elququete Claire, ban đầu được viết với tâm trí an toàn, cho thấy sự bảo mật tốt nhất.
Không có vấn đề nào được xác định trong gói Trivy và kết quả là, người ta kết luận rằng máy quét vùng chứa Docker nên được chạy trong môi trường biệt lập hoặc chỉ được sử dụng để xác minh hình ảnh của chính chúng và cũng nên cẩn thận khi kết nối các công cụ đó với hệ thống tích hợp liên tục tự động.
Những máy quét này làm những việc phức tạp và dễ xảy ra lỗi. Họ đang xử lý docker, giải nén các lớp / tệp, tương tác với trình quản lý gói hoặc phân tích các định dạng khác nhau. Bảo vệ chúng, trong khi cố gắng đáp ứng tất cả các trường hợp sử dụng cho các nhà phát triển, là rất khó. Hãy xem cách các công cụ khác nhau cố gắng và quản lý để làm điều đó:
Điểm tiết lộ có trách nhiệm phản ánh quan điểm cá nhân của tôi: Tôi nghĩ rằng điều quan trọng là các nhà cung cấp phần mềm phải đáp ứng các vấn đề bảo mật được báo cáo cho họ, trung thực và minh bạch về các lỗ hổng, để đảm bảo rằng những người sử dụng sản phẩm của họ được thông báo hợp lệ để quyết định về bản cập nhật. Điều này bao gồm thông tin quan trọng nhất mà bản cập nhật có các thay đổi liên quan đến bảo mật, mở CVE để theo dõi và thông báo về sự cố, đồng thời có khả năng thông báo cho khách hàng của bạn. Tôi nghĩ rằng điều này đặc biệt hợp lý để giả định nếu sản phẩm là về CVE, cung cấp thông tin về các lỗ hổng trong phần mềm. Ngoài ra, tôi cũng yên tâm bởi phản ứng nhanh chóng, thời gian sửa chữa hợp lý và giao tiếp cởi mở với người báo cáo vụ tấn công.
Tại FOSSA, Snyk và WhiteSource, lỗ hổng bảo mật có liên quan với cuộc gọi cho người quản lý gói bên ngoài để xác định các yếu tố phụ thuộc và cho phép bạn tổ chức việc thực thi mã của mình bằng cách chỉ định các lệnh hệ thống và cảm ứng trong tệp gradlew và Podfile.
En Snyk và WhiteSource cũng tìm thấy một lỗ hổng, liên quan đến các lệnh hệ thống khởi chạy tổ chức phân tích cú pháp Dockerfile (ví dụ: trong Snyk thông qua Dockefile, bạn có thể thay thế tiện ích ls (/ bin / ls), do trình quét gây ra và trong WhiteSurce, bạn có thể thay thế mã thông qua các đối số ở dạng "echo"; chạm / tmp / hacked_whitesource_pip; = 1.0 '«).
Trong Anchore, lỗ hổng bảo mật là do sử dụng tiện ích skopeo để làm việc với hình ảnh docker. Thao tác đã được giảm xuống để thêm các tham số có dạng '»os»: «$ (touch hacked_anchore)»' vào tệp manifest.json, được thay thế khi gọi skopeo mà không có lối thoát thích hợp (chỉ các ký tự «; & <bị xóa > ", Nhưng cấu trúc" $ () ").
Cùng tác giả đã thực hiện một nghiên cứu về hiệu quả của việc phát hiện lỗ hổng không vá qua máy quét bảo mật của bộ chứa docker và mức độ dương tính giả.
Ngoài tác giả lập luận rằng một số công cụ này trực tiếp sử dụng trình quản lý gói để giải quyết các phụ thuộc. Điều này khiến chúng trở nên đặc biệt khó bảo vệ. Một số trình quản lý phụ thuộc có tệp cấu hình cho phép bao gồm mã shell.
Ngay cả khi những cách đơn giản này được xử lý bằng cách nào đó, việc gọi những người quản lý gói này chắc chắn sẽ đồng nghĩa với việc tiêu tiền. Điều này, nói một cách nhẹ nhàng, không tạo điều kiện cho việc bảo vệ ứng dụng.
Kết quả kiểm tra 73 hình ảnh có lỗ hổng đã biết, cũng như đánh giá hiệu quả để xác định sự hiện diện của các ứng dụng điển hình trong hình ảnh (nginx, tomcat, haproxy, gunicorn, redis, ruby, node), có thể được tư vấn trong ấn phẩm được thực hiện Trong liên kết sau đây.