Наскільки безпечно складати фрагмент вихідного коду від випадкового незнайомця? [зачинено]

Припустимо, я переглядаю код, який надсилають претенденти на роботу, щоб підтвердити свою майстерність. Ясна річ, я не хочу запускати виконувані файли, які вони надсилають. Не настільки чітко, я краще не запускатимуть результат компіляції їх коду (просто, наприклад, Java дозволяє приховати виконуваний код у коментарях ).

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

Коли я користуюся Google для "вразливості компілятора", я отримую звернення - це оптимізація компілятора та викид коду, а також те, чи надійний код настільки безпечний, як передбачався вихідний вихідний код.

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

Це залежить.

Цей фрагмент файлу може видалити домашній каталог:

all:
    rm -rf ~

Отже, якщо вам потрібно скористатися інструментом (наприклад, cmake або makefile system), це не є безпечним. Просто залежить, наскільки шкідливий кодер.

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

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

Я майже впевнений, що десь у бізнесі є якісь розумні хлопці, які вже створили такий хак для певної мови та версії компілятора. Моє улюблене місце, щоб шукати щось подібне, мабуть, був би Міжнародний конкурс Забруднених С - (не знаю, чи є щось порівнянне для Java). Однак насправді, наскільки високим ви вважаєте ризик, передбачалося це

• заявник справляє на вас правдоподібне враження, що він дуже хоче роботу у вашій компанії (а не позов)

• хлопець не знає, скільки рецензування робиться у вас

• він / вона не знає, яку саме версію компілятора ви використовуєте

• він / вона не знає, чи використовуєте ви віртуальне середовище або онлайн-компілятор, просто щоб бути безпечним

• ви не приймаєте занадто великі програми, щоб їх ефективно переглядати

• ви не збираєте нічого, що вам виглядає підозріло

• у світі не так багато людей, які насправді знають, як технічно виконати таке завдання (а сам гуглінг не дасть тобі «швидкої рефлексу» чи навчального посібника з цього приводу, як ви вже самі з’ясували).

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

Ми маємо виділити кілька випадків:

1. Помилка в компіляторі. Як і кожна складна програма, у компілятора можуть бути помилки, і одна з цих помилок може бути корисною.
2. Троянський кінь. Зловмисник може змусити вас виконати якийсь довільний код як частину процесу компіляції. A Makefile, a build.xml, configureскрипт оболонки тощо. Технічно це пов'язано не з компіляцією коду зловмисника, а з налагодженням середовища компіляції.
3. Мови, які дозволяють запускати довільний код під час компіляції. Мова макросів Scala - це Scala, загальна мова макросу Lisp - звичайна Lisp, мова макросу шаблону Haskell - Haskell. Scala також має плагіни компілятора, які знову-таки є довільним кодом Scala, який працює під час компіляції. F # має провайдерів типів.
4. Мови, які дозволяють проводити обчислення Тьюрінга під час компіляції. Системи типу Scala та Haskell є повноцінними по Тьюрінгу, як і шаблони C ++. Ви можете змусити компілятор виконувати довільні обчислення Тьюрінга під час компіляції, включаючи, але не обмежуючись нескінченними циклами. Зауважте, що Turing-complete означає лише те, що ви можете обчислити кожну функцію, яку можна обчислити за Тюрінгом, це не означає, що ви можете отримати доступ до файлової системи або щось подібне. Але, ви можете зробити програму, для складання якої знадобиться нескінченно багато часу.
5. Дуже довгий час складання. Наприклад, правила C # для вирішення перевантажень настільки складні, що ви можете кодувати будь-яку проблему 3-SAT як роздільну здатність перевантаження C #. 3-SAT, звичайно, NP-комплект. Іншими словами, за нашими сучасними знаннями, неможливо знайти ефективний алгоритм роздільної здатності перевантаження в C #. Ви не можете змусити компіляцію тривати нескінченно багато часу, але це не потребує великої програми, щоб компіляція зайняла більше часу, ніж життя Всесвіту, що практично те саме.

