Trong thế giới phát triển phần mềm, các hệ thống tích hợp và triển khai liên tục đã trở thành công cụ thiết yếu để duy trì chất lượng và bảo mật mã nguồn. Tuy nhiên, một sự cố bảo mật gần đây liên quan đến GitHub Actions đã tiết lộ những lỗ hổng cơ bản trong cách các hệ thống này xử lý mã nguồn không đáng tin cậy, châm ngòi cho cuộc tranh luận gay gắt giữa các chuyên gia bảo mật và nhà phát triển về tính an toàn của các quy trình phát triển hiện đại.
Vấn Đề Với pull_request_target
Vấn đề cốt lõi xoay quanh kích hoạt pull_request_target của GitHub, mà các chuyên gia bảo mật cho rằng về cơ bản là không an toàn trong thiết kế. Không giống như kích hoạt pull_request an toàn hơn, pull_request_target cấp cho các quy trình làm việc quyền đọc/ghi kho lưu trữ và quyền truy cập vào các bí mật theo mặc định, ngay cả khi xử lý các pull request từ các fork không đáng tin cậy. Điều này tạo ra một tình huống nguy hiểm khi các tác nhân độc hại có khả năng khai thác các lỗ hổng để giành quyền truy cập trái phép vào các thông tin xác thực nhạy cảm và nội dung kho lưu trữ.
Đây là một ví dụ điển hình về lý do tại sao
pull_request_targetvề cơ bản là không an toàn, và tại sao GitHub có lẽ nên loại bỏ nó hoàn toàn.
Vấn đề còn trầm trọng hơn bởi tài liệu hướng dẫn gây hiểu lầm của GitHub, gợi ý rằng pull_request_target an toàn hơn vì nó chạy trong ngữ cảnh của nhánh cơ sở thay vì commit hợp nhất. Các chuyên gia bảo mật cho rằng tài liệu này là thiếu trách nhiệm vì nó ngụ ý rằng kích hoạt này cung cấp sự bảo vệ chống lại các cuộc tấn công thực thi mã, trong khi thực tế nó chỉ khuyến khích các nhà phát triển kiểm tra mã do kẻ tấn công kiểm soát một cách rõ ràng, tạo ra các bề mặt lỗ hổng bổ sung.
So sánh các Trigger chính của GitHub Action:
pull_request: Chạy với quyền hạn giới hạn, không có quyền truy cập vào secrets theo mặc định khi xử lý các forkpull_request_target: Chạy với quyền đọc/ghi và quyền truy cập secrets theo mặc định, ngay cả đối với các PR từ fork
Thách Thức Về Mô Hình Tư Duy
Các nhà phát triển phải đối mặt với những thách thức đáng kể khi viết các quy trình làm việc CI/CD cho các pull request vì họ phải liên tục chuyển đổi giữa hai ngữ cảnh bảo mật khác nhau. Khi viết các bước kiểm tra và xác minh, các nhà phát triển thường hoạt động dưới giả định rằng họ đang chạy mã đáng tin cậy từ chính nhóm của mình. Tuy nhiên, khi xử lý các pull request bên ngoài, chính các quy trình làm việc đó lại đang thực thi mã có khả năng độc hại từ các nguồn không xác định.
Sự xung đột về mô hình tư duy này trở nên đặc biệt nguy hiểm khi các quy trình làm việc cần tích hợp với cơ sở hạ tầng nội bộ cho các tác vụ như kiểm tra end-to-end hoặc kiểm tra thỏa thuận của người đóng góp. Sự phức tạp của các tích hợp này khiến việc vô tình tạo ra các lỗ hổng bảo mật nơi các thao tác đặc quyền tương tác với đầu vào không đáng tin cậy trở nên dễ dàng. Tình huống này đại diện cho một trường hợp kinh điển của sự mất an toàn do động cơ - các nhà phát triển cần thực hiện các thao tác hợp lý trên các đóng góp của bên thứ ba, nhưng các công cụ có sẵn lại tạo ra những rủi ro không cần thiết.
Vượt Ra Ngoài Thực Thi Mã Đơn Thuần
Các lỗ hổng bảo mật mở rộng ra ngoài phạm vi các cuộc tấn công thực thi mã đơn giản. Trong sự cố hệ sinh thái Nix, những kẻ tấn công đã phát hiện ra rằng họ có thể khai thác các liên kết tượng trưng trong các kho lưu trữ git để đọc các tệp tùy ý trên hệ thống runner. Bằng cách thay thế một tệp cấu hình bằng một liên kết tượng trưng trỏ đến tệp thông tin xác thực của GitHub, họ có thể trích xuất các token xác thực với quyền truy cập đọc/ghi toàn bộ kho lưu trữ.
Lỗ hổng liên kết tượng trưng này ảnh hưởng đến hầu hết mọi quy trình làm việc xử lý các đóng góp bên ngoài, đại diện cho một bề mặt tấn công khổng lồ mà nhiều nhà phát triển bỏ qua. Vấn đề không nằm ở bản thân git mà ở cách các hệ thống CI/CD xử lý nội dung kho lưu trữ mà không có ranh giới bảo mật phù hợp. Ngay cả các quy trình làm việc không thực thi mã từ các pull request một cách rõ ràng cũng có thể dễ bị tổn thương bởi các cuộc tấn công thao túng hệ thống tệp này.
Các Mẫu Lỗ Hổng Bảo Mật Phổ Biến:
- Tấn công chèn đối số thông qua các công cụ như xargs
- Tấn công liên kết tượng trưng cho phép duyệt qua hệ thống tệp
- Leo thang đặc quyền thông qua việc lộ thông tin xác thực
- Sự phân tách không đủ giữa việc thực thi mã đáng tin cậy và không đáng tin cậy
Lỗ Hổng Thiết Kế Cơ Bản
Các chuyên gia bảo mật chỉ ra một vấn đề sâu xa hơn trong cách các hệ thống CI/CD hiện đại xử lý xác thực. Cách tiếp cận hiện tại là cấp phát các bearer token cho các chương trình đáng tin cậy tạo ra một tình huống vốn dĩ đầy rủi ro. Như một bình luận viên đã lưu ý, nếu GitHub Actions cung cấp quyền truy cập ổ cắm Unix đặc quyền hoặc quyền truy cập ssh-agent thay vì các token thô, thì các loại lỗ hổng này sẽ khó bị khai thác hơn nhiều.
Vấn đề còn trầm trọng hơn bởi các công cụ như xargs, nơi trang hướng dẫn sử dụng ghi rõ rằng không thể sử dụng xargs một cách an toàn trong một số ngữ cảnh nhất định. Mặc dù việc thêm dấu phân cách đối số -- có thể giảm thiểu một số rủi ro, điều này đòi hỏi các nhà phát triển phải luôn cảnh giác về bảo mật - một cách tiếp cận đã nhiều lần chứng minh là không đầy đủ trong thực tế. Cộng đồng bảo mật so sánh điều này với việc cần phải tự thoát HTML ở mọi nơi để ngăn chặn các cuộc tấn công XSS.
Các Bước Giảm Thiểu Ngay Lập Tức:
- Vô hiệu hóa các workflow dễ bị tấn công trong cài đặt GitHub Action
- Rà soát tất cả các trường hợp sử dụng trigger pull_request_target
- Triển khai sanitization đối số một cách phù hợp
- Sử dụng quyền hạn tối thiểu cần thiết
- Tách biệt hoàn toàn các thao tác đáng tin cậy và không đáng tin cậy
Hướng Tới Các Giải Pháp
Cộng đồng bảo mật đã đề xuất một số cách tiếp cận để giải quyết các vấn đề này. Một số chuyên gia khuyến nghị vô hiệu hóa hoàn toàn pull_request_target trên toàn bộ tổ chức, trong khi những người khác ủng hộ việc GitHub cung cấp các token chi tiết, dùng một lần được thiết kế đặc biệt cho các thao tác an toàn trên PR của bên thứ ba. Ngày càng có sự đồng thuận rằng mô hình cấp phép tất cả hoặc không có gì hiện tại là không phù hợp cho các quy trình phát triển hiện đại.
Các tổ chức quan tâm về các lỗ hổng này có thể thực hiện hành động ngay lập tức bằng cách truy cập cài đặt tổ chức GitHub của họ, điều hướng đến Actions → General và vô hiệu hóa các hành động trên tất cả các kho lưu trữ. Cách tiếp cận nút khẩn cấp này cung cấp sự bảo vệ tạm thời trong khi các biện pháp bảo mật lâu dài hơn được triển khai. Để bảo mật liên tục, các nhà phát triển nên kiểm tra kỹ lưỡng các quy trình làm việc của họ, giảm thiểu quyền và tách biệt nghiêm ngặt các thao tác đáng tin cậy với các thao tác không đáng tin cậy.
Cuộc thảo luận đang diễn ra làm nổi bật sự căng thẳng giữa sự tiện lợi cho nhà phát triển và bảo mật trong phát triển phần mềm hiện đại. Khi các hệ thống CI/CD trở nên quan trọng hơn đối với quy trình phát triển, việc tìm ra sự cân bằng phù hợp giữa chức năng và an toàn vẫn là một thách thức cấp bách cho toàn bộ ngành công nghiệp.
Tham khảo: Pwning the Entire Nix Ecosystem