Наскільки небезпечним є доступ до масиву поза межами?

Наскільки небезпечним є доступ до масиву поза його межами (в С)? Іноді може траплятися, що я читаю з-за масиву (тепер я розумію, що потім отримую доступ до пам’яті, яка використовується в деяких інших частинах моєї програми або навіть поза цим) або намагаюся встановити значення індексу поза масивом. Програма іноді виходить з ладу, але іноді просто працює, даючи лише несподівані результати.

Тепер, що я хотів би знати, наскільки це насправді небезпечно? Якщо це шкодить моїй програмі, це не так вже й погано. Якщо, з іншого боку, щось зламає поза моєю програмою, тому що я якось встиг отримати доступ до якоїсь абсолютно не пов'язаної пам’яті, я думаю, це дуже погано. Я читав багато "все, що може статися", "сегментація може бути найменш поганою проблемою" , "ваш жорсткий диск може стати рожевим, і єдинороги можуть співати під вашим вікном", що все приємно, але яка насправді небезпека?

Мої запитання:

1. Чи може зчитування значень із шляху поза масивом пошкоджувати щось, крім моєї програми? Я б міг уявити, що дивлячись на речі нічого не змінюється, чи це, наприклад, змінить атрибут "в останній раз відкритий" файлу, до якого я потрапив?
2. Чи може встановлення значень, що виходять за межі масиву, пошкодити щось, крім моєї програми? З цього питання щодо переповнення стека я розумію, що можна отримати доступ до будь-якого місця пам'яті, що немає гарантії безпеки.
3. Зараз я запускаю свої невеликі програми зсередини XCode. Чи забезпечує це додатковий захист навколо моєї програми, коли вона не може вийти за межі власної пам'яті? Чи може це нашкодити XCode?
4. Будь-які рекомендації щодо безпечного запуску коду помилки?

Я використовую OSX 10.7, Xcode 4.6.

Що стосується стандарту ISO C (офіційне визначення мови), то доступ до масиву поза його межами має " невизначене поведінку ". Буквальний сенс цього полягає в:

поведінка при використанні неподатної або помилкової конструкції програми або помилкових даних, до яких цей Міжнародний стандарт не пред'являє жодних вимог

На це поширюється ненормативна примітка:

Можлива невизначена поведінка варіюється від ігнорування ситуації повністю з непередбачуваними результатами, до поведінки під час перекладу чи виконання програми в документально підтвердженому для середовища середовищі (з видачею діагностичного повідомлення або без нього), до припинення перекладу чи виконання (з видачею діагностичного повідомлення).

Так це теорія. Яка реальність?

У кращому випадку ви отримаєте доступ до частини пам'яті, яка або належить вашій поточній програмі (що може спричинити неправильну поведінку вашої програми), або не належить вашій запущеній програмі (що, ймовірно, спричинить вашу програму збої з чимось на зразок помилки сегментації). Або ви можете спробувати записати в пам'ять, якою володіє ваша програма, але це позначено лише для читання; це, ймовірно, також призведе до збою вашої програми.

Це припустимо, що ваша програма працює в операційній системі, яка намагається захистити одночасно запущені процеси один від одного. Якщо ваш код працює на «голому металі», скажіть, якщо він є частиною ядра ОС або вбудованої системи, то такого захисту немає; ваш недобросовісний код - це те, що повинно було забезпечити цей захист. У цьому випадку можливості пошкодження значно більше, включаючи, в деяких випадках, фізичне пошкодження обладнання (або речей або людей, які знаходяться поблизу).

