Các Nhà Phát Triển Tranh Luận Về Định Nghĩa An Toàn Bộ Nhớ Khi Chính Phủ Thúc Đẩy Việc Áp Dụng

Nhóm Cộng đồng BigGo
Các Nhà Phát Triển Tranh Luận Về Định Nghĩa An Toàn Bộ Nhớ Khi Chính Phủ Thúc Đẩy Việc Áp Dụng

Việc chính phủ gần đây thúc đẩy các ngôn ngữ lập trình an toàn bộ nhớ đã khơi dậy những cuộc tranh luận kỹ thuật sôi nổi giữa các nhà phát triển về việc thực sự cái gì tạo nên an toàn bộ nhớ. Trong khi các cơ quan như NSA và CISA ủng hộ các ngôn ngữ như Rust , Java , và C# để giảm thiểu lỗ hổng bảo mật, cộng đồng lập trình đang đặt câu hỏi liệu các định nghĩa chính thức có đủ chính xác hay không.

Thống kê Bảo mật Chính:

  • 67% lỗ hổng zero-day được phát hiện trong năm 2021 có liên quan đến an toàn bộ nhớ
  • Tỷ lệ phần trăm này đã duy trì ổn định trong suốt 20 năm qua
  • Các lỗ hổng an toàn bộ nhớ đại diện cho một trong những nhóm vấn đề bảo mật phần mềm lớn nhất

Sự Nhầm Lẫn Về Data Race

Một điểm tranh cãi chính tập trung vào việc liệu bảo vệ data race có nên được coi là một phần của an toàn bộ nhớ hay không. Các nhà phê bình cho rằng các tài liệu chính phủ xử lý yêu cầu này một cách không nhất quán. Các ngôn ngữ như Java và C# được liệt kê là an toàn bộ nhớ mặc dù cho phép data race, trong khi các tài liệu đôi khi gợi ý rằng việc tránh data race là cần thiết cho an toàn bộ nhớ thực sự.

Cuộc tranh luận này bộc lộ sự bất đồng cơ bản về các ưu tiên bảo mật. Một số nhà phát triển cho rằng data race trong các ngôn ngữ có garbage collection hiếm khi dẫn đến các lỗ hổng có thể khai thác được, khiến chúng ít quan trọng hơn so với các lỗi hỏng bộ nhớ truyền thống như buffer overflow. Những người khác khẳng định rằng data race có thể tạo ra các lỗ hổng bảo mật nghiêm trọng, chỉ ra các ví dụ như lỗ hổng double-spending trong các ứng dụng tài chính nơi các thao tác đồng thời có thể làm hỏng số dư tài khoản.

Lưu ý: Data race xảy ra khi nhiều thread truy cập bộ nhớ dùng chung cùng lúc mà không có đồng bộ hóa phù hợp, có thể dẫn đến hành vi chương trình không thể dự đoán được.

Các ngôn ngữ an toàn bộ nhớ được liệt kê trong tài liệu chính phủ:

  • Ada
  • C
  • Delphi/Object Pascal
  • Go
  • Java
  • Python
  • Ruby
  • Rust
  • Swift

Các Giải Pháp Thay Thế Đang Bị Bỏ Qua

Cuộc thảo luận cộng đồng cũng làm nổi bật sự thất vọng với việc tập trung hẹp vào các ngôn ngữ an toàn bộ nhớ chính thống. Một số nhà phát triển chỉ ra các dự án thử nghiệm như Fil-C , nhằm mục đích làm cho mã C hiện có trở nên an toàn bộ nhớ thông qua các sửa đổi trình biên dịch và kiểm tra runtime. Mặc dù các dự án như vậy đối mặt với thách thức về việc áp dụng do chi phí hiệu suất và sự hỗ trợ thể chế hạn chế, những người ủng hộ cho rằng chúng xứng đáng được xem xét nhiều hơn cho các codebase cũ.

Sự đánh đổi về hiệu suất vẫn là một điểm khó khăn. Các giải pháp thêm an toàn bộ nhớ vào C thường gây ra mức phạt hiệu suất 20-50%, khiến chúng không phù hợp cho các ứng dụng quan trọng về hiệu suất. Tuy nhiên, những người ủng hộ cho rằng hầu hết phần mềm không đủ nhạy cảm về hiệu suất để biện minh cho các rủi ro bảo mật.

Đánh đổi hiệu suất:

  • Fil-C (giải pháp an toàn bộ nhớ C thử nghiệm): chi phí hiệu suất 20-50%
  • Các giải pháp phần cứng như CHERI cung cấp chi phí thấp hơn nhưng yêu cầu phần cứng chuyên dụng
  • Các giải pháp an toàn bộ nhớ dựa trên phần mềm thường phải hy sinh hiệu suất để đổi lấy bảo mật

Thách Thức Triển Khai Thực Tế

Ngoài các định nghĩa lý thuyết, các nhà phát triển đang vật lộn với các chiến lược di chuyển trong thế giới thực. Cộng đồng đề xuất tập trung vào các phương pháp tiếp cận từng bước, chẳng hạn như thay thế các dependency không an toàn bằng các lựa chọn thay thế an toàn bộ nhớ cho các thành phần quan trọng như file parser và image processor. Cách tiếp cận có mục tiêu này có thể mang lại lợi ích bảo mật mà không cần viết lại hoàn toàn các codebase lớn.

Cuộc thảo luận cũng bộc lộ sự hoài nghi về các tuyên bố kinh tế trong các khuyến nghị của chính phủ. Trong khi các quan chức cho rằng đầu tư vào các ngôn ngữ an toàn bộ nhớ sẽ được đền đáp thông qua việc giảm lỗ hổng và chi phí bảo trì, các nhà phát triển đặt câu hỏi liệu những lợi ích này có được đảm bảo trên tất cả các loại dự án hay không.

Nhìn Về Phía Trước

Cuộc tranh luận phản ánh những căng thẳng rộng lớn hơn giữa lý tưởng bảo mật và các ràng buộc thực tế trong phát triển phần mềm. Mặc dù có sự đồng thuận chung rằng an toàn bộ nhớ là quan trọng, cộng đồng vẫn chia rẽ về con đường tốt nhất để tiến về phía trước. Thách thức nằm ở việc cân bằng các cải tiến bảo mật với yêu cầu hiệu suất, chi phí phát triển, và thực tế của việc duy trì các hệ thống hiện có.

Khi các cơ quan chính phủ tiếp tục thúc đẩy việc áp dụng an toàn bộ nhớ, phản hồi của cộng đồng kỹ thuật cho thấy rằng các phương pháp tiếp cận tinh tế hơn có thể cần thiết. Thay vì các lệnh rộng, các chiến lược có mục tiêu tính đến các trường hợp sử dụng và ràng buộc cụ thể có thể chứng minh hiệu quả hơn trong việc thực sự cải thiện bảo mật phần mềm.

Tham khảo: Memory Safe Languages: Reducing Vulnerabilities in Modern Software Development