Vista Protected Processes Bypassed
Anonymous Hero writes "Security Researcher Alex Ionescu strikes again, this time with a proof of concept program that will arbitrarily enable and foremost disable the protection of so-called 'protected processes' in Windows Vista. Not only threatening Vista DRM and friends, it's also another step towards hardened and even more annoying malware. Normally, only specially signed processes made by special companies (decided by Microsoft) can be protected, but now the bad guys can protect any evil process they want, including the latest version of their own keylogger, spambot, or worm, as well as unprotect any 'good' one."
The problem with this is that the said paid hackers get better pay working on the exploits on their own and selling them in the black market. A lot of exploit code goes for $5000 a pop to the people who use it, and there are plenty of buyers (and it is not like they can't sell to multiple people, and make N*$5000 for a single good exploit). Heck, something like the above would easily sell hundreds or possibly thousands of times for $5000 a pop. Can most software companies afford to pay hackers the $300,000-500,000 a year that a good one could easily make off a single exploit?
We were all warned a long time ago that MS products sucked, remember the Magic 8 Ball said, "Outlook not so good"
He [Alex Ionescu] is also a Microsoft Student Ambassador and is representing the company on campus as a Technical Rep.
not for long, I bet.
Stop Computers/Cars Analogies on S
I miss the days when I gave my computer commands not suggestions.
You are becoming nostalgic, Deny or Allow?
"Protected processes" are a reasonable idea. They're certainly better than putting video and audio processing in the kernel as part of the DRM system. But apparently Microsoft botched the implementation.
Microsoft has for some years allowed processes to do too much to other processes. Things like "injecting" a DLL or thread into a running process from the outside, or "hooking" system calls, are inherently security problems. In the Windows world, normal processes can do that to each other. This tends to be overdone, with too much "hooking" of system calls and such, a tradition from the DOS era. The UNIX/Linux world doesn't have that tradition. Fortunately.
In the Linux world, the things you can't do to a Microsoft "protected process" are roughly equivalent to the functions of the PTRACE call. In SElinux, the mandatory security system controls which processes can use PTRACE on which other processes. So SELinux already has "protected processes", but with a better security model.
If we have to have DRM, protected processes aren't a bad idea. But what you want is for them to be compartmented, not privileged. They should be running in a compartment which prevents other processes from attaching to them, but they don't need the privilege of attaching to other processes. So the video decoder can be protected, but doesn't have enough privileges to act as an aimbot for some game. The security system for a game should be able to lock the game processes into a compartment which other processes cannot enter, preventing cheats. Enforce separation, not privilege.
So get off your old, tired, 20th Century horse and get with the new paradigm.
Just a suggestion of course.
Faster! Faster! Faster would be better!
The tool needs to be run with elevated privileges (otherwise it will not work). It decompresses a 848 bytes driver and loads the driver. The driver does nothing but set bit 11 (ProtectedProcess) of the Flags2 bitfield (offset 0x224) of the corresponding _EPROCESS structure of the process to be modified. However, this requires the neccessary rights to load and install a driver...and as we all know, once being in kernel mode there's no real protection against malicious code...
I agree.
The problem with Microsoft is not so much one of bugs as it is a problem with their general design philosophy.
Such as providing mechanisms for your own developers to bypass the security of the entire system to make some friggin media clips play more smoothly. News flash, idiots: if you provide two paths through security, a strongly checked path and a weakly checked path, you incentivize attackers to take the weak path! And if you provide those hooks for your own developers to bypass security, then attackers can use them too!
They were probably praying that no one would ever figure out that those hooks were there... and security by obscurity is very, very poor design.
My inclinations against myself or my family running vista just got a +1 Justification.
Hydraulic pizza oven!! Guided missile! Herring sandwich! Styrofoam! Jayne Mansfield! Aluminum siding! Borax!