Windows Vista Security : Windows Vista

Microsoft SIRv5 Released

windowsvistasecurity — Mon, 03 Nov 2008 13:44:00 GMT

Good day, Paul Cooke here.

The Microsoft Malware Protection Center has published volume five of the Microsoft Security Intelligence Report. If you have not taken a look at this report before, I urge you to go download it from http://www.microsoft.com/sir. It provides a thorough view of the current threat landscape and is filled with a number of great data points. In my first scanning of the document, the following items immediately jumped out at me:

· Microsoft vulnerabilities accounted for 42% of the total vulnerabilities on Windows XP for browser based attacks; however, on Windows Vista-based machines the proportion of vulnerabilities attacked in Microsoft software dropped to just 6% of the total. This highlights our not only our continued security investments in the browser but also that attackers are focusing more and more on the applications that run in the browser.

· The infection rate for Windows Vista is significantly lower than Windows XP, regardless of service pack levels. In addition, 64-bit versions of XP and Vista have lower infection rates than their 32-bit counterparts.

· The higher the level of service pack a machine runs, the lower the rate of infection. This is consistent across client and server platforms, across all versions. Clearly, keeping up to date with the latest service pack levels and security patches is beneficial from a security perspective. While we have always thought this to be true, having a data point to prove it is great.

This is just a taste of some of the findings in this latest report. I’ll be scouring this report in detail and come back in the next week or so with a comprehensive look at how Windows Vista has fared from a security perspective since its release!

Posting is provided "AS IS" with no warranties, and confers no rights.

TechED - EMEA

windowsvistasecurity — Mon, 03 Nov 2008 13:38:00 GMT

Good day, Paul Cooke here.

I am in Barcelona getting set up for some sessions at TechEd-EMEA in Barcelona. The weather was a bit dicey for parts of yesterday but today is clear and beautiful. I've got two full sessions and a bit part in a third where I will be talking about Windows 7 security features. If you are in Barcelona and have a passion for security, come to one of my sessions or find me on the exhibition hall floor, I would love to chat.

Posting is provided "AS IS" with no warranties, and confers no rights.

Windows Vista Security Stories @ TechEd - Recap

windowsvistasecurity — Fri, 18 Jul 2008 20:00:00 GMT

Good day! Paul Cooke, Director of Enterprise Security, here.

Orlando entertained close to 9,500 customers, partners, and staff at the first Microsoft Tech·Ed for IT Professionals. For four days, IT Professionals from around the world experienced in-depth technical learning with more than 770 Breakout Sessions, Hands-on Labs, and Instructor-led Labs; they also networked and shared information with Microsoft partners and industry peers. It was great to to discuss security topics with both old friends and new.

This year we tried something a little new for us: we went searching for Windows Vista Security Stories and wanted to get them on camera, so that our engineers could hear from you directly. We figured we would get some complaints and some kudos from the participants, but what we were really hoping for is an honest assessment of what you thought about Windows Vista Security! The participation from attendees was great and the candid feedback was exactly what we were looking for….

Well, it’s been just over a month and we have finally finished combing through the hours of video and selected our favorite stories! So without further ado, I would like to congratulate the following story tellers and let you know what you won:

Xbox 360

Zune

· Russ Alexander

· Stephen Dietz

· Joseph Eckhout

· Raymond Comvalius

· Glenn Milles

· Nathaniel Avery

· James Melton

· Cody Jones

· Andreas Hofmann

· Matthew Baker

We have the prizes on order and will be reaching out to you in the next week or so to confirm where you want your prize delivered!

We really want to thank all of you that participated. It was a lot of fun talking with all of you and we hope to see you again next year!

FAQ: Why can’t I bypass the UAC prompt?

User Account Control Team — Fri, 10 Aug 2007 06:44:00 GMT

[This item was authored by Aaron Margosis and originally appeared on his Non-Admin Blog.]

The frequently asked question, "Why can't I bypass the UAC prompt?" is often accompanied by statements like one or more of the following:

"We want our application to run elevated automatically without prompting the user."
"I don't get why I can't authorize an application ONCE and be done with it."
"Unix has setuid root which lets you run privileged programs securely."

The designers of Windows Vista's User Account Control expressly decided not to incorporate functionality like setuid/suid or sudo found in Unix and Unix-like OSes such as Mac OS X. I think they made the right decision.

As I'm sure everyone knows, large parts of the Windows ecosystem have a long legacy of assuming that the end user has administrative permissions, and consequently a lot of programs work correctly only when run that way. (I'm not going to delve into that history here, nor will I entertain any finger-pointing on the topic at this time. One of these days I'll post my thoughts on that subject.) As computer security has become increasingly important, breaking that cycle became absolutely imperative. It is with the release of Windows Vista that the first major move in that direction is achieved. Indeed, the primary purpose of the technologies that comprise UAC is to enable "standard user" to be the default for Windows, encouraging software developers to create applications that do not require admin. The move to standard user is a new paradigm and creates the need for software developers to write applications that do not require admin privileges. Creating a shift in the ecosystem will take a long time due to the large deployed base of legacy applications, and UAC is a good first step.

Pre-approving code to run with elevated permissions without going through an elevation prompt, as described in the bulleted scenarios above, seems at first glance to be both useful and convenient. However, the negatives far outweigh those benefits. In particular:

The "standard user by default" vision would become impossible and ultimately never happen;
Elevation of privilege (EoP) would be trivial – any compromise could lead to full system compromise.

