Code execution 0-day in Windows has been under active exploit for 7 weeks:
A critical code execution zero-day in all supported versions of Windows has been under active exploit for seven weeks, giving attackers a reliable means for installing malware without triggering Windows Defender and a roster of other endpoint protection products.
The Microsoft Support Diagnostic Tool vulnerability was reported to Microsoft on April 12 as a zero-day that was already being exploited in the wild, researchers from Shadow Chaser Group said on Twitter. A response dated April 21, however, informed the researchers that the Microsoft Security Response Center team didn't consider the reported behavior a security vulnerability because, supposedly, the MSDT diagnostic tool required a password before it would execute payloads.
On Monday, Microsoft reversed course, identifying the behavior with the vulnerability tracker CVE-2022-30190 and warning for the first time that the reported behavior constituted a critical vulnerability after all.
"A remote code execution vulnerability exists when MSDT is called using the URL protocol from a calling application such as Word," the advisory stated. "An attacker who successfully exploits this vulnerability can run arbitrary code with the privileges of the calling application. The attacker can then install programs, view, change, or delete data, or create new accounts in the context allowed by the user's rights."
(Score: 2, Interesting) by Opportunist on Friday June 03 2022, @08:20AM (8 children)
Taking a look at the exploit link we find something along the lines of
..\..\..\..\..\..\windows\system32\whatever...
How on earth is something like this still possible?
Ok, to answer my own question: Because in Windows, even today, every fucked up, insignificant process, even if it doesn't need any kind of privileges, runs as nt-authority\system and local system. Why the FUCK? You can't even argue with "oh, we have to stay compatible with legacy systems that expect it". It's your own fucking JOBS that run at this level!
MS, seriously, your security is rubbish, it always has been and it always will be.
(Score: 2) by inertnet on Friday June 03 2022, @09:15AM
As I saw that "C:\Windows\System32" path, I was wondering if installing Windows in a different location would prevent such attacks. The attackers didn't even bother to use the %systemroot% or some such variable, presuming that it would be expanded in such scripts.
(Score: 0) by Anonymous Coward on Friday June 03 2022, @10:59AM (5 children)
I'm not sure I get what you're saying (and I'm not excusing the flaw at all - it's a very bad one).
Why are you picking up on the path? On a *NIX system, I can also do "../../../../../../../../../sbin/whatever" from my own ${HOME}. How _that_ particular thing something that ticks you off?
*NIX has the setuid and setgid flags which Windows do not (they have other issues) so just accessing something on that \windows\system path doesn't mean it runs as you.
Not trying to inflame, just trying to grok what you're trying to say.
(Score: 4, Insightful) by Opportunist on Friday June 03 2022, @11:37AM (4 children)
Yes, you can do that on Linux. The point is, though, that the average daemon can not. Daemons, at least if properly set up, run in their own environment and trying to "../../../../../etc/nc" out of it will fail.
In a properly set up environment, it would also fail because the daemon is running with its own set of privileges and these exclude running any jobs that it doesn't have to run. Also something you can't really do if every fart you want to pass as a service runs on nt-authority/system rights.
(Score: 3, Insightful) by Thexalon on Friday June 03 2022, @12:06PM
But how else can Microsoft allow its business partners to spy on their customers? Geez, you people are so outdated with this idea that people should be able to control the boxes they allegedly own.
"Think of how stupid the average person is. Then realize half of 'em are stupider than that." - George Carlin
(Score: 0) by Anonymous Coward on Friday June 03 2022, @03:14PM
This has nothing to do with services. The RCE runs in user context.
(Score: 2) by RS3 on Friday June 03 2022, @04:40PM (1 child)
Off the cuff, I'm wondering: if process x can't ask OS to run process y, but process x can read the file y, could process x do its own load and go of y? I know that's not privilege elevation, but maybe something to be gained? (I don't think like an attacker, and I'm always both amazed and of course troubled by their cleverness).
(Score: 2) by Opportunist on Friday June 03 2022, @05:47PM
It could, but y would run in the context of x. You don't really gain a lot that way.
(Score: 2) by istartedi on Saturday June 04 2022, @01:37AM
The "Are you kidding me" aspect for me has more to do with why a document would be allowed to invoke something called "Microsoft Support Diagnostic Tool". That seems like something that would only be run by the application when, oh... I dunno... when something goes wrong? Perhaps by the user when they want to troubleshoot something? Very rarely anyway, and certainly not at the whim of a document.
Appended to the end of comments you post. Max: 120 chars.