Оставляет ли подпись кода без строгих имен ваше приложение открытым для злоупотреблений? - PullRequest
22 голосов
/ 19 декабря 2011

Попытка разобраться в аутентификации подписи кода и строгих именах.

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

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

Причина, по которой я не уверен, заключается в том, что ни одна из статей, которые я нашел в Интернете (включая документ MSDN об использовании SN + Authenticode), кажется, не упоминает об этом, и это кажется довольно важным моментом для понимания (если я правильно понял)?

Ответы [ 4 ]

15 голосов
/ 20 декабря 2011

Правильно ли я считаю, что если я подпишу код исполняющего файла, который ссылается на несколько dll (не с строгим именем), то злонамеренный пользователь может заменить мои библиотеки DLL и распространить приложение так, какесли он подписан мной, но выполняет их код?

Да, если остальные библиотеки DLL только подписаны и не имеют строгого имени, они могут быть заменены без .NET, не вызывая исключения.Внутри exe вы можете убедиться, что DLL подписаны тем же ключом, что и exe.Ни один из этих подходов не мешает кому-либо заменить ваши DLL или EXE.

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

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

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

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

Обновлено

Таким образом, перенаправление привязки будет работать только со сборками.строгое имя с тем же ключом, и, следовательно, защищает ли вас от изменения DLL?

Исправьте, с отмеченным исключением, что внедрение кода все еще может быть выполнено различными способами.

... и вернемся к первоначальному вопросуРазве подписание кода без строгих имен подрывает смысл подписи кода?

Не совсем.Подписание кода (не строгое именование) имеет две разные цели:

  1. Аутентификация.Проверка, кто является автором программного обеспечения.
  2. Целостность.Проверка того, что программное обеспечение не было подделано с момента его подписания.

Часто это проверяется только во время установки.Вот почему мы подписываем наш setup.exe, чтобы клиент получал неизмененный установщик от нас.Они получают подсказку «Доверяете ли вы компании XXXX» и тем самым предоставляете авторизацию аутентифицированному / подписанному установщику.Однако после установки ОС практически не использует встроенную подпись кода (за исключением драйверов и некоторых других неясных случаев).

Сильное именование с другой стороны имело совершенно иное назначение.Он полностью сосредоточен на «целостности» приложения.Нет сертификата, нет подписывающего органа (ЦС) для его проверки, нет отображаемой пользователем информации, которую они могут подтвердить, и ничего, что ОС не может проверить относительно исполняемого файла, который она собирается запустить.

.NET Frameworkво многих случаях используются строгие имена, все из которых я свободно классифицирую как целостность приложения:

  1. Содержимое dll / exe имеет подписанный хеш, поэтому его нельзя подделать.
  2. Каждая ссылка должна иметь строгое имя и проверяться при загрузке зависимости.
  3. Сборки могут быть зарегистрированы в GAC и могут использоваться политики издателя.
  4. Для создания собственных изображений можно создавать собственные изображения.скомпилированный образ сборки ИЛ.

Я уверен, что есть и другие вещи, которые мне здесь не хватает, но я знаю об этих основных видах применения.

Лучшие практики для подписи и строгих имен

  • Использование подписанного установщика
  • Использование исполняемого файла с кодовой подписью
  • Использование исполняемого файла со строгим именем
  • Строгое имя всех зависимостей и ссылки на них
  • Зависимости подписывания кода, как правило, не требуются *
  • Рассмотрим регистрацию сборок GAC во время установки

* Примечание. В некоторых случаях подписывание кода может быть полезно для DLL, посколькуНапример, COM-объекты, помеченные как «безопасные» и встроенные в браузер, должны быть подписаны и иметь строгое имя, как если бы это был исполняемый файл.Подписание кода также может быть полезно при внешней проверке зависимостей без загрузки сборки или отражения ее атрибутов.

1 голос
/ 20 декабря 2011

Как только кто-то сможет заменить dll или запустить код на вашем компьютере, вам не останется много защитных мер. В моем случае все библиотеки Dll подписаны индивидуально. Мой код отказывается загружать Dll, которые не подписаны как часть самообновления. Однако любое приложение, работающее на моем уровне целостности или выше в моей системе (в случае> Windows Vista), все еще может внедрить dll в мой exe-файл с помощью чего-то вроде CreateRemoteThread и т. Д. (http://www.codeguru.com/Cpp/W-P/dll/article.php/c105) Но, опять же, предположить, что кто-то может ввести в систему чужой код, является сложной частью. Остальное легко.

0 голосов
/ 28 ноября 2014

После поиска того же и чтения многих вещей. Наконец, я могу ответить на ваш вопрос: ДА, строгое имя для зависимостей обязательно, если вы собираетесь подписывать exe своего приложения цифровой подписью.

Предположим, если у ваших зависимостей нет строгого имени. И они заменяются. Ваше приложение загрузит их без проблем. И пользователь увидит диалог «Проверенный издатель: Ваше имя». Хотя исполняемый файл не был затронут, но зависимости были изменены.

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

0 голосов
/ 20 декабря 2011

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

Именно поэтому многие популярные библиотеки не называют строго dll's

...