№4. та №5. максимум призведе до відмови у наданні послуги. Практично компілятори C ++ і Scala обмежують кількість рекурсії, яку ви можете зробити, так що насправді неможливо написати нескінченний цикл. У Scala це лише обмеження на реалізацію, але в C ++ це дозволяє явно дозволено специфікацією.

№2. технічно виходить за рамки питання, оскільки питання стосувалося компіляції коду, а не його запуску (OTOH, є глибокий філософський питання: якщо перевірка типу Haskell програма може виконати довільну обчислення Тьюрінга, це компіляція чи запуск програми?)

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

Це залишає нас на рівні 3. Деякі компілятори можуть обмежувати тип доступу, який має часовий код компіляції до системи, але для деяких випадків використання повний доступ неминучий. Приміром постачальників типів F #, наприклад, є "підробка" синтетичних типів для даних, система типів яких не відповідає F # 's, щоб ви могли взаємодіяти, скажімо, з веб-службою, що має схему WSDL в сильно набраному типі. мода. Однак для цього постачальнику типів потрібно мати доступ до ресурсу схеми WSDL або у файловій системі, або в Інтернеті, тому для цього потрібно мати файлову систему та доступ до мережі.

Отже, це безпечно? Технічно ні. Це ризиковано? Не зовсім.

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

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

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

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

По-перше, ми можемо поглянути на різні текстові редактори. Здається, найкращі редактори - найпростіші. Vi, якщо ви використовуєте оболонку Linux або Блокнот, якщо ви працюєте в Windows. Щось без можливостей форматування, без аналізу, просто перегляд даних у прямому напрямку та автоматичне припинення розбору, якщо один символ знаходиться поза поточною схемою кодування. Навіть Notepad ++ мав кілька вразливих місць. Уникайте нічого складного при перегляді недовірених файлів.

По-друге, ми можемо подивитися на ІДЕ. Якщо ви вирішите відкрити файл у IDE, вам слід пам’ятати, що деякі IDE повідомили про помилки. Мабуть, Visual Studio мав наявні подвиги через механізм розширень, тому відкрити рішення може бути проблематично. Уникнення IDE дозволяє уникнути цілого класу проблем між вами та ненадійним кодом. Дотримуватися VI виглядає набагато безпечніше.

По-третє, ми можемо подивитися на фактичні компілятори. Я переглянув декілька, включаючи Adobe, Microsoft, Java та C / C ++ GNU, і виявив, що загалом кажучи, компілюючий код (і навіть будувати , якщо не бути спеціального файлу виготовлення) є відносно безпечним, але кожен з цих компіляторів робив чи робив мати подвиги безпеки, які можуть виникнути внаслідок фактичного запуску складених бінарних файлів. Іншими словами, вони не змогли перейняти вашу систему просто склавши, але могли запустити код.

Отже, на закінчення, якщо припустити, що спосіб доставки вже не викрав вашу систему (наприклад, ваш електронний клієнт зламався, або USB-накопичувач, на який він потрапив, був заражений ...), читання вихідного коду та складання вихідного коду, ймовірно, безпечно . Досліджуючи ваше конкретне програмне забезпечення, ви можете зробити його ще безпечнішим, скажімо, перевірка файлу знаходиться на правильній кодовій сторінці і т. Д. Запуск коду слід робити лише на апаратному забезпеченні, про яке ви просто не переймаєтесь. Не VM, а цілий фізично інший комп'ютер без доступу до мережі та без чутливих файлів чи зовнішніх пристроїв. Навіть якщо ви думаєте, що ви розумієте код, просте дослідження показує, що навіть у компіляторів є помилки, які можуть давати можливість прихованому переповненню буфера перебирати ззаду і виконувати довільний код, але тільки якщо ви вирішитезапустити або налагодити програму. Фактична збірка повинна бути безпечною.

