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

Subject: Re: New Peer when IP changes?
From: Saint skullY the Dazed <skully,AT,netlsd,DOT,org>
Date: Wed, 30 May 2001 20:49:46 +0200
In-reply-to: <20010529195352.B24954@netlsd.org>

That's a good temporary fix, but it doesn't address the problem, only
hides it. 

I can see where some would consider this a feature, but the more paranoid
(myself included) would consider it a bug. It looks like the offending code
is the checkpeer function on line 170 of cipe/sock.c. Maybe put a #ifdef 
around that function and have another that doesn't update the peer, and 
then an option to configure to choose? I could do it myself in an hour
or two, but alas, I'm a sysadmin and not a programmer and my change would
be sloppy and ugly and could probably be done a lot better by someone else.

-skullY

On Wed, May 30, 2001 at 09:13:54AM -0700, ewheeler,AT,kaico,DOT,com wrote:
> Skully --
> 
> You might try to deny all incomming udp packets destined for the CIPE port
> unless they come from a specific IP.  I realize that UDP is relativily
> easy to spoof, but that would at least reduce your exposure from anyone
> with your key having access to your cipe tunnel to only those people on
> your circuit having access to your cipe tunnel (who, of course, also had
> your key).
> 
> --Eric
> 
> On Tue, 29 May 2001, Saint skullY the Dazed wrote:
> 
> > Hi. I have a tunnel setup between my home and work using two 
>slackware-current
> > machines, with linux 2.2.19 and cipe 1.5.2. When I initially set this up, 
>I
> > was on a DSL connection with a fixed, real IP. However, I canceled my DSL
> > line and am on a dialup connection again, with only one IP for my network
> > at home. The machine runnung cipe at home sits behind an OpenBSD box doing
> > NAT.
> > 
> > I establish the tunnel using pkcipe, so I don't have to worry about 
>setting 
> > up remote and peer IP's each time. However, I've noticed that if I 
>disconnect
> > and reconnect the modem (Thus getting a new IP) cipe will happily switch 
>to 
> > using the new peer *without* having to rerun pkcipe, even though the IP 
>and 
> > port are completely different, the only thing the same is the key. This 
> > distresses me greatly as it means that if anyone gets the key for that 
> > session, they can take control of my cipe tunnel.
> >   
> > The options file that pkcipe wrote for the work machine, which has a 
> > dedicated, real IP:
> > 
> > root@coffin:/var/run/cipe# cat margin
> > arg=margin
> > peer=216.27.191.139:1025
> > me=63.207.125.198:1042
> > ptpaddr=172.18.0.18
> > ipaddr=172.18.0.17
> > key=XXXXXX
> >  
> > The same on my home machine:
> > 
> > root@margin:/var/run/cipe# cat coffin
> > arg=coffin
> > peer=63.207.125.198:1042
> > me=216.27.191.139:1025
> > ptpaddr=172.18.0.17
> > ipaddr=172.18.0.18
> > key=XXXXXX
> > 
> > The 216.27.191.139 was the address used on DSL (I'm still using those IPs,
> > they're just nat'd). From syslog on my work machine, I find the following:
> > 
> > May 29 20:00:26 coffin kernel: cipcb1: new peer 198.144.204.31:10004
> > May 29 20:00:26 coffin kernel: cipcb1: cipe_sendmsg
> > May 29 20:00:26 coffin kernel: cipcb1: cipe_recvmsg
> > May 29 20:00:26 coffin kernel: cipcb1: cipe_sendmsg
> > May 29 20:00:26 coffin kernel: cipcb1: setkey
> > May 29 20:00:26 coffin kernel: cipcb1: cipe_recvmsg
> > May 29 20:00:26 coffin kernel: cipcb1: setkey
> > May 29 20:00:26 coffin kernel: cipcb1: cipe_sendmsg
> > May 29 20:00:26 coffin kernel: cipcb1: cipe_recvmsg
> > May 29 20:00:27 coffin kernel: cipcb1: cipe_sendmsg
> > May 29 20:00:27 coffin kernel: cipcb1: setkey
> > 
> > Grepping for "new peer" I find the following:
> > 
> > May 29 09:49:13 coffin kernel: cipcb1: new peer 205.162.106.244:10000
> > May 29 20:00:26 coffin kernel: cipcb1: new peer 198.144.204.31:10004
> > May 29 20:20:51 coffin kernel: cipcb1: new peer 198.144.204.31:10005
> > May 29 20:42:49 coffin kernel: cipcb1: new peer 198.144.204.31:10006
> > 
> > (I assume the new ports are from nat timing out the connection and 
>assigning
> > a differant port for that udp "connection")
> > 
> > I did not bring the connection down or rerun pkcipe between either 
>disconnect.
> > 
> > Needless to say, this is quite a problem. Should a weakness be found in 
> > cipe's implementation of blowfish or pkcipe's RSA implmentation, an 
>attacker
> > can easily take over my stream, or cause two machine to fight for it, 
> > which makes a pretty effective DoS. Perhaps cipe should be changed so it
> > only accepts packets for that device from the ip in the peer field?
> > 
> > And please, before anyone flames me, I realise that the keylength used is 
> > 320 bits, which is not trivial to brute force. However, having cipe not
> > renegotiate peer to a different IP is trivial, and is just a little more 
> > protection in the event that weaknessness are found either in the 
>underlying 
> > crypto or in cipe's implementation of the crypto.
> > 
> > --
> > 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>
> > 
> 





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