44 ms·
I'm trying to be charitable, because I don't quite understand the Windows security model, but how is the reasoning to this not just: "We don't trust this code
by SomeStupidPoint 9y ago
I'm trying to be charitable, because I don't quite understand the Windows security model, but how is the reasoning to this not just:
"We don't trust this code from the internet, let's run it as SYSTEM!"
Because that seems insane. It's escalating the runtime permissions of code you don't trust -- moving it from user permission to SYSTEM permission just because it hits internet cache.
I keep thinking there must be some part of this I'm missing, because if that's really how it works... "Double You Tee Eff" indeed.
- UnoriginalGuy 9y agoThere's nothing you're missing, it is insane. So the anti-virus runtime engine has to run as something akin to SYSTEM since it has oversight over the entire system, but once a type is detected it could pass the actual sandboxing into a lowpriv child process and wait for a result. The only explanation I can imagine is performance? But child processes could be pre-spawned or it could use shared memory regions for isolation. There's a number of things you can do here to have your cake and eat it too. I'm legitimately surprised by this from Microsoft, they take security very seriously these days, and I cannot see how this would pass their normal review process? Even just reading the description makes you facepalm.
- userbinator 9y agoSYSTEM is even more privileged than Administrator. This is the real "root" user. One thing that sometimes annoys me greatly is that on Windows, Administrator is not the most privileged user and SYSTEM is hard to actually get to when you need it. On a tangential point, one common "hack" when XP was popular was to replace Winlogon.exe with Minlogon, which basically made it an ultra-fast-booting "single user mode" (and coincidentally, also bypassed WPA) and that single user was... SYSTEM. That along with EWF and some creative RAMdisk usage made for some interesting liveCD-like Windows environments.
- voltagex_ 9y agoWhat advantage would a Minlogon XP have over WinPE?
- bonzini 9y agoProbably, that WinPE did not exist at the time!
- voltagex_ 9y agoWikipedia disagrees - at least by the time of WinXP SP2.
- bonzini 9y agoIt also says that WinPE versions before 2.0 were only available to corporate enterprise customers, and 2.0 is based on Vista.
- yellowapple 9y agoWasn't BartPE all the rage back then, though?
- mintplant 9y agoWhen I was little I booted into a Linux LiveCD and replaced magnify.exe with cmd.exe on a family computer with login time restrictions. Enabling Windows Magnifier from the accessibility menu on the login screen caused magnify.exe--now Command Prompt--to be launched as SYSTEM. From there you could start up explorer.exe to get a SYSTEM user desktop.
- mtreis86 9y agoStill works on win7, with renaming command prompt to stickykeys.
- yellowapple 9y agoThis is actually a relatively common technique for resetting local Administrator passwords in the event that they're forgotten.
- red75prime 9y agoI took it for granted that all SYSTEM superpowers can be given to Administrator via Computer Configuration/Windows Settings/Security Settings/Local Policies/User Rights Assignment in gpedit.msc Do you have examples for what SYSTEM can do, but Administrator cannot?
- tremon 9y agoSYSTEM ignores access controls on the filesystem, for example. With NTFS, you can disallow Administrator access to certain files and explorer will require the administrator to explicitly take ownership of the files before any other action is allowed. SYSTEM does not need to do that.
- userbinator 9y agoThere's also the HKLM\SAM and HKLM\SECURITY registry keys, which are by default only accessible to SYSTEM.
- poizan42 9y agoDoesn't matter, the administrator can just enable their SeBackupPrivilege and SeRestorePrivilege and ignore those ACLs.
- poizan42 9y agoI just checked, and on my system without having changed anything, administrators (i.e. users in the Administrators group, including Administrator) are granted SeBackupPrivilege and SeRestorePrivilege, which are the "ignore access control" privileges. Anyways, even then administrators have by default SERVICE_ALL_ACCESS grant to the Service Control Manager, which allow you to create and start a service running as SYSTEM. Also administrators have SeDebugPrivilege, so they can ignore ACLs on process objects. This means you can just execute arbitrary code in one of the system processes - or you can duplicate the token of one of those and impersonate it.
- wfunction 9y agoSYSTEM has more privileges by default, but Administrators have the privileges to assign all those privileges to themselves too.
- the8472 9y agoTo be fair, 3rd party antivirus software often has kernel modules analyzing files. And that TTF font vulnerability recently was stemming from the font rendering engine interpreting turing-complete font descriptions in kernel mode. And fonts come from untrusted sources of course. So there are precedents for direct paths from untrusted sources to SYSTEM or kernel space execution environments.
- dom0 9y agoThe sad part here is that Microsoft knows much better about this stuff. So it's not like they don't have the know-how, it just looks like the PMs just didn't care. I can only assume that no part of the MS SDL was applied to this system. I expected better from MS, I really did. This is security engineering on the level of the other AVs, Linux Desktops and similarly insecure software, i.e. no security engineering AT ALL.
- AsyncAwait 9y ago> . This is security engineering on the level of the other AVs, Linux Desktops and similarly insecure software Why the unnecessary jab at Linux for no reason?
- deleted 9y ago[deleted]
- yellowapple 9y agoI'm not aware of any Linux desktop with this degree of insecurity. I know they tend to be a bit naïve with the assumption that root access is the only goal for malware, but that's about it.