Damion Wilson <dwilson,AT,ibl,DOT,bm>|
Re: CRC32 - thoughts on Gutmann response|
"R. Steve McKown" <rsmckown,AT,yahoo,DOT,com>|
Thu, 25 Sep 2003 19:29:21 -0600|
<firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org>|
On Thursday 25 September 2003 04:33 pm, Damion Wilson wrote:
> 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.
Well said, for a dead guy. Then again, I'm dead too... Is this heaven? ;^)
> Maybe we should engage in attacking the protocol ourselves, using our
> knowledge and Peter Gutmann's assertions as starting points.
I think the security of the installed base should be the first priority. I'm
for anything that identifies and addresses issues on a fast track to minimize
the window of exposure for our installed tunnels. I'm not qualified to
evaluate crypto risk or alternatives, but I'm ready to volunteer for testing
or other similar tasks.
All the best,
Titanium Mirror, Inc.
> 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
> > "exploited".
> > I think I understand the basis of the CRC-32 weakness:
> > http://honor.trusecure.com/pipermail/firewall-wizards/1998-June/002845.ht
> > 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.
> > --
> > 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>