Как стать автором
Обновить

Комментарии 28

пожалуйста, перенесите статью в блог .net
перенесено
>Строгое имя не может защитить от подмены сборки
неверное утверждение. попробуйте модифицировать System.dll и вы поймете в чем проблема.

подписанные сборки защищены от подмены. Тот факт, что можно снять подпись и подкорректировать все остальные сборки не дает права говорить что защиты нет. Она есть и её можно сломать.
Модификация CLR сборок отдельная тема, можно конечно им все поудалять строгое имя. Но там помимо строгого имени есть цифровая подпись.

Но зачем из них удалять строгое имя? Код приложения там не содержится, смысла делать это нет. Есть смысл удалять строгое имя со сборок приложения.

Проверьте насколько они защищены, напитсав простое приложеньеце из нескольких сборок и попробовав модифицировать код сборок. Не хотел добавлять в текст банальный пример консольного приложения с сателитной сборкой.
Вот нашел ссылочку для Вас
Насчет защищены от подмены — почитайте мой комментарий — ничего удалять нигде не надо.
Это как утверждать, что «дверные замки не защищают от воровства т.к. вор может установить свой замок и беспрепятственно проникать в жилище»
Вы сравниваете не соизмеримые вещи
модифицировать можно и без удаления подписи, существует ключик в реестре HKLM\SOFTWARE\Microsoft\StrongName\Verification\*,71E9BCE111E94*** (ваш отпечаток в общем)… собственно добавляете и среда не станет проверять подпись (аналогично это же делает утилита sn с ключем -Vr)
Да, согласен, но пример с -Vr (ну и реестром, это ведь одно и то же по сути) будет отклонять проверку только на локальной машине. При удалении строгого имени и соотв. атрибута из сборки — на любой. Собственно, как написал mezastel ниже.
Чтобы посмотреть как обходить подписывание, можно глянуть на Reflexil — там можно просто внести сборку в список «освобожденных от проверок» сборок (через командную строку тоже можно), и всё — сборку никто больше не будет проверять. Другое дело что это работает только локально.

Аналогия с вором: вы не можете обворовывать чужих, но можете красть у тех, кто живет с вами.

Млин… бредовая аналогия получилась. Ну вы поняли…
Только у меня осталось впечатление о плохом переводе, потере слов и прочих ужасах текста из Promt?
Вот вам сервис
www.copyscape.com

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

Статью писал сам и исследовал этот вопрос так как коллеги заблуждались по поводу строгого имени. Как оказалось не только они одни.

Если есть предложения по поводу стиля, грамматики, ошибок и прочего литературного охотно их расмотрю и внесу правки
1)Несомненно, что для уникальной идентификации сборок и использования одной и той же сборки разными приложениями такой механизм очень даже подходит.
Наверное, нужно говорить, идентификации уникальности, а не уникальной идентификации.
2)

Блин, хабр скушал остальное, что писал
2)Важно другое, что в случае строгое имя не защитит сборку от модификации, как многие думают, и соответственно механизм в CLR не отработает, как положено и загрузит модифицированную сборку.
Вам не кажется, что после или перед словом «случае», чего-то не хватает?
3)Пока они тоже подписаны тем же строгим и пока в зависимостях у них указано связь со сборкой со строгим именем.
Тем же строгим чем?
Короче можно так еще ооочень долго продолжать, это еще без проверки орфографии, и расстановки знаков препинания!
>Т.е. не смотря на то, что нас уверяют, что строгое имя помимо отношения к глобальному кэшу сборок защищает еще и от модификации сборки, это далеко не так на практике.
На практике нужно предпринять некоторые дополнительные действия, чтобы это работало. Во-первых, защитить сам EXE от модификации (например, Hasp Envelope — согласен, подходит далеко не во всех случаях, но для embedded — самое то), во-вторых, перед загрузкой сборки или в Program.Main проверять данный ключ реестра на наличие токенов, которых там быть не должно. И действовать соответсвенно.
Вот кстати нарыл еще — есть API функция StrongNameSignatureVerificationEx, с помощью которой можно принудительно выполнить проверку подписи, несмотря на записи в реестре для этой сборки. Можно вызывать перед загрузкой плагинов и пр. (требует P/Invoke).
Про то что сборку нужно обфусцировать и криптовать я упомянул, также то что неплохо было бы вручную проверять строгое имя в разных частях сборки тоже.

Про принуительную проверки не писал так как это из разряда «ручная проверка».

Хотя абсолютно согласен было бы неплохо так делать перед загрузкой плагинов, только сами плагины, если они от 3-х разработчиков тогда должны как-то сообщать программе их действительные а не поддельные строгие имена, так как в данном случае строгие имена плагинов и программы не обязаны совпадать.
Строгое имя можно вывести из метаданных. Public key там есть, а токен из него можно получить не очень сложно.
Я не то имел в виду. Естественно можно.

Я имел в виду то что есть издатель приложения. Он подписывает сборку своими ключами. Плагины могут разрабатывать сторонние разработчики. У них другие ключи. Издатель приложения свой закрытый ключ им не даст. Т.е. подпись строгим именем у плагина будет другая. Плагин может создать издатель плагина, а может и злоумышленник изменив его и внедрив код и подписав своим ключом. Т.е. для основного приложения стоит задача отделить две неизвестные ему подписи и определить «правильную» сборку по токенам.

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

А вот про то что можно удалить строгие имена легко нашел в третьей части www.codeproject.com/KB/security/NeCoder03.aspx. Судя по всему автор пересмотрел свое мнение от первой-второй части до третьей

Строгие имена — это не надежный механизм защиты от модификации сборки и основное предназначение их не в этом. А вообще эта тема возникла тогда когда возникли строгие имена с .NET — так что я думаю и автор на кодпроджекте и я не первые и не последние, потому что например во 2-ой редакции рихтера, насколько я помню, строгие исена подаются как, дополнительно, механизм защиты от модификации. Хотя там не говорится насколько надежный и упоминается оговорка про цифровые подписи и Autheticode

Ваша статья сломала мне мозг.
Чтобы снять проверку на strong name для конкретной сборки можно также просто выполнить команду:
sn.exe -Vr имясборки.dll
Да можно и так, только тогда проверка на соответствие строгого имени сборки не будет проходить только на локальной машине. А вот если полностью удалить строгое имя — тогда на любой.

Ключ -Vr делает запись в реестре, см коммент habrahabr.ru/blogs/net/91999/#comment_2781797
Спасибо, вы усилили мою паранойю.
>На основании сборки во время подписи вычисляется криптографический открытый ключ

Может что то поменялось с прошлой неделе, но каким местом криптографический ключ то да еще на основании сборки, да еще и во время подписи вычисляется? Может все таки _перед_ подписью генерится ключевая пара? А то, что вы называете «на основании» имеется в виду как хэш от сборки, подписанный закрытым ключом?
От чего защищает бумажка со штампом на опечатанной двери?
Ведь
1) Кто угодно может сорвать её.
2) Кто угодно может наклеить бумажку с надписью «Здесь был Вася» вместо неё.
Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории