Not too long ago we migrated from sourceforge to RT3; the SF VM died and we were already in the process of migrating from prebuilt VMWare services to natively hosted stuff. SF is unfortunately no longer (maybe it never was) available as a project in this fashion, and we were only using it for the tracker.
RT3 is a pretty decent system, but the interface is rather complicated and cluttered, and modifying it is not as easy a task as one might expect. For example, "resolved" items do not show up in any listings by default, and making custom listings or modifying existing ones can be painful, so we are instead using a 'resolved' queue and never actually resolving issues "the RT way."
I have taken another look at Mantis and it looks like it does everything we need and isn't overly complicated, so I've put up a copy for evaluation by management.
Mantis claims to have integration with subversion built in, but even if it doesn't, it's really easy to use the subversion commit hooks to do some form of integration yourself.
For the record, having good source port randomization does not make you immune, it just makes you resistant.
Using the attack as described, you go to some web forum and post image links as urls 1.yourbank.com to 50000.yourbank.com.
As soon as you post, you start blasting joes (a frequent reader of the forum) dns server with fake responses The chances are actually pretty good that you'll eventually get a match in a short period of time.
That is the 'birthday' part of the attack.
Sending 50,000 packets with forged random source ports and query ids to hit a collision in a 32bit (combined) field, you'll match up one time in four.
That's better than one time in one, and you still have to 'beat the clock', but if you do this with a simultaneous ddos against the legit nameservers for mybank.com, your chances increase dramatically.
I also have to say that I don't believe the extremely contrived example I came up with is entirely valid. By definition, the NS records and their associated glue must (should? Have to check the RFCs) exist within the delegated zone.
In other words, glue records for "aaa.google.com" should only be valid if they exist within "aaa.google.com" e.g. ns1.aaa.google.com.
If the RFCs don't say this, I don't think it would be too difficult to get such an update through the system, since every legitimate subzone I've encountered operates within these rules anyhow.
As I mentioned above, this still doesn't make any sense. Let's look at just what a glue record is and how they are designed to work.
In this example, we're trying to resolve aaa.google.com on a fresh recursive nameserver with no cache. The first thing it will do is make a request out to the root nameservers. The root name servers will respond saying basically "I don't know anything about aaa.google.com, the closest I can get is simply.com.. Here are the nameservers for.com."
The root servers send you no RRs in the answer section, 12 NS RRs in the authority section (the GTLD servers responsible for.com), and 12 A RRs in the additional section with the IP addresses of the NS RRs.
Those A records in the additional section are the glue records. The data they have is crucial to the functioning of DNS; you can't ask the GTLD servers about google.com if you can't get to them.
The same thing happens at the next stage; when you ask the GTLD servers about google.com, you get a response that's basically identical except this one has the NS and corresponding A records for google.com, rather than.com itself.
Again, these records are crucial. You can't ask ns1.google.com about aaa.google.com unless you know the address of ns1.google.com.
However, this is where the attack breaks down.
When you ask ns1.google.com for the address of aaa.google.com., a valid response RR can only be one of three things:
1. A normal RR for aaa.google.com such as an A record or CNAME.
2. A delegation referral that indicates aaa.google.com is a subdomain, with more glue records pointing to something like ns1.aaa.google.com.
3. An NXDOMAIN respose indicating that aaa.google.com doesn't exist, with a single RR in the authority section -- the SOA for all of google.com.
Any record appearing for "www.google.com" is totally irrelevant and any responsible DNS server should discard it without thinking.
The single attack vector I can see is if you are returned a bogus delegation (faking a subzone); e.g., your faked response has a single RR in the authority section that says "aaa.google.con IN NS www.google.com" and a single RR in the additional section that says "www.google.com IN A evil.haxor.ip.addr"
However, that A record should not be cached and definitely should not displace an existing RR for www.google.com if one exists; it is not authoritative.
With this type of spoofed response, you would connect to evil haxor's IP address and once again ask for aaa.google.com and possibly get an address or some other garbage, but anything you get at this point must only be 'trusted' if it applies to the 'aaa.google.com' zone, which 'www.google.com' is not a part of.
I hope I'm making this more clear this time around. The net of this is that with a little intelligence in the DNS server, vulnerability to this attack is nonexistant, because it relies on the victims DNS server to cache irrelevant results, or results that are only relevant in the context of that query and no others.
If after this attack takes place against your nameserver, you attempt to go to www.google.com, the nameserver should be asking ns1.google.com all over again, and not simply trusting the irrelevant address it received when trying to get to aaa.google.com.
Yes that's the right idea, but it seems that just changing this concept of a "balliwick" would solve the issue.
There's no legitimate need for your bogus "www.bankofamerica.com" RR to be accepted when you're asking about "xxffgg.bankofamerica.com."
It makes sense to accept it when you're simply asking about "bankofamerica.com"; that's how normal glue works, but you already have the information you need regarding the domain itself, so accepting more unsolicited information doesn't provide you with anything.
Servers only need glue when they're traversing the chain. Once they're at the level they need to be at, they should ignore any other records (glue or otherwise) that are sent.
If I go make a bunch of links to abcd.bankofamerica.com, bcde.bankofamerica.com, and so on, my intention is to hijack www.bankofamerica.com.
www.bankofamerica.com is not a subdomain of abcd.bankofamerica.com, and thus, any glue related to it that is provided in the above queries should be ignored.
Follow?
BIND may not currently be doing "balliwicking" at this detail, but it should be, and patching it to do so should be rather trivial.
If this is the real deal, there's some bogosity here. This is certainly not a new attack or flaw in the dns protocol, any more than run of the mill dns cache poisoning is.
Spoofing responses from the root servers (to hijack a TLD) is difficult; their TTLs are long, there are many of them (more unpredictability), and most DNS servers service so many requests that it's unlikely that your spoofed answer will be the first one to hit the server and thus poison the cache once the TTL for that TLD has expired.
Spoofing responses from TLD servers is standard issue cache poisoning, and you cannot use it (any more) to poison a cache with an irrelevant record; BIND is going to ignore any NS, A, SOA, or other records for bankofamerica.com. in the additional or authoritative sections if the request was for some-domain-that-don't-exist.com.
I'm back to where I was before; not seeing anything new here except a clever theoretical attack that would work much better if the TTLs for the TLD servers were on the order of minutes or hours rather than days.
Either Halver guessed wrong, or the security community has been mislead about the severity of the issue.
Slashdot Mirror
Not too long ago we migrated from sourceforge to RT3; the SF VM died and we were already in the process of migrating from prebuilt VMWare services to natively hosted stuff. SF is unfortunately no longer (maybe it never was) available as a project in this fashion, and we were only using it for the tracker.
RT3 is a pretty decent system, but the interface is rather complicated and cluttered, and modifying it is not as easy a task as one might expect. For example, "resolved" items do not show up in any listings by default, and making custom listings or modifying existing ones can be painful, so we are instead using a 'resolved' queue and never actually resolving issues "the RT way."
I have taken another look at Mantis and it looks like it does everything we need and isn't overly complicated, so I've put up a copy for evaluation by management.
Mantis claims to have integration with subversion built in, but even if it doesn't, it's really easy to use the subversion commit hooks to do some form of integration yourself.
For the record, having good source port randomization does not make you immune, it just makes you resistant.
Using the attack as described, you go to some web forum and post image links as urls 1.yourbank.com to 50000.yourbank.com.
As soon as you post, you start blasting joes (a frequent reader of the forum) dns server with fake responses The chances are actually pretty good that you'll eventually get a match in a short period of time.
That is the 'birthday' part of the attack.
Sending 50,000 packets with forged random source ports and query ids to hit a collision in a 32bit (combined) field, you'll match up one time in four.
That's better than one time in one, and you still have to 'beat the clock', but if you do this with a simultaneous ddos against the legit nameservers for mybank.com, your chances increase dramatically.
I also have to say that I don't believe the extremely contrived example I came up with is entirely valid. By definition, the NS records and their associated glue must (should? Have to check the RFCs) exist within the delegated zone.
In other words, glue records for "aaa.google.com" should only be valid if they exist within "aaa.google.com" e.g. ns1.aaa.google.com.
If the RFCs don't say this, I don't think it would be too difficult to get such an update through the system, since every legitimate subzone I've encountered operates within these rules anyhow.
As I mentioned above, this still doesn't make any sense. Let's look at just what a glue record is and how they are designed to work.
In this example, we're trying to resolve aaa.google.com on a fresh recursive nameserver with no cache. The first thing it will do is make a request out to the root nameservers. The root name servers will respond saying basically "I don't know anything about aaa.google.com, the closest I can get is simply .com.. Here are the nameservers for .com."
The root servers send you no RRs in the answer section, 12 NS RRs in the authority section (the GTLD servers responsible for .com), and 12 A RRs in the additional section with the IP addresses of the NS RRs.
Those A records in the additional section are the glue records. The data they have is crucial to the functioning of DNS; you can't ask the GTLD servers about google.com if you can't get to them.
The same thing happens at the next stage; when you ask the GTLD servers about google.com, you get a response that's basically identical except this one has the NS and corresponding A records for google.com, rather than .com itself.
Again, these records are crucial. You can't ask ns1.google.com about aaa.google.com unless you know the address of ns1.google.com.
However, this is where the attack breaks down.
When you ask ns1.google.com for the address of aaa.google.com., a valid response RR can only be one of three things:
1. A normal RR for aaa.google.com such as an A record or CNAME.
2. A delegation referral that indicates aaa.google.com is a subdomain, with more glue records pointing to something like ns1.aaa.google.com.
3. An NXDOMAIN respose indicating that aaa.google.com doesn't exist, with a single RR in the authority section -- the SOA for all of google.com.
Any record appearing for "www.google.com" is totally irrelevant and any responsible DNS server should discard it without thinking.
The single attack vector I can see is if you are returned a bogus delegation (faking a subzone); e.g., your faked response has a single RR in the authority section that says "aaa.google.con IN NS www.google.com" and a single RR in the additional section that says "www.google.com IN A evil.haxor.ip.addr"
However, that A record should not be cached and definitely should not displace an existing RR for www.google.com if one exists; it is not authoritative.
With this type of spoofed response, you would connect to evil haxor's IP address and once again ask for aaa.google.com and possibly get an address or some other garbage, but anything you get at this point must only be 'trusted' if it applies to the 'aaa.google.com' zone, which 'www.google.com' is not a part of.
I hope I'm making this more clear this time around. The net of this is that with a little intelligence in the DNS server, vulnerability to this attack is nonexistant, because it relies on the victims DNS server to cache irrelevant results, or results that are only relevant in the context of that query and no others.
If after this attack takes place against your nameserver, you attempt to go to www.google.com, the nameserver should be asking ns1.google.com all over again, and not simply trusting the irrelevant address it received when trying to get to aaa.google.com.
Yes that's the right idea, but it seems that just changing this concept of a "balliwick" would solve the issue.
There's no legitimate need for your bogus "www.bankofamerica.com" RR to be accepted when you're asking about "xxffgg.bankofamerica.com."
It makes sense to accept it when you're simply asking about "bankofamerica.com"; that's how normal glue works, but you already have the information you need regarding the domain itself, so accepting more unsolicited information doesn't provide you with anything.
Servers only need glue when they're traversing the chain. Once they're at the level they need to be at, they should ignore any other records (glue or otherwise) that are sent.
Yes, but that doesn't help in an attack.
If I go make a bunch of links to abcd.bankofamerica.com, bcde.bankofamerica.com, and so on, my intention is to hijack www.bankofamerica.com.
www.bankofamerica.com is not a subdomain of abcd.bankofamerica.com, and thus, any glue related to it that is provided in the above queries should be ignored.
Follow?
BIND may not currently be doing "balliwicking" at this detail, but it should be, and patching it to do so should be rather trivial.
If this is the real deal, there's some bogosity here. This is certainly not a new attack or flaw in the dns protocol, any more than run of the mill dns cache poisoning is. Spoofing responses from the root servers (to hijack a TLD) is difficult; their TTLs are long, there are many of them (more unpredictability), and most DNS servers service so many requests that it's unlikely that your spoofed answer will be the first one to hit the server and thus poison the cache once the TTL for that TLD has expired. Spoofing responses from TLD servers is standard issue cache poisoning, and you cannot use it (any more) to poison a cache with an irrelevant record; BIND is going to ignore any NS, A, SOA, or other records for bankofamerica.com. in the additional or authoritative sections if the request was for some-domain-that-don't-exist.com. I'm back to where I was before; not seeing anything new here except a clever theoretical attack that would work much better if the TTLs for the TLD servers were on the order of minutes or hours rather than days. Either Halver guessed wrong, or the security community has been mislead about the severity of the issue.