This patch eliminates three vulnerabilities affecting Internet Explorer. The first involves how IE handles URLs that include dotless IP addresses. If a web site were specified using a dotless IP format (e.g., http://031713501415 rather than http://207.46.131.13), and the request were malformed in a particular way, IE would not recognize that the site was an Internet site. Instead, it would treat the site as an intranet site, and open pages on the site in the Intranet Zone rather than the correct zone. This would allow the site to run with fewer security restrictions than appropriate. This vulnerability does not affect IE 6.
The second involves how IE handles URLs that specify third-party sites. By encoding an URL in a particular way, it would be possible for an attacker to include HTTP requests that would be sent to the site as soon as a connection had been established. These requests would appear to have originated from the user. In most cases, this would only allow the attacker to send the user to a site and request a page on it. However, if exploited against a web-based service (e.g., a web-based mail service), it could be possible for the attacker to take action on the user's behalf, including sending a request to delete data.
The third is a new variant of a vulnerability discussed in Microsoft Security Bulletin MS01-015, affecting how Telnet sessions are invoked via IE. By design, telnet sessions can be launched via IE. However, a vulnerability exists because when doing so, IE will start Telnet using any command-line options the web site specifies. This only becomes a concern when using the version of the Telnet client that installs as part of Services for Unix (SFU) 2.0 on Windows NT(r) 4.0 or Windows(r) 2000 machines. The version of the Telnet client in SFU 2.0 provides an option for creating a verbatim transcript of a Telnet session. An attacker could start a session using the logging option, then stream an executable file onto the user's system in a location that would cause it to be executed automatically the next time the user booted the machine. The flaw does not lie in the Telnet client, but in IE, which should not allow Telnet to be started remotely with command-line arguments.
Read more
The second involves how IE handles URLs that specify third-party sites. By encoding an URL in a particular way, it would be possible for an attacker to include HTTP requests that would be sent to the site as soon as a connection had been established. These requests would appear to have originated from the user. In most cases, this would only allow the attacker to send the user to a site and request a page on it. However, if exploited against a web-based service (e.g., a web-based mail service), it could be possible for the attacker to take action on the user's behalf, including sending a request to delete data.
The third is a new variant of a vulnerability discussed in Microsoft Security Bulletin MS01-015, affecting how Telnet sessions are invoked via IE. By design, telnet sessions can be launched via IE. However, a vulnerability exists because when doing so, IE will start Telnet using any command-line options the web site specifies. This only becomes a concern when using the version of the Telnet client that installs as part of Services for Unix (SFU) 2.0 on Windows NT(r) 4.0 or Windows(r) 2000 machines. The version of the Telnet client in SFU 2.0 provides an option for creating a verbatim transcript of a Telnet session. An attacker could start a session using the logging option, then stream an executable file onto the user's system in a location that would cause it to be executed automatically the next time the user booted the machine. The flaw does not lie in the Telnet client, but in IE, which should not allow Telnet to be started remotely with command-line arguments.
Read more
