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

To: cipe-l,AT,inka,DOT,de
Subject: Re: CRC32 - thoughts on Gutmann response
From: "R. Steve McKown" <rsmckown,AT,yahoo,DOT,com>
Date: Thu, 25 Sep 2003 12:20:39 -0600
In-reply-to: <1064510902.7652.115.camel@monster.omnifarious.org>
References: <6933.1064509792@persephone.cfrq.net> <1064510902.7652.115.camel@monster.omnifarious.org>

On Thursday 25 September 2003 11:28 am, Eric M. Hopper wrote:
> On Thu, 2003-09-25 at 12:09, Harald Koch wrote:
> > [ Finally, a technical discussion! >:]
> >
> > > I am however pleading for a reasonable view - if you are clever enough
> > > to toggle bits in the CRC and the IP length and IP csum and the TCP
> > > csum and still keep the TCP stream in step then there are any number of
> > > three letter agencies who would employ you immediately!
> >
> > This doesn't require any cleverness these days; the detailed techniques
> > are all published. A little research with Google and some C programming
> > knowledge are all that is required...
>
> And the worst part is, once someone figures out how, they just write a
> little program, and suddenly every idiot knows how.  You have to assume
> that any vulnerability, no matter how tiny, will be quickly found out
> and exploited by all possible attackers.

Granted.  What I'm looking for now is the definition of "quickly" and 
"exploited".

I think I understand the basis of the CRC-32 weakness:
http://honor.trusecure.com/pipermail/firewall-wizards/1998-June/002845.html

But I can't yet logically follow the assertion that because CRC-32 was shown 
to be exploitable in ssh that CIPE is therefore also exploitable because it 
uses CRC-32.

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.

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.

Can someone tell me what I'm missing that would make clear the connection 
between CIPE's CRC-32 weakness and a possible exploit?

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).

All the best,
Steve McKown
Titanium Mirror, Inc.


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