IPv6 enables the 'hierarchicalness', but presumably doesn't necessarily enforce it. Hell, if necessary you can ignore the top 64 bits and just use the host id, and deal with 'routing' at L2. That's no worse than IPv4, and you've got another 8 bits of address.
And there's Mobile IPv6, which still feels a little hacky, but seems better intergrated than IPv4.
Off to watch the Van Jacobson video mentioned elsewhere in this thread..
But, seriously... Why are you running services that require a firewall? Don't they do their own connection management?
It's a fair point, actually.
Originally, there were a handful of services running on any given box, and we just made sure we configured each one properly. It was bit of a pain, particularly as config file formats weren't standardized, but inetd and hosts.{allow,deny} made it bearable.
But then when the number of different services and platforms being deployed increased, we began to worry about the possibility of incorrect configurations slipping through the net - particularly on certain platforms (*cough*) where it wasn't easy / possible to lock down system services, or automate that with existing tools.
Hence, the firewall: originally basically just a way of sticking access control rules for network services in one place (either on a single host, or for a whole (sub)net) -- and dropping a few types of badly formed packets along the way.
The problem is, firewalls have become an object of near-religion devotion, accompanied by a loss of understanding of what they really do and why we need them. Dan Kaminsky's been banging on (since before the recent DNS stuff) about how you can't trust the 'local' network any more. And I think he's right. We need to secure the hosts, and secure the protocols, and drop the pretence that firewalls are much of a defence against modern attacks.
(Note: IP spoofing is, IMO, a slightly different issue. Configuring your routers to drop packets that can't be coming from where they say they are is rather orthogonal.)
IPv4 NAT is quite a nice fit for the issue of dealing with lots machines with dubious security wanting to run 'simple' protocols, in a world with limited public addresses available.
Having said that, at least part of the perceived "niceness" is psychological: it puts a real system boundary right at the point where one feels there's a trust boundary (the edge of the local network.) And it's beginning to look (according to Dan Kaminsky, amongst others, and not just since the recent hysteria) like that feeling of security is misplaced.
When I was at uni, all the workstations (at least the *NIX ones - I never touched our one Windows lab) had public IP addresses. We never had any security issues as a result, to the best of my knowledge. It's just a question of securing the configurations (using centralized management, diskless workstations, or whatever) and applying patches.
NAT also makes running non-trivial stuff complicated. P2P. VOIP. 'Push' technologies (if the client has to keep a connection open to the server, that's not really 'push'.) Remote access, generally. Look at the hoops things like Teredo have to go through to deal one or two layers of NAT. Now try to imagine how that scales..
And anyway, just because (in a theoretical future IPv6 utopia) we're not doing address substitution any more, doesn't mean we can't still have firewalls. ip6tables exists for Linux, and I'm sure the router manufacturers all have their solutions. It's still only one or two rules of config to drop incoming connections, if that's desired.
Oh, and regarding toasters: i'm not sure that's the issue;-) It'll be giving things like mobile phones, iPods and cars IP addresses and running P2P apps between them, I'm guessing.
Don't forget the bottom 64 bits of an IPv6 address are the host address, so a router won't have to worry about those much until it comes to the last hop.
Also, easy renumbering (if it happens) should also allow more 'hierarchicalness' in addressing, -> shorter routing tables -> cheaper / faster routing. To be fair, ease of renumbering is at least theoretically orthogonal to address size, but autoconfig is being 'bundled' with IPv6 in a way it never has been with IPv4.
You're right, DNS isn't trustworthy, so not only should we not use hostnames when configuring systems, we should train our users not to use them either.
Honestly, we have to fix DNS. Even if your hardcoded literal IPv4 addresses are secure (and are they? If I can own your internal authoritative DNS server, there's a good chance I can spoof ARP, or bugger around with DHCP, or exploit that SNMP vulnerability that was kicking around recently..), there are quite a number of ways (start at slide 45) to steal all your users' data if DNS is vulnerable..
Learning new stuff is a PITA, especially if the old stuff still appears to be working well, but sometimes preemptive action saves pain in the long run. Ultimately IPv6 should result in a reduction in complexity, and that's almost always a good thing..
I guess we need to make it trustable, then. I know he presented lots of very clever attacks in his presentation, but an internal query to an authoritative internal DNS server should be pretty safe.
To be honest, even in the IPv4 world, it's not exactly best practice to hardcode IP addresses in the config of network devices, except where unavoidable. Sure, the risk of attacks on internal DNS is real, but the risk of unreliable network service because of byzantine configuration architectures is also real.
I do wonder if we've just crossed a tipping point in technology generally where large numbers of people are beginning to see the advantages of removing unnecessary complexity (or avoiding new complexity.) The popularity of small netbooks running Linux might be evidence of this, as is the general revolt against Vista. If so, all that remains is to convince people that, despite some warts, complexity(IPv6) < complexity(IPv4+lots of bodges).
If I were solving this, I'd suggest separate and non-directly routable IPv4 address spaces for separate countries (and, perhaps, for other entities). And lots and lots of NAT or proxying. Of course that is kind of what is happening anyway.
Eww. Lots of room for bugs and weird feature interaction in the design of protocols that have to punch through NATs, either that or everyone has to role out new helper modules / ALGs each time some wizzy new app is invented.
IPv6 is really a clean-up job. Combing the complexity back out of the network has got to be a win for reliability, ease of administration, and perhaps even security. I'm in favour, though I have to say I'm doubtful about it happening any time soon.
I think the most optimistic scenario is this: when IPv4 exhaustion hits, particularly in countries that have to yet to have their internet 'boom' and so will have a very low number of existing addresses per capita, obviously some sort ISP side NATing is going to be required. People may decide that they might as well implement IPv6 and TRT anyway, particularly if they're deploying new hardware / software combinations (netbooks? set-top boxes?) and so can dictate IPv6-readiness. Hopefully once sufficient numbers of IPv6-only nodes are out there, it'll seem worthwhile rolling out IPv6 on servers.
The alternative, ultimately, is people auctioning off tiny IPv4 address blocks and exponentially bloating routing table sizes, or a horrible twisty unreliable world of multiple NAT or ALGs, where net neutrality is a quaint concept consigned to history..
And yes, printable IPv6 addresses are ridiculous. Admins will have to get used to trusting DNS (or/etc/hosts) when configuring stuff..:)
the Act banned the US making payments to Russia in relation to the ISS if they were seen to be doing this*;
when the shuttle retirement was announced, an exemption was added;
the exemption will run out in 2011;
the Russians are unlikely to do Nasa's work for it if they're not going to get paid;-)
* Not sure why the ISS specifically. Presumably it's some symbolic political thing, the ISS being a demonstration of international cooperation, etc., etc..
The Iran Nonproliferation Act of 2000 (INA) was enacted to help stop foreign
transfers to Iran of weapons of mass destruction, missile technology, and advanced
conventional weapons technology, particularly from Russia. Section 6 of the INA
banned U.S. payments to Russia in connection with the International Space Station
(ISS) unless the U.S. President determined that Russia was taking steps to prevent
such proliferation. When the President in 2004 announced that the Space Shuttle
would be retired in 2010, the Russian Soyuz became the only vehicle available after
that date to transport astronauts to and from the ISS. In 2005 Congress amended INA
to exempt Soyuz flights to the ISS from the Section 6 ban through 2011. It also
extended the provisions to Syria and North Korea, and renamed it the Iran, North
Korea, and Syria Nonproliferation Act (INKSNA).
And in FF3, instead of the colour of the whole address bar giving a fairly large visual clue about SSL use, the colouring seems to be restricted to the background of the site's favicon, which is barely noticeable. A distinct step backwards, AFAICS..
Plus 14 bits of port number (i.e. where in the 48k-64k range it is)
Oops, yes. My bad. Sequentially incrementing port numbers != predictable starting port. To be fair it was early and I was hung over;-)
and 32 bits of IP address. Really.
Think about it: if you have to guess at the transaction ID, that means that you are in a position where you can't see the stub resolver's queries, so you are also not seeing what IP those queries are being sent to or what source ports have been used.
The IP address might be guessable. If you're going to the effort of targeting stub resolvers in the first place, it might not be too much extra effort to whois the IP address and guess the names of the ISP's caching resolvers. (The only situation I can really see this sort of effort being worthwhile is where, say, a particular ISP habitually supplies a particular gateway device, which turns out to have NAT/firewall flaws allowing packet injection into the local network.)
With a recursive resolver using a single port, an attacker can discover and deduce everything but the transaction ID without doing anything but getting the target to resolve some names, while that is simply not the case with a stub resolver.
I'm still not convinced it's impossible, but I'm pretty sure it wouldn't be worth making the effort. There are almost certainly bigger issues.
Regarding DNS design: short of net-wide DNSSEC rollout (ha! We'll see IPv6 transition first..), a medium-term approach might be to start with the assumption that we can't be 100% sure that any individual answer is genuine, but that we can be pretty sure that a sequence of successful spoofing attempts is extremely unlikely. How do we re-engineer caching resolver behaviour (caches are the key target, because of the cascade effect of a successful poisoning on end users) to minimize the amount of trust we place in a single reply packet?
Paul Vixie made some suggestions back in '95 (see 7.2: "What We Would Like To Fix.. Hierarchical Cache.") It might make sense to return additional RRs to the calling stub without caching them, but then setting up another request to grab those names, in order to prime the cache and so minimize network traffic, but at the same time not delaying the first requester's query by too long and only risking returning false information to one client.
I'll admit my grasp on this is a little fuzzy around the edges, I haven't had much experience with DNS guts in the past (I'm hoping Dan Kaminsky's explanation will include some analysis which might clear the waters for me.) The issue as far as I can see it is that the additional RRs, which were originally only needed to solve one specific problem (glue for zone delegation), have been used as a general mechanism to prime caches (e.g. when doing MX record lookups), and so nobody wants to tighten up the processing behaviour of the caching resolvers.
I don't know whether this sort of effort is worth it, a jump to DNSSEC might actually be simpler, and the source port randomization is a good fix for the moment. Network speeds will continue to get faster, however, and I'm sure some people will continue to put nameservers behind NATs that eliminate source port randomness. Also, flaws will presumably continue to be found in random number generators. A bit of further thought might be wise before the next issue crops up..
Well, yes, but for TCP you always have to guess 32 bits of sequence number, whereas for UDP spoofing control has to be implemented at the application layer level. In this case, DNS with sequential serial numbers, we're back to only 16 bits of TXID.
DNS generally runs over UDP, which works slightly differently to TCP. If you send a UDP packet out, and want a reply, you have to listen for that reply, which means you have an "open port", though in the case of DNS, hopefully only to your local network. TCP is connection based and will discard packets which do not appear to part of the connection; UDP isn't and therefore can't.
If someone can inject packets into your local network, they can try to spoof a reply to any queries you make to a recursive DNS server or forwarder (e.g. on your xDSL gateway device.) But if they can do this, you have more substantial security issues anyway. There might be something clever that could be done to attack people who've left their WiFi unsecured, but you'd still need to force them to generate multiple queries for unknown subdomains - perhaps a targetted HTML email with embedded IMG tags? Still sounds like too much work compared to emailing trojans to naive Windows users, unless you happen to work for the security services..
(Incidentally, I'm perilously close to actually installing BIND locally and poking it with a stick to see what all the fuss is about. I haven't gotten my hands that dirty in some time )
(BTW, feel free to drop this conversation if you're fed up with dealing with the hard of thinking and - by this time of the evening - slightly inebriated.)
Of course Mallory's response listed an A record for CXOPQ.VICTIM.COM... and the authority for that record is listed as whatever. In addition to that is the glue that says "Hey, btw, WWW.VICTIM.COM is XYZ." Typically the glue is used to indicate the DNS authority of the information, however that DNS authority can really be anything... WWW.VICTIM.COM for all it matters, they really are free to name their name servers whatever they want.
At this point, we should already be querying (what we think is) an authoritative server. If we're being returned an A record, and not an NS record, why would we process any glue? I thought Paul Vixie fixed this 13 years ago:
The A record returned wouldn't be authoritative, it'd be the same kind of answer that the DNS cache would receive from its parent DNS, or what the end-user's computer would receive from its DNS cache.
But at this point, we should be expecting an authoritative answer for CXOPQ.VICTIM.COM, or a referral with glue, but not a non NS record with glue, surely? Mallory's racing with the authoritative server for the domain we're trying to query..
If you went and asked the authority for confirmation for that address, then there's no reason for the DNS cache.
We're not talking about attacks on stub resolvers.. are we? (You can't poison the cache on a machine that doesn't have one.) The standard situation is that a stub resolver (e.g. Win XP machine) asks an ISP's caching resolver for an address; assuming the answer isn't already cached, the caching resolver figures out the appropriate authoritative server for that zone, and queries it. In the scenario that I think we're discussing, based on ecopeland's post, the attacker races with the authoritative server to get an answer to the caching resolver, and so (somehow) screw over all future clients of that resolver until the TTL expires.
Incidentally, assuming my understanding is close, even if section 5.3 of the Vixie paper hasn't been implemented sufficiently rigorously to prevent this attack (and obviously it hasn't, or there would be no panic), section 7.2 ("What we would like to do.. Hierarchical cache") should nail it. Now, this would be invasive, and so time consuming to test, but it should be penciled in as work to be done after the immediate band-aid has been applied. After all, this is 2008, we all grok Extreme Programming, surely with sufficient testing (unit and otherwise) this could be implemented. Let's face it, sufficiently widespread deployment of DNSSEC is about as likely to happen as IPv6 (sadly)..
"Poisoning CXOPQ.VICTIM.COM is not super valuable to Mallory. But Mallory has another trick up her sleeve. Because her response didnâ(TM)t just say CXOPQ.VICTIM.COM was 6.6.6.0. It also contained Additional RRs pointing WWW.VICTIM.COM to 6.6.6.0."
This is, then, not quite right? Rather Mallory's response would not list an A record for CXOPQ.VICTIM.COM, but instead another delegation, plus glue? There would be no reason to process glue if an authoritative A record response was returned..
Is the fundamental underlying issue merely that it would break too many existing configs if caching resolvers were stricter? I hope Dan Kaminsky's eventual disclosure goes into a bit more detail on this. I'd also quite like to here what DJB has to say.
So ns1 is listed as the server for the subdomain as well, and glue supplied? Why doesn't bailiwick checking apply here as well - only ns1.aaaa.victim.com etc. being allowed?
I'm with Tony Hoyle - I can't (at the moment) see a reason why a query to an (apparently) authoritative server for a subdomain should reasonably be allowed to contain glue for the parent.
Isn't the answer then simply better checking in the recursing resolvers?
If, as a caching resolver, I ask an (apparently) authoritative server for google.com for an A record for xxjk3.google.com, what am I doing processing any returned glue records?
I can think of other tricks, some simple, some more complicated, that might work, but I still don't feel that the whole story's out of the bag here yet -- not that I have a huge problem with that.
I'm hoping to take delivery of a WRT54GL for precisely this reason. I can stick maradns on it, which does its own recursion, keeps an in memory cache, and randomizes the source ports of its queries (avoiding the other big DNS security issue that's come up recently.) This will be nicely platform agnostic, so the Win XP box on my home network is saved from being fdisk'ed for another few months..
(Of course, because my ISP uses PPPoA and not PPPoE, I've also had to get a Speedtouch 536, which can relay via PPTP to the WRT54GL. Oh well..)
I didn't think it sounded much like him, either, but googling the subject turned up this (google cache version), which seems to make it more plausible..
Slashdot Mirror
IPv6 enables the 'hierarchicalness', but presumably doesn't necessarily enforce it. Hell, if necessary you can ignore the top 64 bits and just use the host id, and deal with 'routing' at L2. That's no worse than IPv4, and you've got another 8 bits of address.
And there's Mobile IPv6, which still feels a little hacky, but seems better intergrated than IPv4.
Off to watch the Van Jacobson video mentioned elsewhere in this thread ..
But, seriously... Why are you running services that require a firewall? Don't they do their own connection management?
It's a fair point, actually.
Originally, there were a handful of services running on any given box, and we just made sure we configured each one properly. It was bit of a pain, particularly as config file formats weren't standardized, but inetd and hosts.{allow,deny} made it bearable.
But then when the number of different services and platforms being deployed increased, we began to worry about the possibility of incorrect configurations slipping through the net - particularly on certain platforms (*cough*) where it wasn't easy / possible to lock down system services, or automate that with existing tools.
Hence, the firewall: originally basically just a way of sticking access control rules for network services in one place (either on a single host, or for a whole (sub)net) -- and dropping a few types of badly formed packets along the way.
The problem is, firewalls have become an object of near-religion devotion, accompanied by a loss of understanding of what they really do and why we need them. Dan Kaminsky's been banging on (since before the recent DNS stuff) about how you can't trust the 'local' network any more. And I think he's right. We need to secure the hosts, and secure the protocols, and drop the pretence that firewalls are much of a defence against modern attacks.
(Note: IP spoofing is, IMO, a slightly different issue. Configuring your routers to drop packets that can't be coming from where they say they are is rather orthogonal.)
Transcript? Anyone? Pretty please? :/
IPv4 NAT is quite a nice fit for the issue of dealing with lots machines with dubious security wanting to run 'simple' protocols, in a world with limited public addresses available.
Having said that, at least part of the perceived "niceness" is psychological: it puts a real system boundary right at the point where one feels there's a trust boundary (the edge of the local network.) And it's beginning to look (according to Dan Kaminsky, amongst others, and not just since the recent hysteria) like that feeling of security is misplaced.
When I was at uni, all the workstations (at least the *NIX ones - I never touched our one Windows lab) had public IP addresses. We never had any security issues as a result, to the best of my knowledge. It's just a question of securing the configurations (using centralized management, diskless workstations, or whatever) and applying patches.
NAT also makes running non-trivial stuff complicated. P2P. VOIP. 'Push' technologies (if the client has to keep a connection open to the server, that's not really 'push'.) Remote access, generally. Look at the hoops things like Teredo have to go through to deal one or two layers of NAT. Now try to imagine how that scales..
And anyway, just because (in a theoretical future IPv6 utopia) we're not doing address substitution any more, doesn't mean we can't still have firewalls. ip6tables exists for Linux, and I'm sure the router manufacturers all have their solutions. It's still only one or two rules of config to drop incoming connections, if that's desired.
Oh, and regarding toasters: i'm not sure that's the issue ;-) It'll be giving things like mobile phones, iPods and cars IP addresses and running P2P apps between them, I'm guessing.
I'm sure he's thinking of http://www.ipv6experiment.com/ ;-)
Don't forget the bottom 64 bits of an IPv6 address are the host address, so a router won't have to worry about those much until it comes to the last hop.
Also, easy renumbering (if it happens) should also allow more 'hierarchicalness' in addressing, -> shorter routing tables -> cheaper / faster routing. To be fair, ease of renumbering is at least theoretically orthogonal to address size, but autoconfig is being 'bundled' with IPv6 in a way it never has been with IPv4.
You're right, DNS isn't trustworthy, so not only should we not use hostnames when configuring systems, we should train our users not to use them either.
Honestly, we have to fix DNS. Even if your hardcoded literal IPv4 addresses are secure (and are they? If I can own your internal authoritative DNS server, there's a good chance I can spoof ARP, or bugger around with DHCP, or exploit that SNMP vulnerability that was kicking around recently..), there are quite a number of ways (start at slide 45) to steal all your users' data if DNS is vulnerable ..
Learning new stuff is a PITA, especially if the old stuff still appears to be working well, but sometimes preemptive action saves pain in the long run. Ultimately IPv6 should result in a reduction in complexity, and that's almost always a good thing ..
This DHCPv6 implementation claims to be able to do Dynamic DNS.
I guess we need to make it trustable, then. I know he presented lots of very clever attacks in his presentation, but an internal query to an authoritative internal DNS server should be pretty safe.
To be honest, even in the IPv4 world, it's not exactly best practice to hardcode IP addresses in the config of network devices, except where unavoidable. Sure, the risk of attacks on internal DNS is real, but the risk of unreliable network service because of byzantine configuration architectures is also real.
I do wonder if we've just crossed a tipping point in technology generally where large numbers of people are beginning to see the advantages of removing unnecessary complexity (or avoiding new complexity.) The popularity of small netbooks running Linux might be evidence of this, as is the general revolt against Vista. If so, all that remains is to convince people that, despite some warts, complexity(IPv6) < complexity(IPv4+lots of bodges).
If I were solving this, I'd suggest separate and non-directly routable IPv4 address spaces for separate countries (and, perhaps, for other entities). And lots and lots of NAT or proxying. Of course that is kind of what is happening anyway.
Eww. Lots of room for bugs and weird feature interaction in the design of protocols that have to punch through NATs, either that or everyone has to role out new helper modules / ALGs each time some wizzy new app is invented.
IPv6 is really a clean-up job. Combing the complexity back out of the network has got to be a win for reliability, ease of administration, and perhaps even security. I'm in favour, though I have to say I'm doubtful about it happening any time soon.
I think the most optimistic scenario is this: when IPv4 exhaustion hits, particularly in countries that have to yet to have their internet 'boom' and so will have a very low number of existing addresses per capita, obviously some sort ISP side NATing is going to be required. People may decide that they might as well implement IPv6 and TRT anyway, particularly if they're deploying new hardware / software combinations (netbooks? set-top boxes?) and so can dictate IPv6-readiness. Hopefully once sufficient numbers of IPv6-only nodes are out there, it'll seem worthwhile rolling out IPv6 on servers.
The alternative, ultimately, is people auctioning off tiny IPv4 address blocks and exponentially bloating routing table sizes, or a horrible twisty unreliable world of multiple NAT or ALGs, where net neutrality is a quaint concept consigned to history ..
And yes, printable IPv6 addresses are ridiculous. Admins will have to get used to trusting DNS (or /etc/hosts) when configuring stuff .. :)
* Not sure why the ISS specifically. Presumably it's some symbolic political thing, the ISS being a demonstration of international cooperation, etc., etc..
A quick google turns up this relatively recent report; from the first para:
$DEITY$ is quite clearly a custom CVS keyword, albeit with the capitalization convention wrong, $Deity$ would be more usual ;-)
And in FF3, instead of the colour of the whole address bar giving a fairly large visual clue about SSL use, the colouring seems to be restricted to the background of the site's favicon, which is barely noticeable. A distinct step backwards, AFAICS ..
Plus 14 bits of port number (i.e. where in the 48k-64k range it is)
Oops, yes. My bad. Sequentially incrementing port numbers != predictable starting port. To be fair it was early and I was hung over ;-)
and 32 bits of IP address. Really.
Think about it: if you have to guess at the transaction ID, that means that you are in a position where you can't see the stub resolver's queries, so you are also not seeing what IP those queries are being sent to or what source ports have been used.
The IP address might be guessable. If you're going to the effort of targeting stub resolvers in the first place, it might not be too much extra effort to whois the IP address and guess the names of the ISP's caching resolvers. (The only situation I can really see this sort of effort being worthwhile is where, say, a particular ISP habitually supplies a particular gateway device, which turns out to have NAT/firewall flaws allowing packet injection into the local network.)
With a recursive resolver using a single port, an attacker can discover and deduce everything but the transaction ID without doing anything but getting the target to resolve some names, while that is simply not the case with a stub resolver.
I'm still not convinced it's impossible, but I'm pretty sure it wouldn't be worth making the effort. There are almost certainly bigger issues.
Regarding DNS design: short of net-wide DNSSEC rollout (ha! We'll see IPv6 transition first..), a medium-term approach might be to start with the assumption that we can't be 100% sure that any individual answer is genuine, but that we can be pretty sure that a sequence of successful spoofing attempts is extremely unlikely. How do we re-engineer caching resolver behaviour (caches are the key target, because of the cascade effect of a successful poisoning on end users) to minimize the amount of trust we place in a single reply packet?
Paul Vixie made some suggestions back in '95 (see 7.2: "What We Would Like To Fix .. Hierarchical Cache.") It might make sense to return additional RRs to the calling stub without caching them, but then setting up another request to grab those names, in order to prime the cache and so minimize network traffic, but at the same time not delaying the first requester's query by too long and only risking returning false information to one client.
I'll admit my grasp on this is a little fuzzy around the edges, I haven't had much experience with DNS guts in the past (I'm hoping Dan Kaminsky's explanation will include some analysis which might clear the waters for me.) The issue as far as I can see it is that the additional RRs, which were originally only needed to solve one specific problem (glue for zone delegation), have been used as a general mechanism to prime caches (e.g. when doing MX record lookups), and so nobody wants to tighten up the processing behaviour of the caching resolvers.
I don't know whether this sort of effort is worth it, a jump to DNSSEC might actually be simpler, and the source port randomization is a good fix for the moment. Network speeds will continue to get faster, however, and I'm sure some people will continue to put nameservers behind NATs that eliminate source port randomness. Also, flaws will presumably continue to be found in random number generators. A bit of further thought might be wise before the next issue crops up..
Well, yes, but for TCP you always have to guess 32 bits of sequence number, whereas for UDP spoofing control has to be implemented at the application layer level. In this case, DNS with sequential serial numbers, we're back to only 16 bits of TXID.
I suppose it might be of some use if combined with an exploit against a NAT device -- if you could coerce it into forwarding spoofed responses?
Even so, I don't know how long most stub resolvers cache answers (in memory). If at all, I thought it was a matter of seconds ..
DNS generally runs over UDP, which works slightly differently to TCP. If you send a UDP packet out, and want a reply, you have to listen for that reply, which means you have an "open port", though in the case of DNS, hopefully only to your local network. TCP is connection based and will discard packets which do not appear to part of the connection; UDP isn't and therefore can't.
If someone can inject packets into your local network, they can try to spoof a reply to any queries you make to a recursive DNS server or forwarder (e.g. on your xDSL gateway device.) But if they can do this, you have more substantial security issues anyway. There might be something clever that could be done to attack people who've left their WiFi unsecured, but you'd still need to force them to generate multiple queries for unknown subdomains - perhaps a targetted HTML email with embedded IMG tags? Still sounds like too much work compared to emailing trojans to naive Windows users, unless you happen to work for the security services ..
(Incidentally, I'm perilously close to actually installing BIND locally and poking it with a stick to see what all the fuss is about. I haven't gotten my hands that dirty in some time )
(BTW, feel free to drop this conversation if you're fed up with dealing with the hard of thinking and - by this time of the evening - slightly inebriated.)
Of course Mallory's response listed an A record for CXOPQ.VICTIM.COM ... and the authority for that record is listed as whatever. In addition to that is the glue that says "Hey, btw, WWW.VICTIM.COM is XYZ." Typically the glue is used to indicate the DNS authority of the information, however that DNS authority can really be anything... WWW.VICTIM.COM for all it matters, they really are free to name their name servers whatever they want.
At this point, we should already be querying (what we think is) an authoritative server. If we're being returned an A record, and not an NS record, why would we process any glue? I thought Paul Vixie fixed this 13 years ago:
http://www.usenix.org/publications/library/proceedings/security95/full_papers/vixie.txt (see section 5.3, "Irrelevant Answers")
The A record returned wouldn't be authoritative, it'd be the same kind of answer that the DNS cache would receive from its parent DNS, or what the end-user's computer would receive from its DNS cache.
But at this point, we should be expecting an authoritative answer for CXOPQ.VICTIM.COM, or a referral with glue, but not a non NS record with glue, surely? Mallory's racing with the authoritative server for the domain we're trying to query..
If you went and asked the authority for confirmation for that address, then there's no reason for the DNS cache.
We're not talking about attacks on stub resolvers .. are we? (You can't poison the cache on a machine that doesn't have one.) The standard situation is that a stub resolver (e.g. Win XP machine) asks an ISP's caching resolver for an address; assuming the answer isn't already cached, the caching resolver figures out the appropriate authoritative server for that zone, and queries it. In the scenario that I think we're discussing, based on ecopeland's post, the attacker races with the authoritative server to get an answer to the caching resolver, and so (somehow) screw over all future clients of that resolver until the TTL expires.
Incidentally, assuming my understanding is close, even if section 5.3 of the Vixie paper hasn't been implemented sufficiently rigorously to prevent this attack (and obviously it hasn't, or there would be no panic), section 7.2 ("What we would like to do .. Hierarchical cache") should nail it. Now, this would be invasive, and so time consuming to test, but it should be penciled in as work to be done after the immediate band-aid has been applied. After all, this is 2008, we all grok Extreme Programming, surely with sufficient testing (unit and otherwise) this could be implemented. Let's face it, sufficiently widespread deployment of DNSSEC is about as likely to happen as IPv6 (sadly)..
OK, so diffing against the matasano post:
"Poisoning CXOPQ.VICTIM.COM is not super valuable to Mallory. But Mallory has another trick up her sleeve. Because her response didnâ(TM)t just say CXOPQ.VICTIM.COM was 6.6.6.0. It also contained Additional RRs pointing WWW.VICTIM.COM to 6.6.6.0."
This is, then, not quite right? Rather Mallory's response would not list an A record for CXOPQ.VICTIM.COM, but instead another delegation, plus glue? There would be no reason to process glue if an authoritative A record response was returned ..
Is the fundamental underlying issue merely that it would break too many existing configs if caching resolvers were stricter? I hope Dan Kaminsky's eventual disclosure goes into a bit more detail on this. I'd also quite like to here what DJB has to say.
So ns1 is listed as the server for the subdomain as well, and glue supplied? Why doesn't bailiwick checking apply here as well - only ns1.aaaa.victim.com etc. being allowed?
I'm with Tony Hoyle - I can't (at the moment) see a reason why a query to an (apparently) authoritative server for a subdomain should reasonably be allowed to contain glue for the parent.
Isn't the answer then simply better checking in the recursing resolvers?
If, as a caching resolver, I ask an (apparently) authoritative server for google.com for an A record for xxjk3.google.com, what am I doing processing any returned glue records?
I can think of other tricks, some simple, some more complicated, that might work, but I still don't feel that the whole story's out of the bag here yet -- not that I have a huge problem with that.
I'm hoping to take delivery of a WRT54GL for precisely this reason. I can stick maradns on it, which does its own recursion, keeps an in memory cache, and randomizes the source ports of its queries (avoiding the other big DNS security issue that's come up recently.) This will be nicely platform agnostic, so the Win XP box on my home network is saved from being fdisk'ed for another few months..
(Of course, because my ISP uses PPPoA and not PPPoE, I've also had to get a Speedtouch 536, which can relay via PPTP to the WRT54GL. Oh well..)
I didn't think it sounded much like him, either, but googling the subject turned up this (google cache version), which seems to make it more plausible ..