Навіть у захищеному середовищі ОС захист не завжди є 100%. Існують помилки в операційній системі, які дозволяють, наприклад, непривілейованим програмам отримувати кореневий (адміністративний) доступ. Навіть із звичайними привілеями користувача, несправна програма може споживати зайві ресурси (процесор, пам'ять, диск), можливо, знищуючи всю систему. Багато шкідливих програм (вірусів тощо) використовує надмірну кількість буферів для отримання несанкціонованого доступу до системи.

(Один історичний приклад: я чув, що в деяких старих системах з основною пам'яттю багаторазовий доступ до одного місця пам’яті в тісному циклі може буквально спричинити плавлення цієї пам’яті. Інші можливості включають знищення дисплея CRT та переміщення прочитаного / запишіть голову дисковода з гармонійною частотою шафи накопичувача, змусивши його пройти по столу і впасти на підлогу.)

І завжди існує хвилювання Skynet .

Суть полягає в наступному: якщо ви могли б написати програму , щоб зробити що - то погане свідомо , це по крайней мере , теоретично можливо , що глючить програма може робити те ж саме випадково .

На практиці, це дуже малоймовірно , що ваш баггі програма працює на системі MacOS X збирається зробити що - небудь серйозніше , ніж аварії. Але повністю запобігти помилковому коду неможливо зробити дійсно погані речі.

Загалом, сьогоднішні операційні системи (популярні в будь-якому випадку) запускають усі програми в захищених регіонах пам'яті за допомогою віртуального менеджера пам'яті. Виявляється, не просто ЛЕГКО (за скажімо) просто читати або записувати до місця, яке існує в РЕАЛЬНОМУ просторі за межами регіону, який був призначений / виділений для вашого процесу.

Прямі відповіді:

1) Читання майже ніколи не завдає шкоди іншому процесу, однак це може побічно пошкодити процес, якщо трапиться прочитати значення KEY, яке використовується для шифрування, дешифрування або перевірки програми / процесу. Читання поза межами може вплинути на ваш код дещо негативно / несподівано, якщо ви приймаєте рішення на основі даних, які читаєте

2) Єдиний спосіб, коли ви могли дійсно ПІДТВОРИТИ щось, записуючи на адресу, доступну за адресою пам’яті, якщо ця адреса пам’яті, до якої ви пишете, - це фактично апаратний реєстр (місце, яке насправді не для зберігання даних, а для керування частиною) апаратного забезпечення) не місце оперативної пам'яті. Насправді, ви все одно звичайно не пошкоджуєте щось, якщо не пишете якесь програмоване одноразове місце, яке не підлягає повторному запису (або щось подібне).

3) Зазвичай, що працює всередині налагоджувача, запускає код у режимі налагодження. Запуск у режимі налагодження ТЕНДУЄ (але не завжди) швидше зупиняти ваш код, коли ви зробили щось, що вважається поза практикою або прямо незаконним.

4) Ніколи не використовуйте макроси, використовуйте структури даних, у яких вже вбудовані межі індексу масиву тощо.

ДОДАТКОВО Додам, що вищенаведена інформація справді лише для систем, що використовують операційну систему з вікнами захисту пам'яті. Якщо ви пишете код для вбудованої системи або навіть системи, що використовує операційну систему (в режимі реального часу чи іншу), яка не має вікон захисту пам’яті (або віртуальних адресованих вікон), слід бути набагато обережнішим у читанні та записі в пам'ять. Також у цих випадках завжди слід застосовувати безпечні та безпечні методи кодування, щоб уникнути проблем із безпекою.

Якщо не перевіряти межі, це може призвести до неприємних побічних ефектів, включаючи безпеку. Одне з негарних - це довільне виконання коду . У класичному прикладі: якщо у вас є масив фіксованого розміру, і ви використовуєте strcpy()для того, щоб помістити туди надану користувачем рядок, користувач може надати вам рядок, що переповнює буфер і перезаписує інші місця пам'яті, включаючи кодову адресу, куди повинен повернутися процесор, коли ваша функція закінчення.

Це означає, що ваш користувач може надіслати вам рядок, який призведе до того, що ваша програма по суті буде дзвонити exec("/bin/sh"), що перетворить її в оболонку, виконуючи все, що він хоче у вашій системі, включаючи збирання всіх ваших даних та перетворення машини на ботнет-вузол.

Докладніше про те, як це можна зробити, перегляньте розділ « Розбиття стека для розваги та прибутку» .

Ви пишете:

Я читав багато "все, що може статися", "сегментація може бути найменш поганою проблемою", "ваш жорсткий диск може стати рожевим, і єдинороги можуть співати під вашим вікном", що все приємно, але яка насправді небезпека?

Давайте так сказати: завантажте пістолет. Направляйте його за вікном без особливої ​​мети та вогню. Яка небезпека?

Питання в тому, що ви не знаєте. Якщо ваш код перезаписать щось, що збиває вашу програму, ви все в порядку, оскільки це зупинить його у визначеному стані. Однак якщо вона не виходить з ладу, проблеми починають виникати. Які ресурси перебувають під контролем вашої програми і що це може зробити для них? Які ресурси можуть потрапити під контроль вашої програми і що це може зробити для них? Я знаю принаймні одне головне питання, яке було викликане таким переповненням. Проблема полягала в начебто безглуздій статистичній функції, яка заплутала деяку незв’язану таблицю перетворення для виробничої бази даних. Результатом цього стало дуже дороге прибирання. Насправді було б набагато дешевше і простіше впоратися, якби ця проблема відформатувала жорсткі диски ... іншими словами: рожеві єдинороги можуть бути вашою найменшою проблемою.

Ідея, що ваша операційна система захистить вас, є оптимістичною. По можливості намагайтеся уникати виписування за межі.

Якщо ваша програма не працює як root або будь-який інший привілейований користувач, це не завдасть шкоди жодній вашій системі, тому, як правило, це може бути хорошою ідеєю.

