Câu chuyện tôi đã vấp phải lỗ hổng khóa yếu của Debian

Câu chuyện tôi từng vấp phải lỗ hổng khóa yếu của Debian

• Vào tháng 3 năm 2008, tác giả đang làm việc tại Engine Yard (EY)
• Khi đó EY đang hỗ trợ GitHub bằng cách cung cấp hạ tầng miễn phí
• Khi GitHub phát triển, đã phát sinh vấn đề thời gian đăng nhập SSH trở nên chậm
• GitHub đang dùng cách tiêu chuẩn là tệp ~/.ssh/authorized_keys để quản lý khóa SSH
• Khi người dùng kết nối, SSH mở tệp này và tìm tuyến tính khóa khớp với khóa mà người dùng đưa ra
• Thông thường chỉ có vài khóa nên không thành vấn đề, nhưng khi số người dùng tăng như GitHub thì sẽ chậm

Quyết định dùng DB MySQL thay cho tệp authorized_keys

• Sau khi xem xét nhiều phương án, họ quyết định vá OpenSSH để việc tra cứu khóa được thực hiện qua DB MySQL
• Đây là một quyết định thận trọng, và họ đã nỗ lực rất nhiều để không làm tổn hại đến bảo mật
• Giải pháp được áp dụng vào đầu tháng 4 năm 2008, qua đó giải quyết vấn đề tốc độ đăng nhập SSH

Chuyện lạ xảy ra

• Một tháng sau, vào đầu tháng 5, đã xảy ra vấn đề một số người dùng có thể truy cập kho lưu trữ của người khác qua SSH
• Kết quả điều tra cho thấy những người dùng khác nhau đang sử dụng các khóa có cùng dấu vân tay khóa
• Điều này không thể xảy ra nếu họ không chia sẻ khóa với nhau
• Người dùng nói rằng họ không hề quen biết nhau và cũng không biết khóa đã bị lộ như thế nào
• Vấn đề tương tự cũng được phát hiện ở các cặp người dùng khác
• Điểm chung duy nhất là tất cả đều dùng hệ thống Debian hoặc Ubuntu

Xác định nguyên nhân

• Đến ngày 13 tháng 5 năm 2008, khi DSA-1571-1 được công bố, mọi chuyện mới trở nên rõ ràng
• Một maintainer của Debian khi dọn dẹp mã sinh số ngẫu nhiên của OpenSSL đã vô tình làm giảm số lượng khóa có thể có xuống còn khoảng 32.000
• Nhiều người tham gia GitHub rồi tạo khóa mới theo thông lệ tốt, và vì thế đã xảy ra va chạm
• Sau đó tác giả còn liên quan sâu hơn đến vấn đề này, chẳng hạn dùng các khóa yếu đã biết để tìm ra những cơ quan chứng thực có vấn đề

Ý kiến của GN⁺

• Để phát hiện một lỗ hổng quan trọng như vậy, cần có suy nghĩ “có gì đó không ổn” cùng thời gian và năng lượng để điều tra bền bỉ. Thông thường không có nhiều dư địa như vậy, nên cũng cần phần nào may mắn.
• Phần lớn mọi người bị cuốn theo nhịp sống bận rộn nên khó lần ra nguyên nhân gốc rễ của vấn đề. Việc ngành của chúng ta lấy lại được khoảng trống đó là một bài toán quan trọng.
• OpenSSL là một trong những thư viện mã hóa được dùng rộng rãi nhất, nên tác động của kiểu lỗ hổng này là rất lớn. Đây là ví dụ điển hình cho cả mặt mạnh lẫn mặt yếu của mã nguồn mở.
• Để phòng ngừa loại lỗ hổng này, cần tăng cường review code và kiểm toán bảo mật, đồng thời xem xét cẩn trọng hơn các thay đổi ở những phần quan trọng. Tuy vậy, không có phương pháp nào là hoàn hảo.
• Dù vậy, mã nguồn mở vẫn có ưu điểm là các chuyên gia có thể trực tiếp xem mã để tìm ra vấn đề. Với phần mềm đóng thì ngay cả điều đó cũng không thể.

[GN⁺]

Ý kiến Hacker News

• Luciano Bello đã tình cờ phát hiện lỗ hổng CVE-2008-0166, nhưng theo log IRC thời đó thì cần rất nhiều số nguyên tố nhỏ và không phải lần nào cũng thu được cùng một con số
• Có vẻ cả ngành đã khá may mắn, vì đã có một người sở hữu kỹ năng cùng thời gian và năng lượng có thể tạo ra khác biệt lớn đúng lúc. Đây là khoảnh khắc cho thấy rõ tính thống kê của "nhiều con mắt" và "ánh nắng là chất khử trùng". Dù xác suất ai đó tình cờ phát hiện lỗi có thấp đến đâu, cuối cùng nó vẫn được phát hiện vì con người có thể làm được điều đó. Ngược lại, với mã nguồn sở hữu độc quyền/đóng, xác suất đó là 0
• Thay đổi gây ra lỗ hổng này không phải được thực hiện trong lúc vội vàng. Người bảo trì đã nêu vấn đề trên mailing list của OpenSSL, xin phản hồi và đề xuất giải pháp, đồng thời nhận được một số phản hồi, bao gồm cả từ upstream. Kết quả là một lỗ hổng khủng khiếp, nhưng có vẻ đây là một trường hợp cực kỳ xui xẻo khi không ai nhận ra vấn đề
• GitHub đi đến kết luận rằng lựa chọn tốt nhất là vá OpenSSH để tra cứu các khóa được lập chỉ mục theo dấu vân tay khóa trong cơ sở dữ liệu MySQL. Có vẻ họ chọn MySQL thay vì SQLite vì đây là kiểu tình huống mà MySQL có thể phát huy thế mạnh, trong bối cảnh họ muốn tăng tốc độ truy cập vào ~/.ssh/authorized_keys
• Điều này khiến người ta nghĩ đến khả năng chuyện tương tự xảy ra trong hàm tạo seed của một ví phần cứng Bitcoin phổ biến, cũng như hậu quả của nó
• Việc dùng GCD để phát hiện các khóa RSA có chung thừa số p hoặc q cũng là một giai thoại thú vị
• Có thể thấy thời gian đăng nhập SSH chậm là một manh mối đáng để lần theo vì nhiều lý do khác nhau
• OpenSSL RNG được seed bằng bộ nhớ stack chưa được khởi tạo và PID, nhưng ngay cả khi không có bản vá của Debian thì việc chỉ seed bằng PID thôi dường như cũng đã khá nguy hiểm
• Tò mò không biết GitHub có còn đang chạy bản OpenSSH đã được vá đó hay không
• Câu nói rằng Ezra Zygmuntowicz đã giới thiệu GitHub cho tác giả và cho anh ấy thời gian cùng đội ngũ GitHub đào sâu vấn đề này nghe khá buồn cười. Có lẽ vì nó dễ khiến người ta đọc theo hướng như thể chính đội GitHub đang gặp vấn đề lớn
• Tò mò không biết nếu Luciano không phát hiện ra thì lỗ hổng này còn có thể ẩn mình bao lâu nữa. Có lẽ chỉ một vài nơi lưu trữ hàng nghìn khóa từ người dùng, như GitHub hoặc các nhà cung cấp đám mây lớn, mới có thể tình cờ phát hiện ra nó