Tại sao rất khó để làm cho C ít bị tràn bộ đệm?

Tôi đang tham gia một khóa học ở trường đại học, nơi một trong những phòng thí nghiệm là thực hiện khai thác tràn bộ đệm trên mã mà họ cung cấp cho chúng tôi. Điều này bao gồm các khai thác đơn giản như thay đổi địa chỉ trả về cho một hàm trên ngăn xếp để trở về một chức năng khác, tất cả các cách để mã thay đổi trạng thái đăng ký / bộ nhớ chương trình nhưng sau đó quay lại hàm mà bạn đã gọi, nghĩa là chức năng bạn gọi là hoàn toàn không biết gì về khai thác.

Tôi đã thực hiện một số nghiên cứu về vấn đề này và các loại khai thác này được sử dụng khá nhiều ở mọi nơi ngay cả bây giờ, trong những việc như chạy homebrew trên Wii và jailbreak không giới hạn cho iOS 4.3.1

Câu hỏi của tôi là tại sao vấn đề này rất khó khắc phục? Rõ ràng đây là một khai thác chính được sử dụng để hack hàng trăm thứ, nhưng có vẻ như nó sẽ khá dễ dàng để khắc phục bằng cách cắt ngắn mọi đầu vào vượt quá độ dài cho phép và chỉ cần vệ sinh tất cả đầu vào mà bạn lấy.

EDIT: Một viễn cảnh khác mà tôi muốn có câu trả lời để xem xét - tại sao những người tạo ra C không khắc phục những vấn đề này bằng cách thực hiện lại các thư viện?

Họ đã sửa các thư viện.

Bất kỳ thư viện chuẩn C hiện đại chứa biến thể an toàn hơn strcpy, strcat, sprintf, và vân vân.

Trên các hệ thống C99 - hầu hết các Unix - bạn sẽ tìm thấy những cái này có tên như strncatvà snprintf, "n" chỉ ra rằng nó cần một đối số có kích thước của bộ đệm hoặc số lượng phần tử tối đa để sao chép.

Các chức năng này có thể được sử dụng để xử lý nhiều hoạt động an toàn hơn, nhưng nhìn lại khả năng sử dụng của chúng là không lớn. Ví dụ, một số snprintftriển khai không đảm bảo bộ đệm bị hủy kết thúc. strncatmất một số yếu tố để sao chép, nhưng nhiều người nhầm lẫn vượt qua kích thước của bộ đệm mệnh.

Trên Windows, người ta thường tìm thấy strcat_s, sprintf_sthì "_s" hậu tố cho biết "an toàn". Những thứ này cũng đã tìm được đường vào thư viện chuẩn C trong C11 và cung cấp thêm quyền kiểm soát đối với những gì xảy ra trong trường hợp tràn (ví dụ cắt ngắn so với khẳng định).

Nhiều nhà cung cấp thậm chí còn cung cấp nhiều lựa chọn thay thế không chuẩn hơn như asprintftrong libc GNU, sẽ tự động phân bổ một bộ đệm có kích thước phù hợp.

Ý tưởng rằng bạn có thể "chỉ sửa C" là một sự hiểu lầm. Sửa C không phải là vấn đề - và đã được thực hiện. Vấn đề là sửa hàng thập kỷ mã C được viết bởi các lập trình viên dốt nát, mệt mỏi hoặc vội vã hoặc mã được chuyển từ các bối cảnh mà an ninh không quan trọng đối với bối cảnh bảo mật. Không có thay đổi nào đối với thư viện chuẩn có thể sửa mã này, mặc dù việc di chuyển sang trình biên dịch mới hơn và thư viện chuẩn thường có thể giúp xác định các vấn đề tự động.

Thật sự không chính xác khi nói rằng C thực sự "dễ bị lỗi" theo thiết kế . Ngoài một số sai lầm nghiêm trọng như gets, ngôn ngữ C thực sự không thể là bất kỳ cách nào khác mà không làm mất tính năng chính thu hút mọi người đến C ngay từ đầu.

C được thiết kế như một ngôn ngữ hệ thống để hoạt động như một loại "lắp ráp di động". Một tính năng chính của ngôn ngữ C là không giống như các ngôn ngữ cấp cao hơn, mã C thường ánh xạ rất sát với mã máy thực tế. Nói cách khác, ++ithường chỉ là một inchướng dẫn và bạn thường có thể có được một ý tưởng chung về những gì bộ xử lý sẽ làm trong thời gian chạy bằng cách xem mã C.

