Beginning in early 2002 with Microsoft's announcement of its Trustworthy Computing initiative, a great deal of work has gone into making Windows Vista a more secure operating system than its predecessors. Internally, Microsoft adopted a "Security Development Lifecycle" with the underlying ethos of "Secure by design, secure by default, secure in deployment". New code for Windows Vista was developed with the SDL methodology, and all existing code was reviewed and refactored to improve security.
Some specific areas where Windows Vista introduces new security and safety mechanisms include User Account Control, parental controls, Network Access Protection, a built-in anti-malware tool, and new digital content protection mechanisms.
User Account Control is a new infrastructure that requires user consent before allowing any action that requires administrative privileges. With this feature, all users, including users with administrative privileges, run in a standard user mode by default, since most applications do not require higher privileges. When some action is attempted that needs administrative privileges, such as installing new software or changing system settings, Windows will prompt the user whether to allow the action or not. If the user chooses to allow, the process initiating the action is elevated to a higher privilege context to continue. While standard users need to enter a username and password of an administrative account to get a process elevated (Over-the-shoulder Credentials), an administrator can choose to be prompted just for consent or ask for credentials.
UAC asks for credentials in a Secure Desktop mode, where the entire screen is faded out and temporarily disabled, to present only the elevation UI. This is to prevent spoofing of the UI or the mouse by the application requesting elevation. If the application requesting elevation does not have focus before the switch to Secure Desktop occurs, then its taskbar icon blinks, and when focussed, the elevation UI is presented (however, it is not possible to prevent a malicious application from silently obtaining the focus).
Since the Secure Desktop allows only highest privilege System applications to run, no user mode application can present its dialog boxes on that desktop, so any prompt for elevation consent can be safely assumed to be genuine. Additionally, this can also help protect against shatter attacks, which intercept Windows inter-process messages to run malicious code or spoof the user interface, by preventing unauthorized processes from sending messages to high privilege processes. Any process that wants to send a message to a high privilege process must get itself elevated to the higher privilege context, via UAC.
Applications written with the assumption that the user will be running with administrator privileges experienced problems in earlier versions of Windows when run from limited user accounts, often because they attempted to write to machine-wide or system directories (such as Program Files) or registry keys (notably HKLM) UAC attempts to alleviate this using File and Registry Virtualization, which redirects writes (and subsequent reads) to a per-user location within the user's profile. For example, if an application attempts to write to "C:\program files\appname\settings.ini" and the user doesn't have permissions to write to that directory, the write will get redirected to "C:\Users\username\AppData\Local\VirtualStore\Program Files\appname\."
BitLocker, formerly known as "Secure Startup", this feature offers full disk encryption for the system volume. Using the command-line utility, it is possible to encrypt additional volumes. Bitlocker utilizes a USB key or Trusted Platform Module (TPM) version 1.2 of the TCG specifications to store its encryption key. It ensures that the computer running Windows Vista starts in a known-good state, and it also protects data from unauthorized access. Data on the volume is encrypted with a Full Volume Encryption Key (FVEK), which is further encrypted with a Volume Master Key (VMK) and stored on the disk itself.
Windows Vista is the first Microsoft Windows operating system to offer native support for the TPM 1.2 by providing a set of APIs, commands, classes, and services for the use and management of the TPM. A new system service, referred to as TPM Base Services, enables the access to and sharing of TPM resources for developers who wish to build applications with support for the device.
Encrypting File System (EFS) in Windows Vista can be used to encrypt the system page file and the per-user Offline Files cache. EFS is also more tightly integrated with enterprise Public Key Infrastructure (PKI), and supports using PKI-based key recovery, data recovery through EFS recovery certificates, or a combination of the two. There are also new Group Policies to require smart cards for EFS, enforce page file encryption, stipulate minimum key lengths for EFS, enforce encryption of the user's Documents folder, and prohibit self-signed certificates. The EFS encryption key cache can be cleared when a user locks his workstation or after a certain time limit.
The EFS rekeying wizard allows the user to choose a certificate for EFS and to select and migrate existing files that will use the newly chosen certificate. Certificate Manager also allows users to export their EFS recovery certificates and private keys. Users are reminded to back up their EFS keys upon first use through a balloon notification. The rekeying wizard can also be used to migrate users in existing installations from software certificates to smart cards. The wizard can also be used by an administrator or users themselves in recovery situations. This method is more efficient than decrypting and reencrypting files.
Windows Vista includes Windows Defender, Microsoft's anti-spyware utility. According to Microsoft, it was renamed from 'Microsoft AntiSpyware' because it not only features scanning of the system for spyware, similar to other free products on the market, but also includes Real Time Security agents that monitor several common areas of Windows for changes which may be caused by spyware. These areas include Internet Explorer configuration and downloads, auto-start applications, system configuration settings, and add-ons to Windows such as Windows Shell extensions.
Windows Defender also includes the ability to remove ActiveX applications that are installed and block startup programs. It also incorporates the SpyNet network, which allows users to communicate with Microsoft, send what they consider is spyware, and check which applications are acceptable.
Windows Vista allow administrators to enforce hardware restrictions via Group Policy to prevent users from installing devices, to restrict device installation to a predefined white list, or to restrict access to removable media and classes of devices.
Windows Vista includes a range of parental controls for non-domain user accounts. Parental controls allows administrators to set restrictions on, and monitor, computer activity. Parental controls relies on User Account Control for much of its functionality. Features include:
These features are extensible, and can be replaced by other parental control applications by using the parental controls application programming interfaces (APIs).
Windows Vista uses Address Space Layout Randomization (ASLR) to load system files at random addresses in memory. By default, all system files are loaded randomly at any of the possible 256 locations. Other executables have to specifically set a bit in the header of the Portable Executable (PE) file, which is the file format for Windows executables, to use ASLR. For such executables, the stack and heap allocated is randomly decided. By loading system files at random addresses, it becomes harder for malicious code to know where privileged system functions are located, thereby making it unlikely for them to predictably use them. This helps prevent most remote execution attacks by preventing return-to-libc buffer overflow attacks.
The Portable Executable format has been updated to support embedding of exception handler address in the header. Whenever an exception is thrown, the address of the handler is verified with the one stored in the executable header. If they match, the exception is handled, otherwise it indicates that the run-time stack has been compromised, and hence the process is terminated.
Function pointers are obfuscated by XOR-ing with a random number, so that the actual address pointed to is hard to retrieve. So would be to manually change a pointer, as the obfuscation key used for the pointer would be very hard to retrieve. Thus, it is made hard for any unauthorized user of the function pointer to be able to actually use it. Also metadata for heap blocks are XOR-ed with random numbers. In addition, check-sums for heap blocks are maintained, which is used to detect unauthorized changes and heap corruption. Whenever a heap corruption is detected, the application is killed to prevent successful completion of the exploit.
Windows Vista binaries include intrinsic support for detection of stack-overflow. When a stack overflow in Windows Vista binaries is detected, the process is killed so that it cannot be used to carry on the exploit. Also Windows Vista binaries place buffers higher in memory and non buffers, like pointers and supplied parameters, in lower memory area. So to actually exploit, a buffer underrun is needed to gain access to those locations. However, buffer underruns are much less common than buffer overruns.
Windows Vista offers full support for the NX (No-Execute) feature of modern processors. DEP was introduced in Windows XP Service Pack 2 and Windows Server 2003 Service Pack 1. This feature, present as NX (EVP) in AMD's AMD64 processors and as XD (EDB) in Intel's processors, can flag certain parts of memory as containing data instead of executable code, which prevents overflow errors from resulting in arbitrary code execution.
If the processor supports the NX-bit, Windows Vista automatically enforces hardware-based Data Execution Prevention on all processes to mark some memory pages as non-executable data segments (like the heap and stack), and subsequently any data is prevented from being interpreted and executed as code. This prevents exploit code from being injected as data and then executed.
If DEP is enabled for all applications, users gain additional resistance against zero-day exploits. But not all applications are DEP-compliant and some will generate DEP exceptions. Therefore, DEP is not enforced for all applications by default in 32-bit versions of Windows and is only turned on for critical system components. However, Windows Vista introduces additional NX policy controls that allow software developers to enable NX hardware protection for their code, independent of system-wide compatibility enforcement settings. Developers can mark their applications as NX-compliant when built, which allows protection to be enforced when that application is installed and runs. This enables a higher percentage of NX-protected code in the software ecosystem on 32-bit platforms, where the default system compatibility policy for NX is configured to protect only operating system components. For x86-64 applications, backward compatibility is not an issue and therefore DEP is enforced by default for all 64-bit programs. Also, only processor-enforced DEP is used in x86-64 versions of Windows Vista for greater security.
New digital rights management and content-protection features have been introduced in Windows Vista to help digital content providers and corporations protect their data from being copied.
Windows Vista introduces Mandatory Integrity Control to set integrity levels for processes. A low integrity process can not access the resources of a higher integrity process. This feature is being used to enforce application isolation, where applications in a medium integrity level, such as all applications running in the standard user context can not hook into system level processes which run in high integrity level, such as administrator mode applications but can hook onto lower integrity processes like Windows Internet Explorer 7 or 8. A lower privilege process cannot perform a window handle validation of higher process privilege, cannot SendMessage or PostMessage to higher privilege application windows, cannot use thread hooks to attach to a higher privilege process, cannot use Journal hooks to monitor a higher privilege process and cannot perform DLL-injection to a higher privilege process.
Windows Service Hardening compartmentalizes the services such that if one service is compromised, it cannot easily attack other services on the system. It prevents Windows services from doing operations on file systems, registry or networks which they are not supposed to, thereby reducing the overall attack surface on the system and preventing entry of malware by exploiting system services. Services are now assigned a per-service Security identifier (SID), which allows controlling access to the service as per the access specified by the security identifier. A per-service SID may be assigned during the service installation via the ChangeServiceConfig2 API or by using the SC.EXE command with the sidtype verb. Services can also use access control lists (ACL) to prevent external access to resources private to itself.
Services in Windows Vista also run in a less privileged account such as Local Service or Network Service, instead of the System account. Previous versions of Windows ran system services in the same login session as the locally logged-in user (Session 0). In Windows Vista, Session 0 is now reserved for these services, and all interactive logins are done in other sessions. This is intended to help mitigate a class of exploits of the Windows message-passing system, known as Shatter attacks. The process hosting a service has only the privileges specified in the RequiredPrivileges registry value under HKLM\System\CurrentControlSet\Services.
Services also need explicit write permissions to write to resources, on a per-service basis. By using a write-restricted access token, only those resources which have to be modified by a service are given write access, so trying to modify any other resource fails. Services will also have pre-configured firewall policy, which gives it only as much privilege as is needed for it to function properly. Independent software vendors can also use Windows Service Hardening to harden their own services. Windows Vista also hardens the named pipes used by RPC servers to prevent other processes from being able to hijack them.
Graphical identification and authentication (GINA), used for secure authentication and interactive logon has been replaced by Credential Providers. Combined with supporting hardware, Credential Providers can extend the operating system to enable users to log on through biometric devices (fingerprint, retinal, or voice recognition), passwords, PINs and smart card certificates, or any custom authentication package and schema third party developers wish to create. Smart card authentication is flexible as certificate requirements are relaxed. Enterprises may develop, deploy, and optionally enforce custom authentication mechanisms for all domain users. Credential Providers may be designed to support Single sign-on (SSO), authenticating users to a secure network access point (leveraging RADIUS and other technologies) as well as machine logon. Credential Providers are also designed to support application-specific credential gathering, and may be used for authentication to network resources, joining machines to a domain, or to provide administrator consent for User Account Control. Authentication is also supported using IPv6 or Web services. A new Security Service Provider, CredSSP is available through Security Support Provider Interface that enables an application to delegate the user's credentials from the client (by using the client-side SSP) to the target server (through the server-side SSP). The CredSSP is also used by Terminal Services to provide single sign-on.
Windows Vista can authenticate user accounts using Smart Cards or a combination of passwords and Smart Cards (Two-factor authentication). Windows Vista can also use smart cards to store EFS keys. This makes sure that encrypted files are accessible only as long as the smart card is physically available. If smart cards are used for logon, EFS operates in a single sign-on mode, where it uses the logon smart card for file encryption without further prompting for the PIN.
Fast User Switching which was limited to workgroup computers on Windows XP, can now also be enabled for computers joined to a domain, starting with Windows Vista. Windows Vista also includes authentication support for the Read-Only Domain Controllers introduced in Windows Server 2008.
Windows Vista features an update to the crypto API known as Cryptography API: Next Generation (CNG). The CNG API is a user mode and kernel mode API that includes support for elliptic curve cryptography (ECC) and a number of newer algorithms that are part of the National Security Agency (NSA) Suite B. It is extensible, featuring support for plugging in custom cryptographic APIs into the CNG runtime. It also integrates with the smart card subsystem by including a Base CSP module which implements all the standard backend cryptographic functions that developers and smart card manufacturers need, so that they do not have to write complex CSPs. The Microsoft certificate authority can issue ECC certificates and the certificate client can enroll and validate ECC and SHA-2 based certificates.
Revocation improvements include native support for the Online Certificate Status Protocol (OCSP) providing real-time certificate validity checking, CRL prefetching and CAPI2 Diagnostics. Certificate enrollment is wizard-based, allows users to input data during enrollment and provides clear information on failed enrollments and expired certificates. CertEnroll, a new COM-based enrollment API replaces the XEnroll library for flexible programmability. Credential roaming capabilities replicate Active Directory key pairs, certificates and credentials stored in Stored user names and passwords within the network.
Windows Vista introduces Network Access Protection (NAP), which ensures that computers connecting to or communicating with a network conform to a required level of system health as set by the administrator of a network. Depending on the policy set by the administrator, the computers which do not meet the requirements will either be warned and granted access, allowed access to limited network resources, or denied access completely. NAP can also optionally provide software updates to a non-compliant computer to upgrade itself to the level as required to access the network, using a Remediation Server. A conforming client is given a Health Certificate, which it then uses to access protected resources on the network.
A Network Policy Server, running Windows Server 2008 acts as health policy server and clients need to use Windows XP SP3 or later. A VPN server, RADIUS server or DHCP server can also act as the health policy server.
A number of specific security and reliability changes have been made: