Windows Vista Security

Good day, Paul Cooke here.

The Windows Vista Security blog has been a great avenue for us to talk with you about what has made Windows Vista the most secure client operating system Microsoft has ever delivered. However, hindsight is always 20/20 and it is clear that while we started with a good cadence of posts, our volume and insights definitely fell off over time. This is unfortunate, for there are a lot of things to talk about when it comes to the security of Windows. Now, as we start talking about Windows 7, and look for opportunities to discuss relevant security topics in a broader sense, we felt it was a good time to revamp the blog.

As a result, we are re-launching and moving this blog as simply the Windows Security Blog. The renewed purpose of this blog is to make you aware of all the things that go into having a secure Windows environment. This will cover the gamut from Windows XP all the way through the upcoming Windows 7. I plan to post updates regularly and add some variety with guest posters throughout the security space here at Microsoft.

Thanks for all of you that have followed this blog for the last few years and I hope you follow us to our new location!

Windows Security Blog | RSS Feed

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.

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:

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!

 - Austin

Hi: Russ Humphries here.  There’s been a lot of attention this week paid to memory attacks against disk encryption technologies and I wanted to provide some commentary and thoughts. The focus of these conversations is centering on investigating the contents of a computer’s memory – if it’s running or shortly after it has been recently powered down; where ‘recently’ could be seconds to perhaps minutes. The concept that memory retains a ‘ghost image’ of what was last stored on it has been well documented and is an industry-wide issue.

However, the current debate has an interesting angle to it - specifically a method has been detailed in which an application might be able to reconstruct an encryption key, which might have been used for almost any security purpose, from these ghost images.

Since disk encryption is a topic that gains headlines perhaps it was inevitable that the practical demonstration of this key-reconstruction would be to investigate a computer’s memory to ‘break disk encryption products’ and potentially access data stored on the hard drive.

The thing to keep in mind here is the old adage of balancing security, usability and risk.  For example BitLocker provides several options that allow for a user (or more likely Administrator) to increase their security protections but at the cost of somewhat lowering ease-of-use.  BitLocker supports options that will not allow a machine to boot – or resume from hibernate – until the user can:

·         Enter a PIN

·         Insert a USB stick that contains a secret Key

·         … and as of Windows Vista SP1 both enter a PIN and insert the USB stick!

We provide best practice guidance in the Data Encryption Toolkit (http://www.microsoft.com/technet/security/guidance/clientsecurity/dataencryption/analysis/4e6ce820-fcac-495a-9f23-73d65d846638.mspx ) that describes the various manners in which the above choices can be made and also provides advice to help improve security, such as disabling ‘sleep mode’ – forcing a user to hibernate and thus allowing memory to lose the ghost images discussed. These power management settings can all be configured centrally using Group Policy Objects.

Now with the above context in mind, I’d like to take a step back and, from a BitLocker perspective, detail some of the assumptions that have to be made for this attack to be successful:

·         Physical access to the machine

·         The user’s laptop would likely have to be in sleep mode, rather than hibernate mode or powered off

·         The user would have chosen not to implement multi-factor pre-boot authentication

·         The person who finds/steals the laptop must be knowledgeable and interested enough to execute this attack on the laptop they just stole

I would posit that the opportunistic laptop thief is somewhat unlikely to carry a separate laptop on which they will have installed tools that allow them to reconstruct cryptographic keys – or for that matter have a can of compressed air handy. 

Targeted theft is, of course, an entirely different threat model!

Let me also point out that BitLocker allows an administrator to, quite easily, change the protection method for a laptop, even remotely [but assuming some form of connectivity], by having a script execute.  Thanks to BitLocker’s design, which implements key abstraction, a script can be executed that adds pre-boot protection mechanisms without requiring the re-encryption of the hard disk. This script can therefore execute very quickly.

Let me close by clearly stating that quality security research helps our customers and the industry in general raise the security bar, and I applaud it; but let’s also keep in mind that technologies like BitLocker provide a very valuable service to users and helps them protect data on their PCs. BitLocker’s range of deployment options, ranging from single-factor authentication with sleep mode to TPM+PIN+USB with hibernation only, allow customers to find the right balance of security and convenience for their data; the documentation of one attack method, that can be mitigated through these policy choices, does not equate to a class of data protection products being rendered ‘useless’ as has been reported in some circles.

-Russ

Hi, Austin Wilson here.  Now that Windows Vista has been available to business customers for more than a year, it’s a good time to go back and look at how it’s holding up from a security perspective.  I think that it’s fair to say that Windows Vista is proving to be the most secure version of the Windows to date. Our investments in the SDL and our defense in depth approach to building Windows Vista seem to be paying off.  Let’s take a look at some areas that we’ve made progress in: the impact of defense-in-depth; Internet Explorer 7’s protection of personal information; vulnerabilities and infections; and cost savings.

First, let’s look at the impact of defense-in-depth features like User Account Control and Internet Explorer Protected Mode.  These features have helped reduce both the risk and severity of security bulletins, giving enterprises more time to deploy patches:

•       Running as standard user, which is the recommended configuration and made easier in Windows Vista thanks to User Account Control, helps reduce the impact of any particular vulnerability.  Of the 23 security bulletins that have been released for Windows Vista through January 2008, 12 specifically call out a lower impact for those running without administrative privileges:  MS07-033, 034, 040, 042, 045, 047, 048, 050, 057, 064, 068, and 069.  This is a great illustration of the importance of User Account Control and why we included it in the product.  It’s also the reason I personally run as a standard user on every machine I use.

•       Because of IE Protected Mode, the MS07-056 bulletin from October ’07 was rated important on Windows Vista and critical on Windows XP.  The bulletin rating helps organizations determine the urgency with which they need to deploy the update.  Fewer critical updates help organizations maintain regular processes around patch management.

Internet Explorer 7, which is the default browser in Windows Vista, also helps protect the personal information of end users.  We’re seeing almost 1 million phishing attempts blocked per week, representing a large number of potential cases of identity theft or credit card fraud that were stopped.  In addition, there are over 3500 sites with Extended Validation SSL Certificates (EV SSL) representing an improved level of authentication for securing transactions on these sites.   Internet Explorer 7 is the first browser to fully support EV SSL.  It turns the address bar green for EV SSL sites and notifies users about the available identity information so they can make better trust decisions when entering sensitive personal information while online. 

Next, let’s look at patch events, vulnerabilities and infections.  We’re showing steady positive progress in this area.   When looking at Windows Vista compared to Windows XP, we’ve seen:

•       An important metric for IT professionals is the concept of patch events, which is discussed in the One Year Vulnerability Report released today by Microsoft’s Jeff Jones. During Windows XP’s first year, updates were released on 26 separate days.  Through a combination of the move to a predictable monthly release schedule, and decreased vulnerabilities, Windows Vista had updates released on just nine days in its first year.  To the average security professional, this is one of the most relevant metrics:  how many times did I have to activate my internal patch management process due to vendor update releases over the course of a year?  Nine times is much more attractive, and cost effective, than 26 times.  Jeff Jones’ one year report goes into this in area in more detail, and the graph below from his report shows the patch events during the first year of Windows Vista and Windows XP:

•       Fewer vulnerabilities:   Also from the  One Year Vulnerability Report, we see that Windows Vista in its first year had significantly fewer fixed and unfixed vulnerabilities than Windows XP in its first year: 36 fixed/30 unfixed for Windows Vista vs. 68 fixed/54 unfixed for Windows XP.   The chart below gives you an idea of the progress we’ve made:

•       Fewer months with updates:  Building on the concept of patch events, since Windows Vista was released, there were three months in which Windows XP had updates and Windows Vista did not  (December ’06, January ’07, and November ’07).  This means that an organization running all Windows Vista clients would have had three months in which they wouldn’t have had to deploy an OS update to their clients at all.

Fewer infections:  From January – June 2007, there were 60% fewer malware infections and 2.8 times less potentially unwanted software on Windows Vista than on Windows XP SP2, according to the Microsoft Security Intelligence Report from 10/07. This illustrates how the defense in depth features built in to Windows Vista help prevent machines from getting infected by malicious and potentially unwanted software.

Finally, what does Windows Vista do to help organizations reduce costs?  A recent Microsoft commissioned report from GCR on cost savings for mobile PCs shows $251/machine per year in cost savings for Windows Vista, of which $55/machine per year was attributed to security and data protection features such as User Account Control and BitLocker Drive Encryption.

We’ve said it before, but it bears repeating: our job with security is never finished.  But, the focus we put on engineering for security, the backing of the world-class security response process delivered by the Microsoft Security Response Center, and the defense in depth approach of Windows Vista are showing  real-world benefits for customers and that’ something I take pride in. 

-          Austin

I am Craig Spiezle, Director of Online Security and Safety for Microsoft Internet Explorer.  While I am new to this role, I’ve been at Microsoft for over 10 years, and very involved on usability and online safety, helping users realize their potential, while being confident that their data and privacy are maintained.   In response to mounting online threats, Microsoft recently launched a $250,000 Sweepstakes communication to show users how Internet Explorer and innovative technologies can enhance online trust and confidence.  Leveraging the stop light metaphor of red for stop and green for go, the interactive site demonstrates this to users, while providing them chances to win one of 25, $10,000 shopping sprees with PayPal.  Visit the site today, download Internet Explorer 7 and enter to win.  www.microsoft.com/ie/confidence  Hurry entries must be received by January 31, 2008.

Internet Explorer integrates dynamic Phishing protection and support of the emerging Extended Validation SSL Certificate program, as just two of several investments to help of protect users, their data, their PC and their privacy.

The Microsoft Phishing Filter provides dynamic protection from known phishing sites and blocking nearly 1 million exploits each and every week.  This is an opt-in service that operates in the background and provides an early warning system to notify users of both suspicious websites that could be engaging in identity and data theft, as well as those confirmed to be phishing sites.  By design, user privacy has been at the forefront of this service and verified by third party audits that no personal information is collected by Microsoft or any third party.[1]  http://www.jeffersonwells.com/client_audit_reports/Microsoft_PF_IE7_IEToolbarFeature_Privacy_Audit_20060728.pdf  It relies on browser-based heuristics to analyze Web pages in real time and warn users about suspicious characteristics as they browse. This client-side technology is combined with dynamically updated information that helps prevent users from interacting with confirmed phishing sites reported to Microsoft by a network of third-party data-provider partners and a community of users who help provide information on potential and confirmed phishing sites.

However, phishers have also been able to obtain ‘valid’ SSL certificates for their spoofed sites.  Looking for that gold padlock icon is important, but without the identity information users can end up sending their personal information to the wrong website.  Historically one way users used to help answer that question was the SSL padlock (the gold lock), which was the only indication of any security whatsoever. While helpful, SSL only means that I have an encrypted connection to someone.  So someone with malicious intent could set up a site that closely copied the look and URL of a legitimate business, get a SSL cert, and try to fool users into giving them sensitive personal information via a phishing or social engineering attack. 

Responding to these threats, the CA/ Browser Forum has developed the new Extended Validation SSL Certificates or EV SSL.  EV SSL leverages proven SSL technology, and adds a new process for vetting the identity of the business that is requesting the certificate, offering an improved level of authentication for securing transactions on their Web sites. Given the standardization and rigorousness of the process used, users can realize a higher level of online trust and confidence.

Internet Explorer 7 is the first browser to fully support EV SSL, and here’s what that looks like (in this instance when visiting http://login.live.com). You will notice that the address bar turns green, to notify users about the available identity information, and the name and country of the business are shown right there on the address bar (here “Microsoft Corporation [US]”). If a user wants to see more information about the company behind a website, he can simply click on the name of the company – the identification popup immediately shows the name and address of said company.

This is great news for Internet users: they now have an easy and reliable way to verify that they are on the correct site, and they don’t have to worry as much about phishing attacks or deceptive website, as long as EV SSL is used. Furthermore, when they are transacting with a new website that uses EV SSL  (say one they found through shopping.msn.com), they can easily identify the company behind the website, which helps them legally pursue their claim if the site doesn’t deliver as promised, helping add an element of accountability to the web. Remember that most sites will use a secure connection (https://, that will show you the green bar if they are using EV SSL), only when you are about to exchange with the sensitive information, such as when you login, or are about to check out your cart. If you wonder about the different colors of the address bar and how to use them in making trust decision, you will find this description of the Internet Explorer 7 Security Status Bar helpful.

Today there are nearly 3,500 sites are now protecting their customers with EV SSLs, including Alaska Airlines, AutoZone, British Airways, eBay, FedEx, PayPal, Microsoft, Royal Doulton, The Body Shop UK, and Travelocity. In addition leading financial services have been quickly adopting worldwide including the Banque National du Canada, Charles Schwab, Deutsche Bank, SunLife, Sovereign Bank, UBS, and Vanguard.   While the Microsoft Phishing Filter and EV SSLs alone will not solve all of the internet’s ills, combined they are important step to protect brands and consumers alike. 

Craig Spiezle

Director Safety & Security

Windows Internet Explorer Product Management

So I am reading a lot of stories that seem to have confused, or incorrectly aligned, Windows Vista driver signing and Kernel Patch Protection technologies. Whilst driver signing and KPP are complimentary, they are not conjoined.

Driver signing provides a method to better identify the author/creator of a piece of software or code so that the author/creator can be approached in the event a reliability issue, vulnerability, or malware is discovered. Signing is not designed to confirm the “intent” of signed code (i.e. good or bad), or whether exploitable bugs or malicious code is present.   Malicious or exploitable kernel drivers can lead to system compromise beyond disabling of code signing controls, since kernel driver code has access to hardware as well as all programs running as the user. 

Kernel Patch Protection (KPP) helps protect code and critical structures in the Windows kernel from modification.  Microsoft updates KPP periodically, based on internal and external research.  You can read more about KPP here:

http://blogs.msdn.com/windowsvistasecurity/archive/2006/08/11/695993.aspx

http://www.microsoft.com/whdc/driver/kernel/64bitpatching.mspx

Perhaps the mix up is due to a confluence of events, or – put another way – the fact that we released an update to KPP at the same time that news about an ATI Driver issue appeared.  The update to KPP has no relationship to the ATI driver issue or recent topics related to code signing.

These are unrelated events!

1: Microsoft issued a non-security update for Kernel Patch Protection (KPP), and an accompanying security advisory: Microsoft Security Advisory (932596)

2: Microsoft was made aware of an issue reported in an ATI driver that is potentially vulnerable. Microsoft was in contact with ATI to help address this issue and ATI have posted a fix in the v7.8 Catalyst Package that can be found here:  

http://ati.amd.com/support/drivers/vista64/common-vista64.html,

http://ati.amd.com/support/drivers/vista32/common-vista32.html

I would like to highlight that the driver in question was not shipped ‘in-box’.

              Russ Humphries

[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: (*)

• Secunia items re SETUID and local privilege escalation
• Secunia items re SUID and local privilege escalation
• MOAB posts involving privilege escalation
• Symantec write-up on how easy it is to subvert sudo
• Ease of exploiting a sudo authn "grace period"

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.

Hi,  it’s Scott Field, Windows Security Architect, again.  Microsoft recently became aware of a third party kernel mode driver named “Atsiv” which provides a deliberate means of loading code that conflicts with the Kernel Mode Code Signing (KMCS) policy included in Windows Vista x64 editions.   In Windows Vista x64 editions, the default KMCS policy is to only allow code to load into the kernel if it has been digitally signed with a valid code signing certificate.

The Atsiv driver also provides a means to load unsigned kernel mode code in a manner that is not visible through operating system provided API interfaces (such as the EnumDeviceDrivers() API), and this may allow the code to hide from view of commonly deployed tools.   Installing the Atsiv driver requires administrative privileges, so there is no security vulnerability related to the default case in Windows Vista where users run with limited permissions through the User Account Control feature.

KMCS is a not a security boundary, rather, it is only one aspect of a defense–in-depth approach to security.  KMCS does not provide a means to determine the “intent” of the signed code (i.e., good or bad); indeed, signed code may contain bugs, be of poor quality, or may be malicious in nature.

A primary benefit of KMCS is that it provides a means to identify the author of a piece of code, which helps enable follow-up with the author to address crashes that are observed through mechanisms such as Microsoft Online Crash Analysis.  Identifying the source and ownership of code that is loaded by the kernel is a fundamental component of the operating system and overall ecosystem trust model.    Furthermore, this also provides better transparency to the end user in terms of origin of code that is installed and running on a system.

In the case of the Atsiv kernel driver, the defense-in-depth measures provided by KMCS worked as expected:

1.       Complete anonymity was prevented.   The author of the driver is identified through the code signing certificate, and action has been taken, which is discussed below.

2.       Integrity checking of the Atsiv kernel mode code was provided.  The AtSiv driver is integrity checked by the operating system prior to it loading and executing.

Microsoft is committed to protecting its customers from potential as well as actual security threads; accordingly, we are responding to this issue as follows:

1.       Windows Defender released a signature update on August 2, 2007 that allows detection, blocking, and removal of the current Atsiv driver.   Classification of the Atsiv software was done in accordance with the objective criteria used by the Windows Defender team to assess the characteristics of potentially unwanted software.

2.       Certificate revocation has occurred as of August 2, 2007.  Microsoft has worked with partners in the code signing certification authority ecosystem to assess the Atsiv issue.  VeriSign has revoked the code signing key used to sign the Atsiv kernel driver, which means the code signing key will no longer be considered valid. 

3.       The security team at Microsoft is investigating adding the revoked key to the kernel mode code signing revocation list, as an additional defense in depth measure.   The kernel mode revocation mechanism requires a system reboot in order for the new revocation list to take effect, which is consistent with other Microsoft updates which require and subsequently trigger a reboot.

In short, we were able to identify this issue and respond on multiple fronts, both with help from our partner VeriSign and with new signatures for Windows Defender.

Scott Field

Most anyone who has been in the security industry for a while is familiar with the term ‘security theater’. It’s a term used for security that is about show, rather than substance.

Since I became the Product Manager for Windows Vista security I have noted that the same concept seems to increasingly apply to the  world of vulnerability disclosure – let’s call this  ‘vulnerability theater’.

Vulnerability theater is where an individual, or group, will report a vulnerability that is – and let’s be polite –  over-blown. OK, so maybe it’s not a brand new phenomenom but it certainly seems more common since  the release of Windows Vista!  Perhaps it’s a desire on the behalf of the person making the disclosure to be one of the first to find or report a flaw in a new OS, but in some instances the lengths and steps an individual will go through to claim a vulnerability strain believability.

Hypothetical  example: Someone might report a ‘stunning, world shattering’ Windows Vista vulnerability that allows an application to ‘steal all the users data’.  However when we dig past the shock and horror and into the actual facts behind the vulnerability we discover that this earth shattering attack requires that the attacker has both physical access to the PC as well as administrator rights to the PC. Well hang on a second…if you have physical access and admin rights to the PC you effectively have rights to the box. It’s 0wned!

That’s not a vulnerability – that’s ‘vulnerability theatre’.

So – how do we differentiate between the real and the less substantial?

Here’s a checklist of questions/observations one should consider:

1)      If the vulnerability requires Administrator credentials to execute then carefuly consider if it’s really a vulnerability. Admin’s 0wn the box. That’s the nature of the Admin account. User Account Control in Windows Vista means that far fewer people should have to run as Administrator or indeed have Admin creds at all.  You should ask yourself how the supposed vulnerabilty got admin rights.  If the assumption is the user already has them and then inapparopriately enters them, then it’s most likely not a vulnerabiity…. It’s a user completing or executing an action.

2)      If you provide Admin credentials to an application understand that it 0wns the box! That means it can download and install other stuff, disable stuff, export stuff and in fact generaly mess with stuff including a Standard Users environment. If the attack is a multi-stage attack that requires, at some point in time, Admin credentials then see point 1 above!  Many examples of supposed vulnerabilties we see are a varient of this point, which is really a from of social engineering (tricking the user into completing an action), as opposed to an operating system level vulnerability.

3)      If the vulnerability requires that a user ignore numerous warnings and carries on regardless then the O/S is doing what it’s told to do!  Let’s be reasonable: If a user is warned by Outlook that the email looks like spam but clicks on the link anyway, then is warned by IE that the website looks suspicious but continues to navigate to it anyway, if they then ignore the Defender warning that the mortgage calculator they just downloaded is spyware, then, frankly, the O/S is doing what the user intends that it do!

4)      Is the vulnerability addressed by an existing application setting or security policy? This is an important question to ask oneself.  Security is about making choices.  Make default policy too restrictive and users will have to interact with the software more to do what they want.  Conversely, focus on ease of use by making the default settings less stringent and you increase the chance that a system can be attacked.  I truly think that Microsoft has developed the right balance and made the right decisions when evaluating the tradeoffs between usability and security for the default Windows Vista experience; but what is typically overlooked is the fact that many of the security technologies have numerous options that allow for a user (or Administrator!) to make their own judgments as to their need for security balanced against usability. For examples go take a look at the Windows Vista Security Guide at http://www.microsoft.com/downloads/details.aspx?FamilyId=A3D1BBED-7F35-4E72-BFB5-B84A526C1565&displaylang=en .

5)      Theory and Practice! Another important point to consider is the real world applicability of a vulnerability. Hypothetical observation: Is a key-storage mechanism that takes 1,000 Billion years to theoretically crack more ‘vulnerable’ than one that takes  10,000 Billion years to theoretically crack. Yes it is, but would most companies or individuals really care?

Security is vitally important and I can assure you that everyone at Microsoft takes it very seriously.  This post isn’t meant to make light of how we react to and address potential security vulnerabilities in any Microsoft product – we take every potential threat very seriously and treat each report the same in terms of investigation. Rather, what I really wanted to highlight is that not all reported vulnerabilities are equal and that we should look a bit closer than the headlines and into the detail, and that sometimes, to borrow a common saying, the bark is worse than the bite.

Of course vulnerabilities do exist; none of the security features in Windows Vista, either individually or collectively, are intended as a “Silver Bullet” solution to the problem of computer security.  Instead, a defense in depth approach makes Windows Vista far more difficult to attack than any previous version of Windows, thus making it more secure.

It’s also important to remember that Microsoft has an unparalleled worldwide security response process operated through the Microsoft Security Response Center (MSRC) that responds quickly to security threats and to provide customers with the information, guidance, and mitigation tools and measures they need.

So, yes - whilst there are real threats to computer security I hope I have shown that there are also threats that get a tad over-blown. Please consider the five points above the next time you see a ‘shock-horror’ headline J

