Việc sử dụng một trình biên dịch C lỗi thời có phải là một rủi ro bảo mật không?

Chúng tôi có một số hệ thống xây dựng trong sản xuất mà không ai quan tâm và những máy này chạy các phiên bản GCC cổ như GCC 3 hoặc GCC 2.

Và tôi không thể thuyết phục ban quản lý nâng cấp nó lên gần đây hơn: họ nói, "nếu không bị hỏng, đừng sửa nó".

Vì chúng tôi duy trì một cơ sở mã rất cũ (được viết vào những năm 80), mã C89 này sẽ biên dịch tốt trên các trình biên dịch này.

Nhưng tôi không chắc nên sử dụng những thứ cũ này.

Câu hỏi của tôi là:

Có thể sử dụng trình biên dịch C cũ làm tổn hại đến bảo mật của chương trình được biên dịch không?

CẬP NHẬT:

Mã tương tự được xây dựng bởi Visual Studio 2008 cho các mục tiêu Windows và MSVC chưa hỗ trợ C99 hoặc C11 (Tôi không biết liệu MSVC mới hơn có làm được không) và tôi có thể xây dựng nó trên hộp Linux của mình bằng GCC mới nhất. Vì vậy, nếu chúng ta chỉ thả vào một GCC mới hơn, nó có thể sẽ xây dựng tốt như trước đây.

Thật ra tôi sẽ tranh luận ngược lại.

Có một số trường hợp hành vi không được xác định bởi tiêu chuẩn C nhưng rõ ràng điều gì sẽ xảy ra với một "trình biên dịch câm" trên một nền tảng nhất định. Các trường hợp như cho phép một số nguyên đã ký tràn hoặc truy cập vào cùng một bộ nhớ mặc dù các biến thuộc hai loại khác nhau.

Các phiên bản gần đây của gcc (và tiếng kêu) đã bắt đầu coi những trường hợp này là cơ hội tối ưu hóa không quan tâm nếu chúng thay đổi cách thức hoạt động của nhị phân trong điều kiện "hành vi không xác định". Điều này rất tệ nếu codebase của bạn được viết bởi những người đối xử với C như một "trình biên dịch di động". Khi thời gian trôi qua, các trình tối ưu hóa đã bắt đầu xem xét các đoạn mã lớn hơn và lớn hơn khi thực hiện các tối ưu hóa này làm tăng khả năng nhị phân cuối cùng sẽ làm một việc gì đó ngoài "những gì một nhị phân được tạo bởi trình biên dịch câm" sẽ làm.

Có các trình biên dịch để khôi phục hành vi "truyền thống" (-fwrapv và -fno -rict-aliasing cho hai tôi đã đề cập ở trên), nhưng trước tiên bạn phải biết về chúng.

Mặc dù về nguyên tắc, một lỗi trình biên dịch có thể biến mã tuân thủ thành lỗ hổng bảo mật, tôi sẽ coi nguy cơ của điều này là không đáng kể trong sơ đồ lớn của mọi thứ.

Có những rủi ro trong cả hai khóa hành động.

Trình biên dịch cũ hơn có lợi thế về sự trưởng thành và bất cứ điều gì đã bị phá vỡ trong chúng có lẽ (nhưng không có gì đảm bảo) đã được xử lý thành công.

Trong trường hợp này, một trình biên dịch mới là một nguồn tiềm năng của các lỗi mới.

Mặt khác, trình biên dịch mới hơn đi kèm với công cụ bổ sung :

• Cả GCC và Clang hiện đều có tính năng khử trùng , có thể tạo thời gian chạy để phát hiện các hành vi không xác định thuộc nhiều loại khác nhau (Chandler Carruth, thuộc nhóm Google Compiler, tuyên bố năm ngoái rằng ông hy vọng chúng sẽ đạt được phạm vi bảo hiểm đầy đủ)
• Clang, ít nhất, có tính năng làm cứng , ví dụ tính toàn vẹn của Control Flow là về việc phát hiện các luồng điều khiển hi-hi, cũng có các công cụ cứng để bảo vệ chống lại các cuộc tấn công đập ngăn xếp (bằng cách tách phần luồng điều khiển của ngăn xếp khỏi phần dữ liệu) ; tính năng làm cứng nói chung là chi phí thấp (<1% chi phí CPU)
• Clang / LLVM cũng đang làm việc trên libFuzzer , một công cụ để tạo các bài kiểm tra đơn vị làm mờ công cụ khám phá không gian đầu vào của hàm được kiểm tra một cách thông minh (bằng cách điều chỉnh đầu vào để thực hiện các đường dẫn thực thi chưa được khám phá)

