• Article

Security Bulletin

Microsoft Security Bulletin MS02-064 - Moderate

Windows 2000 Default Permissions Could Allow Trojan Horse Program (Q327522)

Published: October 30, 2002 | Updated: February 28, 2003

Version: 1.2

Originally posted: October 30, 2002

Updated: February 28, 2003

Summary

Who should read this bulletin:  System administrators running Microsoft® Windows® 2000.

Impact of vulnerability:  Trojan Horse program execution

Maximum Severity Rating:  Moderate

Recommendation:  Administrators should consider changing access permissions on the Windows 2000 system root directory.

Affected Software:

  • Microsoft Windows 2000

General Information

Technical details

Technical description:

On Windows 2000, the default permissions provide the Everyone group with Full access (Everyone:F) on the system root folder (typically, C:\). In most cases, the system root is not in the search path. However, under certain conditions - for instance, during logon or when applications are invoked directly from the Windows desktop via Start | Run - it can be.

This situation gives rise to a scenario that could enable an attacker to mount a Trojan horse attack against other users of the same system, by creating a program in the system root with the same name as some commonly used program, then waiting for another user to subsequently log onto the system and invoke the program. The Trojan horse program would execute with the user's own privileges, thereby enabling it to take any action that the user could take.

The simplest attack scenario would be one in which the attacker knew that a particular system program was invoked by a logon script. In that case, the attacker could create a Trojan horse with the same name as the system program, which would then be executed by the logon script the next time someone logged onto the system. Other scenarios almost certainly would require significantly greater user interaction - for instance, convincing a user to start a particular program via Start | Run - and would necessitate the use of social engineering.

The systems primarily at risk from this vulnerability would be workstations that are shared between multiple users, and local terminal server sessions. Other systems would be at significantly less risk:

  • Workstations that are not shared between users would be at no risk, because the attacker would require the ability to log onto the system in order to place the Trojan horse.
  • Servers would be at no risk, if standard best practices have been followed that advocate only allowing trusted users to log onto them.
  • Remote Terminal server sessions would be at little risk, because each user's environment is isolated. That is, the system root is never the current folder - instead, the user's Documents and Settings folder is, but the permissions on this folder would not enable an attacker to place a Trojan horse there.

Mitigating factors:

  • An attacker would require the ability to log onto the system interactively in order to place the Trojan horse program. It could not be placed remotely
  • As discussed above, dedicated workstations, servers and remote terminal server sessions would be at less risk (or, in some cases, none at all) from the vulnerability.

Severity Rating:

Internet Servers Intranet Servers Client Systems
Windows 2000 Low Low Moderate

The above assessment is based on the types of systems affected by the vulnerability, their typical deployment patterns, and the effect that exploiting the vulnerability would have on them.

Vulnerability identifier: CAN-2002-1184

Tested Versions:

Microsoft tested Windows NT, Windows 2000, and Windows XP to assess whether they are affected by this vulnerability.

Frequently asked questions

What's the scope of the vulnerability?
This is a Trojan Horse vulnerability. An attacker who was able to successfully exploit this vulnerability could place a program on a system that, at some later point, could be inadvertently run by another user. The program would run with the privileges associated with the user, and could take any action the user could take, including loading and running programs, altering data on the system, reformatting the hard drive, and so forth. In most cases, exploiting the vulnerability would not be a straightforward task, but would instead require at least some social engineering on the attacker's part. In addition, the vulnerability does not affect all systems equally. Instead, workstations that are shared between users would be at greatest risk, and servers - including terminal servers - would typically be at significantly less risk.

What causes the vulnerability?
The vulnerability results because of a combination of two factors: the default permissions on the system root folder, and the search path Windows uses when locating programs. The former would enable an attacker to place a Trojan horse program on the system; the latter could cause it to be inadvertently executed by a subsequent user on the system.

What's the system root folder, and what does it do?
The system root folder is the topmost folder on the drive that contains the operating system (typically, C:\). The primary purpose of the system root is to provide a logical "anchor point" for the file system - a reference point from which other files and folders can be located. No sensitive files are stored there by default.

What are the default permissions on the system root?
The default permissions are Everyone Full Access. This allows any user who can log onto the system to read files located on the system root, write new files there (or modify existing ones), or execute programs that reside there.

