Ai cũng có thể truy cập dữ liệu repo đã xóa hoặc riêng tư trên GitHub

• Trên GitHub, có thể truy cập dữ liệu từ các fork đã bị xóa, các kho lưu trữ đã bị xóa, thậm chí cả các kho lưu trữ riêng tư
• GitHub biết về điều này và đây là cách được thiết kế có chủ đích
  • Vì đây là một vector tấn công rất lớn đối với mọi tổ chức sử dụng GitHub, bài viết đưa ra một thuật ngữ mới là "Cross Fork Object Reference (CFOR)"
• Lỗ hổng CFOR xảy ra khi một fork của kho lưu trữ có thể truy cập dữ liệu quan trọng từ một fork khác, bao gồm cả dữ liệu từ các fork riêng tư và đã bị xóa

Truy cập dữ liệu fork đã xóa

• Hãy xét một quy trình làm việc phổ biến trên GitHub: fork một kho lưu trữ công khai, commit mã vào fork đó, rồi xóa fork
• Mã đã commit vào fork vẫn có thể truy cập được và sẽ có thể truy cập vĩnh viễn
• Bạn có thể nghĩ rằng chỉ cần biết hash commit mới truy cập được thì sẽ an toàn, nhưng hash này có thể bị tìm ra
• Việc tìm dữ liệu từ các fork đã xóa xảy ra khá thường xuyên

Truy cập dữ liệu kho lưu trữ đã xóa

• Hãy xét một kịch bản trong đó có một kho lưu trữ công khai trên GitHub, người dùng fork kho đó, commit dữ liệu sau khi fork, rồi xóa toàn bộ kho lưu trữ,
• Mã được commit sau khi fork vẫn có thể truy cập được
• GitHub lưu kho lưu trữ và các fork trong một mạng kho lưu trữ, trong đó kho "upstream" ban đầu đóng vai trò nút gốc
• Khi kho công khai "upstream" đã được fork bị "xóa", GitHub sẽ gán lại vai trò nút gốc cho một trong các fork downstream
• Tuy nhiên, mọi commit của kho "upstream" vẫn tồn tại và có thể truy cập thông qua mọi fork

Truy cập dữ liệu kho lưu trữ riêng tư

• Hãy xét một quy trình làm việc phổ biến khi open source một công cụ mới trên GitHub,
• Có trường hợp tạo một kho lưu trữ riêng tư sẽ được công khai sau này, tạo một phiên bản nội bộ riêng tư của kho đó (thông qua fork), commit thêm mã cho các tính năng sẽ không được công khai, rồi công khai kho "upstream" trong khi vẫn giữ fork ở trạng thái riêng tư
• Việc các tính năng riêng tư và mã liên quan (ở bước 2) có bị nhìn thấy công khai hay không phụ thuộc vào việc có thể truy cập chúng từ kho công khai hay không
• Mọi thứ được commit vào fork riêng tư sau khi kho "upstream" đã được công khai thì sẽ không nhìn thấy được

Thực tế truy cập dữ liệu như thế nào?

• Bằng cách truy cập trực tiếp vào commit
• Trong mạng kho lưu trữ của GitHub, các thao tác mang tính phá hủy (như 3 kịch bản nêu trên) sẽ xóa tham chiếu đến dữ liệu commit khỏi UI GitHub tiêu chuẩn và các thao tác git thông thường
• Tuy nhiên, dữ liệu này vẫn tồn tại và có thể truy cập được nếu biết hash commit
• Hash commit là giá trị SHA-1, và nếu người dùng biết hash commit SHA-1 của commit cụ thể mà họ muốn xem, họ có thể truy cập trực tiếp commit đó qua endpoint https://github.com/<user/org>/…;
• Hash commit có thể bị brute-force thông qua UI của GitHub
• Cũng có thể truy vấn hash commit thông qua endpoint public events API của GitHub

Chính sách của GitHub

• Gần đây, tác giả đã gửi các phát hiện này thông qua chương trình VDP của GitHub, và GitHub đã làm rõ rằng kho lưu trữ được thiết kế để hoạt động theo cách này
• Sau khi xem lại tài liệu, có thể thấy GitHub đã ghi chép khá rõ người dùng nên kỳ vọng điều gì trong các trường hợp được mô tả ở trên

Tác động

• Chỉ cần còn tồn tại dù chỉ một fork, mọi commit trong mạng kho lưu trữ đó (commit của kho "upstream" hoặc của các fork "downstream") sẽ tồn tại vĩnh viễn
• Kiến trúc kho lưu trữ của GitHub đòi hỏi khiếm khuyết thiết kế này, và phần lớn người dùng GitHub không hiểu mạng kho lưu trữ thực sự vận hành như thế nào nên sẽ kém an toàn hơn
• Khi secret scanning tiếp tục phát triển để có thể quét mọi commit trong mạng kho lưu trữ, người dùng có thể nhận cảnh báo về các secret không phải của mình
• Ba kịch bản này tuy gây sốc nhưng vẫn chưa bao quát hết mọi cách GitHub có thể lưu giữ dữ liệu đã bị xóa khỏi kho lưu trữ