Thiết bị nhị phân của bạn với các chất khử trùng (Bộ khử trùng địa chỉ, Bộ khử trùng bộ nhớ hoặc Bộ khử trùng hành vi không xác định) và sau đó làm mờ nó ( ví dụ sử dụng American Fuzzy Lop ) đã phát hiện ra các lỗ hổng trong một số phần mềm cấu hình cao, ví dụ như bài viết này của LWN.net .

Những công cụ mới đó và tất cả các công cụ trong tương lai đều không thể truy cập được trừ khi bạn nâng cấp trình biên dịch.

Bằng cách ở trên một trình biên dịch không đủ mạnh, bạn sẽ vùi đầu vào cát và vượt qua những ngón tay mà không tìm thấy lỗ hổng nào. Nếu sản phẩm của bạn là mục tiêu có giá trị cao, tôi khuyên bạn nên xem xét lại.

Lưu ý: ngay cả khi bạn KHÔNG nâng cấp trình biên dịch sản xuất, bạn vẫn có thể muốn sử dụng trình biên dịch mới để kiểm tra lỗ hổng; lưu ý rằng vì đó là các trình biên dịch khác nhau, nên các đảm bảo được giảm bớt.

Mã biên dịch của bạn chứa các lỗi có thể bị khai thác. Các lỗi đến từ ba nguồn: Lỗi trong mã nguồn của bạn, lỗi trong trình biên dịch và thư viện và hành vi không xác định trong mã nguồn của bạn mà trình biên dịch biến thành lỗi. . tôi đến một số rác và là một lỗi).

Tỷ lệ lỗi trong mã được biên dịch của bạn có lẽ thấp do kiểm tra và sửa lỗi do báo cáo lỗi của khách hàng. Vì vậy, có thể đã có một số lượng lớn lỗi ban đầu, nhưng điều đó đã đi xuống.

Nếu bạn nâng cấp lên trình biên dịch mới hơn, bạn có thể mất các lỗi được giới thiệu bởi lỗi trình biên dịch. Nhưng tất cả các lỗi này sẽ là những lỗi mà kiến ​​thức của bạn không ai tìm thấy và không ai khai thác. Nhưng trình biên dịch mới có thể có lỗi riêng và các trình biên dịch mới hơn có xu hướng mạnh mẽ hơn để biến hành vi không xác định thành lỗi trong mã được biên dịch.

Vì vậy, bạn sẽ có rất nhiều lỗi mới trong mã được biên dịch của bạn; tất cả các lỗi mà tin tặc có thể tìm thấy và khai thác. Và trừ khi bạn thực hiện rất nhiều thử nghiệm và để lại mã của bạn với khách hàng để tìm lỗi trong một thời gian dài, nó sẽ kém an toàn hơn.

Nếu nó không bị hỏng, đừng sửa nó

Sếp của bạn nghe có vẻ đúng khi nói điều này, tuy nhiên, yếu tố quan trọng hơn , là bảo vệ an toàn đầu vào, đầu ra, tràn bộ đệm. Thiếu những thứ đó luôn luôn là liên kết yếu nhất trong chuỗi từ quan điểm đó bất kể trình biên dịch được sử dụng.

Tuy nhiên, nếu cơ sở mã là cổ xưa và công việc đã được đưa ra để giảm thiểu các điểm yếu của K & R C được sử dụng, chẳng hạn như thiếu an toàn loại, các lỗi không an toàn, v.v., hãy cân nhắc câu hỏi " Sẽ nâng cấp trình biên dịch lên C99 hiện đại hơn / Tiêu chuẩn C11 phá vỡ mọi thứ? "

Với điều kiện là có một đường dẫn rõ ràng để chuyển sang các tiêu chuẩn C mới hơn, có thể gây ra tác dụng phụ, tốt nhất nên thử một ngã ba của cơ sở mã cũ, đánh giá nó và đưa vào kiểm tra loại bổ sung, kiểm tra độ tỉnh táo và xác định xem có nâng cấp lên không trình biên dịch mới hơn có bất kỳ ảnh hưởng nào đến bộ dữ liệu đầu vào / đầu ra.

