Remote Procedure Call (RPC)
A Remote Procedure Call (RPC) is a message-passing facility that allows an application on one computer to call services that are available on various computers on a network. RPCs are commonly used to do remote administration of computers on a network, to share files and printers, and to build custom distributed applications.
Windows XP has a Remote Procedure Call subsystem (the rpcss network service) that provides the infrastructure for many other services and applications. The RPC subsystem takes care of mapping the endpoints of the available services and enables applications to use dynamic endpoints. The Remote Procedure Call Locator (rpclocator) service helps distributed application clients to find available compatible server applications.
Windows XP systems as normally installed have over 60 RPC-based services running that listen for client requests on the network, mostly in processes called Svchost.exe. If unprotected, these present a huge "attack surface" for intruders. In previous versions of Windows, ICF (the predecessor to Windows Firewall) blocked all RPC communications from outside the computer, which interfered with file and print sharing and remote administration as well as other useful services. This is one reason why many users did not run ICF.
Windows Firewall now takes a different, more compatible approach. When a process tries to open a port, claiming that it is an RPC service, Windows Firewall will accept this claim if and only if the caller is running in the Local System, Network Service, or Local Service security context – in other words, only if the process is actually a service. This reduces the chance that unprivileged Trojan horse programs will open a port for themselves by pretending to be RPC servers.
In addition, there is a new system policy for RPC servers that restricts their usage to local and/or authenticated clients. By default, the RPC runtime will reject all remote, anonymous calls. If a service registers a security callback that can authenticate remote, anonymous calls, then that service is granted an exemption. There is a new registry key, RestrictRemoteClients, that can modify this behavior to be more or less restrictive than the default, which administrators and developers can read about in http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnwxp/html/securityinxpsp2.asp and the online training at
http://msdn.microsoft.com/security.
Distributed Component Object Model (DCOM)
The Microsoft Component Object Model (COM) is a platform-independent, distributed, object-oriented system for creating binary software components that can interact. The Distributed Component Object Model (DCOM) allows applications to be distributed across locations on the network. The DCOM wire protocol transparently provides support for reliable and efficient communication between COM components.
Administrators typically configure COM servers to be available for remote use via DCOM. In previous versions of Windows, DCOM servers could sometimes present targets to remote attackers. In one scenario, an anonymous remote client would ask a DCOM server to perform a task that normally requires authentication. Since there are about 150 COM servers in a default installation of Windows XP, and no way to check their settings automatically, it would be difficult for an administrator to even determine the level of exposure on one computer, much less an entire network.
In Windows XP Service Pack 2, the security of DCOM has been enhanced. A system-wide setting restricts DCOM activation, launch, and call privileges, and differentiates between local and remote clients. By default, everyone is granted local launch, local activation, and local call permissions, which should enable all local scenarios to continue to work without change. By default, all authenticated users are granted remote call permissions, which enables most common server applications, as long as the client is not anonymous. By default, only administrators are granted remote activation and launch permissions.
In addition to the system-wide DCOM security settings, individual COM servers can be set to restrict the rights available to users. There are four new launch permission levels for COM servers: local launch, remote launch, local activate, and remote activate. There are two new access permission levels for COM servers: local calls and remote calls. The default permission levels will work properly for almost all cases.
Administrators and developers can read about the new DCOM security levels in http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnwxp/html/securityinxpsp2.asp and the online training at http://msdn.microsoft.com/security.
Alerter and Messenger services
The Alerter and Messenger services, which are sometimes used by administrators and developers to communicate over a network, have been disabled by default in Windows XP Service Pack 2. In previous versions of Windows, the Messenger service was started automatically, and could be abused by advertisers if no firewall was active. The Alerter service was available for manual start, but rarely used. Administrators and developers who use either of these services should read about the issues in http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnwxp/html/securityinxpsp2.asp. Most users will not see any effect from these services being disabled, other than noticing that some annoying popup messages from the Internet have stopped appearing.
Memory protection
Buffer overrun attacks are among the most common mechanisms, or vectors, for intrusion into computers. In this type of exploit, the attacker sends a long string to an input stream or control – longer than the memory buffer allocated to hold it. The long string injects code into the system, which is executed, launching a virus or worm.
Windows XP Service Pack 2 uses two general categories of protection measures to inhibit buffer-overrun attacks. On CPUs that support it, the operating system can turn on the execution protection bit for virtual memory pages that are supposed to hold only data. On all CPUs, the operating system is now more careful to reduce both stack and heap buffer overruns, using "sandboxing" techniques.
Execution Protection (NX)
On the 64-bit AMD K8 and Intel Itanium processor families, the CPU hardware can mark memory with an attribute that indicates that code should not be executed from that memory. This execution protection (NX) feature functions on a per-virtual memory page basis, most often changing a bit in the page table entry to mark the memory page.
On these processors, Windows XP Service Pack 2 uses the execution protection feature to prevent the execution of code from data pages. When an attempt is made to run code from a marked data page, the processor hardware raises an exception immediately and prevents the code from executing. This prevents attackers from overrunning a data buffer with code and then executing the code; it would have stopped the Blaster worm dead in its tracks.
Although the support for this feature is currently limited to 64-bit processors, Microsoft expects future 32-bit and 64-bit processors to provide execution protection.
Sandboxing
To help control this type of attack on existing 32-bit processors, Service Pack 2 adds software checks to the two types of memory storage used by native code: the stack, and the heap. The stack is used for temporary local variables with short lifetimes; stack space is automatically allocated when a function is called and released when the function exits. The heap is used by programs to dynamically allocate and free memory blocks that may have longer lifetimes.
The protection added to these two kinds of memory structures is called sandboxing. To protect the stack, all binaries in the system have been recompiled using an option that enables stack buffer security checks. A few instructions added to the calling and return sequences for functions allow the runtime libraries to catch most stack buffer overruns. This is a case where a little paranoia goes a long way.
In addition, "cookies" have been added to the heap. These are special markers at the beginning and ends of allocated buffers, which the runtime libraries check as memory blocks are allocated and freed. If the cookies are found to be missing or inconsistent, the runtime libraries know that a heap buffer overrun has occurred, and raise a software exception.
Safer message handling
Many viruses spread through file attachments to e-mail and instant messages. Virus writers capitalize on people's curiosity and willingness to accept files from people they know or work with, in order to transmit malicious files disguised as or attached to benign files.
Millions of people opened an email that said "I love you" even though it came from business associates that they barely knew. Millions of people opened what they thought was an image of tennis star Anna Kournikova. And, as we know, millions of people infected their computers, their networks, and their friends' computers with these viruses, which when activated mailed themselves to many of the contacts listed in the infected computers' address books.
Some attachment files, like plain text messages and simple images, are inherently safe. Other files, like binary executables, are inherently suspect. Still others might be safe, if certain easily detectable elements are absent, like an Excel spreadsheet without any macros. Zip files and other archives are themselves safe, but might contain other unsafe files.
Windows users and the operating system have traditionally distinguished file types by their extension: a file called ReadMe.txt is a plain text file that can be read in Notepad, while a file called ReadMe.doc is a Word document. Email and Web browsers also have the concept of a MIME type for files, and some applications and services "sniff" the content of files to determine the type of content they hold.
Microsoft Outlook increased its protection from email viruses once Outlook implemented attachment blocking as an internal function. Microsoft is now bringing this same kind of protection to Outlook Express, Windows Messenger, and other messaging applications, using a new system service for managing attachments. In the future, Outlook will use this system service rather than relying on its own internal methods for identifying safe and unsafe attachments.
Attachment Execution Service (AES)
Windows XP Service Pack 2 introduces the new Attachment Execution Service (AES) to control the viewing and execution of files attached to messages. AES has a COM interface that is in turn used by other programs, such as Outlook Express.
A ES looks at a file and determines whether it is safe to view or execute based on several criteria. First, it looks at the file extension. It knows it can trust text files (.TXT), JPEG images (.JPG), and GIF images (.GIF). It can look up the associated application for a given MIME type and file extension, and make sure the two are consistent. It can decide whether a given association is safe or dangerous, based on a list. It can make sure that an antivirus is active and up-to-date before allowing the user to view or run unsafe files. It can also check the current security zone of the message source to control its policy.
|