Russ Humphries

Just as he did at the 90-day mark, Jeff Jones, a Microsoft Director from the Trustworthy Computing group and frequent blogger on security topics, has done a comparison of vulnerabilities discovered in Windows Vista versus other operating systems in their first 6 months of availability.   Windows Vista holds up well in this comparison, showing a significantly improved vulnerability profile over its first 180 days of availability compared to Windows XP and the other operating systems that were examined.   The report is available here.

-          Austin

 I’m Avi Ben-Menahem, the lead program manager for the PKI and smart card technologies in Windows Security.   The PKI (Public Key Infrastructure) team in Microsoft is responsible for the different technologies related to digital certificates, these technologies and products include the CA (Certificate Authority), the client enrollment API and UI, OCSP (Online Certificate Status Protocol) Responder, SCEP (Simple Certificate Enrollment Protocol) and the smart card subsystem in Windows.

 In Windows Vista and Windows Server 2008 the PKI team focused on 4 main investments pillars:

1.  Crypto enhancements - it was not an easy task, but I'm proud to say that the Microsoft crypto and PKI platform now supports the most advanced crypto algorithms such as ECC and the SHA-2 hashing alg family out of the box. The Microsoft CA can now issue ECC certificates and the Microsoft client can enroll and validate ECC and SHA-2 based certificates. Moreover, the platform is now dynamic enough to allow plugability of new algorithms much easily than before. The use of the new crypto and hash algorithms will be mandated by the US government as well as some of the European governments in the next few years making the OS support key for Microsoft PKI success in those market segments.