Nhưng việc thêm vào kiểm tra giới hạn ngầm sẽ bổ sung thêm rất nhiều chi phí - chi phí mà lập trình viên không yêu cầu và có thể không muốn. Chi phí này vượt xa dung lượng lưu trữ bổ sung cần thiết để lưu trữ độ dài của mỗi mảng hoặc các hướng dẫn bổ sung để kiểm tra giới hạn mảng trên mỗi truy cập mảng. Số học con trỏ thì sao? Hoặc nếu bạn có một hàm lấy con trỏ thì sao? Môi trường thời gian chạy không có cách nào để biết liệu con trỏ đó có nằm trong giới hạn của khối bộ nhớ được phân bổ hợp pháp hay không. Để theo dõi điều này, bạn cần một số kiến ​​trúc thời gian chạy nghiêm túc có thể kiểm tra từng con trỏ dựa vào bảng các khối bộ nhớ hiện được phân bổ, tại thời điểm đó chúng ta đã đi vào lãnh thổ thời gian chạy được quản lý theo kiểu Java / C #.

Tôi nghĩ rằng vấn đề thực sự không phải là các loại lỗi rất khó để sửa chữa, nhưng điều đó họ rất dễ dàng để thực hiện: Nếu bạn sử dụng strcpy, sprintfvà bạn bè trong (dường như) Cách đơn giản nhất là công việc có thể, sau đó bạn đã có thể mở cửa cho một tràn bộ đệm. Và không ai sẽ nhận thấy nó cho đến khi ai đó khai thác nó (trừ khi bạn có đánh giá mã rất tốt). Bây giờ hãy thêm một thực tế là có rất nhiều lập trình viên tầm thường và họ luôn chịu áp lực về thời gian - và bạn có một công thức mã bị xáo trộn với bộ đệm tràn đến mức khó có thể khắc phục tất cả chỉ vì có rất nhiều người trong số họ và họ đang trốn rất tốt.

Thật khó để sửa lỗi tràn bộ đệm vì C hầu như không cung cấp công cụ hữu ích nào để giải quyết vấn đề. Đó là một lỗ hổng ngôn ngữ cơ bản mà các bộ đệm bản địa cung cấp không có bảo vệ và nó hầu như, nếu không hoàn toàn, không thể thay thế chúng bằng một sản phẩm cao cấp, giống như C ++ đã làm với std::vectorvà std::array, và thật khó ngay cả dưới chế độ gỡ lỗi để tìm đệm tràn.

Vấn đề không phải là với C ngôn ngữ .

IMO, trở ngại lớn duy nhất cần vượt qua là C chỉ đơn giản là dạy xấu . Hàng thập kỷ thực hành xấu và thông tin sai đã được thể chế hóa trong các tài liệu tham khảo và ghi chú bài giảng, đầu độc tâm trí của mỗi thế hệ lập trình viên mới ngay từ đầu. Học sinh được cung cấp một mô tả ngắn gọn về các chức năng I / O "dễ dàng" như gets¹ hoặc scanfsau đó để lại cho các thiết bị của riêng họ. Họ không cho biết những công cụ đó có thể thất bại ở đâu hoặc làm thế nào để ngăn chặn những thất bại đó. Họ không nói về việc sử dụng fgetsvàstrtol/strtodbởi vì những công cụ được coi là "tiên tiến". Sau đó, họ tung ra thế giới chuyên nghiệp để tàn phá thế giới của họ. Không phải là nhiều lập trình viên có kinh nghiệm hơn biết nhiều hơn, bởi vì họ nhận được cùng một nền giáo dục bị tổn thương não. Thật điên rồ. Tôi thấy rất nhiều câu hỏi ở đây và trên Stack Overflow và trên các trang web khác, nơi rõ ràng rằng người hỏi câu hỏi đang được dạy bởi một người chỉ đơn giản là không biết họ đang nói về điều gì , và tất nhiên bạn không thể nói "Giáo sư của bạn sai," bởi vì anh ta là Giáo sư và bạn chỉ là một người trên Internet.

