Почему .NET Framework (V2.0) может пытаться связываться с реестром Internet Explorer?

Question

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

При запуске приложение пытается изменить реестр в HKCU \ Software \ Microsoft \ Windows \ CurrentVersion \ Internet Settings \ ZoneMap \ AutoDetect. В исходном коде нет известных ссылок на это местоположение. Фактически, рассматриваемое приложение не должно вносить каких-либо изменений в реестр.

Кто-нибудь может подсказать, что может быть не так с приложением, из-за которого оно (или .NET Framework) получит доступ к реестру таким образом?

Answer 1

Вы уверены, что он пытается записать этот ключ или просто открывает и читает его? Является ли приложение Authenticode подписанным случайно? Если это так, то вы должны знать, что CLR всегда будет пытаться проверить двоичные файлы с подписанным Authenticode, что означает, что он может попасть в сеть, чтобы получить списки отзыва сертификатов. Взгляните на сообщение в .NET Security Blog . Соответствующая выдержка:

---

Производительность при сборке
Когда CLR загружает сборку с подписью Authenticode, он всегда будет пытаться проверить эту подпись. Это отличается от загрузчика Windows, который будет проверять подпись файла только в определенных случаях, например, когда файл является элементом управления ActiveX. Эта проверка может занимать довольно много времени, поскольку может потребоваться несколько раз нажать сеть, чтобы загрузить обновленные списки отзыва сертификатов, а также убедиться, что на пути к доверенному корню имеется полная цепочка действительных сертификатов. Поэтому, когда к сборке применяется подпись Authenticode, нередко можно увидеть задержку в несколько секунд во время загрузки этой сборки.

Answer 2

Этот конкретный ключ касается настроек безопасности вашего компьютера, а не только IE. В других частях операционной системы параметры зоны используются для определения разрешений, предоставляемых исполняемому файлу. .Net Framework делает много вещей под капотом, о которых мы просто не знаем, включая определение соответствующих разрешений.

Мне было бы интересно узнать, как было установлено ваше приложение. (т. е. ClickOnce, или он был загружен с веб-адреса или с общего диска в вашей сети?)

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

Конечно, тогда возникают очевидные вопросы, например, выполняет ли приложение ЛЮБОЙ доступ к сети (вызовы веб-служб, доступ в Интернет, доступ к другим машинам в сети, подключение к централизованному серверу БД, загрузка файлов с любого из перечисленных и т. д.)

Answer 3

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