On Fri, Jul 04, 2003 at 10:43:42PM +0400, kuznet@ms2.inr.ac.ru wrote: > > > The network 10.10.10.0/24 is the trusted network T. Any packets > > with source addresses in T via the ESP tunnel are genuine. > > What does make it "trusted"? I do not see any references to this > subnet in the description. It is not wonderful that such trusted > network turns out to be untrusted eventually. :-) T is trusted in the sense that our security gateway 192.168.0.1 uses whatever means necessary to make sure that any packet with a source address from T really is from T. For example, it can do this by establishing an IPsec SA to each host in T. > Despite of ironical comments above, I understand that it is real > source of pain. OK, let's split the problem: > > 1. Enforcing single subnet selector on SA is evil. Agreed and ready > to accept any solution for this, including even your one, despye of > it is very indirect. That's actually the least of my concerns :) It's really the tunnel hijacking that I'm worried about. > 2. That T subnet... I do not understand, if it is "trusted", you have > some policy for this which asserts this trust. How could spoofed > packets pass through this policy? OK, I forgot to restate how the spoofed packets pass through. Recall that we have two inbound policies, arranged in this order: 10.10.0.0/16 -> 192.168.0.178 ESP tunnel from 192.168.0.1 -> 192.168.0.178 10.0.0.0/8 -> 192.168.0.178 IPCOMP tunnel from 10.10.0.1 -> 192.168.0.178 ESP transport from 10.10.0.1 -> 192.168.0.178 ESP tunnel from 192.168.0.1 -> 192.168.0.178 Notice that if the second tunnel was not there, we can trust packets from T because by assumption 192.168.0.1 has established their identity. However, with the second tunnel present, that trust is violated because we have used a tunnel to bypass any check that 192.168.0.1 has done. For example, suppose that the evil host 10.10.20.30 can send packets with the source address 10.10.0.1. This is possible since 10.10.0.1 is outside the trusted network T and consequently 192.168.0.1 does not guarantee the validity of its source address. It can then send IPCOMP packets to 192.168.0.178 with the inner source address belonging to the trusted network 10.10.10.0/24, e.g., 10.10.20.30 can cause this packet to be sent: outer address: 10.10.0.1 -> 192.168.0.178 IPCOMP encapsulation/IPIP encapsulation inner address: 10.10.10.1 -> 192.168.0.178 This passes the __xfrm_policy_check function because: 1. There is only one SA in the security path. Its selector is 10.0.0.0/8 -> 192.168.0.178 which contains 10.10.10.1 -> 192.168.0.178. 2. The policy check passes as well because it matches the first policy which only requires the ESP tunnel from 192.168.0.1. That tunnel is present by definition. To summarise, this breach of security occured because we're allowing packets to add extra SAs on top of the ones prescribed by the policy. And those SAs happen to be tunnel SAs with no authentication, i.e., IPCOMP SAs. -- Debian GNU/Linux 3.0 is out! ( http://www.debian.org/ ) Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt - : send the line "unsubscribe linux-net" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
