Vista

Microsoft Fix it Solution for Disappearing System Tray Icons on Windows Vista

Scott Dorman — Mon, 06 Apr 2009 15:07:34 GMT

About two years ago I talked about a very common problem in Windows Vista where the network, volume, and power icons in the system tray disappear. In that post, I provide a solution which involves editing the registry. Several people posted comments that provide slightly more automated ways to make the registry changes through a batch/command file and through a registry file.

Jump ahead to today and Microsoft has a Fix it solution for this problem.

Fix this problem

Technorati Tags: Fix it,Vista,System Tray icons

Windows Vista Service Pack 2

Scott Dorman — Fri, 05 Dec 2008 06:21:21 GMT

Windows Vista Service Pack 2 Beta is now available for public download on MSDN and TechNet. This is a combined update for Windows Server 2008 and Windows Vista Service Pack 1. This will be the first service pack for Windows Server 2008 since it shipped and includes a lot of performance improvements for WS08.

Did you notice that I specifically said Windows Vista Service Pack 1? That’s correct, if you want to install this service pack on Vista, you must first have SP1 installed.

That means that SP2 is an incremental service pack, which is a significant change from past service pack releases. According to Microsoft,

There were a number of reasons we did this, the primary one is that the size of the standalone package for SP1 was so large. There were a lot of customer concerns around the size of SP1. Adding the SP2 contents would have made it even larger (certainly it can't shrink if it's cumulative).

Another reason is that because now that Vista SP1 and Server 2008 are synced-up, having the entire contents of the SP1 client code in the first service pack for the Server would have meant carrying a lot of extra size for the Server deployments. Vista and Server 2008 are the same binaries for all common files, having two separate service packs would have doubled the testing and time until release. (John Gray, Live Chat on Vista SP2, November 19, 2008)

After installing the service pack, you won’t immediately notice any differences. Most of the differences are more fundamental such as:

Support for Bluetooth 2.1
Ability to record data on Blu-Ray media
Windows Connect Now (WCN) Wi-Fi Configuration
Windows Search 4
Hyper-V (WS08 only)

There are some other significant changes as well, such as an easier upgrade and migration experience to Windows 7.

The upgrade process using Windows Update was relatively painless and so far, everything is working exactly as it should.

Technorati Tags: Vista, SP2

Windows Vista UX Guidelines and Visual Studio

Scott Dorman — Fri, 25 Jul 2008 14:50:23 GMT

Whether you like Vista or not, the user interface aspects of the operating system are here to stay. Overall, I think Microsoft did a good job with the core interface guidelines, as presented in the Windows Vista User Experience Guidelines.

From the guidelines,

The goals for these official Windows Vista® User Experience Guidelines (or "UX Guide" for short) are to:

Establish a high quality and consistency baseline for all Windows Vista-based applications.

Answer your specific user experience questions.

Make your job easier!

The UX Guide is one of the most comprehensive UI guidelines I’ve seen published from Microsoft since the Windows 3.1 UI Guidelines book.

The problem is that the Visual Studio Windows Forms designer doesn’t follow all of the guidelines, specifically the layout guidelines. There is a bug entered at Microsoft Connect about this issue, but after 4 days Microsoft closed the issue saying it won’t be fixed because it’s too big of a change to the .NET Framework.

The problem with that is that this issue has absolutely nothing to do with the .NET Framework. It is purely an issue that exists within the Visual Studio Windows Forms designer. By not fixing this issue, Microsoft is making it virtually impossible for developers to create applications that run on Vista which also follow the Vista UX Guidelines...at least using Visual Studio.

As I have mentioned previously, there was a time when Microsoft was primarily concerned with creating solid developer tools and ensuring that developers were able to create applications that followed all of their UX guidelines for the current operating system. By not continuing this trend, Microsoft is sending mixed signals to the developer community…you should follow the Vista UX Guidelines but you can’t use Visual Studio to do it.

Discussing this in the forums isn't really going to be of much help as there really is no workaround to resolve this issue and there really isn't much to discuss about it anyway...the Windows Forms designer simply doesn't follow the new UX Guidelines.

Be sure to vote on this issue so Microsoft continues to be aware of the problem and how the developer community see it.

Code Signing

Scott Dorman — Sat, 01 Mar 2008 03:59:10 GMT

Ever since the .NET Framework was first release, Microsoft has always recommended that your code be signed. Windows Vista drives this point home even more with UAC and the Windows Error Reporting (WER) features, not to mention the fact that it's a requirement for Vista logo certification. John Robbins from Wintellect provides an excellent explanation of how to sign your code. As it turns out, it's a lot easier than many of you may have thought.

