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


41

Предположим, я проверяю код, который соискатели посылают для подтверждения своих навыков. Очевидно, я не хочу запускать исполняемые файлы, которые они отправляют. Не очень ясно, что я бы предпочел не запускать результат компиляции их кода (например, Java позволяет скрыть исполняемый код в комментариях ).

Как насчет компиляции их кода? Я хочу предупреждения компилятора, если таковые имеются, но что, если их код содержит некоторые умные последовательности символов, которые используют мой компилятор, а мой компилятор ставит под угрозу мою машину?

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

Являются ли компиляторы, как правило, проверенными, чтобы убедиться, что они не скомпрометируют пользовательский компьютер при компиляции некоторого умного фрагмента кода? Насколько безопасно скомпилировать кусок кода от незнакомца?


40
Просто используйте виртуальную машину ...
Florian Margaine

14
Если вы на самом деле просматриваете код, тогда должно быть довольно сложно получить что-то столь же сложное, как «пробить машину пользователя», не будучи замеченным, верно?
RemcoGerlich

17
Так как вы оцениваете их навыки? Я спрашиваю об этом, потому что я часто просматривал код, присланный нам соискателями, но я всегда только читал его, никогда не чувствовал необходимости выполнять его.
RemcoGerlich

9
Java позволяет скрыть исполняемый код в комментариях. Не все Java IDE выполняют преобразование юникода при выделении синтаксиса, что не является удаленным.
Пит Киркхэм,

68
Даже не читайте код. Они могут использовать уязвимость в вашем мозгу.
Хенрик

Ответы:


34

Это зависит.

Этот фрагмент make-файла может удалить ваш домашний каталог:

all:
    rm -rf ~

Итак, если вам нужно использовать инструмент (например, cmake или makefile system), тогда он небезопасен. Это зависит только от того, насколько вредоносен кодер.

С другой стороны, компиляторы программируются людьми, поэтому они получают ошибки. Возможно, кто-то нашел способ выполнить вредоносный код во время компиляции.

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


32
«использовать виртуальную машину» - и если вы действительно параноик, имейте в виду, что, используя несколько недостатков, вредоносные программы могут вылезти из вашей виртуальной машины и задушить вас ( venom.crowdstrike.com )
Стив Джессоп,

23
@SteveJessop да, лучше использовать вложенные виртуальные машины;) Скорее всего, кодер не осознает, что, сломав одну виртуальную машину, он все еще находится внутри другой.
Руслан

3
Или просто используйте старый ноутбук для проверки кода. Пока у него нет сетевых возможностей, вы всегда будете уверены, что вредоносная программа не выскочит. Если, конечно, программные ошибки не будут волшебным образом превращаться в настоящие ошибки.
Мачта

5
@Ruslan: к сожалению, большинство хакеров видели Начало.
Стив Джессоп

2
@Ruslan Это буквально вкладка, которую я открыл перед этой страницей: matrix.wikia.com/wiki/Matrix_in_a_Matrix_theory, которую я читал из-за несвязанного вопроса на сайте SciFi SE.
Армани

23

Я уверен, что где-то в бизнесе есть некоторые умные парни, которые уже создали такой взлом для определенного языка и версии компилятора. Моим любимым местом для поиска чего-то подобного, вероятно, был бы международный конкурс «Затененный С» - (не знаю, есть ли что-то сопоставимое для Java). Однако на самом деле, насколько высоко вы считаете риск, предполагалось, что

  • заявитель производит на вас правдоподобное впечатление, он действительно хочет получить работу в вашей компании (а не судебный иск)

  • парень не знает, сколько у вас сделано рецензий

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

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

  • Вы не принимаете программы, которые слишком велики для эффективного рассмотрения

  • вы не компилируете ничего подозрительного

  • в мире не так много людей, которые на самом деле знают, как технически выполнить такую ​​задачу (и поиск в Google сам по себе не даст вам «быстрого реферирования» или учебника по этому вопросу, как вы уже узнали сами).

Таким образом, хотя компиляция не является «абсолютно безопасной» в теории, IMHO на самом деле риск очень низок, что ваш «компилятор получает pwned».


15
Запутано это хорошо. Закулисный лучше. underhanded-c.org

11
«заявитель действительно хочет получить работу в вашей компании (а не судебный иск)» Не ясно, что незнакомец, который отправляет заявление, действительно хочет эту работу.
Кристиан

