Loại bỏ các lỗ hổng an toàn bộ nhớ từ gốc trong mã nguồn

Loại bỏ tận gốc các lỗ hổng an toàn bộ nhớ

Kết quả mang tính nghịch lý

• Khi codebase được viết bằng các ngôn ngữ không an toàn bộ nhớ ngày càng tăng, việc chuyển các tính năng mới sang ngôn ngữ an toàn bộ nhớ sẽ làm giảm mạnh các lỗ hổng an toàn bộ nhớ
• Điều này là do các lỗ hổng giảm theo hàm mũ theo thời gian

Giải thích bằng toán học

• Vòng đời của lỗ hổng tuân theo phân phối hàm mũ
• Lỗ hổng chủ yếu phát sinh trong mã mới, và theo thời gian mã sẽ trở nên an toàn hơn
• Mật độ lỗ hổng của mã đã 5 năm tuổi thấp hơn từ 3,4 đến 7,4 lần so với mã mới

Trường hợp thực tế trên Android

• Từ năm 2019, nhóm Android đã bắt đầu chuyển hoạt động phát triển mới sang các ngôn ngữ an toàn bộ nhớ
• Tính đến năm 2024, tỷ lệ lỗ hổng an toàn bộ nhớ đã giảm từ 76% xuống 24%
• Khi các lỗ hổng an toàn bộ nhớ giảm, rủi ro bảo mật tổng thể cũng giảm theo

Sự tiến hóa của chiến lược an toàn bộ nhớ

• Thế hệ 1: vá phản ứng - phát hiện rồi sửa lỗ hổng
• Thế hệ 2: giảm thiểu chủ động - khiến việc khai thác lỗ hổng trở nên khó hơn
• Thế hệ 3: phát hiện lỗ hổng chủ động - tìm ra lỗ hổng trước khi chúng bị khai thác
• Thế hệ 4: phòng ngừa độ tin cậy cao - chuyển sang ngôn ngữ an toàn bộ nhớ để ngăn lỗ hổng phát sinh ngay từ đầu

Ưu điểm của phòng ngừa độ tin cậy cao

• Chấm dứt cuộc chạy đua bất tận giữa bên phòng thủ và bên tấn công
• Nâng cao bảo mật và giảm chi phí thông qua các ngôn ngữ an toàn bộ nhớ
• Cải thiện tính đúng đắn của mã và năng suất của nhà phát triển

Từ bài học đến thực hành

• Không cần loại bỏ hoặc viết lại toàn bộ mã hiện có không an toàn bộ nhớ
• Tăng tốc quá trình chuyển sang ngôn ngữ an toàn bộ nhớ bằng cách cải thiện khả năng tương tác
• Phát triển các công cụ cải thiện khả năng tương tác giữa Rust và C++, cũng như giữa Rust và Kotlin

Vai trò của các thế hệ trước

• Sử dụng có chọn lọc các biện pháp giảm thiểu và phát hiện chủ động
• Khi chuyển sang mã an toàn bộ nhớ, nhu cầu về giảm thiểu và phát hiện sẽ giảm xuống

Kết luận

• Việc dùng ngôn ngữ an toàn bộ nhớ cho mã mới khiến lỗ hổng giảm theo hàm mũ
• Hơn 6 năm kết quả nhất quán trên Android đã chứng minh hiệu quả của cách tiếp cận này

Tóm tắt của GN⁺

• Việc chuyển sang các ngôn ngữ an toàn bộ nhớ là rất quan trọng để giảm các lỗ hổng an toàn bộ nhớ
• Trường hợp của nhóm Android cho thấy các lỗ hổng an toàn bộ nhớ đã giảm mạnh
• Cải thiện khả năng tương tác thực tế hơn so với việc viết lại hoàn toàn mã hiện có
• Sử dụng các ngôn ngữ an toàn bộ nhớ như Rust có thể đồng thời nâng cao bảo mật và năng suất

[GN⁺]

Ý kiến Hacker News

• Việc chuyển phần phát triển mới sang ngôn ngữ an toàn bộ nhớ có thể mang lại cải thiện đáng kể
  • Dễ và rẻ hơn rất nhiều so với việc port mọi thứ
• Biểu đồ trong bài viết rõ ràng và ngắn gọn
  • Việc lựa chọn dữ liệu và gắn nhãn cẩn thận có thể truyền tải ý tưởng một cách dễ dàng
• Lỗ hổng giảm theo cấp số nhân
  • Điều quan trọng là tập trung vào mã mới
  • Các dự án RiiR làm lại mọi thứ một cách đại trà là sự lãng phí tài nguyên
  • Chiến lược được các chuyên gia Rust khuyến nghị là hiệu quả nhất để giảm thiểu lỗ hổng bộ nhớ
• Nhóm Android quan sát thấy tỷ lệ rollback của các thay đổi bằng Rust chưa đến một nửa so với C++
• Có mối tương quan giữa mã mới và lỗ hổng bộ nhớ
  • Mã liên quan đến tính năng mới tập trung nhiều lỗ hổng hơn
  • Mã cũ phát hiện các edge case thông qua sử dụng thực tế
• Khó có thể khẳng định mã mới gây ra lỗ hổng bộ nhớ
  • Có những lỗ hổng tác động lớn như lỗi Heartbleed
• Lỗ hổng giảm theo cấp số nhân
  • Ngừng bổ sung tính năng mới có thể tốt hơn cho bảo mật
  • Windows LTSC có thể là phiên bản an toàn nhất
• Việc lập trình an toàn cải thiện tính đúng đắn của mã và năng suất của lập trình viên
  • Đưa việc phát hiện lỗi lên trước thời điểm check-in mã
  • Nhóm Android quan sát thấy tỷ lệ rollback của các thay đổi bằng Rust chưa đến một nửa so với C++
• Sau khi biết đến Rust, lấy lại được niềm đam mê với lập trình
• Trong các ngôn ngữ an toàn bộ nhớ (MSL), chỉ có Rust được nhắc đến
  • Kotlin cũng được nhắc đến nhưng các tính năng an toàn bộ nhớ không mạnh bằng Rust
• Vòng đời của lỗ hổng có phân bố theo hàm mũ
  • Việc đảm bảo an toàn bộ nhớ cho mã mới là rất đáng giá
  • Hữu ích ngay cả với các codebase legacy quy mô lớn
• Mã cũ có thể chưa được rà soát đầy đủ
  • Thường xuyên xem lại commit log gần đây hơn
• Khác biệt về ngôn ngữ viết mã giữa Mac và Windows
  • Mac dùng Swift an toàn bộ nhớ, còn Windows chủ yếu dùng C hoặc C++
• Lỗ hổng càng trở nên hiếm thì càng có giá trị cao
  • Những lỗ hổng còn lại có thể bị các tác nhân cấp quốc gia sử dụng nhắm vào các mục tiêu giá trị cao
  • Có thể cần các tính năng như Lockdown Mode của iOS
  • Người dùng có nhận thức về bảo mật có thể tích vào ô bảo mật để đánh đổi bằng việc giảm hiệu năng
  • Phát hiện tấn công và gửi cho đội bảo mật để phân tích
  • Gửi cảnh báo cho người dùng và cho biết đã phát hiện tấn công
  • Thay vì giám sát thụ động hoạt động của người dùng, hãy thông báo cho người dùng khi phát hiện tấn công