Path traversal cho phép đọc tệp tùy ý không cần xác thực trong GitLab CE/EE

GitLab đã khắc phục một vấn đề trong GitLab CE/EE ảnh hưởng đến mọi phiên bản từ 18.7 đến trước 18.11.12, 19.0 đến trước 19.0.9, 19.1 đến trước 19.1.8, 19.2 đến trước 19.2.6 và 19.3 đến trước 19.3.2; trong một số điều kiện, người dùng chưa xác thực có thể đọc các tệp tùy ý từ máy chủ GitLab do việc giới hạn đường dẫn không đúng cách và thiếu cơ chế thực thi xác thực trong repository commits API.

GitLab CE/EE được xác định bị ảnh hưởng trong các nhánh sau:

• Nhánh 18.7: mọi phiên bản từ 18.7 đến trước 18.11.12.
• Nhánh 19.0: mọi phiên bản trước 19.0.9.
• Nhánh 19.1: mọi phiên bản trước 19.1.8.
• Nhánh 19.2: mọi phiên bản trước 19.2.6.
• Nhánh 19.3: mọi phiên bản trước 19.3.2.

GitLab.com và GitLab Dedicated được GitLab xác nhận là đã được vá. Chỉ các phạm vi trên được xác định là bị ảnh hưởng trong evidence hiện có; các deployment tự quản lý vẫn cần được đối chiếu với nhánh thực tế và trạng thái patch.

GitLab CE/EE có các tham số đường dẫn do phía gửi request kiểm soát trong repository commits API, gắn với dữ liệu upload. Lỗi đã được xác nhận là CWE-22: việc giới hạn đường dẫn không đủ chặt và cơ chế thực thi xác thực bị thiếu trên đường xử lý dễ bị lỗi, vì vậy người gọi chưa xác thực có thể khiến Rails mở một đường dẫn trên máy chủ thay cho tệp upload hoặc metadata tạm thời dự kiến. Tài liệu kỹ thuật của GitLab xác định file.path là tham số chính và metadata.path là tham số cùng nhóm trong multipart request; cùng primitive này cũng có thể được tiếp cận qua repository files API. Điểm vào mạng chính là POST /api/v4/projects/:id/repository/commits, và việc khai thác không nhất thiết phải dùng multipart body vì endpoint có thể được tiếp cận bằng body application/x-www-form-urlencoded. Việc máy chủ đọc tệp và việc nội dung tệp được tiết lộ là hai sự kiện khác nhau: máy chủ đọc đường dẫn được chọn, nhưng dữ liệu chỉ đến được client khi quá trình percent-decoding của request parser phát sinh lỗi và thông báo lỗi chứa một phần nội dung. Chi tiết chính xác của thay đổi trong mã nguồn và toàn bộ điều kiện quyết định byte nào được trả về chưa được thiết lập trong hồ sơ; hướng dẫn hỗ trợ của GitLab yêu cầu đối chiếu api_error với written_bytes trong log của Workhorse để xác định dữ liệu thực sự đã được gửi.

Đường tấn công có thể truy cập qua mạng thông qua repository commits API; tài liệu detection của GitLab cũng xác định repository files API là một đường tiếp cận cho tham số cùng nhóm. Hồ sơ chuẩn hóa mô tả rằng không cần xác thực, không cần tương tác của người dùng và độ phức tạp tấn công thấp. Hướng dẫn hỗ trợ của GitLab cho biết request chính có thể được xử lý mà không cần multipart body. Lỗ hổng đã được đưa vào danh mục Known Exploited Vulnerabilities, và hồ sơ được cung cấp đánh dấu rằng exploit công khai đã tồn tại. Nếu một instance không công khai API cho người dùng ẩn danh, hướng dẫn detection của GitLab lưu ý rằng người dùng đã xác thực với đặc quyền thấp vẫn có thể thử primitive này. Việc sử dụng trong một chiến dịch ransomware cụ thể vẫn chưa được xác định.

Khai thác thành công có thể tạo primitive đọc tệp cục bộ tùy ý trên máy chủ GitLab. Mức độ tiết lộ thực tế phụ thuộc vào nội dung tệp và cách request parser xử lý nội dung; máy chủ có thể đã đọc tệp dù không có byte nào được trả về client. Nếu nội dung nhạy cảm được trả về, credential trong phần bị lộ có thể cho phép truy cập vào database, object storage, SMTP, LDAP hoặc các hệ thống liên kết khác. Việc lộ Rails secret key base hoặc encryption key có thể dẫn đến giả mạo session hoặc token và giải mã một số dữ liệu được lưu trữ, nhưng đây là hậu quả tiếp theo phụ thuộc vào secret thực sự bị lộ, không phải kết quả được chứng minh cho mọi request. Primitive trực tiếp là đọc dữ liệu và không tự nó chứng minh có gián đoạn dịch vụ; tác động đến tính toàn vẹn hoặc quyền truy cập có thể phát sinh sau đó nếu credential bị lộ bị lạm dụng.