Windows Vista User Experience (UX) Guidelines

Scott Dorman — Fri, 26 Oct 2007 00:27:31 GMT

The Windows Vista UX Guide is probably the most comprehensive UX guide that Microsoft has published. The big drawback has been that it was only available online through MSDN. Fortunately, as of today, the UX Guide is now available as a PDF document so you can read all 627 pages of it offline.

Windows Vista Application Compatability Labs

Scott Dorman — Thu, 24 May 2007 17:01:25 GMT

I won't be able to attend these labs as I have other schedule conflicts, but the Windows Vista team is providing two training labs at Tech·Ed 2007. Both labs are free for Tech·Ed attendees, but you must register to reserve your spot.

The first lab is an Instructor led Lab in Room S331-C and is broken up into two 90 minute parts. Part 1 takes an in-depth look at the most common application compatability issues and the ramifications of the new security enhancements in Windows Vista. This covers topics such as User Account Control (UAC), running as Standard User, accessing Administrative Rights, and Administrators running as Standard User. Part 2 is a walk-through of the tools commonly used to diagnose, analyze, and mitigate application compatability issues and covers Application Compatability Toolkit (ACT) 5.0, Standard User Analyzer (SUA), shim infrastructure, and Compatability Administrator.

The second lab is in Room S329, and is the Windows Application Compatability Lab - "Bring Your Own Apps". Microsoft held this lab at last year's Tech·Ed and was very popular. The lab is designed to help you test your application on Windows Vista with the hands-on help of Microsoft Consultants and Engineers. Bring your own applications that are blocked and get Microsoft's help to diagnose the issue, file bugs, and mitigate the blocking issues when possible. Space is very limited for this lab, so you will be served in the order you registered. You must bring your own application with you to test.

Vista Goes Gold!

Scott Dorman — Thu, 09 Nov 2006 00:08:00 GMT

Earlier today Microsoft announced that Vista is finally complete, after over 5 years of work. Expect to see it hit the consumer and small-business market by the end of January 2007. Large companies will have access to it by the end of the month.

For more details, read the full PC Magazine article.

PatchGuard, the eWEEK opinion

Scott Dorman — Thu, 02 Nov 2006 21:44:00 GMT

eWEEK Security Center Editor Larry Seltzer just published an article on eWEEK.com providing his opinion on the benefits, and limitations, of PatchGuard.

In the article, Larry reiterates some of the points I made in my post on PatchGuard a few days ago, namely:

Only 64-bit Windows versions are affected by PatchGuard.
64-bit Windows versions, especially desktop versions, have puny market share.
The problems are limited to what can generally be called HIPS (Host Intrusion Prevention Systems).
Conventional security protection is unaffected by PatchGuard.
There is no documented, supported way for vendors to implement key HIPS functions in the face of PatchGuard.

As Larry mentions, HIPS primarily focuses on behavior blocking. In order to do that, it needs the ability to monitor certain kernel information such as the creation and manipulation of processes, image loading, and the creation of movement of memory.