@ Кристиан: очевидно. Но я полагаю, что ОП не потратил бы времени на пересмотр кода заявителя, если последний не придумал, по крайней мере, правдоподобное появление в отношении его запроса на работу. А также незнакомец, вероятно, не хочет быть привлечен к ответственности. Моя точка зрения такова: каждый из вышеперечисленных пунктов сам по себе может быть обойден, но все вместе? Это довольно низкий риск.
Док Браун

13

Мы должны выделить несколько случаев:

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

# 4. и № 5. приведет к отказу в обслуживании. На практике компиляторы C ++ и Scala ограничивают количество рекурсии, которую вы можете сделать, так что на самом деле невозможно написать бесконечный цикл. В Scala это просто ограничение реализации, но в C ++ это явно разрешено спецификацией, я считаю.

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

# 1. вряд ли. С одной стороны, производственные компиляторы очень сложны, поэтому вероятность ошибок высока. С другой стороны, они проходят строгую проверку, в конце концов, корректная обработка некорректных входных данных является частью описания работы компилятора. Даже если они не будут протестированы, они все равно будут засыпаны плохо сформированным кодом ... просто посмотрите на некоторые вопросы StackOverflow для примеров того, что мусорные люди бросают в свои компиляторы!

Это оставляет нам 3. Некоторые компиляторы могут ограничивать вид доступа, который код времени компиляции имеет к системе, но в некоторых случаях использование полного доступа неизбежно. Например, целью поставщиков типов F # является «подделка» синтетических типов для данных, система типов которых не соответствует F #, так что вы можете взаимодействовать, например, с веб-службой, имеющей схему WSDL в строго типизированной форме. мода. Однако для этого у поставщика типов должен быть доступ к ресурсу схемы WSDL либо в файловой системе, либо в Интернете, поэтому он должен иметь доступ к файловой системе и сети.

Так это безопасно? Технически нет. Это рискованно? На самом деле, нет.


1
C ++ действительно ограничивает глубину создания шаблонов некоторым значением, зависящим от реализации. Раньше это было несколько десятков; современные реализации подняли предел до нескольких сотен. Тем не менее, удвоить количество экземпляров шаблонов на уровень совершенно тривиально, поэтому для 100 уровней потребуется, чтобы компилятор создавал 2 ^ 100 шаблонов. Это пока просто DoS-атака.
MSalters

3

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

Имейте в виду, что здание может быть небезопасным. Например, в C # «событие сборки» позволяет указать произвольные командные строки, которые будут выполняться до и после сборки, что, очевидно, опасно и намного проще в использовании, чем, скажем, переполнение буфера в коде компилятора.


3
Scala, Template Haskell, почти все Лиспы могут выполнять произвольный код во время компиляции. Все языки с системой типов, полной по Тьюрингу (Scala, Haskell) могут выполнять произвольные вычисления по Тьюрингу во время компиляции, включая, но не ограничиваясь, бесконечный цикл. Система шаблонов в C ++ снова Turing-complete, что позволяет вам выполнять произвольные вычисления, включая бесконечные циклы во время компиляции. Разрешение перегрузки C # эквивалентно 3-SAT, поэтому NP-complete, который не является Turing-complete, но все же позволит вам повесить компилятор на время существования юниверса, если хотите.
Йорг Миттаг

3
Система типа Тьюринга не позволяет вам пинать компьютер. В худшем случае компилятор зависнет, если вы его эксплуатируете. Но да, если у вас есть языки, в которых на этапе компиляции может выполняться произвольный код, то, очевидно, вам не следует компилировать ненадежный код.
JacquesB

3

Вместо того, чтобы спекулировать, я на самом деле потрудился провести некоторое исследование по этой теме, прежде чем ответить, перейдя к самому авторитетному ресурсу, который я мог придумать ( подробности CVE ). Этот исчерпывающий список публично раскрытых уязвимостей безопасности, вероятно, является лучшим, что можно сделать для оценки уровней угроз различных типов программного обеспечения.

Конечно, я не потратил время на чтение всех доступных материалов, но выбрал несколько «первичных» компиляторов, IDE и текстовых редакторов, чтобы подготовить примерную оценку угроз. Если вы серьезно относитесь к запуску какого-либо программного обеспечения, вы должны хотя бы посмотреть, какие существуют угрозы. Также обратите внимание, что старое программное обеспечение, как правило, работает хуже, чем новое, поэтому идеальным является запуск новейшего программного обеспечения.

