Re: CRC32 - thoughts on Gutmann response

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 255.255.255.255, 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


--
Message sent by the [email protected] mailing list.
Unsubscribe: mail [email protected], "unsubscribe cipe-l" in body
Other commands available with "help" in body to the same address.
CIPE info and list archive: <URL:http://sites.inka.de/~bigred/devel/cipe.html>