Slashdot Mirror
Windows' Patchguard Hinders Security Vendors
eldavojohn writes "Windows' PatchGuard seems to be upsetting third party security vendors such as Symantec, Sana Security and Agnitum. It sounds like the 'black hats' will be able to bypass this security feature (which will be in all copies of Vista) but force security software companies to give up developing software for Windows. From the article: 'PatchGuard will make it harder for third parties, particularly host intrusion-prevention software, to function in Vista,' said Yankee Group analyst Andrew Jaquith. 'Third parties have two choices: continue to petition Microsoft to create an approved kernel-hooking interface so products like theirs can work, or use "black hat" techniques to bypass the restrictions.' Apparently, using these techniques is not a difficult trick."
I agree, this sort of system software IS going to break with each security rev of Windows. It only stands to reason that breaking viruses, which is what MS wants to do, is likely to break anti-virus software as well.
It is fascinating that TFA explains how if a boot routine can initialize a "debugger attached" flag, the PatchGuard system is not initialized. From this aspect alone, I'd say MS should start playing more nicely with the vendors, since any malicious code worth it's salt should set this value permanently and then replace kernal routines on disk as necessary.
Also, given the fact that MS intends to making patching the standard for releasing a secure OS, the vendors can't really do this kernal checking themselves. Thus, I think it's safe to say from the perspective of this article, the OS's kernel is patchable by anyone.
Whether MS' technique works or not, it's bad for us as it limits our choices.
Of course I'm sure neither of these is a concern to symantec, only that they'll make less money, but they are still valid arugments to consider.
Certificates of trust already exist in Windows. They're used by web browsers. It would be trivial to use the code that is already present to check for a valid certificate. The second layer of protection - requiring the user/IT department to countersign the patch - would make transparent breakins much harder. Not impossible, but definitely much harder.
Of course, this is all pointless these days, anyway. All a rootkit writer has to do is develop a mini hypervisor or hijack one already in use. For zombies, viruses, etc, you'd then have the externally-visible interfaces in the OS and everything else concealed outside. BIOS viruses could also be quite lethal, as they too would bypass this protection. Far too low a level for the OS to detect. These days, with graphics processors essentially being parallel CPUs, I'm surprised nobody has put a virus on the graphics card. If the PCI is multi-mastered (not uncommon on higher-end machines), then the card could control all the other devices without going through the OS at all, giving a virus that could inhabit that space ABSOLUTE power over the machine.
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
Does anyone else smell a new monopoly suit?
Microsoft moves into system security (with their firewall, spyware tool, and I think they recently bought an AV company), and then sets up a 'security' feature that just happens to block out their competitors?
Yeah... that smells pungent to me.
110100 1101000 1101000 1100110 0 1101111 1101000 1100011 1
If PatchGuard was optional, the first thing malware would do after getting into your computer is turn it off. (Of course, this is only a problem for people who want it turned on.) The only solution is to make security that can't be turned off.
The whole "PatchGuard" concept shows how broken Microsoft's approach to an OS has become. The whole concept is to catch changes made by programs which already have full access to kernel space. By checking every five or ten minutes for a change, no less. That's inherently a futile exercise. It may break some current exploits, but it won't break new ones. Any program that has access to kernel space can take over the machine. It could load a whole new OS if it wanted to.
The whole concept of add-on programs having access to kernel memory is so insecure that it has to go. UNIX and Linux limit it to loadable drivers, and the serious microkernels like QNX and IBM's VM don't allow it at all. But the Microsoft world, mostly for historical reasons, has all sorts of crap running with access to kernel memory, from various "security programs" to game DRM components. All that crap should have been taken out in Vista. The fact that it wasn't indicates how minor a change at the kernel level Vista is over XP.
Viruses and you. In this case we're talking about locally executed binaries that are being run with root(admin) privileges.
I just felt it had to be said but : Since when can you not totally mess up a Linux system when you're running software as root?
I don't see local software running as root and therefore having root permissions as "a security hole". The only security holes I worry about is elevated permissions and unauthorized installs such as the 0-day IE exploit and buffer overruns.
While I'm glad MS is securing stuff, I'd rather they do it via preventing 0-day exploits/permission elevations and implementing "sudo/pass-request" sorts of requirements for installing software and accessing system internals in order to make the process more transparent and auditable.
Summarily, you should not be able to totally mess up the system with any piece of software you run in a standard Windows home installation. Force a root login for that sort of thing, at least that'd make it somewhat obvious what's happening. That being said, the problem with windows (asides those I've mentioned which are valid security holes), lies not in the admin account being insecure but rather the fact that everyone and their uncle is an admin the entire time they're running.
Absolutely you can. But, if I choose to install software, I can decide that I trust it, and want it running as root. But the rest of the time, I'm logged in as a user who doesn't have root priveleges, and can't bork anything but my own stuff. If the user wishes to install kernel-level software, they're allowed. I've ran apache as both userland and root, except for which ports it can bind to, apache doesn't care.
That has always been the problem. You simply can't do anything on windows without being the admin, because so much crap just expects to have it, and fails if it doesn't. And then every damned website you visit which has an exploit is the administrator. Whee!! How fun!
Back in the day, if I wanted some software on a UNIX machine, and the cranky UNIX admin said "leave me the fsck alone", I could still untar it into my own directory, set my path variable (give or take one or two more) and just run it. The software ran just fine in userland, and was isolated from the OS. It could hose my files, but not the system.
Same deal on a Mac, the folder which was the install was the whole app. You could move it or delete it -- deleting was uninstalling basically. On Windows, every bloody piece of software expects to be able to write to the registy, install itsself for every user, demands that it write to Program Files, and possibly muck with some stuff in the Windows folders. Because that's how you're expected to do these things.
The fact that you can't do anything in Windows without being the admin has always been a major source of problems. If they had a model whereby users could install software into their own "user programs" or somesuch, and that was separated from the rest of the damned OS, these things couldn't happen.
However, as long as MS sticks with the way they have envisioned the world, preventing people from having kernel hooks (unless you use black hat methods) is kind of an empty solution, because it doesn't address the bigger problem of needing to be the Administrator to accomplish anything on a Windows machine.
Cheers
Lost at C:>. Found at C.
This I tend to agree with but I don't view it so much as a "security software shortcoming" as a "convenience against security tradeoff" in their business model. I classify it as a separate thing because that isn't a "hole", its very much "by design" in order to cater to people who know jack all about computers.
And its not a matter of being insecure at the software level, its a matter of bad practices implemented to make things convenient for "low knowledge users" in home environments.
While I get what you're saying, I separate the two issues, because you're fundamentally talking about two separate things. If every UNIX engineer wrote software the way they write it for Windows, you'd have an equal amount of UNIX issues. But either way, its more of a procedural practice thing than it is a "bug" thing. When I'm talking about security holes I restrict it to things you can't prevent (remote exploits like buffer overruns) or things that shouldn't be happening (ie, elevated privileges).
The fact that you can't do anything in Windows without being the admin has always been a major source of problems.
I agree, but theres no *point* in doing anything in Windows without being admin.
There is no point in running Windows as a non-priviledged user.
If you doubt my word, log into your favorite Windows as your unpriviledged user and set up a scheduled task to run cmd.exe
When the scheduled task runs and you get a command window try and see what you *cannot* do on the system...
(I used to put a great deal of effort into running as an unpriviledged user; I spent hours trying to get games to run without having to be Admin. It seems that I totally wasted my time. Thanks, Bill.)
In the free world the media isn't government run; the government is media run.