2.  Revocation enhancements - In the revocation space we've made significant improvements. OCSP (Online Certificate Status Protocol) is now supported natively in the Windows platform. The OCSP client is included as part of Windows Vista and Windows Server 2008 and a new OCSP Responder is available as part of the Certificate Server role. Additional revocation checking enhancements such as CRL pre-fetching, OCSP response stapling and CAPI diagnostics are also introduced to improve our PKI revocation story as well as to improve the user experience when using PKI-aware applications. Revocation was always one of the biggest problems in PKI, especially in the internet age. Introducing OCSP and enhancing the revocation platform will significantly assist deploying PKI for such large scale scenarios.

3.  Management and monitoring - this topic has been a major pain point in the past and we invested significant efforts on the server side to improve that experience. We made it real easy for administrators to deploy PKI and to manage their PKI from a single console.  A new CA MOM Pack was created, the CA was armed with a bunch of new performance counters, and the PKI View monitoring console was added to the server default setup. Most important, the CA setup was written from scratch to allow simple and easy deployment of the CA and now provides "one click setup" for deploying the CA.

4.  Certificate Services Client - on the client side of the Microsoft PKI we focused on both the UX (User experience) and on the developer experience. A completely new set of developer enrollment API is introduced (CertEnroll). This new COM based library replaces the legacy XEnroll library which been around for a long time and provides an OO developer experience and the ability to practically modify any request extension or attribute. Pretty powerful stuff. By doing that we ensure we give the proper developer support to enable PKI-Aware applications development.

 Again, this is just a high level overview of the work we've done. Want to read more? See http://www.microsoft.com/downloads/details.aspx?FamilyID=9bf17231-d832-4ff9-8fb8-0539ba21ab95&displaylang=en .

- Avi Ben-Menahem