The important thing to realize here is that most of the current security products (with the exception of those that are only HIPS products or that include HIPS features, which won't work on 64-bit Windows) will work just fine as they shouldn't be using anything that triggers interference from PatchGuard.

Yes, the security vendors that rely on HIPS do run in to the proverbial "brick wall" with PatchGuard. However, by removing the restrictions put in place by PatchGuard we are creating an inherently less secure environment. As I mentioned in my earlier post, one of the primary goals of PatchGuard is to ensure the integrity and security of the kernel.

The reality of the story is that as Microsoft is working to make Windows more secure by restricting the amount of access to kernel, the security industry publicly says "great" but internally cringes as it directly impacts their business. The unfortunate truth of this is that while some vendors are working to create products that circumvent PatchGuard (essentially hacking their way in to the kernel) they are giving credibility to the hacker community and proving in no uncertain terms that PatchGuard is vulnerable.

The fact that PatchGuard is vulnerable should not come as a surprise. It is virtually impossible to write an operating system that is actually usable and not have some level of vulnerabilities. According to CERT, for this year alone (Q1-Q3) there have been 5,340 vulnerabilities reported. Compare this to 345 reported 10 years ago.

All this is telling us is that as the complexity in operating systems and applications increases, so does the number of vulnerabilities. As the malware vendors have almost limitless amounts of time and resources to create malware, this trend will only increase (at least for the foreseeable future).

The longer we draw out debates over issues like PatchGuard, the longer it will take to create a more secure operating system. As a whole, the security industry has played catch-up to the malware industry. Rather than about the fact that legitimate security vendors are being "locked out" of hacking the kernel, we need to realize that while the legitimate vendors are being locked out, so also are the malware vendors. Rather than finding ways to circumvent PatchGuard, the industry needs to be finding ways to strengthen it.

Kernel Patch Protection aka "PatchGuard"

Scott Dorman — Mon, 30 Oct 2006 22:06:00 GMT

If anyone has been following this technology closely, there have been a lot of complaints by some of the security vendors regarding PatchGuard. I first heard about this technology at TechEd 2006 in a lot of the Vista sessions.

The recent controversy caused me to do a little more research in to this technology and the issues surrounding it.

The official name for this technology is called Kernel Patch Protection (KPP) and it's purpose is to increase the security and stability of the Windows kernel. KPP was first supported in Windows Server 2003 SP1, Windows XP, and Windows XP Professional Edition. The important thing to understand about this support is that it is for x64 architectures only.

KPP is a direct outgrowth of both customer complaints regarding the security and stability of the Windows kernel and Microsoft's Trustworthy Computing initiative, announced in early 2002.

In order to understand the controversy surrounding KPP, it is important to understand what KPP actually is and what aspects of the Windows operating system it deals with.

What is the Kernel?

The kernel is the "heart" of the operating system and is one of the first pieces of code to load when the operating system starts. Everything in Windows (and almost any operating system, for that matter) runs on a layer that sits on top of the kernel. This makes the kernel the primary factor in the performance, reliability and security of the entire operating system.

Since all other programs and many portions of the operating system itself depend on the kernel, any problems in the kernel can make those programs crash or behave in unexpected ways. The "Blue Screen of Death" (BSoD) in Windows is the result of an error in the kernel or a kernel mode driver that is so severe that the system can't recover.

What is Kernel Patching?

According to Microsoft's KPP FAQ, kernel patching (also known as kernel "hooking") is

the practice of using internal system calls and other unsupported mechanisms to modify or replace code or critical structures in the kernel of the Microsoft Windows operating system with unknown code or data. "Unknown code or data" is any code or data that is not provided by Microsoft as part of the Windows kernel.

What exactly, does that mean? The most common scenario is for programs to patch the kernel by changing a function pointer in the system service table (SST). The SST is an array of function pointers to in-memory system services. For example, if the function pointer to the NtCreateProcess method is changed, anytime the service dispatch invokes NtCreateProcess, it is actually running the third-party code instead of the kernel code. While the third-party code might be attempting to provide a valid extension to the kernel functionality, it could also be malicious.

Even though almost all of the Windows kernels have allowed kernel patching, it has always been an officially unsupported activity.

Kernel patching breaks the integrity of the Windows kernel and can introduce problems in three critical areas:

Reliability
Since patching replaces kernel code with third-party code, this code can be untested. There is no way for the kernel to assess the quality of intent of this new code. Beyond that, kernel code is very complex, so bugs of any sort can have a significant impact on system stability.
Performance
The overall performance of the operating system is largely determined by the performance of the kernel. Poorly designed third-party code can cause significant performance issues and can make performance unpredictable.
Security
Since patching replaces known kernel code with potentially unknown third-party code, the intent of that third-party code is also unknown. This becomes a potential attack surface for malicious code.

Why Kernel Patch Protection?

As I mentioned earlier, the primary purpose of KPP is to protect the integrity of the kernel and improve the reliability, performance, and security of the Windows operating systems. This is becoming increasingly more important with the prevalence of malicious software that is implementing "root kits". A root kit is a specific type of malicious software (although it is usually included as a part of another, larger, piece of software) that uses a variety of techniques to gain access to a computer. Increasingly, root kits are becoming more sophisticated and are attacking the kernel itself. If the rootkit can gain access to the kernel, it can actually hide itself from the file system and even from any anti-malware tools. Root kits are typically used by malicious software, however, they have also been used by large legitimate businesses, including Sony.

While KPP is a good first step at preventing such attacks, it is not a "magic bullet". It does eliminate one way to attack the system...patching kernel images to manipulate kernel functionality. KPP takes the approach that there is no reliable way for the operating system to distinguish between "known good" and "known bad" components, so it prevents anything from patching the kernel. The only official way to disable KPP is by attaching a kernel debugger to the system.

KPP monitors certain key resources used by the kernel to determine if they have been modified. If the operating system detects that one of these resources has been modified it generates a "bug check", which is essentially a BSoD, and shuts down the system. Currently the following actions trigger this behavior:

Modifying system service tables.
Modifying the interpret descriptor table (IDT).
Modifying the global descriptor table (GDT).
Using kernel stacks that are not allocated by the kernel.
Patching any part of the kernel. This is currently detected only on AMD64-based systems.

Why x64?

At this point, you may begin to wonder why Microsoft chose to implement this on x64 based systems only. Microsoft is again responding to customer complaints in this decision. Implementing KPP will almost certainly impact comparability of many legitimate software, primarily security software such as anti-virus and anti-malware tools, which were built using unsupported kernel patching techniques. This would cause a huge impact on the consumer and also on Microsoft's partners. Since x64-based machines still make up the smaller install base (although they are gaining ground rapidly) and the majority of x64-based software has been rewritten to take advantage of the newer architecture, the impact is considered to be substantially smaller.

So...why the controversy?

Since KPP prevents an application or driver from modifying the kernel, it will, effectively, prevent that application or driver from running. KPP in Vista x64 requires any application drivers be digitally signed, although there are some non-intuitive ways to turn that off. (Turning off signed drivers does prevent certain other aspects of Windows from operating, such as being able to view DRM protected media.) However, all that really means is anyone with a legitimately created company and about $500 per year to spend can get the required digital signature from VeriSign. Unfortunately, even it is a reputable company, it still doesn't provide any guarantees as to the reliability, performance, and security of the kernel.

In order for software (or drivers) to work properly on an operating system that implements KPP, the software must use Microsoft-documented interfaces. If what you are trying to do doesn't have such an interface, then you cannot safely use that functionality. This is what has lead to the controversy. The security vendors are saying that the interfaces they require are not publicly documented by Microsoft (or not yet at any rate) but that Microsoft's own security offerings (Windows OneCare, Windows Defender, and Windows Firewall) are able to work properly and use undocumented interfaces. The security vendors want to "level the playing field".

There are many arguments on both sides of the issue, but it seems that many of them are not thought out completely. Symantec and McAfee have argued that the legitimate security vendors be granted exceptions to KPP using some sort of signing process. (See the TechWeb article.) However, this is fraught with potential problems. As I mentioned earlier, there is currently no reliable way to verify that code is actually from a "known good" source. The closest we can come to that is by digital signing, however, a piece of malicious code can simply include enough pieces from a legitimate "known good" source and hook into the exception.

So lets say, for arguments sake, that Microsoft does relent and is able to come up with some sort of exception mechanism that minimizes (or even removes) the chance of abuse. What happens next? Windows Vista, in particular, already includes an array of new features to provide security vendors ways to work within the KPP guidelines.

The Windows Filtering Platform (WFP) is one such example. WFP enables software to perform network related activities, such as packet inspection and other firewall type activities. In addition to WFP, Vista implements an entirely new TCP stack. This new stack has some fundamentally different behavior than the existing TCP stack on Windows. We also have network cards that implement hardware based stacks to perform what is called "chimney offload", which effectively bypasses large portions of the software based TCP stack. Hooking the network related kernel functions (as a lot of software based firewalls currently do), will miss all of the traffic on a chimney offload based network card. However, hooking in to WFP will catch that traffic.

Should Microsoft stop making technological innovations in the Windows kernel simply because there are a handful of partners and other ISVs that are complaining? The important thing to realize is that KPP is not new in Windows Vista. It has been around since Windows XP 64-bit edition was released. Why is it now that the security vendors are realizing that their products don't work properly on the x64-based operating systems? The main point Microsoft is trying to get across is that most of the functionality required doesn't have to be done in the kernel. Microsoft has been working for the last few years trying to assist their security partners in making their solutions compatible. If there is an interface that isn't documented, or functionality that a vendor believes can only be accomplished by patching the kernel, they can contact their Microsoft representative or email msra@microsoft.com for help finding a documented alternative. According to the KPP FAQ, "if no documented alternative exists...the functionality will not be supported on the relevant Windows operating system version(s) that include patch protection support."

I think the larger controversy is the fact that there are now documented ways to break KPP. This is where Microsoft and it's security partners and other security ISVs should be spending their time and energy. If we are going to have a reliable and secure kernel, we need to focus on locking down the kernel so that no one is able to breach it, including the hackers. This is an almost endless process, as the attackers generally have almost infinite amounts of time to bring their "products" to market and don't really have an quality issues to worry about. Even with the recent introduction by Intel and AMD of hardware based virtualation technology (which essentially creates a virtual mini-core processor that can run a specially created operating system), there is still a long way to go.

What's next?

While it is important to understand the goals of KPP and the potential avenues of attack against it, the most important thing for the security community to focus on is in making sure that the Windows kernel stays safe. The best way to do this is to keep shrinking the attack surface until it is almost non-existent. There will always be an attack surface, however, the smaller that surface becomes the easier it is to protect. Imagine guarding a vault. If there is only one way in and out, and that entrance is only 2-feet wide it is much more easily guarded than a vault that has 2 entrances, each of which are 30-feet wide.

However, as malware technology advances it is important for the security technology that tries to protect against it to advance as well. In fact, the security technology really needs to be ahead of the malware if it is to be successful. PatchGuard has already been hacked, some of the proposed Microsoft APIs for KPP won't be available until sometime in 2008, and the security vendors do have legitimate reasons for needing to access certain portions of the kernel.

Host Intrusion Prevention Systems (HIPS), for instance, uses kernel access to prevent certain types of attacks, such has buffer overflow attacks or process injection attacks, by watching for system functions being called from memory locations where they shouldn't be called. The Code Red Worm would not have been detected if only file-based protection systems were in use.

The bottom line is that the malware vendors are unpredictable and not bound by any legal, moral, or ethical constraints. They are also not bound by customer reviews, deadlines, and code quality. The security vendors and Microsoft need to work together to ensure that the attack surface for the kernel and Windows itself is small and stays small. They can do this by:

Establishing a more reliable way to authenticate security vendors and their products that will prevent "spoofing" by the malware vendors.
Minimizing the attack surface of the Windows Kernel.
Establishing documented APIs to interact with the kernel to perform security related functions, such as firewall activities.
Enforcing driver signatures...in other words, don't allow this mechanism to be turned off. At least don't allow it to be turned off for certain security critical drivers.
Enforcing security software digital signatures. If you want your security tool to run, it must be signed. Again, don't allow this mechanism to be turned off.
Establishing a more secure way for the security products to hook in to the kernel.
Restricting products to patching only specific areas of the kernel. Currently, it is possible to patch almost any portion of the kernel.
Enforcing Windows certification testing for any security products.

BitLocker™ - The dirty details

Scott Dorman — Tue, 04 Jul 2006 14:21:00 GMT

One of the new security features coming in Windows Vista and Longhorn is the new BitLocker™ Drive Encryption technology. BitLocker™ is designed to help prevent information loss, whether it is by theft or accidental. Information loss is costly to business on several levels, and the U.S. Department of Justice estimates that intellectual property theft cost enterprises $250 billion in 2004.

BitLocker™ Drive Encryption gives you improved data protection on your notebooks, desktops, and servers by providing a transparent user experience that requires little to no interaction on a protected system. BitLocker also prevents the use of another operating system or hacking tool to break file and system protections by preventing the offline viewing of user data and OS files through enhanced data protection and boot validation using TPM v1.2.

For those of you who may not know, TPM stands for Trusted Platform Module. So what's that? TPM is a piece of hardware that is part of the motherboard that:

Performs cryptographic functions
- RSA, SHA-1, RNG
- Meets encryption export requirements
Can create, store, and manage keys
- Provides a unique Endorsement Key (EK)
- Provides a unique Storage Root Key (SRK)
Performs digital signature operations
Holds platform measurements (hashes)
Anchors a chain of trust for keys and credentials
Protects itself against attacks

So now that you know what a TPM is, why should you use one? A TPM is a hardware implementation of a Root-of-Trust, which can be certified to be tamper resistant. When combined with software, it can protect root secrets better than software alone. A TPM can ensure that keys and secrets are only available for use when the environment is appropriate.

The important thing to know about BitLocker is that it will only encrypt the Windows partition. You also won't be able to dual-boot another operating system on the same partition, different partitions are fine. Any attempts to modify the protected Windows partition will render it unbootable.

To completely protect all of the data on the computer, you will need to use a combination of BitLocker on the Windows partition and Encrypted File System (EFS) on the other partitions. When properly configured, EFS is computationally infeasible to crack.

Even with all of the new security that is provided by BitLocker, it can't stop everything. Some of the areas that BitLocker is helpless to defend against are:

Hardware debuggers
Online attacks—BitLocker is concerned only with the system’s startup process
Post logon attacks
Sabotage by administrators
Poor security maintenance
BIOS reflashing
- Protection against this can be enabled if you wish

Additional Resources