Записуючи дані в якесь місце випадкової пам'яті, ви безпосередньо не «пошкодите» будь-яку іншу програму, що працює на вашому комп’ютері, оскільки кожен процес працює у власному просторі пам’яті.

Якщо ви спробуєте отримати доступ до будь-якої пам'яті, не виділеної вашому процесу, операційна система зупинить виконання вашої програми з помилкою сегментації.

Тож безпосередньо (без запуску root та прямого доступу до таких файлів, як / dev / mem) немає небезпеки, що ваша програма буде перешкоджати будь-якій іншій програмі, що працює у вашій операційній системі.

Тим не менш - і, напевно, про це ви чули з точки зору небезпеки - сліпо записуючи випадкові дані у випадкові місця пам'яті випадково, ви впевнені, що ви можете пошкодити все, що ви можете пошкодити.

Наприклад, ваша програма може захотіти видалити певний файл, заданий ім'ям файлу, який зберігається десь у вашій програмі. Якщо ви випадково просто перезаписали місце, де зберігається ім'я файлу, ви можете замість цього видалити зовсім інший файл.

NSArrays в Objective-C призначається певний блок пам'яті. Перевищення меж масиву означає, що ви отримаєте доступ до пам'яті, яка не призначена для масиву. Це означає:

1. Ця пам'ять може мати будь-яке значення. Неможливо дізнатися, чи є дані дійсними на основі вашого типу даних.
2. Ця пам'ять може містити конфіденційну інформацію, таку як приватні ключі або інші облікові дані користувачів.
3. Адреса пам'яті може бути недійсною або захищеною.
4. Пам'ять може мати змінне значення, оскільки до неї звертається інша програма або потік.
5. Інші речі використовують адресний простір пам’яті, наприклад, порти, зіставлені з пам’яттю.
6. Запис даних на невідому адресу пам’яті може призвести до збою вашої програми, перезапису пам’яті операційної пам’яті та, як правило, спричиняє випадання сонця.

З точки зору програми ви завжди хочете знати, коли ваш код перевищує межі масиву. Це може призвести до повернення невідомих значень, що призведе до збою вашої програми або надання недійсних даних.

Можливо, ви захочете спробувати скористатися memcheckінструментом у Valgrind під час тестування свого коду - він не сприймає порушення окремих меж масиву в межах кадру стека, але він повинен вирішити безліч інших проблем із пам’яттю, включаючи ті, які можуть спричинити тонкі, ширші проблеми, що виходять за межі однієї функції.

З посібника:

Memcheck - детектор помилок пам'яті. Він може виявити такі проблеми, які є загальними для програм C і C ++.

• Доступ до пам’яті ви не повинні, наприклад, розгортання та заниження блоків купи, перевищення вершини стека та доступ до пам’яті після її звільнення.
• Використання невизначених значень, тобто значень, які не були ініціалізовані, або які були отримані з інших неозначених значень.
• Неправильне звільнення пам'яті купи, наприклад, подвійне звільнення блоків купи, або невідповідне використання malloc / new / new [] проти безкоштовного / видалення / видалення []
• Перекриття покажчиків src та dst у memcpy та пов'язаних з ними функціях.
• Пам'ять протікає.

ETA: Хоча, як говорить відповідь Каза, це не панацея і не завжди дає найбільш корисний результат, особливо коли ви використовуєте захоплюючі схеми доступу.

Якщо ви коли-небудь займаєтесь програмуванням на рівні систем або програмованими вбудованими системами, дуже погані речі можуть трапитися, якщо ви запишете у випадкові місця пам'яті. Старіші системи та багато мікроконтролерів використовують IO, відображений на пам'яті, тому записування до місця пам'яті, яке відображається в периферійний регістр, може спричинити загрозу, особливо якщо це робиться асинхронно.

Приклад - програмування флеш-пам’яті. Режим програмування на мікросхемах пам'яті вмикається шляхом запису певної послідовності значень у конкретні місця у межах адресного діапазону чіпа. Якщо інший процес повинен був записувати в будь-яке інше місце в мікросхемі, поки це тривало, це призведе до збою циклу програмування.

У деяких випадках апаратне забезпечення обертає адреси навколо (більшість значущих біт / байт адреси ігнорується), тому записування на адресу поза межами фізичного адресного простору насправді призведе до того, що дані записуються прямо посередині.