Во-первых, мы можем взглянуть на различные текстовые редакторы. Кажется, лучшие редакторы самые простые. Vi, если вы используете оболочку Linux, или Notepad, если вы находитесь в Windows. Что-то без возможностей форматирования, без разбора, просто прямой просмотр данных и автоматическое завершение разбора, если один символ находится за пределами текущей схемы кодирования. Даже в Notepad ++ было несколько уязвимостей. Избегайте ничего сложного при просмотре недоверенных файлов.

Во-вторых, мы можем посмотреть на IDE. Если вы решите открыть файл в IDE, вы должны знать, что некоторые IDE сообщали об ошибках. Очевидно, в Visual Studio были доступны эксплойты с помощью механизма расширений, поэтому открытие решения может быть проблематичным. Избегание IDE позволяет избежать целого класса проблем между вами и ненадежным кодом. Придерживаться VI, кажется, намного безопаснее.

В-третьих, мы можем посмотреть на фактические компиляторы. Я просмотрел несколько, в том числе Adobe, Microsoft, Java и ГНУ C / C ++, и обнаружил , что , вообще говоря, компиляции кода (и даже строить , не предполагая пользовательского грим-файл) является относительно безопасным, но каждый из этих компиляторов делают или делали иметь эксплойты безопасности, которые могут возникнуть в результате запуска скомпилированных двоичных файлов. Другими словами, они не могли захватить вашу систему, просто компилируя, но они могли запускать код.

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


2

Ну, я бы начал с «просмотра их кода». Почему на самом деле нужно запускать код?

Кроме того, есть много онлайн-компиляторов, где вы можете просто вставить код, скомпилировать и / или запустить его. Вы можете сделать это требованием: он компилируется в тот или иной онлайн-компилятор.

Вот пример страницы с онлайн-компиляторами: Онлайн-компиляторы

Код для проверки на собеседование не должен быть настолько большим, чтобы вы не понимали, что происходит.


3
Msgstr "Почему на самом деле нужно запускать код?" Чтобы выяснить, насколько это хорошо, конечно, обзор только скажет вам, что его недостатки неуловимы :-). «Остерегайтесь ошибок в приведенном выше коде; я только доказал, что это правильно, а не пробовал». - Кнут
Стив Джессоп

2

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

В общем, они слишком сложны и часто пишутся на языках, на которых не практично доказывать это свойство.

Возможно, не с этим конкретным намерением, но понятие компиляторов нечеткого тестирования, по крайней мере, известно ( теперь LLVM может сам выполнять нечеткое тестирование ). Тесты, предназначенные для обнаружения входных данных, которые приводят к сбою компилятора из-за ошибок компилятора, также имеют тенденцию обнаруживать уязвимости, которые можно использовать.

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

Насколько безопасно скомпилировать кусок кода от незнакомца?

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

Любой язык или компилятор со средствами для выполнения общего кода во время компиляции, конечно, очень подозрительно. Шаблоны C ++ функционально завершены, но не имеют (предполагаемого) доступа к системе, поэтому они относительно низки. BЈовић упоминает makeкак чрезвычайно рискованный (поскольку он выполняет код незнакомца, просто код написан на makeязыке, а не на C ++). Если компилятор запустится, systemзначит, вы в одной лодке. Раньше я работал с ассемблером, который, если я правильно помню, мог выполнять произвольное выполнение кода во время компиляции. Он был предназначен для вычисления справочных таблиц, но я не думаю, что что-то мешает вам делать системные вызовы.

На практике , если код выглядит нормально для меня, и я думаю, что я его понимаю, то я считаю, что компилировать его крайне низко, гораздо меньше, чем, скажем, «просматривать интернет с заблокированным браузером». Я обычно делаю более рискованные вещи на своей машине общего назначения, но многие из них я бы не делал, например, в вирусной лаборатории или на критически важном сервере. Если код выглядит смешно или явно запутан, то я не рискну скомпилировать его, потому что, помимо риска, он может содержать эксплойт, скрытый в нечитаемом мусоре, это мусорный код. Секретный код сложен, но возможен. Закулисный код, который обрабатывает машину с помощью эксплойта компилятора, должен содержать нетривиальную исполняемую полезную нагрузку, поэтому он чрезвычайно сложен.

Если вы хотите разобраться в этом подробнее, попробуйте спросить людей, которые размещают онлайн-компиляторы. Если это не было сделано для них, то (если вы не обратили на себя внимание АНБ или эквивалент), вы можете разумно предположить, что это не будет сделано для вас. Они прикладывают некоторые усилия для запуска своего компилятора в правильной песочнице, что может потребовать больше усилий, чем вы готовы, но они, по крайней мере, смогут сказать вам, как часто эта песочница избавляет их от проблем.


