When hosted in IIS, are ASP.NET applications built targeting old versions of framework vulnerable?

Question

For the sake of argument, imagine I have three ASP.NET Web Applications, each targeting a different version of .NET framework (4.0, 4.5.2, and 4.8). All of these applications are hosted on IIS 8.5 in the same app pool running CLR v4.0. Do each of these web applications technically use different versions of say, System.Web? Or do they all end up using the latest version of the runtime? Obviously any limitations of earlier frameworks (i.e. TLS versions) couldn't be updated I've setup a test server to look at via process explorer, and the .NET Assemblies tab seems to indicate only one copy/version of System.Web is loaded, but I don't entirely understand how it all fits together.

Answer 1

Firstly, this has nothing to do with IIS or app pools so let's just throw that complexity out the window. There is only 1 copy of the CLR on a machine. The current CLR is v4 which is what NET 4.0 to NET 4.8 run against. All NET 4.x apps that want to run on the machine will use the same CLR. It doesn't matter what version they compiled against. Suppose you installed MyApp which happen to be built against NET 4.5. You then install another app YourApp that was built against NET 4.8. During the install of YourApp it would confirm that you have at least NET 4.8 installed. Now all your NET 4.x apps are running against the NET 4.8 runtime. The CLR is a single set of files stored globally on the system.

Going back to your original premise, since you installed the NET 4.8 runtime then all the apps running in IIS that target CLR v4 will be using the NET 4.8 version because there is only a single copy. It doesn't matter whether they are using the same app pool or not.

Note that this is assuming the binary you're referencing is actually part of the framework. Most apps also rely on third-party libraries, including from Microsoft. Those are generally copied to your app's output directory at build time. In this case each app has their own copy. As an example, if MyApp relies on SomeLibraryA v1 and YourApp relies on SomeLibraryA v2 then we each have our own copy in the same directory as our binary. MyApp loads v1 and YourApp loads v2 because they are local binaries, not shared by other apps on the machine.

Answer 2

While they all use the lastest runtime (.net 4.* is update in place) probably most use nuget or 3rd party packages, which probable have security issues if not the lastest. If the project runtime is not kept up to date, most likely, other packages are not kept up to date. So my guess is that they have security issues. If the practice is not to run security audits, and keep dependencies updated, then I’d guess even the 4.8 apps are suspect.