Why might the .NET framework (V2.0) be trying to mess with the Internet Explorer registry?

Question

One of our applications recently got installed in a system that is tightly locked down.

On startup, the application tries to modify the registry at HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap\AutoDetect. There are no known references to that location in the source code. In fact the application in question should not be making any modifications to the registry.

Can anyone suggest what might be wrong with the application which would cause it (or the .NET framework) to access the registry in this way?

Answer 1

This particular key as to do with security settings on your computer, not just IE. Other portions of the operating system use the zone settings to determine permissions to give to an executable. The .Net Framework does a lot of stuff under the hood that we're just not aware of, including determining appropriate permissions.

I'd be curious to determine how your app was installed. (ie, ClickOnce, or was it downloaded from a web address or a shared drive on your network?)

It could be that it came from a potentially "untrusted" location like the ones I just mentioned, and the runtime is attempting to grant it the permissions it needs to run.

Of course, then there are the obvious questions, like does the app do ANY network access (web service calls, Internet access, Accessing other machines on the network, connecting to a centralized DB server, downloading files from any of the above, etc.)

Answer 2

Are you sure it's trying to write to that key or just accessing and reading it? Is the application Authenticode signed by any chance? If so, then you should be aware that the CLR will always try to verify binaries that are Authenticode signed, which means that it may hit the network to get the cert revocation lists. Take a look at the post on the .NET Security Blog. Relevant excerpt:

---

Assembly Load Performance
When the CLR loads an assembly which has an Authenticode signature, it will always try to verify that signature. This is in contrast to the Windows loader, which will verify the signature of a file only in specific instances, such as when the file is an ActiveX control. This verification can be quite time intensive, since it can require hitting the network several times to download up to date certificate revocation lists, and also to ensure that there is a full chain of valid certificates on the way to a trusted root. So, when an Authenticode signature is applied to an assembly it's not unheard of to see a several second delay while that assembly is being loaded.

Answer 3

It seems that the issue was not caused by our software, or at least not directly. I still don't know what the IT department changed on the machine, but the problem mysteriously vanished with no modifications to our application (or at least nothing related to any attempt to solve the problem). To date, only that one machine was affected by the problem, so I'm guessing it was a very specific interaction problem... although I am none the wiser about the root cause.