Благодаря работе профессора Джона Регера в Университете Юты, clang и gcc прошли довольно интенсивное фазз-тестирование, выбив сотни дефектов, которые могут привести к сбою компилятора или даже к созданию кода, который ведет себя не так, как другие компиляторы. Что нужно искать, так это ошибки, которые все еще открыты, и достаточно ли они представляют угрозу.
Фил Миллер

@Novelocrat: согласен, и спасибо за конкретную информацию. Мой страх , что команда компилятора DEV может оценить ошибки как низкий приоритет , потому что «никто не будет когда - либо писать , что код», и они не были зафиксированы еще , в то время как раз вы думаете компилятор как поверхность атаки вы бы рассмотреть их критично. Имейте в виду, мы надеемся, что гордость обеспечит, чтобы компилятор не позволил чему-то столь смущающему, как переполнение буфера при записи ;-)
Стив Джессоп

1

Хотя это, как правило, проблема, я думаю, что проблема не существует из-за установки.

Заявитель отправил вам некоторый исходный код. Как или почему это произошло?

Ну, очевидно, есть только три возможности:

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

О 2) и 3)

Основным риском является различие между 2) и 3). Высоки шансы, что если на то, что он написал, стоит взглянуть , это то, что вы можете либо получить исходный код для онлайн (из «нейтрального» источника), и что вы, возможно, даже уже знакомы, или это то, что вы на самом деле надеваете не хочу смотреть, потому что вы нарушите интеллектуальную собственность конкурента (бывшего работодателя). Последнее будет означать, что вы все равно не захотите нанимать этого человека.
Если вы можете получить источник в Интернете, сделайте это. Если вы можете проверить вклад заявителя в известное программное обеспечение (включая проприетарное программное обеспечение) по его имени где-то в титрах, сделайте это.
В любом другом случае просто игнорируйте все, что он вам послал. На это либо не стоит смотреть, либо нелегально, либо рискованно.

О 1)

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

Если вы не можете сказать, что программа, вероятно, будет работать (или что она вообще делает) в течение 30 секунд, тот, кто написал ее, не тот человек, которого вы хотите нанять, полный ход. Вам нужны люди, которые пишут код, который другие люди могут понять и поддерживать. Вы не хотите, чтобы кто-то, кто пытается стать умным на вас, или кто-то, кто регулярно побеждает в запутанном конкурсе Си. Даже не имеет значения, работает ли программа. Как только другой человек не может понять код, он никогда не «работает».
Если программа выглядит так, как будто она, вероятно, будет работать, но вы найдете все, что выглядит «странно» (скажем, escape-последовательности Java Unicode, литералы необработанных строк C ++, вещи, которые выглядят как триграфы, что угодно), обработайте присвоение как «fail», переместите к следующему заявителю. Нет необходимости включать что-либо подобное в 99% всех программ (и, разумеется, не в вашем назначении - я надеюсь). Поэтому, если вы обнаружите что-то «странное», заявитель не тот, кого вы захотите нанять.

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

Это должно вызвать проблемы, которые вы, возможно, пропустили при чтении источника (например, вызов неопределенного поведения или сужение конверсии).
Компиляция прежде всего скажет вам, обладает ли заявитель необходимым усердием и вниманием к деталям, а не тем, обладает ли он навыками программирования. Подобно правильному написанию имени работодателя в вашем приложении и проверке правописания вашего резюме перед его передачей, лучше всего убедиться, что любой исходный код, который вы передаете, компилируется без ошибок (и желательно без предупреждений). Если кому-то это не удается, вы не хотите его нанимать.

Риск злых вещей, происходящих в этот момент (использование компилятора и взлом виртуальной машины), пренебрежимо мал, видя, как вы уже выполнили проверку достоверности кода. Не произойдет.


0

Если такая возможность вас беспокоит, возьмите более старую машину (разве большинство из нас не сидят без дела?), Установите текущую версию Linux и компилятор & c, скопируйте в него исходный код, отсоедините сетевой кабель (или отключите WiFi ) и делать компиляции. Если случится что-нибудь неприятное, это не повлияет ни на что другое.

Что касается вредоносного ПО в Makefile, запустите его с флагом -n (IIRC, RTMF), чтобы увидеть, что он будет делать, фактически не делая этого.

* Если, конечно, ваш программист не закодировал вредоносную программу так, чтобы она ожидала повторного подключения, но в этом случае вы а) стираете машину; и б) переслать резюме парня в АНБ, потому что он впустую в коммерческом мире :-)


0

Суть заключается в том, что есть риск. Риск довольно мал, как отмечают другие ответы, но есть риск. Это означает, что вам нужно задать два вопроса:

  1. Что я могу сделать, чтобы уменьшить риск?
  2. Достаточно ли высок риск, чтобы мне было все равно?

Второе - это то, что вы задали здесь в этом вопросе, но это не тот фокус для данного конкретного случая. Ответ на снижение риска ясен и доступен: не компилируйте код на своем компьютере . У вас есть два очевидных способа компиляции без использования вашей машины:

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

Эти способы снижения риска настолько очевидны, дешевы и легко доступны, что не стоит тратить много времени, пытаясь проанализировать, насколько велик риск. Просто сделайте один из них и покончите с этим.


0

Visual Studio фактически предупреждает вас, если вы открываете проект из ненадежного места (например, загруженный или сетевой ресурс).

Один пример того, как это можно было бы использовать, можно найти в проекте WPF: вы можете ссылаться на классы .NET из XAML и предоставлять IntelliSense, VS загружает и выполняет указанные классы во время разработки.

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

Поэтому, несмотря на то, что весь предоставленный код «чистый», компилятор не содержит ошибок, и вы, конечно же, никогда не будете запускать какой-либо предоставленный .EXE, вредоносный код все равно может выполняться в фоновом режиме. (Чтобы обезопасить себя от этой конкретной атаки, вы можете просто убедиться, что в дереве каталогов НЕТ двоичных файлов, прежде чем открывать решение. VS предложит вам построить решение, прежде чем предоставлять IntelliSense во время разработки.)

Подобные векторы, вероятно, существуют с другими языками / ОС.


0

Чтение исходного кода: абсолютно безопасно. Компилирование исходного кода: абсолютно безопасно. Выполнение скомпилированных двоичных файлов: хорошо ... это зависит.

Компиляция - это просто компьютер, читающий исходный код и записывающий его эквивалент в двоичном виде. После компиляции у вас есть только 2 документа: один читаемый человеком, а другой читаемый компьютером. Если вы не заставите компьютер прочитать (т.е. запустить) 2-й документ, ничего не произойдет.


3
Любое объяснение того, почему компиляция абсолютно безопасна? Можно настроить сервер, отправив умно созданное сообщение - почему он не может написать компилятор, предоставив ему умело созданный ввод?
sharptooth

2
Я думаю, вы заметите хитроумный код, разработанный для использования уязвимости на сервере или в компиляторе. Но доводя это до крайности, зачем вообще рисковать просмотром кода ?! В редакторах есть несколько эксплойтов, которые можно использовать, просто просматривая файл .
gbjbaanb

2
Этот ответ - полная чепуха. Нет никакой причины, по которой компилятор был бы по своей природе безопасным или, по крайней мере, более безопасным, чем то, что выполняет простую задачу, такую ​​как настройка SSL-соединения, однако недавно популярная библиотека содержала уязвимость. Я бы даже сказал, что, поскольку компиляторы, как правило, не используются во враждебной среде (например, в Интернете), они меньше проверяются на наличие уязвимостей и, следовательно, имеют больше шансов их иметь.
Дорус

1
Не уверен, что компиляция кода абсолютно безопасна. Даже в Java с Maven (например) небрежный " mvn package" может извлекать вещи и выполнять задачи с помощью дополнительных плагинов, о которых вам может быть нелегко узнать. Я уверен, что то же самое может относиться к другим системам сборки.
Бруно

1
Полный по Тьюрингу язык может позволить программе тратить неограниченное количество времени на компиляцию, если компилятору разрешено работать в течение неограниченного времени , но многие компиляторы создают ограниченное количество потоков независимо от того, что может появиться в компилируемый код, означающий, что загрузка ЦП от попыток компилировать одну программу за раз будет ограничена. Потенциально большей проблемой могут быть требования к дисковому пространству; вполне вероятно, что исходный файл размером 1 КБ может генерировать много гигабайт объектного кода.
суперкат

-1

Я думаю, что вы беспокоитесь об одном из двух вкусов:

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

Некоторые люди предлагают виртуальные машины или старые системы, но я предлагаю гораздо более простое решение: скомпилируйте как другого пользователя с ограниченными / другими разрешениями . Гораздо проще, чем настроить виртуальную машину или выделенный компьютер.

Если маловероятно, что ваша система будет повреждена эксплойтами во время компиляции, восстановите из резервных копий (у вас есть такие, верно?).

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.