Ý kiến của GN⁺

• Bài viết này nêu ra một vấn đề bảo mật quan trọng đối với các tổ chức sử dụng GitHub. Việc dữ liệu từ các kho lưu trữ đã bị xóa hoặc đặt ở chế độ riêng tư vẫn có thể truy cập được là điều gây sốc. Đây có vẻ là một lỗi thiết kế nền tảng do kiến trúc mạng kho lưu trữ của GitHub gây ra
• Các nhà phát triển cần nhận thức được vấn đề này và thận trọng khi commit dữ liệu quan trọng hoặc secret lên GitHub. Một khi đã push lên kho công khai, dữ liệu đó có thể truy cập được vĩnh viễn. Nếu secret quan trọng đã bị lộ, chỉ có xoay vòng khóa mới có thể giải quyết triệt để
• GitHub có công khai minh bạch và tài liệu hóa vấn đề này, nhưng phần lớn người dùng có thể sẽ không hiểu đầy đủ cách mạng kho lưu trữ vận hành. GitHub cần nỗ lực hơn để nâng cao nhận thức và đào tạo người dùng về vấn đề này
• Các vấn đề tương tự cũng có thể tồn tại trong những hệ thống quản lý phiên bản khác. Các nhà phát triển và tổ chức cần hiểu rõ kiến trúc cũng như giới hạn của công cụ mình đang dùng khi quản lý dữ liệu quan trọng
• Để ngăn rò rỉ dữ liệu quan trọng, cần có các biện pháp bảo mật đa lớp như kiểm soát truy cập nghiêm ngặt, áp dụng nguyên tắc đặc quyền tối thiểu, quét secret định kỳ và giám sát liên tục. Trên hết, nhận thức bảo mật cao của nhà phát triển là yếu tố then chốt

[GN⁺]

Ý kiến Hacker News

• Đã báo cáo với HackerOne vào năm 2018, nhưng GitHub nói đây là hành vi được thiết kế nên không sửa. Kết luận: hãy sao chép kho lưu trữ để dùng thay vì dùng fork riêng tư
• GitHub ám ảnh với việc biến mọi thứ thành công khai và không thể thay đổi. Ví dụ, để xóa bình luận, bạn phải gửi email kèm giấy tờ tùy thân thật cho chủ sở hữu kho lưu trữ
• Người dùng không nên phải biết về những vấn đề như thế này của tính năng "riêng tư", và việc GitHub coi đây là tính năng chứ không phải lỗi cho thấy sự thờ ơ với bảo mật. Có lẽ nên gọi kho lưu trữ riêng tư là kho lưu trữ "không niêm yết" thì đúng hơn
• Nếu dùng kho lưu trữ riêng tư và fork riêng tư rồi chuyển kho lưu trữ sang công khai, thì fork cũng sẽ thành công khai. GitHub có thể khẳng định đây là hành vi được thiết kế, nhưng lẽ ra phải buộc xác nhận việc công khai cả kho lưu trữ lẫn fork cùng lúc
• Hành vi này trông như một dark pattern, và dù sinh kế của mọi người bị ảnh hưởng, GitHub vẫn không quan tâm. Có lẽ vì khả năng chối bỏ có chủ đích và điều khoản sử dụng mơ hồ có giá trị hơn tổn thất về danh tiếng
• Thật ngạc nhiên khi có những bình luận giảm nhẹ vấn đề này. Tôi đã dùng GitHub rất lâu nhưng không ngờ lại có hệ quả như vậy và cảm thấy bất an. Khuyên mọi người nên đọc trực tiếp bài viết
• Đây không phải vấn đề mới. Nhiều người trước đây đã phát hiện ra chuyện này
• OSPO của GitHub đang phát triển một GitHub App mã nguồn mở để duy trì bản mirror riêng tư của các fork công khai. Dự kiến phát hành beta trong tuần này
• Lỗ hổng thực sự là cách kho lưu trữ GitHub Events làm lộ hash SHA1 của các kho lưu trữ dễ bị ảnh hưởng. Có thể quét toàn bộ mạng để truy cập các kho lưu trữ riêng tư đã bị xóa
• Vấn đề nằm ở cách dữ liệu riêng tư có thể phụ thuộc vào dữ liệu công khai. Ví dụ, nếu một commit riêng tư phụ thuộc vào commit công khai C, khi C bị xóa khỏi kho công khai thì GitHub vẫn phải giữ nó. Nếu không, commit riêng tư sẽ bị hỏng
• Mọi commit đều tồn tại vĩnh viễn sau khi được đưa lên GitHub, và một commit đã từng công khai thì luôn có thể được truy cập qua hash của commit