I assume that this would have to be a "crafted" packet since, as you say, it would be awfully strange to see normal traffic matching this description.
For example, assume I created the following packet: [ethernet header] + 46 data bytes + 4 byte crc = 64 byte packet Normal IP total length = 46 bytes (20 byte header + 26 bytes of data) Now I forge the total length field in the IP header and change it to say the IP packet is actually 100 bytes long instead of only 46 bytes. This bug would cause the router to give me 54 bytes of previous packet data. I could expand this to "capture" up to 1500-46 = 1454 bytes of possibly useful data from previous packets. (there are programs that allow you to create packets in any way you want, such as those at http://www.packetfactory.net) In order for this to be really useful though, the attacker would have to have a way of viewing those packets after they transit the router, which implies that they can establish valid conversations through the router in question back to a host they have access to view the packets on. (or something listening on the other side of the router for them) Regards, Kent -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Priscilla Oppenheimer Sent: Thursday, February 28, 2002 10:58 AM To: [EMAIL PROTECTED] Subject: Re: Another Security Advisory [7:36823] This is awfully strange. When would the "packet length described in the IP header be larger than the physical packet size?" I've never seen such a thing. If what they are really trying to say is that the packet must go out on a data-link that has a minimum size and thus must be padded, then the description of the problem makes sense. I've seen that. For example when IP has a packet to send that is shorter than the Ethernet 64-byte minimum, then padding is required. And I have seen security issues with this. I have seen hosts (not routers though) pad with left over data that was sensitive. (I saw a password in the Ethernet pad once!) OK, I've typed enough to avoid the GroupStudy bug that filters URLs at the beginning of messages. I really wanted to say that the URL in the original message got chopped. The URL to the security advisory is: http://www.cisco.com/warp/public/707/IOS-CEF-pub.shtml Priscilla At 12:38 PM 2/28/02, Kaminski, Shawn G wrote: >Here's another one: > >Cisco Security Advisory: Data Leak with Cisco Express Forwarding Enabled > >Revision 1.0 > >For Public Release 2002 February 27 08:00 (UTC -0800) > >- ------------------------------------------------------------------------- - > >Summary >======= > >All Cisco devices running Cisco IOS(r) and having Cisco Express Forwarding >(CEF) enabled can leak information from previous packets that have been >handled by the device. This can happen if the packet length described in the >IP header is bigger than the physical packet size. Packets like these will >be expanded to fit the IP length and, during that expansion, an information >leak may occur. Please note that an attacker can only collect parts of some >packets but not the whole session. > >No other Cisco product is vulnerable. Devices that are having fast switching >enabled are not affected by this vulnerability. > >The workaround for this vulnerability is to disable CEF. > >This advisory is available at the http://www.cisco.com/warp/public/707/ > >IOS-CEF-pub.shtml. > >Affected Products >================= > >All Cisco IOS releases that are supporting CEF are vulnerable. In order to >trigger this vulnerability CEF or dCEF must be enabled on the device. The >vulnerable Cisco IOS releases are (this is not an exhaustive list): > > * 11.1CC > * 12.0, 12.0S, 12.0T, 12.0ST > * 12.1, 12.1E, 12.1T > * 12.2, 12.2T > >No other Cisco products are affected. > >Details >======= > >When a router receives a packet where MAC level packet length is shorter >than is indicated by the IP level, the router will "extend" the packet to >the size indicated by the IP level. This extension will be done by padding >the packet with an arbitrary data. The issue here is that padding may >contain data from a previous packets that has not been erased. > >Although it is possible to trigger this vulnerability on command, it is not >possible to predict what information would be collected this way. It is not >possible for an attacker to selectively capture desired packets (for >example, packets with username and password combination). > >This vulnerability is specific to CEF. Fast switching is not affected by it. > >This vulnerability is documented as Cisco Bug ID CSCdu20643. For the Cisco >IOS 11.1CC image, this vulnerability is described as Cisco Bug ID >CSCdp58360. > >Impact >====== > >By sending malformed packets, and capturing them after they have been >processed by CEF, an attacker may find a remnants of a previous packets in >them. The remnant data may contain whatever the previous packet has carried. >That may be parts of a document, mail or any other content. > >Note that in an interactive session such as typing a password, characters >are sent one by one in separate packets. That drastically lowers the >probability that all packets will be captured. In addition, it is almost >certain that typed characters will be overwritten by the contents of the >attacking packets. > > >Shawn G. Kaminski >EDS Network Engineering - DowNET ________________________ Priscilla Oppenheimer http://www.priscilla.com Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=36842&t=36823 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
