It seems that many people didn’t fully understand why I wrote the previous post – Vista Security Model – A Big Joke... There are two things which should be distinguished:
1) The fact that UAC design assumes that every setup executable should be run elevated (and that a user doesn't really have a choice to run it from a non-elevated account),
2) The fact that UAC implementation contains bug(s), like e.g. the bug I pointed out in my article, which allows a low integrity level process to send WM_KEYDOWN messages to a command prompt window running at high integrity level.
I was pissed off not because of #1, but because Microsoft employee - Mark Russinovich - declared that all implementation bugs in UAC are not to be considered as security bugs.
True, I also don't like the fact that UAC forces users to run every setup program with elevated privileges (fact #1), but I can understand such a design decision (as being a compromise between usability and security) and this was not the reason why I wrote "The Joke Post".
I agree. security in vista seems to be just a different mechanism, not a better one. they seem to have improved on many of the various bugs from systems past, but in doing so, they are leaving the OS open in other areas. Wouldn't it just be easier to rebuild the OS from the ground up instead of trying to improve upon a system that has shown in the past to be flawed in so many ways?
ReplyDeleteThere are three types of setup programs on Vista:
ReplyDeleteRegular Setup (Admin)
Managed (fully protected)
Web Install (OneClick install)
Only the first runs elevated. The other two are restricted by either managed permissions or sandboxed by IE.
Mark's posting is frustrating because Mark is speaking to technical fact in a manner that is obtuse, and isn't in sync with the marketing-type statements that Microsoft makes.
ReplyDeleteMark says that UAC elevations and integrity levels do not define new Windows security boundaries, and, as such, attacks against these features aren't attacks against "security". This is all true, assuming you understand the minutae he's talking about. Distinguishing between the established Windows security architecture (the LSA, desktops, security prinicpals, ACL's, privileges, etc) and this integrity level retrofit is pretty minute, but it's accurate.
It's silly that Mark said this in this way, because a user with a Vista-based PC that has been taken-over by malicious software (that they, no doubt, installed by elevating the installer for the malware) isn't going to differentiate between breaches to the Windows security model, and attacks against UAC. What Mark says is factually correct, but isn't in sync with the types of non-technical statements coming out of Microsoft.
It's compelling, from a sales perspective, for Microsoft to make lofty and vague statements about Vista's enhanced security, while convenient for them to have technical fact to fall back on-- technical fact that the average user won't ever know is there.
I like that you've posted about this, and I hope that others do, too. Comments in Mark's blog are also right on th emark. Mark's words may come back to haunt him, as the press picks this up and runs with it. "Microsoft Technical Fellow Says Bugs In New Vista Security System Not Really Security Bugs"... Heh heh...
It took a long time for Microsoft to acknowledge Shatter Attacks as a vulnerability, when they were first discovered and researched. They only started worrying about them in XP when they insisted a lot more on non-interactive services, and the fix didn't come until UIPI and Session 0 services.
ReplyDeleteHopefully it won't take a couple of years for these implementation bugs to be fixed. Mark was very clever in wording his statement to be accurate; it's true that ILs are *not* security boundaries, so in theory there's nothing guaranteeing this kind of safety.
I think the argument from that side is always going to be "Well, it makes things *more* secure, but there's still work to be done, it wasn't designed as a perfect solution". But I go with the school of thought that says if you're implementing a security feature, do it completely, not half-assed.
I'm sure developers inside Microsoft aren't to happy about the tradeoffs they had to make, and they probably know about WM_COMMAND, but either didn't have the time to properly test all messages or a large company's product needed this to work; it's always something like that.
I think you should've followed responsible disclosure and notified Microsoft privately about this bug though.
Best regards,
Alex Ionescu
"I think you should've followed responsible disclosure and notified Microsoft privately about this bug though."
ReplyDeleteMicrosoft already know about this bug and aren't going to do anything to fix it.
In fact Microsoft have declared that bugs whether by accident or by design with UAC are not security bugs as UAC does not actually provide any extra security.
It's only purpose therefore is to annoy users, and give a false sense of increased security. But it apparently does nothing else and was never designed to.
So not only was there no need to "responsibly disclose" this supposed non-bug, but it's not even security related according to Microsoft.
-Steve
As a former IBM server developer, I think you are right on the money. If it were the case that Vista were only ever going to be a consumer OS, it would be bad enough, but we all know that it will play a part in holding/managing sensitive business informtion. The only excuse MS can truthfully offer is that someone didn't know any better.
ReplyDeleteJoanna, have you tried the Windows Application Compatibility Toolkit 5.0 (http://www.microsoft.com/downloads/details.aspx?FamilyID=24da89e9-b581-47b0-b45e-492dd6da2971&displaylang=en) ?
ReplyDeleteIt provides shims that can be used to override the elevation marking of a given application. You could simply apply the “RunAsInvoker” shim/layer to the installer.
A lot easier than going through the manifests or fiddling with your individual permissions raising or lowering them with each app.
Re: Drew:
ReplyDelete"Wouldn't it just be easier to rebuild the OS from the ground up"
They could rebuild the _implementation_ from the ground up, but that won't help, because they can't rebuild the APIs, security mechanisms, etc. from the ground up, as this would break compatibility with existing Windows software. That way, Microsoft wouldn't make a new version of Windows, but in fact a new Windows competitor. Their main competitive advantage -- largest number of apps, developers, and users familiar with the workings of the system -- would be out of the, err, window. They'd suddenly have to create an OS that is superior to Linux and Mac OS X.
A compromise (tradeoffs) "between security and convenience"...
ReplyDelete...or "between usability and security"..
A compromise is a function - what are the measures, what is the matrix, where are the limits (borders), who setup them, according to which more-far (strategic) criterions ?
You are not fighting with bugs but with decision making process;
If it is mobile, non limited, or limited by current environment only - You are hunting the ghosts.
UAC and integrity levels are step 1, as Mark says "to get us to a world where everyone runs as standard user by default and all software is written with that assumption". Step 2 will be to cash in on this and provide real security boundaries once the climate allows it. It all makes sense, it's just unfortunate that Microsoft marketing has to be so disingenuous about UAC. What can they do though? People want the security now and aren't going to swallow some 2-step process.
ReplyDeleteMaybe, I am inappropriately channeling my UNIX roots, but this smells a lot like setuid to me. Remember the buffer overflow in finger(1)? This reads like the same sort of security challenge. Now every privileged process, thread or application has to validate input and be secure against buffer overflow, file handle races, symlink races all of the myriad ways to escalate privilege that the UNIX community took about 20 years to mostly weed out. The problem is only compunded by the fact that Microsoft has once again ignored all of the published studies on user behavior. HINT: They almost always say yes.
ReplyDeleteI think what we see here is a failure to parse. What Russinovich said was this:
ReplyDelete- Weaknesses in UAC will not be fixed via Microsoft Security Bulletins or necessarily fixed at all.
- Weaknesses in the actual security perimeter will continue to be fixed via Microsoft Security Bulletins.
- The actual purpose of UAC warnings is not to immediately augment security; ultimately the APIs which present the security perimeter must be safe.
- The actual purpose of UAC warnings is to make it annoying to use Admin privileges; the intentionality is that this will force software vendors into fixing any software the requires running under Admin.
Mark however seems to have missed something that Joanna is inhernetly getting at with her recent vulnerability finds: msiexec is a special security perimeter that is used by Admins in a normal use case. However the case with msiexec is complicated. An MSI can contain code in the form of Custom Actions which would theoretically allow arbitrary back doors into msiexec privilege. Is this a vulnerability or feature?
It's actually quite simple for software manufacturers to add a manifest to their setup programs so that Vista doesn't automatically require them to run elevated.
ReplyDeleteThe annoying thing is that there is no way to have a setup program run elevated or not elevated according to the user's choice; which would be useful in tightly-managed corporate environments. Setup could install into C:\Program Files if it was being run elevated and into the user's private directory if it wasn't.
If an user is able to install a program without Administrator privileges this means the user is able to install any sort of malware and the administrator is not able to control the users i.e. all users are freely to install everything, any soft of installers and this is worst. For this reason, Microsoft hash chosen to allow the software installation with Administrator privileges only, and this is the better because to install a program installer an user needs an administrative privilege i.e. the administrator consent. And installing a program with administrative privilege is also more safer because that program will be put in C:\Program Files and can't be modified by another running program or malware
ReplyDeletescalo: a user should still be required to enter credentials for 'installer' account.
ReplyDelete