Gauging Vista's Integrity
|
When is a flaw not a flaw? That's one of the questions security researchers are asking Microsoft about Windows Vista. |
The answers shed more insight into Vista's security architecture and whether UAC (User Account Control) adequately protects the operating system.
"There's a formal security science model behind [Vista]," said Andrew Jaquith, Yankee Group's program manager for Security Research.
Microsoft adopted the Biba Integrity Model, which Kenneth Biba developed in 1977. The model seeks to prevent a lower-level object from affecting or corrupting one of higher order. The idea is that an object of lower order cannot write to one of higher order.
Using a mechanism Microsoft calls MIC (Mandatory Integrity Control), Vista assigns one of five ILs (Integrity Levels) to objects: Untrusted, Low, Medium, High and System. Windows Vista uses a token-based system for executing privileges and maintaining integrity.
Last week, in a blog post, security researcher Joanna Rutkowska raised some concerns about Microsoft's integrity approach and how the operating system implements privileges.
While Vista's Biba Model "is really good from a security perspective," Jaquith said, "Microsoft cut some corners here." Rutkowska identified some of those cut corners in her blog post.
MIC executes based on the trustworthiness of the code, rather than truly protecting data--as in information--integrity. As such, the security mechanism prevents lower order objects from writing to those of higher order, but doesn't prevent lower IL objects from reading higher ones.
"In other words, if somebody exploits [Internet Explorer] running in Protected Mode (at Low IL), she will be able to read (i.e. steal) all user's data," Rutkowska wrote in her blog post. "This is not an implementation bug, this is a design decision and it's cleverly called the 'read-up policy.'"
She laid out a couple possible exploits of the "read-up policy" that would allow the stealing of data files, such as Word or Excel files.
Rutkowska identified bigger problems related to UAC privileges.
"One thing that I found particularly annoying though, is that Vista automatically assumes that all setup programs (application installers) should be run with administrator privileges," she wrote in the blog post.
Conceptually, a seemingly innocuous program would have temporary privileges at the highest level, including writing (in 32-bit Vista) to the kernel. While in her blog post, Rutkowska called the approach a "very severe hole in the design of UAC," in an e-mail exchange today she emphasized, "I don't consider this as a fundamental flaw in Windows UAC."
While maybe not "fundamental," Jaquith absolutely called it a "flaw. Other operating systems don't do that." He explained how in Mac OS X, programs can "install without the need for root privileges."
Rutkowska told me: "I can understand such a design decision as being a compromise between usability and security."
Another problem relates to UAC and MIC together, where a malicious program running at lower IL executes a process when privileges are elevated, say, when installing another program or changing the time.
This is "one possible way of attack which allows a low-integrity process to execute commands in the context of a high-integrity process," Rutkowska told me. "I don't consider it as highly critical--it just shows that UAC is not perfect and that there are probably more holes in it.
Both Jaquith and Rutkowska praised Microsoft's overall approach to security with Windows Vista. Improved security is coming elsewhere, as Biba Model concepts are adopted to Mac OS X 10.5 (aka Leopard) and future Linux versions.
"These operating systems will be more like trusted Solaris than Windows 3.1," Jaquith said.
But in a strange aside, in a blog post apparently in response to Rutowska's, Mark Russinovich took a surprisingly contrary position. The noted Windows expert joined Microsoft last summer when Microsoft bought his company, Winternals Software.
"Because elevations and ILs don't define a security boundary, potential avenues of attack, regardless of ease or scope, are not security bugs," Russinovich wrote. "So if you aren't guaranteed that your elevated processes aren't susceptible to compromise by those running at a lower IL, why did Windows Vista go to the trouble of introducing elevations and ILs? To get us to a world where everyone runs as standard user by default and all software is written with that assumption."
In our e-mail exchange today, Rutkowska expressed shock at Microsoft's newfound position.
"Russinovich declared that all implementation bugs in UAC are not to be considered as security bugs," she said. "Now it seems that Microsoft is backpedaling and that they will not treat UAC and IL seriously enough."
Comments (8)
you probably meant "Gauging".
Posted by A | February 14, 2007 5:40 AM
Just one more example of an insular culture in love with itself.
Posted by Mobutu Ubuntu | February 14, 2007 8:19 AM
One point of clarification about Joanna's comment on setup programs needing admin permission. The issue is that Vista doesn't necessarily know what permissions the files in an application might need. That's because legacy setup programs are just big executables (EXEs). InstallShield, for example, will take a developer's application and jam it into a big program. To Vista, the EXE is opaque, a blob. It can't know that the files the setup program wants to install need to go into Windows\System32, for example -- which would need elevated privileges to install. Or, the files could be 100% local, and not need extra privileges to install. So, to be safe, Vista takes the position that it will need admin permissions to run.
This behavior is basically Microsoft needing to deal with how older setup applications have always worked since the early days of Windows. (Vista *does* have a newer format that allows permissions to be explicitly defined ahead of time, but few applications use this... today.) Other operating systems do things differently, which was the point of my comments to Joe.
Example: OS X has two installation methods: drag-install or via a setup package. The drag-install method is what you see in 75% of the apps out there: you mount the disk image and simply drag the application icon to where you want it. Because the icon is actually a directory, all of its contents come with it. Assuming you don't drag the application to a sensitive directory, you won't get prompted. Personally, I love this feature and think it's incredibly intuitive and natural -- why "run a setup program" when you can simply move the app to where you want it?
The second OS X method involves running an actual setup program. In this case, the installer inspects what is called a Bill of Materials (BOM) that specifies exactly what files should be installed, and what privileges they require. The installer uses the BOM to determine whether it needs elevated privilges to install the app. Apple's BOM method isn't perfect (see http://projects.info-pull.com/moab/MOAB-05-01-2007.html), but it works quite well for the most part.
In UNIX, the prevailing installer methods are either simply file copies (like when you compile an application and type "make install") or a package format like Debian's APT or Red Hat's RPM, which have "manifests" in them enumerating what files need to be installed. In these cases, the installers either will make a determination that you need (or don't need) elevated privileges, or will simply fail to install unless you elevate.
My point with this lengthy post isn't to suggest that Linux or Mac are better, although I do believe in this case they've had the benefit of learning from the legacy Windows installer experiences. Vista's next-generation technologies for this are promising (see http://msdn2.microsoft.com/en-us/library/aa480150.aspx), but for now we've got a whole boatload of legacy stuff to deal with. Hence Joanna's objection.
[EDITOR'S NOTE AND APOLOGY: The blogging system flagged Andrew's post as possible junk because of the number of links. This delayed his comment appearing live on the blog.]
Posted by Andrew Jaquith | February 14, 2007 10:54 AM
> "Just one more example of an insular culture in love with itself."
This goes both ways though. Security experts try to glorify themselevs by insisting on the validity of faults. Still, have a look:
Microsoft : Arrogance leads to Vulnerability
,----[ Quote ]
| Chatting with the Microsoft senior sales people, I was struck by
| their incredible arrogance. They know the company?s products are good,
| but they have no qualms whatsoever about charging top dollar as a
| result.
|
| It reminds us how Microsoft used to behave when it comes to their
| products' security records. IE5 and 6 were nothing short of being
| proper Swiss Cheese with loads of holes in them but hey, they had 95%
| of the browser market at that time and couldn't care less.
`----
http://securityblog.itproportal.com/?p=514
Posted by Roy Schestowitz | February 14, 2007 1:26 PM
First there is the assumption that the malicious program was loaded on the PC. So who installed this program? A human. So the root cause of all security problems is us. Even with MLS certified operating systems at Certification level A, the human factor is still the weak point.
I am no fan of Microsoft for the most part, but they have made a move towards the right direction. I am hoping that with the release of service pack 1, some of these issues may have been addressed in some form.
As for myself I am designing a system that with any downloaded application, email attachment, or unknown web site a little robot will pop out, swinging it's little arms wildly, and state: "Danger Will Roberson! Danger! Danger!". Ok there I go aging myself again .
Posted by Lori Carrig | February 14, 2007 2:39 PM
I agree with Lori's assertion that the end user is the weakest link in the security chain. And I, too, fondly remember the warnings copiously spewed by the lost Robinson Family's robot whenever the slightest apparent threat reared it's ugly (or pretty) head. Too bad it didn't adequately or properly warn about Dr. Zachary Smith.
As it is with UAC. Being a rather well-informed PC user, I can make reasonably accurate judgement calls as to whether an application ought to be doing what UAC is warning me about, or not. I can also see where non-technical users might eventually out-of-hand grant access to any and all code, regardless of its source, because they're simply annoyed by UAC's constant alarms. The Robinson's robot often received this kind of dismissive response. A warning not heeded is as good as a warning not provided. Who pays attention anymore when a car alarm is sounding? Something about crying wolf...
Products like ZoneAlarm are excellent at identifying applications which should be trusted, warning about unknown applications, blocking known bad applications, providing an explanation of what has gone on to cause the alert, and remembering the permissively trusted applications so further user annoyance does not build. In doing so, ZoneAlarm's warnings are very much more valuable and effective than UAC's. In my opinion, Microsoft needs to commence an in-dept consultation with ZoneLabs and take lots of notes -- and lots of follow-up action.
Posted by Rick | February 14, 2007 3:50 PM
I read that bit about the MS decision that will "allow lower IL objects to read higher ones", and thereby capture personal info. Reminds me of the famous quote "That's not a bug, it's a FEATURE".
Posted by Brian | February 15, 2007 6:46 PM
Simply put, Vista assumes that its user is way beyond the average level as a computer user. Also, it assumes that it’s installed in a PC where all programs are on the same lever or higher than it. Actually, I really don’t want to comment anything about Vista. I’ve switched back to XP in order not to waste time getting errors and committing more mistakes than corrects in my everyday work. In my free time, I surf the Internet expecting that somewhere out there I’d be lucky to see someone from MS talk about what in the world happened to Vista.
Posted by life like animal portraits | March 19, 2008 2:38 AM