Video Screencast Help
Symantec to Separate Into Two Focused, Industry-Leading Technology Companies. Learn more.
Security Response

Microsoft's Inaccurate Teredo Documentation, and Other Vista CVEs

Created: 03 Apr 2007 07:00:00 GMT • Updated: 23 Jan 2014 18:50:41 GMT
Jim Hoagland's picture
0 0 Votes
Login to vote

Last week the CVE project issued nine new CVEs for Vista, numberedCVE-2007-1527 through CVE-2007-1535. While these CVEs were directlybased on our findings in Windows Vista Network Attack Surface Analysis[1] report (released as a Symantec Security Response whitepaper on March 7th), they had been requested by a third party. I'll describe each of these in this post.

We don't feel that most of the issues are especially significant.Microsoft reviewed the paper prior to its public release and Symantecwould participate in any warranted responsible disclosure forvulnerabilities.

We regard CVE-2007-1535 asimportant, and it could be regarded as a vulnerability. The describedissue is that Teredo (an IPv4 to IPv6 transition technology that worksthrough NATs) becomes qualified (active) even in situations where theMicrosoft documentation says it should not be. At least four Microsoftweb pages [3,4,5,6] have descriptions that are similar to:

"The Teredo component is enabled but inactive by default. In orderto become active, a user must either install an application that needsto use Teredo, or configure the advanced settings on a Windows Firewallexception to use edge traversal."

The clear implication is that the user must do something special(install an Teredo-dependent application or change firewall settings)for Teredo to be used. So, in an out-of-the-box installation, itshouldn't be used, right? Well, that is not what we found (see AppendixXXVII of our report). Teredo automatically became active shortly afterVista was installed and Teredo automatically became active duringWindows Activation. There may also be other circumstances that activateTeredo, but these were the only two times this particular host was anInternet-connected network. Another reason Microsoft's documentation isclearly wrong is that if you do a "ping -6 " onVista, Teredo will become qualified if Teredo is needed for IPv6Internet access and if Teredo can get set up properly. Ping.exe ispresent in standard Vista installs. We hope that Microsoft resolvesthis documentation (or behavior) problem.

Whether Teredo is qualified or not is significant because of the security implications we describe in The Teredo Protocol: Tunneling Past Network Security and Other Security Implications[2].In addition to what the CVE makes reference to, in Appendix XIII-A of[1] we call for more clear documentation on the circumstances underwhich Teredo will be used in preference to native IPv4.

Okay, enough on that topic. On to a briefer review of the othereight CVE numbers. The appendix numbers below refer to appendices in[1].

CVE-2007-1533.This is a Teredo issue we discuss in Appendix XIII-K.. In subsequentsetup (qualification) communication with its Teredo server, the VistaTeredo client will use the same nonce as it used the first time. Thismakes things simpler for the client but slightly increases the chanceof spoofing the nonce since there is a longer opportunity to trydistinct nonces in a brute force attempt, and since there is moreopportunity to observe the nonce in transit. The nonce is used toverify that the reply from the server matches the request and hence isan anti-spoofing measure.

CVE-2007-1534.The CVE description makes this sound more significant than it is.DFSR.exe becomes active and listens on TCP port 5722 (IPv4 and IPv6)during Windows Meeting Service (WMS) and there is approximately a twominute delay in it shutting down after WMS is shut down. This meansthat instead of DFSR being exposed for 60 minutes during a 60 minuteWMS session, it is exposed for approximately 62 minutes, which isslightly longer than the user would expect.. This exposure istheoretically useful to an attacker. This wouldn't matter except thatthe Windows Firewall rule that allows access to the port is one of the"sticky firewall rules" we describe in the report. For more informationsee Appendix XXI-D.4.

CVE-2007-1531.As with XP, in Vista if an ARP message is forged so that it appearsanother host has the same IPv4 address as the Vista host, the networkinterface will become unusable until reset. We have found this to bethe case at least for statically configured addresses. The CVE alsoseems to refer to our discovery that Vista will allow unsolicited ARPmessages to update existing ARP table entries, which can be used as adenial or service or to redirect traffic. Microsoft has tightened thecircumstance under which this attack can take place since betabuilds[7]. Both of these require access to the subnet, are not novel,and have limited solutions available. These two issues also seem to becovered by CVE-1999-0667. (Appendix V.)

CVE-2007-1532.With IPv6, the functions that were performed by ARP in IPv4 are handledby the Network Discovery Protocol (NDP). It is documented (RFC 3756)that ordinary neighbor discovery is susceptible to cache poisoningattacks to cause a denial or service or redirect. SEND (SEcure NeighborDiscovery, RFC 3971)is designed to prevent this, although it is not available in Windows.Any attack requires subnet access and we document what types of attacksare possible under Vista in Appendix VI.

The last four relate to the new Link Layer Topology Discovery (LLTD)protocol, which is used in Vista to draw network topology maps. Thisprotocol sits directly on top of Ethernet, so an attack would have tohave access to a victim's local subnet to do any attacks, a significantlimitation. In addition, most of these only affect what is displayed tothe user, which narrows the possible usefulness to an attacker. Thatsaid, there appear to be things that Microsoft can do to mitigatethese. We note in the report that we last examined Vista's LLTDimplementation in the 5472 build, which was a Beta 2 stage build. We donot know if the following still apply in release Vista.

CVE-2007-1527."Spoof and Management URL IP Redirect" attack (Appendix III-K). It ispossible to cause a fake node to appear on the Vista network map.Moreover, it is possible for the attacker to mark the node as having aweb configuration interface. If the user uses the network map as alaunching point for device configuration, they could be directed to theattacker supplied host, which could be on the Internet. Whileinteresting, there seem to be limited circumstances where this would bea worthwhile attack to conduct.

CVE-2007-1528."Spoof on Bridge" attack (Appendix III-L). It is possible to spoof ahost to make it appear nearby on the network map (on the same bridge).

CVE-2007-1529."Total Spoof" attack (Appendix III-M). If a race condition is met, itis possible to have incorrect details appear on the network map insteadof a host's real information.

CVE-2007-1530.During our testing, there were several ways to cause the networkmapping to fail. We document one of these in Appendix III-N, and theCVE makes reference to this.

On a separate note, in two weeks time I will be presenting [1] and[2] at CanSecWest in Vancouver. Looks like there is a good lineup yetagain this year; I hope to see you there.

Further Reading:
[1] Windows Vista Network Attack Surface Analysis

[2] The Teredo Protocol: Tunneling Past Network Security and Other Security Implications

[3] Microsoft: Teredo Overview

[4] Microsoft: Enterprise Networking with Windows Vista

[5] Microsoft: New Networking Features in Windows Server "Longhorn" and Windows Vista

[6] Microsoft: Using IPv6 and Teredo

[7] Windows Vista Network Attack Surface Analysis: A Broad Overview (this edition covers beta builds)

More research papers about Windows Vista security can be found at:
http://www.symantec.com/enterprise/theme.jsp?themeid=vista_rese