On Thursday 25 September 2003 12:49 pm, Ori Pessach wrote:
> R. Steve McKown wrote:
> > The ssh exploit relies on an established ssh connection ... [snip]
>
> 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.
Yeah, bridging is a nightmare; glad we don't use that CIPE protocol. UDP or
other protocols that don't have good message reliability look to be pretty
suspect as well. A host of DOS strategies would be effective, perhaps even
the recent low-bandwidth TCP DOS:
http://portal.acm.org/citation.cfm?id=863966&jmp=references&dl=ACM&dl=ACM
If there's a way to find 16 bytes of plaintext, it appears all of these --
and
more! -- are available for the network admin's displeasure.
BTW, we run a deny-by-default firewall ruleset on the traffic crossing the
tunnels, so we really constrain the tunnelled traffic. Not a perfect
beachhead, because important servers are those that have to be accessed
across the tunnel! But constrained rules and effective use of netfilter
modules like limit, recent, et. al. might provide some measure of breathing
room to correctly resolve the CIPE problem.
> [snip] The lack of
> responsiveness from the maintainers really worries me, ...
Yes. No maintenance for CIPE makes all other arguments moot. I'm hopeful
Olaf jumps in soon, and a few others on this list seem ready to dive in as
well. CIPE has some great benefits, and I'd like to see it stay viable.
> ... as is the general
> "it's good enough, and prove me wrong by showing me the exploit!"
> attitude shown here.
It might be closer to say my attitude is "please help me understand the facts
and their ramifications." Generally, my bad decisions have been due to a
lack of information or a poor understanding of the information. This is day
three, and in my case I think it prudent to get a more comprehensive
understanding of the nature of the problem before making a change. Also, for
larger networks, change will (should) take time and more understanding will
yield better "stopgap" measures while changes can be implemented. I respect
the fact that others are in different situations, where additional
understanding or information doesn't change their decision equation.
> I don't buy the argument that because Gutmann uses
> foul language his opinion shouldn't be taken seriously.
Neither do I. This is very serious stuff, which is why it is even more
important to be thoughtful in decision processes. And keep in mind that
those of us with imperfect understanding can't always factually qualify
assertions made by an expert. In these cases, it is common to attempt to
assess bias and agenda in the 'assertee'. This understanding can help
separate opinion from fact, which is very hard for a layman to accomplish
under the best of circumstances.
And yes, before you say it, I agree its an extremely faulty approach. This
is
why experts tend to be very careful about how they present information, and
why I value your input, as well as insights from Jake, Eric, Allen, and
everyone else on this list. It's great to see such an honest and open
exchange of information.
Thanks!
Steve McKown
Titanium Mirror, Inc.