Và sau đó, bạn có đám đông coi thường bất kỳ câu trả lời nào bắt đầu bằng "tốt, theo tiêu chuẩn ngôn ngữ ..." bởi vì họ đang làm việc trong thế giới thực và theo họ, tiêu chuẩn này không áp dụng cho thế giới thực . Tôi có thể đối phó với một người chỉ có một nền giáo dục tồi tệ, nhưng bất cứ ai khăng khăng không biết gì cũng chỉ là một sự tàn phá trong ngành.

Sẽ không có vấn đề tràn bộ đệm nếu ngôn ngữ được dạy chính xác với sự nhấn mạnh vào việc viết mã bảo mật. Nó không "cứng", nó không "tiên tiến", nó chỉ cẩn thận.

Vâng, đây đã là một cơn thịnh nộ.

Vấn đề là một trong những sự thiển cận của người quản lý hơn là sự bất tài của lập trình viên. Hãy nhớ rằng, một ứng dụng 90.000 dòng chỉ cần một thao tác không an toàn là hoàn toàn không an toàn. Gần như không có khả năng rằng bất kỳ ứng dụng nào được viết trên đầu xử lý chuỗi không an toàn về cơ bản sẽ hoàn hảo 100% - điều đó có nghĩa là nó sẽ không an toàn.

Vấn đề là chi phí không an toàn sẽ không được tính cho người nhận đúng (công ty bán ứng dụng sẽ gần như không bao giờ phải hoàn trả giá mua) hoặc không thể thấy rõ tại thời điểm quyết định được đưa ra ("Chúng tôi phải giao hàng vào tháng 3 không có vấn đề gì! "). Tôi khá chắc chắn rằng nếu bạn chú ý đến chi phí và chi phí dài hạn cho người dùng thay vì lợi nhuận của công ty bạn, thì việc viết bằng C hoặc các ngôn ngữ liên quan sẽ tốn kém hơn nhiều, có thể đắt đến mức rõ ràng là lựa chọn sai ở nhiều người lĩnh vực mà ngày nay trí tuệ thông thường nói rằng đó là một điều cần thiết. Nhưng điều đó sẽ không thay đổi trừ khi trách nhiệm phần mềm chặt chẽ hơn được đưa ra - điều mà không ai trong ngành muốn.

Một trong những sức mạnh tuyệt vời của việc sử dụng C là nó cho phép bạn thao tác bộ nhớ theo bất kỳ cách nào bạn thấy phù hợp.

Một trong những điểm yếu lớn của việc sử dụng C là nó cho phép bạn thao tác bộ nhớ theo bất kỳ cách nào bạn thấy phù hợp.

Có phiên bản an toàn của bất kỳ chức năng không an toàn. Tuy nhiên, các lập trình viên và trình biên dịch không thực thi nghiêm ngặt việc sử dụng của họ.

Tại sao những người tạo ra C không khắc phục những vấn đề này bằng cách thực hiện lại các thư viện?

Có lẽ vì C ++ đã làm điều này và tương thích ngược với mã C. Vì vậy, nếu bạn muốn một loại chuỗi an toàn trong mã C của mình, bạn chỉ cần sử dụng std :: string và viết mã C của mình bằng trình biên dịch C ++.

Hệ thống con bộ nhớ cơ bản có thể giúp ngăn chặn lỗi tràn bộ đệm bằng cách giới thiệu các khối bảo vệ và kiểm tra tính hợp lệ của chúng - vì vậy tất cả các phân bổ đều có 4 byte 'fefefefe' được thêm vào, khi các khối này được ghi vào, hệ thống có thể ném một wobbler. Nó không được đảm bảo để ngăn chặn việc ghi bộ nhớ, nhưng nó sẽ cho thấy rằng đã xảy ra lỗi và cần phải sửa.

Tôi nghĩ vấn đề là các thói quen strcpy cũ vẫn còn tồn tại. Nếu chúng được loại bỏ có lợi cho strncpy, vv thì điều đó sẽ giúp ích.

Thật đơn giản để hiểu tại sao vấn đề tràn không được khắc phục. C đã bị thiếu sót trong một vài lĩnh vực. Tại thời điểm những sai sót được coi là có thể chấp nhận được hoặc thậm chí là một tính năng. Bây giờ nhiều thập kỷ sau những sai sót đó là không thể sửa chữa.

Một số phần của cộng đồng lập trình không muốn những lỗ đó được cắm. Chỉ cần nhìn vào tất cả các cuộc chiến ngọn lửa bắt đầu qua chuỗi, mảng, con trỏ, bộ sưu tập rác ...