І нарешті, більш старі процесори, такі як MC68000, можуть заблокуватись до того моменту, що лише апаратне скидання може змусити їх знову працювати. Не працював над ними пару десятиліть, але я вважаю, що коли виникає помилка в шині (неіснуюча пам'ять) при спробі обробляти виняток, вона просто зупиниться, доки не буде затверджено скидання обладнання.

Моя найбільша рекомендація - це кричущий штекер для продукту, але я не маю особистого інтересу до нього, і я жодним чином не пов'язаний з ними - але на основі декількох десятиліть програмування С та вбудованих систем, де надійність була критичною, ПК Gimpel Лінт не тільки виявить подібні помилки, він зробить з вас кращого програміста C / C ++, постійно натягуючи на вас про шкідливі звички.

Я також рекомендую ознайомитися зі стандартом кодування MISRA C, якщо ви можете комусь скопіювати копію. Я не бачив жодних останніх, але в старі дні вони дали хороше пояснення, чому ви повинні / не повинні робити те, що вони охоплюють.

Давно про вас, але про 2-й або 3-й раз, коли я отримую коридору або зависання від будь-якої програми, моя думка про те, що компанія виробляла, знижується вдвічі. Четвертий або п'ятий раз, і все, що пакет є, стає посудом, і я проїжджаю дерев’яну колу через центр пакету / диска, він прийшов, щоб переконатися, що він ніколи не повертається до мене.

Я працюю з компілятором для мікросхеми DSP, який свідомо генерує код, який отримує доступ один минулий кінець масиву з коду C, який не робить!

Це відбувається тому, що петлі побудовані так, що кінець ітерації попередньо вибирає деякі дані для наступної ітерації. Таким чином, попередньо встановлена ​​дата в кінці останньої ітерації ніколи фактично не використовується.

Написання подібного коду С посилається на невизначене поведінку, але це лише формальність із стандартного документа, що стосується максимальної переносимості.

Частіше, ні, програма, яка отримує доступ за межі, не є розумно оптимізованою. Це просто баггі. Код отримує деяке значення сміття, і, на відміну від оптимізованих циклів вищезгаданого компілятора, код потім використовує значення в наступних обчисленнях, тим самим пошкоджуючи їх.

Варто ловити помилки таким чином, і тому варто зробити поведінку невизначеною навіть тільки з цієї причини: щоб час запуску міг створити діагностичне повідомлення типу "перевищення масиву в рядку 42 main.c".

У системах з віртуальною пам’яттю може виникнути розподіл масиву таким чином, що наступна адреса знаходиться у незробленій області віртуальної пам’яті. Після цього доступ буде бомбити програму.

Зауважте, що в C нам дозволено створити вказівник, який знаходиться в кінці масиву. І цей покажчик повинен порівняти більше, ніж будь-який вказівник, на внутрішній масив. Це означає, що реалізація C не може розмістити масив прямо в кінці пам'яті, де адреса один плюс обернеться і буде виглядати менше, ніж інші адреси в масиві.

Тим не менш, доступ до неініціалізованих значень або за межами меж іноді є дійсною методикою оптимізації, навіть якщо не є максимально портативною. Це, наприклад, чому інструмент Valgrind не повідомляє про доступ до неініціалізованих даних, коли ці звернення трапляються, але лише тоді, коли значення пізніше використовується якимось чином, що може вплинути на результат програми. Ви отримуєте діагностику на кшталт "умовна гілка в xxx: nnn залежить від неініціалізованого значення", і іноді важко відстежити, звідки вона походить. Якби всі подібні звернення були негайно захоплені, було б багато помилкових позитивних результатів, що випливають з коду, оптимізованого компілятором, а також правильно оптимізованого кодом.

Якщо говорити про це, я працював з деяким кодеком від постачальника, який видав ці помилки під час перенесення в Linux та запуску під Valgrind. Але продавець переконав мене, що лише кілька бітвикористовуваного значення насправді походить з неініціалізованої пам'яті, і ці біти ретельно уникали логіки. Використовувалися лише хороші біти значення, і Valgrind не має можливості відстежувати окремий біт. Неініціалізований матеріал з’явився з прочитанням слова в кінці бітового потоку кодованих даних, але код знає, скільки бітів у потоці і не використовуватиме більше бітів, ніж насправді є. Оскільки доступ за межі кінця масиву бітових потоків не завдає ніякої шкоди архітектурі DSP (немає ні віртуальної пам’яті після масиву, ні портів, відображених у пам’яті, а адреса не обертається), це правильна техніка оптимізації.

"Не визначена поведінка" насправді не означає багато, тому що згідно з ISO C, просто включення заголовка, який не визначений у стандарті C, або виклик функції, яка не визначена в самій програмі або стандарті C, є прикладами невизначених поведінка. Невизначена поведінка не означає "не визначена ніким на планеті", просто "не визначена стандартом ISO C". Але, звичайно ж , іноді невизначений поведінка дійсно є абсолютно не визначений ніким.

Окрім власної програми, я не думаю, що ви нічого не зламаєте, в гіршому випадку ви спробуєте прочитати чи записати з адреси пам'яті, що відповідає сторінці, яку ядро ​​не призначило вашим процесам, створивши належне виключення і будучи вбитим (я маю на увазі ваш процес).