<< | Thread Index | >> ]    [ << | Date Index | >> ]

To: "R. Steve McKown" <rsmckown,AT,yahoo,DOT,com>
Subject: Re: CRC32 - thoughts on Gutmann response
From: Ori Pessach <mail,AT,oripessach,DOT,com>
Date: Thu, 25 Sep 2003 12:49:50 -0600
Cc: cipe-l,AT,inka,DOT,de
References: <6933.1064509792@persephone.cfrq.net> <1064510902.7652.115.camel@monster.omnifarious.org> <200309251220.39215.rsmckown@yahoo.com>
Reply-to: mail,AT,oripessach,DOT,com

R. Steve McKown wrote:
The ssh exploit relies on an established ssh connection into which an attacker injects a packet that the server processes via the shell process connected to the session's socket. The exploit doesn't allow directly for packets to be decryptable by the attacker; it doesn't need to since it need not 'see' server response data to execute an arbitrary command. Since CIPE tunnels IP packets "router to router", wouldn't the exploit have to inject a complete TCP packet would successfully be injected into an established TCP connection terminating at an application that could then be exploited? This sounds *hard*, since the exploit doesn't allow the attacker to view plaintext packets to try to find an existing TCP session within the tunnel to hijack.

What about injecting spoofed UDP packets? That should be much easier. What about ARP? ICMP? Since CIPE can be an ethernet bridge, being able to inject anything to your network (which normally would be behind a firewall) can be very harmful. If there's anything on your network that can be compromised by a hand crafted UDP packet with a destination address of, CIPE can theoretically be exploited to inject such UDP packets to your network.

It seems attacking management packets is more likely to be doable. Gutmann alluded to key weakness in 3DES and IDEA, but since we use Blowfish (don't most of us anymore?) I can't make the connection here. Also, I'm not sure how readily 16 bytes of known plaintext can be determinable in these packets.

The danger, as I understand it, is in an attacker forcing a CIPE tunnel to use modified keys, or compromised keys. The example given, of weak keys, just serves to illustrate the worst case scenario. Since we're lucky, we don't use 3DES or IDEA. Still, the problem seems real.

I'm not suggesting that CIPE is not vulnerable; there seems ample evidence to show changes are warranted. What I'm trying to understand is the level of exposure, which for me translates into how long I can/should allow my customers to continue to use CIPE before making a change (either to a revised CIPE or something else).

I'm using CIPE right now, and I plan to make the change as quickly as possible. You can't assume that nobody knew about these problems and tried to exploit them until Mr. Gutmann found them. The lack of responsiveness from the maintainers really worries me, as is the general "it's good enough, and prove me wrong by showing me the exploit!" attitude shown here. I don't buy the argument that because Gutmann uses foul language his opinion shouldn't be taken seriously.

-Ori Pessach

<< | Thread Index | >> ]    [ << | Date Index | >> ]