What's the scope of the vulnerability?
This is a buffer overrun vulnerability. By entering a specially malformed record into a machine's event log, an attacker could cause either of two effects to occur when the record was subsequently opened. In the least serious case, he could cause the event viewer to fail. In the more serious case, he could cause the event viewer's functionality to be modified while running, in order to perform a task of his choosing on the other user's machine.
The most significant mitigating factor associated with this vulnerability is the need for the attacker to be able to authenticate to the machine he wanted to attack. The net result is that, on a properly configured system, it is unlikely that an outsider such as an Internet user could exploit this vulnerability.
What causes the vulnerability?
The event viewer in Windows 2000 contains an unchecked buffer. If the event viewer were used to view an event log record containing a specially malformed record, the buffer could be overrun, which could in the worst case potentially enable code of another user's choice to be run on the machine.
What's the event viewer?
The event viewer is a tool that's used to view event logs in Windows NT® and Windows 2000. Whenever an event like an application error, system warning, or security-critical operation occurs, the event logging system generates a record in either of three event logs: the Application, System or Security logs, respectively. The event viewer enables authorized users to view the records, as well as enabling them to manage the logs.
What's wrong with the Windows 2000 event viewer?
The event viewer contains an unchecked buffer in a part of the code that processes and displays the properties pages for event records. If it were used to view the properties of an event record that contained a particular type of malformed information, a buffer overrun would result.
As is usually the case with buffer overrun vulnerabilities, either of two outcomes could occur. In the least serious case - in which the buffer was overrun by random data - the event viewer would fail. In the more serious case - in which the attacker filled the affected field in the event record with carefully selected data - the functionality of the event viewer could be modified while it was running, in order to make it take something other than its intended action.
What would the first case enable an attacker to do?
If the event record were filled with random data, the event viewer would fail each time it attempted to read the malformed record. The user could restart it and continue working normally. Although she could not delete the specific record, she could avoid viewing it until such time as she cleared the entire log.
What would the second case enable an attacker to do?
If an attacker were able to insert an event record containing specially chosen data, he could cause the event viewer to take any action he wanted when it processed the record. The only limitation on the actions the code could take would be those associated with the user - if she had few privileges on the machine, the code might be able to do very little. On the other hand, if she was an administrator, the code could do virtually anything on the machine.
Who can view the event logs?
It varies, depending on the particular event log. The Application and System log can be viewed by any user, but only administrators can view the Security log.
What would the user need to do in order to trigger the buffer overrun?
The buffer overrun would only occur if the user viewed the detailed information about the specially malformed event record the attacker had created. When Event Viewer is started, the left pane shows the console tree, and the right pane shows a listing of all events in the log. Simply viewing the information on this screen would not be sufficient to trigger the buffer overrun. The buffer overrun could only be triggered if the user double-clicked on the attacker's event record, or if she right-clicked it and chose "Properties".
How could the attacker create the malformed event record?
By design, unprivileged processes are able to write event records to the Application and System logs using standard Win32 API calls. (They can't, however, write to the Security log). The attacker could write an application that would use these API calls to write a malformed record to an event log.
Could someone create such a record accidentally, though normal use of the system?
No. None of the system services will create a record with the specific malformation at issue here. Simply using the system would not, under any conditions, create such a record.
Could the attacker exploit this vulnerability remotely?
It is possible to write an event record remotely. However, the mechanism by which this could be done is typically blocked by firewalling. Thus, in a properly-secured environment, it's likely that this vulnerability could only be exploited by an intranet user.
Could the attacker insert a malformed record into the event viewer and then deliberately view the record, as a way of elevating his privileges?
No. Although he could insert a record into the log and then view it, the event viewer would run in his own security context, so he wouldn't gain anything by doing this.
Is there any way to view the event log safely?
Of course, the best way to use the event viewer safely is to apply the patch. However, it would also be possible to use the Dumpel tool to dump the event log into an Excel file, and then view it using Excel.
Does this vulnerability affect Windows NT 4.0 systems?
The Windows NT 4.0 event viewer is not affected by this vulnerability. However, there is a scenario through which a Windows NT 4.0 system could be involved in an exploit scenario for this vulnerability.
The event viewer can be used to remotely view the event log on another machine. The important factor is not what system houses the malformed record, but whether an affected event viewer were used to display it. This means that if an attacker inserted a malformed record into the event log on a Windows NT 4.0 system, and a user on a Windows 2000 system remotely viewed it, she could be affected by the vulnerability.
Who should use the patch?
Microsoft recommends that all Windows 2000 users consider installing the patch. However, it's especially important that the patch be installed on critical machines like servers, domain controllers, and the like.
What does the patch do?
The patch eliminates the vulnerability by causing the event viewer to check all input before using it, thereby preventing the buffer from being overrun.