Ну, я б почав з "перегляду їх коду". Чому насправді потрібно запустити код?

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

Ось приклад сторінки з онлайн-компіляторами: Онлайн-компілятори

Код для перегляду співбесіди не повинен бути настільки великим, щоб ви не розуміли, що відбувається.

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

Взагалі вони занадто складні і часто написані на мовах, на яких не практично доводити цю властивість.

Можливо, не з таким конкретним наміром, але поняття компіляторів нечіткого тестування, принаймні, відоме ( LLVM тепер може сам нечіткий тест ). Тести, призначені для введення даних, які виходять з ладу через компілятора через помилки компілятора, також мають тенденцію виявити корисні недоліки.

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

Наскільки безпечно скласти шматок коду від незнайомця?

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

Звичайно, будь-яка мова або компілятор із засобами для виконання компіляції загального коду, звичайно, є дуже підозрілим. Шаблони C ++ функціонально завершені, але не мають (призначеного) доступу до системи, тому вони відносно низькі. BЈович згадує makeяк надзвичайно високий ризик (оскільки він виконує код незнайомця, це просто так, що код пишеться makeмовою, а не на C ++). Якщо компілятор запуститься, systemви знаходитесь в одному човні. Раніше я працював з асемблером, який, якщо я правильно пам’ятаю, міг виконувати довільне виконання компіляційного часу. Він був призначений для обчислення таблиць пошуку, але я не думаю, що щось заважало тобі робити системні дзвінки.

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

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

Хоча це, як правило, викликає занепокоєння, я вважаю, що це не існує через налаштування.

Заявник надіслав вам вихідний код. Як чи чому це сталося?

Ну очевидно, що є лише три можливості:

1. Ви дали заявнику завдання вирішити певну (чітко визначену) проблему, щоб оцінити його вміння.
2. Заявник хоче показати щось класне, що написав.
3. Заявник - ривок, шпигун чи інша шкідлива особа і насправді не зацікавлений у прийнятті на роботу. Все, на що він сподівається - це ти досить дурний, щоб запустити його код.

Про 2) та 3)

Основним ризиком є ​​розмежування 2) та 3). Велика ймовірність того, що якщо все, що він написав, варто переглянути , це те, що ви можете або отримати вихідний код для Інтернету (з "нейтрального" джерела), і що ви, можливо, вже знайомі, або це щось, що ви насправді не робите Не хочу дивитись на це, оскільки ви порушили б інтелектуальну власність конкурента (колишнього роботодавця). Останнє означає, що ви все одно не хочете наймати цю людину.
Якщо ви можете отримати джерело в Інтернеті, зробіть це. Якщо ви можете перевірити внесок заявника у відоме програмне забезпечення (включаючи власницьке програмне забезпечення) за його ім’ям десь у кредитах, зробіть це.
У будь-якому іншому випадку просто ігноруйте все, що він вам надіслав. Це або не варто дивитися, або незаконно, або високий ризик.

Про 1)

Заявник щось вам надіслав, тому що ви дали йому доручення. Якщо у вас є якісь компетенції (які, я вважаю, ви виконуєте!), То для типового завдання програмування (... яке ви навіть вибрали самі!), Ви зможете сказати, чи це правдоподібне рішення, яке виглядає так, ніби воно може спрацювати переглядаючи вихідний код менше 30 секунд (швидше за все, 10 секунд).

Якщо ви не можете сказати, що програма, ймовірно, запрацює (або що вона взагалі робить) протягом 30 секунд, той, хто її написав, не такий тип людини, якого ви хочете найняти, повний стоп. Ви хочете, щоб люди, які пишуть код, який могли зрозуміти та підтримувати інші люди. Ви не хочете, щоб хтось, хто намагається бути розумним до вас, чи хтось, хто регулярно перемагає в затуманеному конкурсі C. Навіть не важливо, чи працює програма. Як тільки інша людина не може зрозуміти код, він ніколи не "працює".
Якщо програма виглядає так, що вона, ймовірно, спрацює, але ви знайдете все, що виглядає "дивно" (скажімо, послідовності втечі Java unicode, необроблені рядки C ++, речі, схожі на триграфи, як би там не було), трактуйте завдання як "провал", перемістіть до наступного заявника. Не обов’язково включати щось подібне до 99% усіх програм (і, звичайно, не у своєму завданні - я сподіваюся). Тож якщо ви знайдете щось подібне "дивне", заявник - це не той, кого ви хочете найняти.

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

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

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

