0

We have had the following pointed out to us:

URL Description
https://www.cvedetails.com/cve/CVE-2015-6099/ Cross-site scripting (XSS) vulnerability in ASP.NET in Microsoft .NET Framework 4, 4.5, 4.5.1, 4.5.2, and 4.6 allows remote attackers to inject arbitrary web script or HTML via a crafted value, aka ".NET Elevation of Privilege Vulnerability."
https://www.cvedetails.com/cve/CVE-2015-2504/ Microsoft .NET Framework 2.0 SP2, 3.5, 3.5.1, 4, 4.5, 4.5.1, 4.5.2, and 4.6 improperly counts objects before performing an array copy, which allows remote attackers to (1) execute arbitrary code via a crafted XAML browser application (XBAP) or (2) bypass Code Access Security restrictions via a crafted .NET Framework application, aka ".NET Elevation of Privilege Vulnerability."
https://www.cvedetails.com/cve/CVE-2011-3416 The Forms Authentication feature in the ASP.NET subsystem in Microsoft .NET Framework 1.1 SP1, 2.0 SP2, 3.5 SP1, 3.5.1, and 4.0 allows remote authenticated users to obtain access to arbitrary user accounts via a crafted username, aka "ASP.Net Forms Authentication Bypass Vulnerability."

These are deemed to be an issue as our headers (x-aspnet-version) report running CLR 4.0.30319

Our code is built against .Net framework 4.8

The earliest of these issues is from 2011. How can any of them still be a problem? And yet our servers are running CLR 4.0.30319.

My nearly new PC is running CLR 4.0.30319.

C:\Program Files\Microsoft Visual Studio\2022\Enterprise>clrver

Microsoft (R) .NET CLR Version Tool Version 4.8.3928.0 Copyright (c) Microsoft Corporation. All rights reserved.

Versions installed on the machine: v4.0.30319

It looks as if that version of the CLR has been around for a decade :-/

Clearly, I am missing something. These vulnerabilities must have been fixed by now. How can you establish that when the CLR version they are reported against hasn't changed?

Adam Benson
  • 7,480
  • 4
  • 22
  • 45
  • What tool is generating those vulnerability reports? If it's simply doing it based on the CLR version, then it's not a very smart tool. But, I wouldn't actually serve the x-aspnet-version header in the first place. I'd [stop serving it](https://stackoverflow.com/questions/3418557/how-to-remove-asp-net-mvc-default-http-headers). It leaks information about your server that nobody really needs to know about. Many security tools will flag that header itself as a vulnerability. – mason Dec 22 '22 at 18:30
  • @mason Thanks for the response. Stopping the headers is something we'll consider (not my decision). Still curious about the CLR version though. Do you know why it seems to have stayed the same for so long? – Adam Benson Dec 23 '22 at 09:10
  • .NET Framework 4.x still runs on CLR 4. As for exact reasoning, I'll probably butcher it, but in my layman's understanding, I imagine there hasn't been a real need to update the CLR itself, since new framework features can still be implemented anyways. I've been working with .NET for over a decade, the fact that it's still on CLR 4 even from when I started working with it hasn't really mattered one bit. Of course, keeping an application on .NET Framework instead of moving to .NET 6+ isn't a great idea. Hopefully y'all have plans to upgrade. – mason Dec 23 '22 at 13:34

1 Answers1

0

In short, what you observed is the limitation of such scanners, who cannot tell what's the actual ASP.NET version on your server side. All they can get is the x-aspnet-version header and value of "4.0.30319", so that they know you are running ASP.NET 4.x.

Like you already knew, all 4.x .NET Framework versions use the same CLR version number 4.0.30319. That's why in the reports you see those results are clearly marked for old ASP.NET versions 4.0-4.6, not 4.8 the version you are using.

Thus, you can almost be certain that such items can be ignored, as .NET Framework 4.8 contains all security fixes and is being monthly patched by Windows update.

However, don't let your guard down, as web apps do have their own vulnerabilities that such scanners cannot easily detect,

  • XSS (at application level, not framework level)
  • SQL injection
  • many other common coding issues

Talk to security experts in your organization further on such and learn from them.

Lex Li
  • 60,503
  • 9
  • 116
  • 147