The original Etherleak paper which was written by myself and Josh Anderson specifically states that:
"The Ethernet standards impose strict limitations on the size of encapsulated packets,
requiring small packets to be padded up to a minimum size. Many device drivers
responsible for Ethernet frame generation incorrectly handle the padding of small
packets. They use data from the end of the frame manipulation buffer without initializing
it to zero as required by the RFCs. The location of the buffer containing the frame
determines the contents of the padding bytes."
Sure, the examples were given with ICMP echo requests and replies, but this does not implicate that it is restricted to these type of packets only. Further more, in another email we have sent to bugtraq shortly after (http://www.sys-security.com/archive/papers/ More_information_regarding_Etherleak.txt) we specifically stated that:
"You need to send packets which are less than 46 data bytes long (the minimum
packet size) to examine if you experience this vulnerability with your Ethernet
card and device driver. Any packet less than 46 data bytes long would do the
trick..."
The nice thing about your advisory is that Microsoft now digitally signs the device drivers.
Sincerely yours,
Ofir Arkin Founder The Sys-Security Group http://www.sys-security.com 8AE6 E481 8901 8A78 21EC 6639 AD37 5422 1844 EA00
On Monday, June 9, 2003, at 03:40 PM, NGSSoftware Insight Security Research wrote:
NGSSoftware Insight Security Research Advisory
Name: Etherleak information leak in Windows Server 2003 drivers Systems Affected: Windows Server 2003 (all versions) Severity: Low/Medium Risk Vendor URL: http://www.microsoft.com/windowsserver2003/ Author: Chris Paget (chrisp@ngssoftware.com) Date: 9th June 2003 Advisory URL: http://www.nextgenss.com/advisories/etherleak-2003.txt Advisory number: #NISR09062003
Description *********** Several NIC device drivers that ship with Windows Server 2003 have been found to disclose information in a similar way to the 'Etherleak' frame padding issue announced by @Stake in January 2003. The original Etherleak paper and subsequent discussion was concerned with ICMP message padding; NGSSoftware Insight Security Research (NISR) have observed a similar issue within a TCP stream.
Details
*******
The original Etherleak paper from Ofir Arkin and Josh Anderson of
@Stake (available at
http://www.atstake.com/research/advisories/2003/ atstake_etherleak_report.pdf)
concerns itself primarily with frame padding of ICMP messages with
non-zero bytes; the padding bytes could potentially come from any area
of physical memory. NISR have observed the issue within a TCP stream,
particularly during the FIN-ACK exchange when a connection is
gracefully closed. To date, NISR have not seen any discussion of
Etherleak-style vulnerabilities within a TCP stream, only ICMP. It is
possible that vendors are only testing for ethernet frame padding
issues within ICMP and are neglecting TCP.
When the @Stake paper was released, Microsoft stated that tests would be added to the Microsoft driver certification program which specifically checked for this issue; NISR are releasing this advisory since there are multiple drivers shipped with Windows Server 2003 which are vulnerable and yet certified by Microsoft and included on the CD.
Vulnerable drivers include: VIA Rhine II Compatible network card (integrated into some motherboards). AMD PCNet family network cards (Used by several versions of VMWare)
Both drivers are digitally signed by the Microsoft Windows Publisher, and are included on the Windows Server 2003 CD. Both drivers exhibit the same behaviour, that of padding frames with arbitrary data. The FIN-ACK packets exchanged during the graceful close of a TCP connection are a particularly good source of information; several bytes of potentially sensitive data (including POP3 passwords) has been observed appended to the data portion of Ethernet frames sent by these cards.
Fix Information *************** Microsoft's statement regarding this issue on the CERT website (available at http://www.kb.cert.org/vuls/id/JPLA-5BGP7V) states: "Microsoft does not ship any Microsoft written drivers that contain the vulnerability. However, we have found some 3rd party drivers and samples in our documentation that, when compiled without alteration, could yield a driver that could contain this issue. We have made corrections to the samples in our documentation and are working with 3rd parties, and have included tests for this issue in our driver certification program."
Since some network drivers that are certified by Microsoft in their latest release of Windows are still exhibiting these issues, NISR recommends that Microsoft certification is not taken as a guarantee of comprehensive testing. Instead, a list is provided by CERT at
http://www.kb.cert.org/vuls/id/412115 of all related hardware and software vendors; we would recommend that customers refer to this list for the specific hardware vendor to determine exposure to this issue. Alternatively, contact the vendor of your networking hardware for further information.
About NGSSoftware ***************** NGSSoftware design, research and develop intelligent, advanced application security assessment scanners. Based in the United Kingdom, NGSSoftware have offices in the South of London and the East Coast of Scotland. NGSSoftware's sister company NGSConsulting, offers best of breed security consulting services, specialising in application, host and network security assessments.
http://www.ngssoftware.com/ http://www.ngsconsulting.com/
Telephone +44 208 401 0070 Fax +44 208 401 0076
enquiries@ngssoftware.com
