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

To: mail,AT,oripessach,DOT,com
Subject: Re: CRC32 - thoughts on Gutmann response
From: Damion Wilson <dwilson,AT,ibl,DOT,bm>
Date: Thu, 25 Sep 2003 19:38:32 -0300
Cc: cipe-l,AT,inka,DOT,de
In-reply-to: <3F7338CE.10801@oripessach.com>
References: <6933.1064509792@persephone.cfrq.net> <200309251220.39215.rsmckown@yahoo.com> <3F7338CE.10801@oripessach.com>

What do you mean "lack of response" ? There are two implementations of CIPE, 
of which at least one of the maintainers has responded (me). I'm doing so 
much email right now that I've had to stop programming.

Seriously, though, I think that we should give Olaf the benefit of the doubt 
right now. And later, if he's no longer able to be involved in this, then 
maybe we make CIPE a bazaar-style development project, with a separate 
protocol group so the real crypto people can bang their heads against it.

Believe me, I'm paying very close attention.

DKW

On Thursday 25 September 2003 03:49 pm, Ori Pessach wrote:
> 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 cipe-l,AT,inka,DOT,de mailing list.
> Unsubscribe: mail majordomo,AT,inka,DOT,de, "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>


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