Якщо ця можливість вас турбує, візьміть старішу машину (невже більшість з нас мало сидить?), Встановіть поточну версію Linux та компілятор & c, скопіюйте на неї вихідний код, відключіть мережевий кабель (або вимкніть WiFi ), і робіть компіляції. Якщо трапиться щось неприємне, це не вплине ні на що інше.

А для зловмисного програмного забезпечення в Makefile запустіть його прапором -n (IIRC, RTMF), щоб побачити, що він буде робити, не роблячи насправді.

* Якщо, звичайно, ваш програміст не зашифрував шкідливе програмне забезпечення, щоб він чекав на повторне підключення, але в такому випадку ви a) витріть машину; і б) переслати резюме хлопця до АНБ, бо він потратив у комерційний світ :-)

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

1. Що я можу зробити, щоб зменшити ризик?
2. Чи достатньо високий ризик, що я повинен піклуватися?

Друге - це те, що ви поставили тут у цьому питанні, але це неправильний фокус для даного конкретного випадку. Відповідь на зменшення ризику зрозуміла і легко доступна: не збирайте код на своїй машині . У вас є два очевидних способи складання без використання машини:

1. Використовуйте віртуальну машину (як @FlorianMargaine вказував негайно у коментарях). Ви просто знімаєте його перед компілюванням, а потім відновлюєте знімок, коли закінчите.
2. Використовуйте розміщену послугу (наприклад, онлайн-компілятор).

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

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

Одним із прикладів використання цього проекту може бути проект WPF: Ви можете посилатись на .NET-класи з XAML, а також забезпечувати завантаження IntelliSense, VS та виконання посиланих класів під час проектування.

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

Тож незважаючи на те, що весь наданий код "чистий", компілятор не містить помилок, і ви, звичайно, ніколи не виконуєте вручну жодного наданого файлу .EXE, шкідливий код все одно може виконуватися у фоновому режимі. (Щоб бути захищеним від конкретної атаки, ви можете просто переконатися, що в дереві каталогів немає відкритих бінарних файлів перед відкриттям рішення. Потім VS запропонує створити рішення перед тим, як забезпечити IntelliSense на час проектування.)

Подібні вектори, ймовірно, існують і з іншими мовами / ОС.

Читання вихідного коду: абсолютно безпечно. Складання вихідного коду: повністю безпечно. Виконання складених двійкових файлів: ну ... це залежить.

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

Я думаю, що ти турбуєшся про один із двох ароматів:

• складна, керована експлуатуванням шкідливе програмне забезпечення : малоймовірно, особливо тому, що вони орієнтовані на дуже специфічні апаратні та / або програмні засоби і [на основі вашого запитання] ваш зловмисник, мабуть, не має такого рівня системних знань.
• те, що відповідає вашому оточенню : шкідливі директиви розігрувань (наприклад, видалення домашнього каталогу) або непомітні / некомпетентні директиви, які змінюють поведінку вашої системи (наприклад, перезапис змінних середовища PATH або LIBRARY)

Деякі люди пропонують віртуальні машини чи старі системи, але я пропоную набагато простіше рішення: компілюйте як іншого користувача зі зменшеними / різними дозволами . Набагато простіше, ніж налаштування віртуальної машини або виділеного комп’ютера.

Якщо навіть навряд чи ваша система перешкоджає експлуатуванням часу компіляції, відновіть із резервних копій (у вас це є, правда?).