If there aren't any sensitive files stored on the system root, why do the default permissions pose a security vulnerability?
The reason has to do with the way Windows locates programs. In a nutshell, there are cases in which the system root can become the first place the system looks when searching for a program. If an attacker had previously created a program, given it the same name as a frequently requested program, and placed it in the system root, the attacker's program - rather than the legitimate program - could execute.

How does Windows locate programs?
If a program is invoked using an absolute path - that is, if the caller specifies the exact location of the program - Windows will check that location and only that location, and return an error if the program isn't found there. However, if only the name of the program was provided, Windows will undertake a search process to find and execute it. First, it checks within the so-called current folder - that is, whatever folder the user (or calling application) happens to be working in at the time - then checks the folders specified in an environment variable called %PATH%. It's the second case that plays a role in this vulnerability. Specifically, there are cases in which the system root can become the current folder. When this happens, the system root will be the first place Windows looks for programs. Under these circumstances, if a program in the system root had the same name as, say, a legitimate system program, the bogus program would have precedence in the search order and be executed instead of the system file.

Under what circumstances is the system root also the current folder?
It's not possible to provide an all-encompassing answer, because it depends in some degree on the specific way the system is configured. However, two examples of circumstances in which this occurs in default configurations include:

  • At system startup. Specifically, when logon scripts are run, the system root is the current folder.
  • When launching programs from the Windows desktop. For instance, if a program is started using the Start | Run command, or if Task Manager is started via the ctrl-alt-del sequence, the system root is the current folder.

It's worth pointing out that the foregoing is not true in the case of a remote terminal server session. Terminal Server isolates each user's session so, in the cases mentioned above, the current folder would be the user's own Documents and Settings folder rather than the system root.

What could an attacker do via this vulnerability?
An attacker who had the ability to log onto a system that's shared with other users could place a program in the system root, in the hope that a subsequent user would inadvertently run it. The attacker's program, if run, would do so with the user's own privileges, and would be able to do anything that the user could do. The attack would likely proceed along the following lines:

  • The attacker would log onto the system and identify a program that he or she believed other users might invoke. For purposes of illustration, let's assume that the program is named x.exe.
  • The attacker would create a hostile program, name it x.exe, and put it in the system root.
  • At some later point, another user might log onto the system and invoke x.exe. If this happened during a time when the system root was the current folder, the attacker's version of x.exe rather than the legitimate version would run.

Who could exploit the vulnerability?
In order to exploit the vulnerability, the attacker would need valid logon credentials on the system - the Trojan horse could not be emplaced remotely. However, simply putting the file on the system would not be enough. To actually make the program to run, the attacker would also need some means of getting the user to invoke it.

How might the attacker get the user to invoke the Trojan horse program?
The simplest scenario would be one in which the attacker knew that a logon script would be run anytime a user logged onto the system, and would call a particular system program. In this case, the attacker could simply give the Trojan horse program a matching name and wait for another user to log on. Other scenarios would be more difficult to carry out and almost certainly require a significant degree of social engineering. For instance, the attacker could attempt to create a scenario in which the user would be likely to invoke a particular program via the Start | Run command, open Task Manager via ctrl-alt-del, and so forth.

You said that the system root is the current folder for the Window desktop. Does that mean that clicking on an icon on the desktop could cause a Trojan horse to run?
No. Desktop icons, in almost every case, use an absolute path name to reference the programs they're associated with. As discussed above, when an absolute path is used to invoke a program, the search path never comes into play.

What systems are at great risk from the vulnerability?
Shared workstations are far and away the most likely systems to be affected by this vulnerability, but terminal servers can also be at risk if the user logs on locally instead of via a remote session. The reason for this can be most easily seen through a process of elimination.

  • Workstations that aren't shared are at no risk from the vulnerability. The vulnerability could only be exploited if the attacker could plant the Trojan horse and then persuade another user to log onto the same machine.
  • Servers would tend to be at less risk, if standard security practices have been followed and only trusted users are allowed to log onto them. Without the ability to log onto the system interactively, an attacker would have no way to place the Trojan horse.
  • Remote Terminal Server sessions would also be at significantly less risk, because each user's session is isolated. That is, system root doesn't ever become the current folder - the user's Documents and Settings folder does, but permissions on that folder do not allow anyone but the user and the system administrator to write to it.

