Homelander The Seven
I will laser every f****** one of you!
Cơ quan An ninh mạng và Cơ sở hạ tầng Hoa Kỳ (CISA) và Cục Điều tra Liên bang (FBI) đã tăng cường nỗ lực thuyết phục các nhà sản xuất phần mềm từ bỏ các ngôn ngữ lập trình "không an toàn về bộ nhớ" như C và C++, một động thái không gây ngạc nhiên.
Báo cáo về Các Thực tiễn Xấu trong Bảo mật Sản phẩm cảnh báo các nhà sản xuất phần mềm về việc phát triển "các dòng sản phẩm mới để sử dụng trong cơ sở hạ tầng quan trọng hoặc [chức năng quan trọng quốc gia] NCF bằng ngôn ngữ không an toàn về bộ nhớ (ví dụ: C hoặc C++) trong khi có sẵn các ngôn ngữ an toàn về bộ nhớ thay thế có thể sử dụng là nguy hiểm và làm tăng đáng kể rủi ro đối với an ninh quốc gia, an ninh kinh tế quốc gia, và sức khỏe và an toàn cộng đồng quốc gia." Tóm lại, đừng sử dụng C hoặc C++. Điều này liệu có khả thi?
CISA đã nhấn mạnh điểm này trong nhiều năm. Đầu năm 2024, CISA, cùng với các cơ quan đối tác bao gồm FBI, Trung tâm An ninh mạng Úc của Tổng cục Tín hiệu Úc và Trung tâm An ninh mạng Canada, hay còn gọi là Five Eyes, đã xuất bản một báo cáo, Khám phá An toàn Bộ nhớ trong Các Dự án Nguồn Mở Quan trọng, phân tích 172 dự án nguồn mở quan trọng. Kết quả cho thấy hơn một nửa số dự án này chứa mã được viết bằng các ngôn ngữ không an toàn về bộ nhớ, chiếm 55% tổng số dòng mã trên các dự án được kiểm tra.
Cụ thể, "Các ngôn ngữ không an toàn về bộ nhớ yêu cầu nhà phát triển quản lý việc sử dụng và phân bổ bộ nhớ đúng cách. Những sai lầm, chắc chắn sẽ xảy ra, có thể dẫn đến các lỗ hổng bảo mật bộ nhớ như tràn bộ đệm và sử dụng sau khi giải phóng. Việc khai thác thành công các loại lỗ hổng này có thể cho phép kẻ thù kiểm soát phần mềm, hệ thống và dữ liệu." Đây chẳng phải là điều ai cũng biết sao?
CISA tiếp tục cho biết các lỗ hổng bảo mật bộ nhớ chiếm 70% các lỗ hổng bảo mật. Để giải quyết vấn đề này, CISA khuyến nghị các nhà phát triển chuyển sang các ngôn ngữ lập trình an toàn về bộ nhớ như Rust, Java, C#, Go, Python và Swift. Các ngôn ngữ này kết hợp các biện pháp bảo vệ tích hợp chống lại các lỗi liên quan đến bộ nhớ phổ biến, giúp chúng an toàn hơn ngay từ mã nguồn.
Nghe có vẻ hay, phải không? Nhưng nếu chỉ cần búng tay và biến đổi mã từ C sang Rust một cách kỳ diệu thì thật dễ dàng. Nhưng thực tế không đơn giản như vậy. Ví dụ như Rust trong Linux. Ngay cả với sự hỗ trợ từ người tạo ra Linux, Linus Torvalds, Rust vẫn đang di chuyển vào Linux với tốc độ chậm chạp.
Vấn đề là, như Torvalds đã nói tại Hội nghị thượng đỉnh nguồn mở châu Âu 2024, "Toàn bộ cuộc thảo luận về Rust so với C đã mang sắc thái gần như tôn giáo" với những tranh luận gay gắt dẫn đến việc một người bảo trì Rust trong Linux bỏ cuộc trong sự phẫn nộ. Những người đã dành nhiều năm, thậm chí nhiều thập kỷ để thành thạo C không muốn học lại một ngôn ngữ rất khác biệt như Rust. Họ không thấy được lợi ích. Họ có thể viết mã an toàn về bộ nhớ bằng C, vậy tại sao bạn lại không thể? Vâng, một lý do là vì họ không có nhiều năm kinh nghiệm như vậy.
Vấn đề không chỉ nằm ở các nhà phát triển lớn tuổi, bảo thủ. Việc chuyển đổi các cơ sở mã lớn hiện có sang các ngôn ngữ an toàn về bộ nhớ có thể là một công việc khổng lồ. Nó tốn thời gian, tốn nhiều tài nguyên, đòi hỏi lập kế hoạch cẩn thận để duy trì chức năng và thành thật mà nói, nó rất khó khăn.
Một vấn đề khác là các ngôn ngữ an toàn về bộ nhớ có thể làm giảm hiệu suất so với C và C++. Có một lý do khiến chúng ta vẫn đang sử dụng các ngôn ngữ khó, đã tồn tại hàng thập kỷ này; với chúng, các nhà phát triển có thể tạo ra các chương trình nhanh nhất. Khi phải lựa chọn giữa tốc độ và bảo mật, các lập trình viên và các công ty thuê họ luôn ưu tiên mã nhanh nhất.
Bên cạnh chi phí di chuyển, các công ty cũng phải đối mặt với chi phí thay thế các công cụ phát triển, trình gỡ lỗi và khung kiểm tra hiện có để hỗ trợ các ngôn ngữ mới. Sau đó, tất nhiên, họ phải tích hợp các chương trình mới với mã và thư viện cũ. CISA đang khẳng định rằng điều này phải được thực hiện. Hoặc, ít nhất, các công ty phải đưa ra lộ trình để chuyển đổi các cơ sở mã hiện có của họ trước ngày 1 tháng 1 năm 2026. CISA lập luận rằng lợi ích lâu dài về việc giảm lỗ hổng và cải thiện bảo mật vượt xa khoản đầu tư ban đầu.
Báo cáo về Các Thực tiễn Xấu trong Bảo mật Sản phẩm cảnh báo các nhà sản xuất phần mềm về việc phát triển "các dòng sản phẩm mới để sử dụng trong cơ sở hạ tầng quan trọng hoặc [chức năng quan trọng quốc gia] NCF bằng ngôn ngữ không an toàn về bộ nhớ (ví dụ: C hoặc C++) trong khi có sẵn các ngôn ngữ an toàn về bộ nhớ thay thế có thể sử dụng là nguy hiểm và làm tăng đáng kể rủi ro đối với an ninh quốc gia, an ninh kinh tế quốc gia, và sức khỏe và an toàn cộng đồng quốc gia." Tóm lại, đừng sử dụng C hoặc C++. Điều này liệu có khả thi?
CISA đã nhấn mạnh điểm này trong nhiều năm. Đầu năm 2024, CISA, cùng với các cơ quan đối tác bao gồm FBI, Trung tâm An ninh mạng Úc của Tổng cục Tín hiệu Úc và Trung tâm An ninh mạng Canada, hay còn gọi là Five Eyes, đã xuất bản một báo cáo, Khám phá An toàn Bộ nhớ trong Các Dự án Nguồn Mở Quan trọng, phân tích 172 dự án nguồn mở quan trọng. Kết quả cho thấy hơn một nửa số dự án này chứa mã được viết bằng các ngôn ngữ không an toàn về bộ nhớ, chiếm 55% tổng số dòng mã trên các dự án được kiểm tra.
Cụ thể, "Các ngôn ngữ không an toàn về bộ nhớ yêu cầu nhà phát triển quản lý việc sử dụng và phân bổ bộ nhớ đúng cách. Những sai lầm, chắc chắn sẽ xảy ra, có thể dẫn đến các lỗ hổng bảo mật bộ nhớ như tràn bộ đệm và sử dụng sau khi giải phóng. Việc khai thác thành công các loại lỗ hổng này có thể cho phép kẻ thù kiểm soát phần mềm, hệ thống và dữ liệu." Đây chẳng phải là điều ai cũng biết sao?
CISA tiếp tục cho biết các lỗ hổng bảo mật bộ nhớ chiếm 70% các lỗ hổng bảo mật. Để giải quyết vấn đề này, CISA khuyến nghị các nhà phát triển chuyển sang các ngôn ngữ lập trình an toàn về bộ nhớ như Rust, Java, C#, Go, Python và Swift. Các ngôn ngữ này kết hợp các biện pháp bảo vệ tích hợp chống lại các lỗi liên quan đến bộ nhớ phổ biến, giúp chúng an toàn hơn ngay từ mã nguồn.
Nghe có vẻ hay, phải không? Nhưng nếu chỉ cần búng tay và biến đổi mã từ C sang Rust một cách kỳ diệu thì thật dễ dàng. Nhưng thực tế không đơn giản như vậy. Ví dụ như Rust trong Linux. Ngay cả với sự hỗ trợ từ người tạo ra Linux, Linus Torvalds, Rust vẫn đang di chuyển vào Linux với tốc độ chậm chạp.
Vấn đề là, như Torvalds đã nói tại Hội nghị thượng đỉnh nguồn mở châu Âu 2024, "Toàn bộ cuộc thảo luận về Rust so với C đã mang sắc thái gần như tôn giáo" với những tranh luận gay gắt dẫn đến việc một người bảo trì Rust trong Linux bỏ cuộc trong sự phẫn nộ. Những người đã dành nhiều năm, thậm chí nhiều thập kỷ để thành thạo C không muốn học lại một ngôn ngữ rất khác biệt như Rust. Họ không thấy được lợi ích. Họ có thể viết mã an toàn về bộ nhớ bằng C, vậy tại sao bạn lại không thể? Vâng, một lý do là vì họ không có nhiều năm kinh nghiệm như vậy.
Vấn đề không chỉ nằm ở các nhà phát triển lớn tuổi, bảo thủ. Việc chuyển đổi các cơ sở mã lớn hiện có sang các ngôn ngữ an toàn về bộ nhớ có thể là một công việc khổng lồ. Nó tốn thời gian, tốn nhiều tài nguyên, đòi hỏi lập kế hoạch cẩn thận để duy trì chức năng và thành thật mà nói, nó rất khó khăn.
Một vấn đề khác là các ngôn ngữ an toàn về bộ nhớ có thể làm giảm hiệu suất so với C và C++. Có một lý do khiến chúng ta vẫn đang sử dụng các ngôn ngữ khó, đã tồn tại hàng thập kỷ này; với chúng, các nhà phát triển có thể tạo ra các chương trình nhanh nhất. Khi phải lựa chọn giữa tốc độ và bảo mật, các lập trình viên và các công ty thuê họ luôn ưu tiên mã nhanh nhất.
Bên cạnh chi phí di chuyển, các công ty cũng phải đối mặt với chi phí thay thế các công cụ phát triển, trình gỡ lỗi và khung kiểm tra hiện có để hỗ trợ các ngôn ngữ mới. Sau đó, tất nhiên, họ phải tích hợp các chương trình mới với mã và thư viện cũ. CISA đang khẳng định rằng điều này phải được thực hiện. Hoặc, ít nhất, các công ty phải đưa ra lộ trình để chuyển đổi các cơ sở mã hiện có của họ trước ngày 1 tháng 1 năm 2026. CISA lập luận rằng lợi ích lâu dài về việc giảm lỗ hổng và cải thiện bảo mật vượt xa khoản đầu tư ban đầu.
