"R. Steve McKown" <rsmckown,AT,yahoo,DOT,com>|
Re: CRC32 - thoughts on Gutmann response|
Damion Wilson <dwilson,AT,ibl,DOT,bm>|
Thu, 25 Sep 2003 19:33:38 -0300|
<firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org>|
I certainly don't know.
This is part of the problem with Gutmann's purely theoretical approach. He
didn't have to do any real research and thus hasn't provided real exploits.
In a sense, he's provided us with half the help we would need to make things
better, which is ok except for the tone of his first posting. From his
perspective, that's alright because we're so small a community that it was
even plausible to consider us "dead" or quiescent.
Maybe we should engage in attacking the protocol ourselves, using our
knowledge and Peter Gutmann's assertions as starting points.
On Thursday 25 September 2003 03:20 pm, R. Steve McKown wrote:
> 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
> I think I understand the basis of the CRC-32 weakness:
> 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
> 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.
> 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: