Lỗi đi theo liên kết trong moby/go-archive cho phép ghi ra ngoài thư mục giải nén

Các routine giải nén tar trong moby/go-archive (Unpack, UnpackLayer, Untar/UntarUncompressed, và các helper ApplyLayer) không giới hạn các thao tác filesystem trong thư mục đích. Bộ giải nén quyết định vị trí của từng entry trong archive bằng các kiểm tra chuỗi mang tính từ vựng, sau đó thực hiện thao tác filesystem trên một đường dẫn được hệ điều hành resolve, vì vậy các link do archive tạo ra có thể bị đi theo để thoát ra ngoài thư mục đích. Attacker kiểm soát nội dung archive có thể tạo hoặc ghi đè các tệp tại những đường dẫn tùy ý mà tiến trình giải nén có quyền ghi.

• github.com/moby/go-archive: affected với phiên bản < 0.3.0; phiên bản 0.3.0 là bản đã được vá.
• Docker Sandboxes: affected với phiên bản < 0.38.0; release 0.38.0 chứa bản sửa cho luồng copy-out bị ảnh hưởng.
• Docker Desktop: affected với phiên bản < 4.86.0; release 4.86.0 sửa lỗi destination escape trong docker container cp.
• Docker Engine: affected với phiên bản < 29.7.0; release 29.7.0 cập nhật github.com/moby/go-archive lên 0.3.0.
• Docker CLI: affected với phiên bản < 29.7.0; cần kiểm tra và cập nhật CLI theo boundary tương ứng.
• Docker Compose: affected với phiên bản < 5.4.0; 5.4.0 là fixed boundary được cung cấp trong bản ghi.
• Microsoft Azure Linux 3.0 có các boundary package riêng: moby-engine trước 0:25.0.3-20.azl3 và docker-cli trước 0:25.0.7-5.azl3 được liệt kê là affected; các package boundary tương ứng là 0:25.0.3-20.azl3 và 0:25.0.7-5.azl3.

Các package được distro backport hoặc bundle trong sản phẩm khác phải được đối chiếu với advisory của vendor tương ứng. Không nên suy luận rằng một nhánh song song hoặc một bản package downstream đã an toàn chỉ vì một nhánh upstream khác đã được vá.

moby/go-archive xử lý nội dung tar do bên ngoài cung cấp thông qua các routine Unpack, UnpackLayer, Untar, UntarUncompressed và các helper ApplyLayer.

1. Bộ giải nén dùng các kiểm tra chuỗi mang tính từ vựng để quyết định mỗi entry của archive sẽ nằm ở đâu.
2. Sau đó, thao tác filesystem được thực hiện trên đường dẫn do hệ điều hành resolve. Nếu archive đã tạo một symbolic link hoặc loại link tương tự trong cây đích, thao tác tiếp theo có thể bị đi theo link và thoát ra ngoài thư mục đích.
3. Kết quả là tiến trình giải nén có thể tạo hoặc ghi đè tệp tại các đường dẫn tùy ý mà nó có quyền ghi.

Đây là lỗi link following, thuộc CWE-59, đồng thời có đặc điểm của việc giới hạn pathname không đúng cách. Điều kiện khai thác là attacker phải kiểm soát nội dung archive và archive đó phải được đưa vào một luồng giải nén bị ảnh hưởng. Bản ghi hiện không xác định syscall filesystem cụ thể được dùng trong từng routine hoặc mọi khác biệt theo nền tảng.

Đánh giá được cung cấp mô tả đây là lỗi có thể tiếp cận cục bộ, độ phức tạp thấp, không yêu cầu quyền trước đó nhưng cần người dùng hoặc quy trình chủ động thực hiện thao tác giải nén. Attacker phải cung cấp archive được tạo đặc biệt cho một routine hoặc sản phẩm đang dùng logic vulnerable.

Một public proof of concept đã được công bố, trong đó mô tả việc lạm dụng luồng copy-out của Docker để gây ghi tệp trên máy chạy Docker trong các kịch bản thử nghiệm. Điều này xác nhận khả năng tạo PoC công khai, nhưng tình trạng khai thác thực tế ngoài môi trường thử nghiệm không được xác lập trong bằng chứng hiện có. Đây không phải là lỗi được mô tả như một network service có thể khai thác trực tiếp từ xa.

Kết quả kỹ thuật được xác nhận là tiến trình giải nén có thể tạo hoặc ghi đè tệp ở đường dẫn tùy ý mà tiến trình đó có quyền ghi, thay vì chỉ thao tác trong thư mục đích. Điều này tạo ra mất tính toàn vẹn trực tiếp và có thể gây mất tính sẵn sàng nếu tệp dịch vụ hoặc dữ liệu bị thay thế.

Mất tính bí mật, thay đổi đặc quyền hoặc code execution có thể xảy ra tùy vào tệp bị tác động, quyền của tiến trình và cách hệ thống sử dụng tệp sau đó; các hậu quả này không tự động xảy ra trong mọi môi trường. Nếu extraction chạy với quyền host cao, phạm vi file có thể rộng hơn đáng kể so với một job chạy dưới tài khoản hạn chế. Nếu tiến trình không có quyền ghi vào mục tiêu, thao tác sẽ bị giới hạn bởi quyền filesystem đó.

Lỗi có thể làm mất tính toàn vẹn của các tệp nằm trong phạm vi quyền ghi của tiến trình giải nén, kể cả tệp ở ngoài thư mục mà người vận hành nghĩ rằng archive sẽ sử dụng. Nếu tiến trình chạy với quyền cao, tác động có thể mở rộng tới file cấu hình, executable hoặc dữ liệu của dịch vụ, và có thể gây gián đoạn hoặc thay đổi hành vi hệ thống.

Tác động thực tế bị giới hạn bởi quyền của tiến trình thực hiện extraction và bởi việc attacker có thể đưa archive vào workflow hay không. Một file bị ghi đè có thể dẫn đến code execution hoặc persistence nếu file đó về sau được hệ thống hoặc dịch vụ tin cậy thực thi, nhưng đây là hậu quả phụ thuộc môi trường chứ không phải kết quả được đảm bảo trong mọi triển khai. Bằng chứng hiện có không nêu breach, nạn nhân hoặc chiến dịch cụ thể.

1. Ưu tiên nâng github.com/moby/go-archive lên 0.3.0 hoặc bản vá tương ứng do vendor phân phối. Với các sản phẩm Docker, nâng Docker Sandboxes lên 0.38.0, Docker Desktop lên 4.86.0, Docker Engine và Docker CLI lên 29.7.0, hoặc Docker Compose lên 5.4.0 theo đúng sản phẩm đang triển khai.
2. Đối với Azure Linux 3.0, áp dụng package update của Microsoft cho moby-engine tới 0:25.0.3-20.azl3 và docker-cli tới 0:25.0.7-5.azl3, hoặc bản vendor update tương ứng đã xác nhận là fixed.
3. Nếu chưa thể cập nhật ngay, chỉ giải nén archive đáng tin cậy. Đây là workaround được advisory nêu, không phải bản sửa triệt để và không loại bỏ rủi ro khi nguồn archive bị kiểm soát.
4. Rebuild hoặc redeploy các ứng dụng bundle trực tiếp thư viện vulnerable, đồng thời kiểm tra image, binary và artifact CI có mang theo bản cũ hay không.
5. Kiểm tra lại từng release branch và package downstream riêng biệt sau khi cập nhật. Một fixed boundary của Docker Desktop, Engine, CLI, Compose hoặc một distro package không chứng minh rằng mọi sản phẩm hay nhánh song song khác đã an toàn.

1. Kiểm kê dependency trực tiếp và transitive để tìm github.com/moby/go-archive trong ứng dụng Go, image build system và các binary liên quan đến Docker.
2. Đối chiếu phiên bản Docker Engine, Docker CLI, Docker Desktop, Docker Compose và Docker Sandboxes với các nhánh bị ảnh hưởng trong mục affected_summary. Với package do distro cung cấp, kiểm tra trạng thái bản vá của chính vendor thay vì chỉ suy ra từ phiên bản upstream.
3. Xác định các workflow nhận tar archive từ người dùng, container, registry, CI job hoặc nguồn không hoàn toàn đáng tin cậy, đặc biệt những workflow gọi các routine giải nén nêu trên hoặc sử dụng docker container cp.
4. Rà soát file integrity, quyền sở hữu và thay đổi bất ngờ đối với các đường dẫn nằm ngoài thư mục đích sau khi có hoạt động giải nén. Đây là biện pháp giám sát phòng ngừa, không phải IOC đã được xác nhận.
5. Thử nghiệm việc giải nén trong môi trường cô lập và kiểm tra rằng thao tác bị giới hạn trong thư mục đích sau khi nâng cấp. Không nên coi việc không thấy log hoặc thay đổi bất thường là bằng chứng hệ thống an toàn.