|
|
|
|
| |
Credit:
The information has been provided by Microsoft Product Security.
The original article can be found at: http://www.microsoft.com/technet/security/bulletin/MS06-051.mspx
|
| |
Affected Software:
* Microsoft Windows 2000 Service Pack 4 - Download the update
* Microsoft Windows XP Service Pack 1 and Microsoft Windows XP Service Pack 2 - Download the update
* Microsoft Windows XP Professional x64 Edition - Download the update
* Microsoft Windows Server 2003 and Microsoft Windows Server 2003 Service Pack 1 - Download the update
* Microsoft Windows Server 2003 for Itanium-based Systems and Microsoft Windows Server 2003 with SP1 for Itanium-based Systems - Download the update
* Microsoft Windows Server 2003 x64 Edition - Download the update
User Profile Elevation of Privilege Vulnerability - CVE-2006-3443:
There is a privilege elevation vulnerability in the way that Windows 2000 starts applications. This vulnerability could allow a logged on user to take complete control of the system.
Mitigating Factors for User Profile Elevation of Privilege Vulnerability - CVE-2006-3443:
* An attacker must have valid logon credentials and be able to log on locally to exploit this vulnerability. The vulnerability could not be exploited remotely or by anonymous users.
* On Windows XP Service Pack 1, Windows XP Service Pack2, Windows Server 2003 and Windows Server 2003 Service Pack1 SafeDllSearchMode is set to 1 by default and is not affected. If this default configuration is modified by an Administrator or is disabled those systems could be susceptible to the vulnerability.
Workarounds for User Profile Elevation of Privilege Vulnerability - CVE-2006-3443:
Microsoft has tested the following workarounds. Although these workarounds will not correct the underlying vulnerability, they help block known attack vectors. When a workaround reduces functionality, it is identified in the following section.
Set SafeDllSearchMode to 1
Setting SafeDllSearchMode to 1 within the registry ensures the DLL search path order targets the system directory before the current working directory or User Profile directory. For more information about Dynamic Link Library search order please read the following MSDN article.
Note Using Registry Editor incorrectly can cause serious problems that may require you to reinstall your operating system. Microsoft cannot guarantee that problems resulting from the incorrect use of Registry Editor can be solved. Use Registry Editor at your own risk. For information about how to edit the registry, view the "Changing Keys And Values" Help topic in Registry Editor (Regedit.exe) or view the "Add and Delete Information in the Registry" and "Edit Registry Data" Help topics in Regedt32.exe.
Note Microsoft recommends backing up the registry before you edit it.
1. Click Start, click Run, type "regedt32 " (without the quotation marks), and then click OK.
2. In Registry Editor, locate the following registry key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\ Control\Session Manager
3. Add the DWORD Value: SafeDllSearchMode. Set the value to 1. This value set the default DLL search order to the system directory. By default, this key does not exist on Windows 2000.
4. You must restart your system for this change to take effect.
FAQ for User Profile Elevation of Privilege Vulnerability - CVE-2006-3443:
What is the scope of the vulnerability?
This is a privilege elevation vulnerability. An attacker who successfully exploited this vulnerability could take complete control of an affected system. An attacker could then install programs; view, change, or delete data; or create new accounts with full user rights. To attempt to exploit the vulnerability, an attacker must be able to log on locally to the system and run a program.
What causes the vulnerability?
On Windows 2000 Winlogon does not prohibit the use of an invalid path. If a specially crafted DLL is placed in the user directory, it is possible for WinLogon to execute the code of the DLL resulting in an elevation of the user s privileges.
What is Winlogon?
Winlogon is the process that manages security-related user interactions in Windows. It handles logon and logoff requests, locking or unlocking the machine, changing the password, and other requests.
What is a DLL?
A DLL can define two kinds of functions: exported and internal. The exported functions are intended to be called by other modules, as well as from within the DLL where they are defined. Internal functions are typically intended to be called only from within the DLL where they are defined. Although a DLL can export data, its data is generally used only by its functions. However, there is nothing to prevent another module from reading or writing that address. DLLs provide a way to modularize applications so that their functionality can be updated and reused more easily. DLLs also help reduce memory overhead when several applications use the same functionality at the same time, because although each application receives its own copy of the DLL data, the applications share the DLL code. For more information on DLLs please ready the following MSDN article.
Is my Windows XP and Windows 2003 vulnerable since I do not see the SafeDllSearchMode registry key?
No. On Windows XP Service Pack 1, Windows XP Service Pack 2, Windows Server 2003 and Windows Server 2003 Service Pack1 SafeDllSearchMode is set to 1 by default within the operating system code and is therefore not vulnerable. Adding the registry key with a value other than 1 will change the default configuration. For more information about SafeDllSearchMode configuration options please read following MSDN article.
What might an attacker use the vulnerability to do?
An attacker who successfully exploited this vulnerability could take complete control of the affected system.
Who could exploit the vulnerability?
To try to exploit the vulnerability, an attacker must be able to log on locally to a system and run a program
How could an attacker exploit the vulnerability?
To exploit this vulnerability, an attacker would first have to log on to the system. An attacker could then place a specially crafted DLL within their UserProfile directory and then restart the computer. After the restart and subsequent re-logon by the attacker, the DLL would execute code that could exploit the vulnerability and allow the attacker to gain complete control over the affected system.
What systems are primarily at risk from the vulnerability?
Windows 2000 systems are primarily at risk. Servers could be at more risk if users who do not have sufficient administrative permissions are given the ability to log on to servers and to run programs. However, best practices strongly discourage allowing this.
Could the vulnerability be exploited over the Internet?
No. An attacker must be able to log on to the specific system that is targeted for attack. An attacker cannot load and run a program remotely by using this vulnerability
What does the update do?
The update removes the vulnerability by not allowing WinLogon to use an invalid path on Windows 2000.
When this security bulletin was issued, had this vulnerability been publicly disclosed?
No. Microsoft received information about this vulnerability through responsible disclosure
When this security bulletin was issued, had Microsoft received any reports that this vulnerability was being exploited?
No. Microsoft had not received any information to indicate that this vulnerability had been publicly used to attack customers and had not seen any examples of proof of concept code published when this security bulletin was originally issued.
Unhandled Exception Vulnerability - CVE-2006-3648:
There is a remote code execution vulnerability in the way that exception handling is managed on multiple applications that are resident in memory.
Mitigating Factors for Unhandled Exception Vulnerability - CVE-2006-3648:
* An attacker would have to host a Web site that contains a Web page that is used to exploit this vulnerability. An attacker would have no way to force users to visit a specially crafted Web site. Instead, an attacker would have to persuade them to visit the Web site, typically by getting them to click a link that takes them to the attacker's Web site. After they click the link, they would be prompted to perform several actions. An attack could only occur after they performed these actions.
* An attacker who successfully exploited this vulnerability could gain the same user rights as the local user. Users whose accounts are configured to have fewer user rights on the system could be less impacted than users who operate with administrative user rights
* The Restricted sites zone helps reduce attacks that could try to exploit this vulnerability by preventing Active Scripting and ActiveX controls from being used when reading HTML e-mail. However, if a user clicks on a link within an e-mail they could still be vulnerable to this issue through the Web-based attack scenario described previously
* By default, Outlook Express 6, Outlook 2002, and Outlook 2003 open HTML e-mail messages in the Restricted sites zone. Additionally, Outlook 98 and Outlook 2000 open HTML e-mail messages in the Restricted sites zone if the Outlook E-mail Security Update has been installed. Outlook Express 5.5 Service Pack 2 opens HTML e-mail messages in the Restricted sites zone if Microsoft Security Bulletin MS04-018 has been installed.
Workarounds for Unhandled Exception Vulnerability - CVE-2006-3648:
Microsoft has tested the following workarounds. Although these workarounds will not correct the underlying vulnerability, they help block known attack vectors. When a workaround reduces functionality, it is identified in the following section.
* Disable active scripting in the My Computer zone
More information on the values being modified by this workaround can be found at the following Web site. There are two ways to deploy this workaround:
Note Using Registry Editor incorrectly can cause serious problems that may require you to reinstall your operating system. Microsoft cannot guarantee that problems resulting from the incorrect use of Registry Editor can be solved. Use Registry Editor at your own risk. For information about how to edit the registry, view the "Changing Keys And Values" Help topic in Registry Editor (Regedit.exe) or view the "Add and Delete Information in the Registry" and "Edit Registry Data" Help topics in Regedt32.exe.
Note Microsoft recommends backing up the registry before you edit
* Click Start, click Run, type "regedt32 " (without the quotation marks), and then click OK.
* In Registry Editor, locate the following registry key: HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Zones\0
* Double click the DWORD Value: 1400.
* The Edit DWORD value dialogue appears. The default value is 0. Change this value to value to 3.
* Close any instances of Internet Explorer. The change takes effect the next time Internet Explorer is started.
* Read e-mail messages in plain text format if you are using Outlook 2002 or a later version, or Outlook Express 6 SP1 or a later version, to help protect yourself from the HTML e-mail attack vector.
Microsoft Outlook 2002 users who have applied Office XP Service Pack 1 or a later version and Microsoft Outlook Express 6 users who have applied Internet Explorer 6 Service Pack 1 or a later version can enable this setting and view e-mail messages that are not digitally signed or e-mail messages that are not encrypted in plain text only.
Digitally signed e-mail messages or encrypted e-mail messages are not affected by the setting and may be read in their original formats. For more information about how to enable this setting in Outlook 2002, see Microsoft Knowledge Base Article 307594.
For information about this setting in Outlook Express 6, see Microsoft Knowledge Base Article 291387.
Impact of Workaround: E-mail messages that are viewed in plain text format will not contain pictures, specialized fonts, animations, or other rich content. Additionally:
* The changes are applied to the preview pane and to open messages.
* Pictures become attachments so that they are not lost.
* Because the message is still in Rich Text or HTML format in the store, the object model (custom code solutions) may behave unexpectedly.
FAQ for Unhandled Exception Vulnerability - CVE-2006-3648:
What is the scope of the vulnerability?
This is a remote code vulnerability. An attacker who successfully exploited this vulnerability could take complete control of an affected system. An attacker could then install programs; view, change, or delete data; or create new accounts with full user rights.
What causes the vulnerability?
Improper exception handling in memory resident applications.
What might an attacker use the vulnerability to do?
An attacker who successfully exploited this vulnerability could take complete control of the affected system.
How could an attacker exploit the vulnerability?
In a Web-based attack scenario, an attacker would have to host a Web site that contains a Web page that is used to attempt to exploit this vulnerability. An attacker would have no way to force users to visit a specially crafted Web site. Instead, an attacker would have to persuade them to visit the Web site, typically by getting them to click a link that takes them to the attacker's site. It could also be possible to display specially crafted Web content by using banner advertisements or by using other methods to deliver Web content to affected systems.
What systems are primarily at risk from the vulnerability?
Windows workstation and server systems are primarily at risk. Servers could be at more risk if users who do not have sufficient administrative permissions are given the ability to log on to servers and to run programs. However, best practices strongly discourage allowing this.
Could the vulnerability be exploited over the Internet?
Yes. An attacker could try to exploit this vulnerability over the Internet.
What does the update do?
The update removes the vulnerability by correctly unloading chained exception
When this security bulletin was issued, had this vulnerability been publicly disclosed?
No. Microsoft received information about this vulnerability through responsible disclosure.
When this security bulletin was issued, had Microsoft received any reports that this vulnerability was being exploited?
No. Microsoft had not received any information to indicate that this vulnerability had been publicly used to attack customers and had not seen any examples of proof of concept code published when this security bulletin was originally issued.
|
|
|
|
|
