Critical Microsoft Code-Execution Vulnerability
A critical code-execution vulnerability in Microsoft Windows was patched in September. It seems that researchers just realized how serious it was (and is):
Like EternalBlue, CVE-2022-37958, as the latest vulnerability is tracked, allows attackers to execute malicious code with no authentication required. Also, like EternalBlue, it’s wormable, meaning that a single exploit can trigger a chain reaction of self-replicating follow-on exploits on other vulnerable systems. The wormability of EternalBlue allowed WannaCry and several other attacks to spread across the world in a matter of minutes with no user interaction required.
But unlike EternalBlue, which could be exploited when using only the SMB, or server message block, a protocol for file and printer sharing and similar network activities, this latest vulnerability is present in a much broader range of network protocols, giving attackers more flexibility than they had when exploiting the older vulnerability.
[…]
Microsoft fixed CVE-2022-37958 in September during its monthly Patch Tuesday rollout of security fixes. At the time, however, Microsoft researchers believed the vulnerability allowed only the disclosure of potentially sensitive information. As such, Microsoft gave the vulnerability a designation of “important.” In the routine course of analyzing vulnerabilities after they’re patched, Palmiotti discovered it allowed for remote code execution in much the way EternalBlue did. Last week, Microsoft revised the designation to critical and gave it a severity rating of 8.1, the same given to EternalBlue.
Clive Robinson • December 22, 2022 10:11 AM
@ ALL,
Whilst I can understand this,
As you focus on what is infront of you when “under the gun”, it can lead to two major effects that people need to keep in their head,
1, Severity estimation is just that an estimation.
2, Vulnarabilites are seldom singltons or not built towards.
In this case we see the first effect, but it happens.
It’s the second effect we realy need to keep in mind like the old joke about how quickly a “mouse problem” becomes a “mice problem”.
These sorts of vulnerabilities are not “one bad line of code” they actually come about from the way people think about meeting requirments.
People tend to “fall into groves” we get told a problem, and rather than treat it as unique we mentally see it through our experience of previously problems. That is we almost work by analogy.
It’s why in part we have “classes of vulnerabilities” that contain several “instances of vulnerabilities”.
But such thinking is not constrained to a single piece of code… It happens in many pieces of code.
Thus expect to see another “instance” of vulnerability in this “class” in the not to distant future…