Cách tôi tạo ra lỗi tràn heap trong Curl

• Bài viết về CVE-2023-38545, một vấn đề bảo mật nghiêm trọng được phát hiện trong curl 8.4.0, được xem là lỗi bảo mật nghiêm trọng nhất của curl trong một thời gian dài
• Vấn đề là lỗi tràn heap, xảy ra do khiếm khuyết trong hàm kết nối tới proxy SOCKS5
• Lỗi này được đưa vào từ đầu năm 2020 khi hàm được chuyển từ lời gọi chặn sang máy trạng thái không chặn, nhằm cải thiện hiệu năng truyền tải song song quy mô lớn qua SOCKS5
• Khiếm khuyết nằm ở trạng thái INIT của máy trạng thái, nơi một biến cục bộ được thiết lập để quyết định curl sẽ phân giải host hay chuyển tên sang proxy. Nếu tên host quá dài, mã sẽ chuyển sang chế độ phân giải cục bộ, điều này có thể gây tràn bộ nhớ nếu tên host dài hơn bộ đệm đích
• Tràn có thể xảy ra nếu kích thước bộ đệm được đặt nhỏ hơn 65541 byte và tên host dài hơn kích thước bộ đệm. Điều này đòi hỏi tác nhân độc hại nhập một tên host cực dài vào công thức để kích hoạt lỗi
• Kẻ tấn công kiểm soát máy chủ HTTPS mà client dùng libcurl truy cập thông qua proxy SOCKS5 có thể trả về một chuyển hướng bị thao túng cho ứng dụng qua phản hồi HTTP 30x, từ đó gây ra tràn bộ đệm heap
• Vấn đề này đã được sửa trong curl 8.4.0 bằng cách để curl trả về lỗi nếu tên host quá dài, thay vì chuyển từ phân giải từ xa sang phân giải cục bộ. Một ca kiểm thử chuyên biệt cho kịch bản này cũng đã được bổ sung
• Tác giả thừa nhận lỗi này đã không xảy ra nếu curl được viết bằng ngôn ngữ an toàn bộ nhớ thay vì C, nhưng cho biết hiện không có kế hoạch port curl sang ngôn ngữ khác
• Tác giả đề xuất rằng việc cho phép, sử dụng và hỗ trợ nhiều phụ thuộc được viết bằng ngôn ngữ an toàn bộ nhớ hơn là một hướng tiếp cận khả thi, và dần dần có thể thay thế một số phần của curl
• Tác giả thừa nhận sai lầm và xin lỗi, đồng thời cho biết lỗi này lẽ ra có thể được phát hiện bằng một bộ kiểm thử tốt hơn. Ông cũng nhắc đến các công cụ phân tích mã tĩnh đã không phát hiện ra vấn đề trong hàm này
• Tác giả kết luận rằng việc phát hành một lỗi tràn heap trong đoạn mã được cài đặt trên hơn 20 tỷ bản thể là một trải nghiệm không đáng khuyến khích

[GN⁺]

Ý kiến Hacker News

• Bài viết về vấn đề tràn bộ nhớ heap trong thư viện Curl; thư viện này được dùng trên rất nhiều thiết bị và phần lớn do một người viết.
• Tác giả của Curl, Daniel, đã xin lỗi vì sai sót bắt nguồn từ một lỗi không được phát hiện trong mã suốt 1315 ngày.
• Bài viết cho rằng nếu Curl được viết bằng một ngôn ngữ an toàn bộ nhớ thay vì C thì có thể đã tránh được các vấn đề về an toàn bộ nhớ.
• Tác giả cân nhắc khả năng dần thay thế một phần của Curl bằng ngôn ngữ an toàn bộ nhớ hơn, nhưng thừa nhận tốc độ tiến triển của kiểu phát triển đó là chậm.
• Tác giả cho rằng 41% các lỗ hổng bảo mật của Curl có thể đã tránh được nếu dùng ngôn ngữ an toàn bộ nhớ.
• Bài viết này được đánh giá cao nhờ lối viết rõ ràng và thẳng thắn trong việc giải thích logic và góc nhìn đằng sau vấn đề.
• Một số bình luận cho rằng vector tấn công là rất nhỏ và cần những điều kiện rất cụ thể để khai thác, nên đặt câu hỏi về mức độ nghiêm trọng của vấn đề này.
• Một bình luận chỉ trích phần mã có thể làm lộ danh tính người dùng qua DNS đối với những người sử dụng công cụ chống kiểm duyệt.
• Một bình luận khác chỉ ra rằng tác giả đã bỏ qua các giới hạn hostname DNS được nêu trong RFC1123, và điều này có thể đã góp phần gây ra vấn đề.
• Có nhắc đến việc bản cập nhật bảo mật Windows 10 mới nhất không bao gồm phiên bản Curl mới hơn.