Trình biên dịch có thể vô hiệu hóa các lớp bảo vệ bảo mật của bạn

Bạn có thể viết mã C an toàn, tuân thủ đầy đủ các nguyên tắc tốt nhất được giới chuyên gia khuyến nghị, và vẫn tạo ra một bản binary chứa lỗ hổng. Lý do rất đơn giản: CPU không chạy mã nguồn của bạn, mà chạy bất cứ thứ gì trình biên dịch tạo ra. Tại hội nghị Black Hat USA 2026, nhà nghiên cứu bảo mật Chris Domas đã ngồi lại với David Bombal để phân tích cách những tối ưu hóa hợp lệ của trình biên dịch có thể âm thầm phá hủy các lớp bảo vệ mà lập trình viên tin tưởng.

Khi trình biên dịch "dọn dẹp" các biện pháp bảo mật

Điểm mấu chốt mà Chris Domas nhấn mạnh là khoảng cách giữa mã nguồn và bản binary thực thi. Trình biên dịch được phép biến đổi mã một cách mạnh mẽ miễn là giữ nguyên hành vi quan sát được theo đặc tả của C — gọi là C abstract machine. Nhưng chính sự tự do đó lại mở ra cánh cửa cho những hệ quả ngoài ý muốn.

• Các thao tác xóa bộ nhớ nhạy cảm có thể bị loại bỏ hoàn toàn vì trình biên dịch cho rằng chúng "không còn tác dụng".
• Những biện pháp kiểm tra bảo mật có thể bị tối ưu hóa ra khỏi luồng thực thi.
• Các lỗ hổng kiểu TOCTOU (time-of-check to time-of-use) có thể xuất hiện trong đoạn mã trông có vẻ an toàn tuyệt đối.

Điều đáng lo ngại là trình biên dịch không hề "phá hoại" theo nghĩa đen — nó chỉ đang thực hiện đúng những gì được cho phép.

Những yếu tố tưởng như vô hại lại quyết định lỗ hổng

Chris Domas chỉ ra rằng áp lực thanh ghi (register pressure), cách bố trí cấu trúc dữ liệu, và thậm chí cả kích thước dữ liệu đều có thể ảnh hưởng đến việc một bản binary có lỗ hổng hay không.

Một ví dụ gây sốc: trong cùng một đoạn mã, kích thước 17 byte hoặc 33 byte có thể an toàn, nhưng những kích thước lân cận lại tạo ra mã dễ bị khai thác. Đây là kiểu hành vi mà rất ít lập trình viên có thể đoán trước khi đọc mã nguồn.

"Đừng bỏ cuộc trong việc viết mã an toàn" — lời khuyên xuyên suốt của Chris Domas trong buổi trò chuyện.

Chuyển sang Rust hay đổi trình biên dịch có giải quyết được không?

Câu trả lời ngắn gọn là không hoàn toàn. Chris Domas cho rằng Rust không giải quyết triệt để vấn đề này, và việc chuyển qua lại giữa GCC và Clang cũng chẳng phải giải pháp — bởi vì bản chất của vấn đề nằm ở mô hình trừu tượng và các tối ưu hóa, chứ không nằm ở một trình biên dịch cụ thể nào.

Điểm thú vị là AI đã được sử dụng để phân tích 500 triệu dòng mã nguồn mở, từ đó xác định khoảng 300 mẫu (pattern) có khả năng nguy hiểm. Đây là một trong những ứng dụng thực tiễn đáng chú ý của AI trong lĩnh vực kiểm tra bảo mật mã nguồn quy mô lớn.

Lập trình viên cần làm gì ngay bây giờ?

Chris Domas đưa ra một loạt khuyến nghị thiết thực, có thể áp dụng ngay trong quy trình phát triển:

• Bật cảnh báo của trình biên dịch ở mức nghiêm ngặt nhất có thể.
• Sử dụng sanitizer để phát hiện các hành vi bất thường khi chạy.
• Phân tích các bản build đã tối ưu hóa, chứ không chỉ phân tích mã nguồn.
• Kiểm thử chính xác bản binary sẽ được phát hành — không phải bản debug hay bản build khác cấu hình.

Với các lập trình viên Việt Nam, đặc biệt là những bạn đang làm việc với hệ thống nhúng, IoT hoặc các sản phẩm phần mềm sử dụng C/C++, đây là lời nhắc nhở quan trọng: quy trình kiểm thử và đánh giá bảo mật cần được thực hiện trên đúng phiên bản mã máy sẽ chạy thực tế, chứ không dừng lại ở mức đọc hiểu mã nguồn.

Có thể bạn sẽ không bao giờ nhìn vào trình biên dịch với ánh mắt hoàn toàn tin tưởng như trước nữa.