Sau đó, bạn có thể hiển thị cho sếp của mình, " Đây là cơ sở mã được cập nhật, được tái cấu trúc, phù hợp hơn với các tiêu chuẩn C99 / C11 được chấp nhận trong ngành ... ".

Đó là canh bạc sẽ phải được cân nhắc, rất cẩn thận , khả năng chống lại sự thay đổi có thể hiển thị ở đó trong môi trường đó và có thể từ chối chạm vào những thứ mới hơn.

BIÊN TẬP

Chỉ cần ngồi lại vài phút, nhận ra điều này, mã tạo K & R có thể đang chạy trên nền tảng 16 bit, rất có thể, việc nâng cấp lên trình biên dịch hiện đại hơn thực sự có thể phá vỡ cơ sở mã, theo suy nghĩ về kiến ​​trúc, mã 32 bit sẽ được tạo , điều này có thể có tác dụng phụ buồn cười trên các cấu trúc được sử dụng cho bộ dữ liệu đầu vào / đầu ra, đó là một yếu tố lớn khác để cân nhắc cẩn thận.

Ngoài ra, vì OP đã đề cập đến việc sử dụng Visual Studio 2008 để xây dựng cơ sở mã, sử dụng gcc có thể tạo ra môi trường cho MinGW hoặc Cygwin, có thể có sự thay đổi tác động đến môi trường, trừ khi, mục tiêu là dành cho Linux, thì nó sẽ là đáng để thử, có thể phải bao gồm các công tắc bổ sung cho trình biên dịch để giảm thiểu nhiễu trên cơ sở mã K & R cũ, điều quan trọng khác là thực hiện nhiều thử nghiệm để đảm bảo không có chức năng nào bị hỏng, có thể là một bài tập đau đớn.

Có thể sử dụng trình biên dịch C cũ làm tổn hại đến bảo mật của chương trình được biên dịch không?

Tất nhiên là có thể, nếu trình biên dịch cũ chứa các lỗi đã biết mà bạn biết sẽ ảnh hưởng đến chương trình của bạn.

Câu hỏi là, phải không? Để biết chắc chắn, bạn sẽ phải đọc toàn bộ nhật ký thay đổi từ phiên bản của bạn đến ngày hiện tại và kiểm tra từng lỗi được sửa trong nhiều năm.

Nếu bạn không tìm thấy bằng chứng nào về các lỗi trình biên dịch sẽ ảnh hưởng đến chương trình của bạn, thì việc cập nhật GCC chỉ vì lợi ích của nó có vẻ hơi hoang tưởng. Bạn sẽ phải nhớ rằng các phiên bản mới hơn có thể chứa các lỗi mới, chưa được phát hiện. Rất nhiều thay đổi đã được thực hiện gần đây với sự hỗ trợ của GCC 5 và C11.

Điều đó đang được nói, mã được viết trong những năm 80 rất có thể đã được lấp đầy bởi các lỗ hổng bảo mật và phụ thuộc vào hành vi được xác định kém, bất kể trình biên dịch. Chúng ta đang nói về C chuẩn trước đây.

Có một rủi ro bảo mật nơi một nhà phát triển độc hại có thể lẻn vào cửa sau thông qua lỗi trình biên dịch. Tùy thuộc vào số lượng lỗi đã biết trong trình biên dịch đang sử dụng, cửa hậu có thể trông ít nhiều không rõ ràng (trong mọi trường hợp, điểm chính là mã chính xác, ngay cả khi bị chập, ở cấp nguồn. một trình biên dịch không có lỗi sẽ không tìm thấy cửa hậu, vì cửa sau không tồn tại trong các điều kiện này). Để có thêm điểm từ chối, nhà phát triển độc hại cũng có thể tự mình tìm kiếm các lỗi trình biên dịch chưa biết trước đó. Một lần nữa, chất lượng của ngụy trang sẽ phụ thuộc vào sự lựa chọn các lỗi biên dịch được tìm thấy.

Cuộc tấn công này được minh họa trên chương trình sudo trong bài viết này . bcrypt đã viết một phần tiếp theo tuyệt vời cho các công cụ khai thác Javascript .

Ngoài mối quan tâm này, sự phát triển của trình biên dịch C đã được khai thác hành vi undefined hơn và nhiều hơn và nhiều hơn tích cực, do đó, mã C cũ mà đã được viết trong đức tin tốt sẽ thực sự được an toàn hơn biên soạn với một trình biên dịch C từ thời điểm đó, hoặc biên soạn tại -O0 (nhưng một số tối ưu hóa khai thác UB phá vỡ chương trình mới được giới thiệu trong các phiên bản mới của trình biên dịch ngay cả ở -O0 ).