If it were possible to mark an application to run with silently-elevated privileges, what would become of all those apps out there with LUA bugs? Answer: they'd all be marked to silently elevate. How would future software for Windows be written? Answer: To silently elevate. Nobody would actually fix their apps, and end-user applications will continue to require and run with full administrative permissions unnecessarily.

What if the application could not mark itself for silent elevation but instead had to be marked by the consumer or enterprise administrator installing the application? Answer: the developer of the installation program (which necessarily runs with admin/system permissions in order to install machine-wide) would figure out where the setting lived, and set it. (Several major ISVs told us directly that they would in fact do exactly that.) There would be no real way to protect that setting from anything running as admin. This would be especially true if it were settable via Group Policy (which would be expected, if not demanded).

"Well, so what? We're only talking about applications I approved!" OK, let's say that's true, but how do you ensure that a malicious user cannot use the application for purposes other than those for which it was intended? And at least as important – how do you ensure that malware that has infected the user's session cannot drive a setuid application programmatically to take over the system? Ensuring strict behavioral boundaries for complex software running with elevated privileges is (at best) incredibly difficult. And ensuring that it is free of exploitable design and implementation bugs is far beyond the capabilities of software engineering today. The complexity and risk compounds when you consider how many apps have extensibility points that load code that you or your IT admin may not be aware of, or that can load code or consume data from user-writable areas with minimal if any validation.

Privilege escalation due to setuid and sudo has plagued Unix-like systems for many years, and continues to do so. In fact, several of the bugs in the recent Month of Apple Bugs fell into this category. Follow these links for lots more references: (*)

In the past, elevation of privilege has tended not to be noticed in Windows – there is no real "elevation" if you're already running as admin. (**) With the Vista shift toward "standard user", EoP threats become much more important, and it is vital that Windows do as much as practical to mitigate them. That is also why Windows services are no longer able to interact with the user desktop. Taking on the setuid headaches that *nix has had to live with does not seem like a profitable deal.

We expect that in ordinary day-to-day usage, users should rarely, if ever, see elevation prompts, since most should rarely, if ever, have to perform administrative tasks – and never in a well-managed enterprise. Elevation prompts are to be expected when setting up a new system or installing new software. Beyond that, they should be infrequent enough that they catch your attention when they occur, and not simply trigger a reflexive approval response. This will increasingly be the case as more software conforms to least-privilege norms, and as improvements in the Windows user experience reduces prompting further.

Having said all that, there is a Local Security Policy option to change the behavior of the elevation prompt for Administrators to "elevate without prompting". With this option selected, anything that requests elevation gets elevated without prompting the user. (The default setting is "prompt for consent"; the third option is "prompt for credentials". Note that "elevate without prompting" is available only for members of the Administrators group. The options for standard users are "prompt for credentials" and "automatically deny elevation requests".) While "elevate without prompting" may be useful in well-constrained, secure environments for automated testing and possibly for initial system setup, having this option selected otherwise is very risky and strongly discouraged. (Note also that Vista's Home SKUs do not include the policy editor.)

Nitpicker's corner (***)

(*) Pointing out the obvious: local privilege escalation by definition means that the bad actor is already on your system. However, there's a huge difference between malware running as you (non-admin) and malware running with root privileges. If there weren't, there would be no point (from a security point of view) in running with least privilege.

(**) "Elevation of privilege" in this context means "unauthorized elevation of privilege". Technically, yes, Administrator is not as powerful as System (in that there are operations that Administrator will get Access Denied where System will succeed), and System is not as powerful as kernel-mode code (in that there are operations that fail for user-mode code running as System that succeed when called from kernel code). However, two of the things that Administrator is authorized to do include: 1) configuring arbitrary code to run as System, and running it; and 2) loading arbitrary code into the kernel, and running it. Hence, if code is running as admin, there is nothing it is not authorized to do.

(***) "Nitpicker's corner" might be a trademark of The Old New Thing.

Windows Vista Security Testing

windowsvistasecurity — Fri, 28 Jul 2006 23:16:00 GMT

Hi, I’m Austin Wilson , Director of Product Management for Windows Vista security. Our first focus for Windows Vista security is engineering the operating system for security. Windows Vista is the first Windows client release to be developed end to end...(read more)

Welcome to the Windows Vista Security Blog

windowsvistasecurity — Mon, 24 Jul 2006 20:33:00 GMT

Thousands of people from around the world have been hard at work to ensure that Windows Vista is the most secure versions of Windows ever released. From new engineering best practices as part of the Security Development Lifecycle (SDL) to new data protection features like BitLocker™ drive encryption, Windows Vista will help make large enterprises, small businesses, and home users more secure.

The purpose of this blog is to make you aware of what makes Windows Vista more secure, keep you updated on the latest developments, and give you a behind-the-scenes look at the development process from the people building the product.

We plan to update the blog at least several times a month so add it to your favorites and subscribe to the feeds. In the meantime, here are links to some of the key Windows Vista security resources we’ve published already:

· Widows Vista Security Home page on TechNet

· White Paper: Microsoft Windows Vista Security Advancements (.doc file, 222 kb)

· Video: Windows Vista Security Enhancements (.wmv file, 27 min. 58 sec.)

· Windows Vista Security Home Page on MSDN

· The other Product Team Blogs that are listed on the right of the page. Here are a few key postings that would have been on this blog if it had existed at the time:

o Address Space Layout Randomization in Windows Vista

o Windows Firewall: the best new security feature in Vista?

o [BitLocker] Back-door nonsense

o Reducing Elevation Prompts in User Account Control

Thank you for reading and we look forward to your comments—we will do our best to address them all.

Ben Fathi
Corporate Vice President
Security Technology Unit

(Comments have been turned off to deter spam.)