Does the vulnerability affect Windows NT 4.0?
In Windows NT 4.0, all folders - not just the system root - default to Everyone Full Access. As a result, while it would be possible for an attacker to mount a Trojan horse attack through the same scenario as described above, it would be simpler for him or her to simply overwrite system files directly. However, the need to appropriately configure the permissions on Windows NT 4.0 systems is well-known to most system administrators, and is discussed in Microsoft's security checklists for Windows NT 4.0 as well as most third-party guides.

Does the vulnerability affect Windows XP?
In most cases, no. The default permissions for the system root in Windows XP allow only read access. The single case in which this is not true is if a Windows 2000 system is upgraded to Windows XP - in this case, the existing permissions on all folders, including the system root, are retained. However, even then, the vulnerability would be difficult to exploit because the current directory for the Windows XP desktop is the user's Documents and Settings folder, rather than the system root.

Why isn't there a patch for this vulnerability?
A patch simply isn't practical for this case. The right permissions vary from organization to organization and can depend on factors like the specific applications in use. Any set of permissions set by a patch would almost certainly need to be adjusted in many cases, and as a result we believe the most effective way to remediate the problem is for system administrators to set the permissions that are right for their organizations.

What's a good baseline set of permissions?
The default permissions for Windows XP can serve as a guide for a set of permissions which have been thoroughly designed and tested. The default permissions for the root directory on the system drive for Windows XP are:

  • Administrators: Full Control
  • Creator Owner: Full Control (Subfolders and Files)
  • System: Full Control
  • Users: Read & Execute (This folder, subfolders, and files)
  • Users: Create Folders / Append Data (This folder and Subfolders)
  • Users: Create Files / Write Data (Subfolders only)
  • Everyone: Read & Execute

Can I use security templates to apply the new permissions?
Yes. Customers using a security template can add the following to the [File Security] section to set the permissions to be the same as those for Windows XP (this should be added as a single line in the security template, no line breaks).

"%SystemDrive%\",0,"D:AR(A;OICI;GA;;;BA)(A;OICI;GA;;;SY)(A;OICIIO;GA;;;CO)(A;CIOI;GRGX;;;BU)(A;CI;0x00000004;;;BU)(A;CIIO;0x00000002;;;BU)(A;;GRGX;;;WD)"

Patch availability

Download locations for this patch

  • This vulnerability requires an administrative procedure rather than a patch. The needed changes are discussed in the FAQ.

Additional information about this patch

Installation platforms:

This permissions change can be made on systems running any version of Windows 2000.

Caveats:

None

Obtaining other security patches:

Patches for other security issues are available from the following locations:

  • Security patches are available from the Microsoft Download Center, and can be most easily found by doing a keyword search for "security_patch".
  • Patches for consumer platforms are available from the WindowsUpdate web site

Other information:

Acknowledgments

Microsoft thanks Jason Miller of Security Focus (https://www.securityfocus.com) for reporting this issue to us and working with us to protect customers.

Support:

  • Microsoft Knowledge Base article Q327522 discusses this issue and will be available approximately 24 hours after the release of this bulletin. Knowledge Base articles can be found on the Microsoft Online Support web site.
  • Technical support is available from Microsoft Product Support Services. There is no charge for support calls associated with security patches.

Security Resources: The Microsoft TechNet Security Web Site provides additional information about security in Microsoft products.

Disclaimer:

The information provided in the Microsoft Knowledge Base is provided "as is" without warranty of any kind. Microsoft disclaims all warranties, either express or implied, including the warranties of merchantability and fitness for a particular purpose. In no event shall Microsoft Corporation or its suppliers be liable for any damages whatsoever including direct, indirect, incidental, consequential, loss of business profits or special damages, even if Microsoft Corporation or its suppliers have been advised of the possibility of such damages. Some states do not allow the exclusion or limitation of liability for consequential or incidental damages so the foregoing limitation may not apply.

Revisions:

  • V1.0 (October 30, 2002): Bulletin Created.
  • V1.1 (November 27, 2002): Clarified Security Template information.
  • V1.2 (February 28, 2003): Updated Windows XP Base Permissions in the Frequently Asked Questions section.

Built at 2014-04-18T13:49:36Z-07:00