Đối với GitLab Self-Managed, một request không cần tài khoản có thể buộc dịch vụ đọc tệp cấu hình, secret hoặc credential trên máy chủ. Nếu nội dung được trả về, secret key base của instance có thể tạo điều kiện cho việc giả mạo session hoặc token và giải mã dữ liệu CI/CD variables hoặc dữ liệu 2FA được lưu trữ. Database credential cùng credential của object storage, SMTP hoặc LDAP cũng có thể bị lộ; từ đó có thể dẫn đến truy cập trái phép vào các hệ thống liên kết và làm lộ source code hoặc tài sản sở hữu trí tuệ. Không nên giả định rằng một request chỉ gây lỗi là vô hại, nhưng cũng không nên coi mọi lần đọc tệp là một lần exfiltration thành công khi chưa đối chiếu api_error và written_bytes. Sự cố có thể kéo theo điều tra incident, xoay vòng secret, rà soát hệ thống bên thứ ba và nghĩa vụ tuân thủ.

1. Nâng cấp GitLab Self-Managed lên bản sửa lỗi tương ứng với nhánh đang chạy: 18.11.12, 19.0.9, 19.1.8, 19.2.6 hoặc 19.3.2. Phải chọn đúng bản sửa lỗi cho nhánh bị ảnh hưởng, không suy luận rằng việc vá một nhánh đã bảo vệ mọi nhánh khác.
2. Với các instance đang chạy nhánh 18.11 hoặc 19.0, GitLab cung cấp các bản backport bảo mật 18.11.12 và 19.0.9. GitLab vẫn khuyến nghị chuyển sang release stream được hỗ trợ khi khả thi, vì các bản backport này chỉ chứa các security fix liên quan.
3. Nếu instance bị ảnh hưởng từng có thể truy cập trong thời gian phơi lộ, hãy bảo toàn log trước khi restart hoặc upgrade. Đối chiếu api_json.log với log access của Workhorse bằng correlation_id, đồng thời kiểm tra api_error và written_bytes để xác định nội dung nào thực sự đã được gửi.
4. Nếu fragment bị tiết lộ chứa credential hoặc secret, chỉ xoay vòng các thông tin xác thực xuất hiện trong fragment đó và kiểm tra hoạt động đăng nhập trên các hệ thống object storage, SMTP, LDAP hoặc SSO liên quan. Không quyết định xoay vòng chỉ dựa trên HTTP status.
5. Nếu evidence liên quan đến db_key_base hoặc otp_key_base, cần theo hướng dẫn hỗ trợ của GitLab trước khi thực hiện xoay vòng. GitLab lưu ý rằng hiện không có quy trình được hỗ trợ để xoay vòng db_key_base.
6. GitLab cho biết GitLab.com và GitLab Dedicated đã được vá và khách hàng của hai dịch vụ này không cần thực hiện hành động riêng cho bản sửa lỗi này.

1. Kiểm kê các triển khai GitLab Self-Managed và đối chiếu nhánh phiên bản đang chạy với các phạm vi bị ảnh hưởng và bản sửa lỗi trong phần remediation.
2. Trước khi restart hoặc upgrade, bảo toàn các bản ghi liên quan, gồm api_json.log, log truy cập của Workhorse và log nginx. Với Omnibus, cần lưu cả các bản xoay vòng của /var/log/gitlab/gitlab-rails/api_json.log và log Workhorse; với triển khai source hoặc Helm, thu thập vị trí log tương ứng của Rails, Webservice và Workhorse.
3. Trong api_json.log, kiểm tra trường params để tìm file.path hoặc metadata.path trỏ ra ngoài các thư mục tạm hợp lệ của Workhorse. Percent-decode giá trị và xử lý các đoạn .. trước khi so sánh; kiểm tra cả tên tham số được percent-encode và không chỉ dựa vào route literal.
4. Dùng correlation_id để đối chiếu request với bản ghi access của Workhorse, sau đó kiểm tra written_bytes và trường api_error. HTTP status đơn lẻ không đủ để kết luận nội dung có được trả về hay không.
5. Nếu api_error chứa fragment của tệp, coi các bản sao log là artifact chứa secret, xác định credential hoặc secret thực sự xuất hiện trong fragment, rồi xoay vòng các credential bị lộ và kiểm tra log xác thực của các hệ thống liên quan. Nếu không có bằng chứng nội dung được trả về, chỉ được kết luận rằng chưa có bằng chứng tiết lộ nội dung, không được kết luận rằng tệp chưa từng bị đọc.