Các nhà phân tích bảo mật đã hoan nghênh khuyến nghị từ Cơ quan An ninh Quốc gia Hoa Kỳ (NSA) vào tuần trước đối với các nhà phát triển phần mềm xem xét việc áp dụng các ngôn ngữ như C#, Go, Java, Ruby, Rust và Swift để giảm các lỗ hổng liên quan đến bộ nhớ trong mã.
NSA đã mô tả đây là những ngôn ngữ “an toàn cho bộ nhớ” quản lý bộ nhớ một cách tự động như một phần của ngôn ngữ máy tính. NSA cho biết họ không dựa vào lập trình viên để triển khai bảo mật bộ nhớ và thay vào đó sử dụng kết hợp kiểm tra thời gian biên dịch và thời gian chạy để bảo vệ chống lại các lỗi bộ nhớ.
Trường hợp cho ngôn ngữ an toàn bộ nhớ
Lời khuyên hơi bất thường của NSA vào ngày 10 tháng XNUMX chỉ ra các ngôn ngữ được sử dụng rộng rãi như C và C++ như dựa quá nhiều vào các lập trình viên không mắc các lỗi liên quan đến bộ nhớ, mà nó lưu ý, tiếp tục là nguyên nhân hàng đầu dẫn đến các lỗ hổng bảo mật trong phần mềm. Các nghiên cứu trước đây—từng nghiên cứu Microsoft năm 2019 và một từ khác Google năm 2020 liên quan đến trình duyệt Chrome của họ—chẳng hạn, cả hai đều tìm thấy 70% lỗ hổng bảo mật là các vấn đề về an toàn bộ nhớ, NSA cho biết.
NSA cho biết: “Các ngôn ngữ được sử dụng phổ biến, chẳng hạn như C và C++, cung cấp rất nhiều sự tự do và linh hoạt trong việc quản lý bộ nhớ trong khi phụ thuộc rất nhiều vào lập trình viên để thực hiện các kiểm tra cần thiết đối với các tham chiếu bộ nhớ”. Điều này thường dẫn đến các lỗ hổng có thể khai thác gắn liền với các lỗi đơn giản như lỗi tràn bộ đệm, vấn đề cấp phát bộ nhớ và điều kiện chủng tộc.
NSA cho biết trong lời khuyên của mình rằng C#, Go, Java, Ruby, Rust, Swift và các ngôn ngữ an toàn cho bộ nhớ khác không loại bỏ hoàn toàn rủi ro của những vấn đề này. Ví dụ, hầu hết chúng bao gồm ít nhất một vài lớp hoặc chức năng không an toàn cho bộ nhớ và cho phép lập trình viên thực hiện chức năng quản lý bộ nhớ có khả năng không an toàn. Các ngôn ngữ an toàn cho bộ nhớ đôi khi cũng có thể bao gồm các thư viện được viết bằng các ngôn ngữ có chứa các chức năng bộ nhớ không an toàn tiềm tàng.
Nhưng ngay cả với những cảnh báo này, các ngôn ngữ an toàn cho bộ nhớ có thể giúp giảm lỗ hổng trong phần mềm NSA cho biết kết quả của việc quản lý bộ nhớ kém và bất cẩn.
Tim Mackey, chiến lược gia bảo mật chính tại Trung tâm Nghiên cứu An ninh mạng Synopsys, hoan nghênh khuyến nghị của NSA. Trên thực tế, việc sử dụng các ngôn ngữ an toàn cho bộ nhớ nên là mặc định cho hầu hết các ứng dụng, ông nói. Ông nói: “Đối với các mục đích thực tế, việc dựa vào các nhà phát triển để tập trung vào các vấn đề quản lý bộ nhớ thay vì lập trình các tính năng mới thú vị sẽ thể hiện sự đánh thuế đối với sự đổi mới. Mackey cho biết, với các ngôn ngữ lập trình an toàn cho bộ nhớ và các khung liên quan, chính tác giả của ngôn ngữ đảm bảo quản lý bộ nhớ thích hợp chứ không phải các nhà phát triển ứng dụng.
Thay đổi có thể là thử thách
NSA thừa nhận rằng việc chuyển đổi một môi trường phát triển phần mềm trưởng thành từ ngôn ngữ này sang ngôn ngữ khác có thể khó khăn. Các lập trình viên sẽ cần phải học ngôn ngữ mới, và có khả năng sẽ có những lỗi của người mới và hiệu quả đạt được trong quá trình này. Mức độ bảo mật bộ nhớ khả dụng cũng có thể thay đổi đáng kể theo ngôn ngữ. Một số có thể chỉ cung cấp bảo mật bộ nhớ tối thiểu, trong khi một số khác cung cấp các biện pháp bảo vệ đáng kể xung quanh việc truy cập, cấp phát và quản lý bộ nhớ.
Ngoài ra, các tổ chức sẽ cần xem xét mức độ đánh đổi mà họ sẵn sàng thực hiện giữa bảo mật và hiệu suất. NSA cảnh báo: “An toàn bộ nhớ có thể tốn kém về hiệu suất và tính linh hoạt. “Đối với các ngôn ngữ có mức độ bảo vệ cố hữu cực cao, có thể cần phải thực hiện nhiều công việc chỉ để biên dịch chương trình do quá trình kiểm tra và bảo vệ.”
Mike Parkin, kỹ sư kỹ thuật cấp cao của Vulcan Cyber cho biết, có vô số biến số khi cố gắng chuyển một ứng dụng từ ngôn ngữ này sang ngôn ngữ khác. Parkin nói: “Trong trường hợp tốt nhất, việc chuyển đổi rất đơn giản và một tổ chức có thể hoàn thành nó một cách tương đối dễ dàng. “Ở những nơi khác, ứng dụng dựa trên các tính năng tầm thường trong ngôn ngữ gốc nhưng yêu cầu sự phát triển rộng rãi và tốn kém để tạo lại trong ngôn ngữ mới.”
Mackey cảnh báo rằng việc sử dụng các ngôn ngữ an toàn cho bộ nhớ cũng không thay thế được nhu cầu kiểm tra phần mềm thích hợp. Chỉ vì ngôn ngữ lập trình an toàn với bộ nhớ không có nghĩa là ngôn ngữ hoặc ứng dụng được phát triển trên ngôn ngữ đó không có lỗi.
Mackey nói: Chuyển từ ngôn ngữ lập trình này sang ngôn ngữ lập trình khác là một đề xuất mạo hiểm trừ khi bạn có đội ngũ nhân viên đã hiểu cả ngôn ngữ cũ và ngôn ngữ mới. “Việc di chuyển như vậy được thực hiện tốt nhất khi ứng dụng đang trải qua một bản cập nhật phiên bản chính; nếu không, có khả năng các lỗi vô tình được đưa vào như một phần của nỗ lực di chuyển,” ông lưu ý.
Mackey gợi ý rằng các tổ chức nên cân nhắc sử dụng microservice khi cần thay đổi ngôn ngữ. Mackey nói: “Với kiến trúc microservices, ứng dụng được phân tách thành một tập hợp các dịch vụ được chứa trong bộ chứa. “Từ quan điểm của một ngôn ngữ lập trình, không có gì bắt buộc mỗi dịch vụ siêu nhỏ phải được lập trình bằng cùng một ngôn ngữ lập trình như các dịch vụ khác trong cùng một ứng dụng.”
Thực hiện Di chuyển
Dữ liệu gần đây từ Statista cho thấy rằng nhiều nhà phát triển đã sử dụng ngôn ngữ được coi là bộ nhớ an toàn. Ví dụ, gần hai phần ba (65.6%) sử dụng JavaScript, gần một nửa (48.06%) sử dụng Python, một phần ba sử dụng Java và gần 28% sử dụng C#. Đồng thời, một tỷ lệ đáng kể vẫn đang sử dụng các ngôn ngữ không an toàn như C++ (22.5%) và C (19.25%).
Johannes Ullrich, trưởng khoa nghiên cứu tại Viện Công nghệ SANS cho biết: “Tôi nghĩ rằng nhiều tổ chức đã chuyển sang sử dụng C/C++ không chỉ vì vấn đề an toàn bộ nhớ mà còn vì sự dễ dàng trong việc phát triển và bảo trì nói chung. “Nhưng vẫn sẽ có những cơ sở mã kế thừa sẽ phải duy trì trong nhiều năm tới.”
Cố vấn của NSA đưa ra một chút hiểu biết sâu sắc về những gì có thể đã thúc đẩy khuyến nghị của họ vào thời điểm này. Nhưng John Bambenek, thợ săn mối đe dọa chính tại Netenrich, khuyên rằng các tổ chức không nên bỏ qua nó. Ông nói: “Các lỗ hổng bộ nhớ và các cuộc tấn công đã phổ biến từ những năm 1990, vì vậy nhìn chung, đây là lời khuyên tốt. “Như đã nói, vì điều này đến từ NSA, tôi tin rằng lời khuyên này cần được cấp bách hơn nữa và đang được thúc đẩy bởi kiến thức mà họ có còn chúng tôi thì không.”
