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.