Trình biên dịch cũ hơn có thể không có bảo vệ chống lại các cuộc tấn công hack đã biết. Ví dụ, bảo vệ đập ngăn xếp không được giới thiệu cho đến GCC 4.1 . Vì vậy, yeah, mã được biên dịch với trình biên dịch cũ hơn có thể dễ bị tổn thương theo cách mà trình biên dịch mới hơn bảo vệ chống lại.

Một khía cạnh khác phải lo lắng là sự phát triển của mã mới .

Trình biên dịch cũ hơn có thể có hành vi khác nhau đối với một số tính năng ngôn ngữ so với những gì được lập trình viên chuẩn hóa và mong đợi. Sự không phù hợp này có thể làm chậm sự phát triển và giới thiệu các lỗi tinh vi có thể bị khai thác.

Trình biên dịch cũ hơn cung cấp ít tính năng hơn (bao gồm cả tính năng ngôn ngữ!) Và cũng không tối ưu hóa. Các lập trình viên sẽ tìm cách khắc phục những thiếu sót này - ví dụ như bằng cách thực hiện lại các tính năng còn thiếu hoặc viết mã thông minh khó hiểu nhưng chạy nhanh hơn - tạo ra cơ hội mới để tạo ra các lỗi tinh vi.

Không

Lý do rất đơn giản, trình biên dịch cũ có thể có lỗi và khai thác cũ, nhưng trình biên dịch mới sẽ có lỗi và khai thác mới.

Bạn không "sửa" bất kỳ lỗi nào bằng cách nâng cấp lên trình biên dịch mới. Chuyển đổi các lỗi cũ và khai thác cho các lỗi và khai thác mới.

Có khả năng cao hơn là bất kỳ lỗi nào trong trình biên dịch cũ đều được biết đến và được ghi nhận là trái ngược với việc sử dụng trình biên dịch mới để có thể thực hiện các hành động để tránh những lỗi đó bằng cách mã hóa xung quanh chúng. Vì vậy, theo cách không đủ để làm đối số để nâng cấp. Chúng tôi có cùng các cuộc thảo luận nơi tôi làm việc, chúng tôi sử dụng GCC 4.6.1 trên cơ sở mã cho phần mềm nhúng và có một sự miễn cưỡng lớn (trong số quản lý) để nâng cấp lên trình biên dịch mới nhất vì sợ lỗi mới, không có giấy tờ.

Câu hỏi của bạn rơi vào hai phần:

• Rõ ràng: Có rủi ro lớn hơn trong việc sử dụng trình biên dịch cũ hơn (ít nhiều như trong tiêu đề của bạn)
• Tiềm ẩn: Làm thế nào tôi có thể thuyết phục quản lý để nâng cấp

Có lẽ bạn có thể trả lời cả hai bằng cách tìm ra một lỗ hổng có thể khai thác trong cơ sở mã hiện tại của bạn và cho thấy rằng một trình biên dịch mới hơn sẽ phát hiện ra nó. Tất nhiên, quản lý của bạn có thể nói rằng bạn đã thấy rằng với trình biên dịch cũ, nhưng bạn có thể chỉ ra rằng nó tốn rất nhiều công sức. Hoặc bạn chạy nó thông qua trình biên dịch mới để tìm lỗ hổng, sau đó khai thác nó, nếu bạn có thể / được phép biên dịch mã với trình biên dịch mới. Bạn có thể muốn trợ giúp từ một hacker thân thiện, nhưng điều đó phụ thuộc vào việc tin tưởng họ và có thể / được phép hiển thị cho họ mã (và sử dụng trình biên dịch mới).

Nhưng nếu hệ thống của bạn không tiếp xúc với tin tặc, có lẽ bạn nên quan tâm hơn đến việc liệu nâng cấp trình biên dịch có làm tăng hiệu quả của bạn hay không: Phân tích mã MSVS 2013 thường tìm thấy các lỗi tiềm ẩn sớm hơn MSVS 2010 và ít nhiều hỗ trợ C99 / C11 - không chắc chắn nếu nó chính thức, nhưng khai báo có thể theo các câu lệnh và bạn có thể khai báo các biến trong for-loops.