[dns-operations] summary of recent vulnerabilities in DNS security.

Mon Oct 21 02:36:16 UTC 2013

On 10/21/2013 12:33 PM, Vernon Schryver wrote:
>> From: Haya Shulman <haya.shulman at gmail.com>
> 
>>> I do not see an answer to my intended question. Again, given inevitiably
>> limited real time, over-committed programmer and DNS adminstrator
>> hours, and limited money, should problems in DNSSEC implementations
>> and installations be addressed before or after your issues?
> 
>> Some of our recommendations can be useful for security (also against
>> other attacks - see earlier email), and can assist with
>> interoperability problems, that may emerge during deployment of
>> DNSSEC.
>> For instance, our recommendations for IP layer, e.g., reducing IP
>> defragmentation cache size or randomising IP-ID, can be useful not
>> only against poisoning attacks (in particular, fragmentation has a
>> long history of exploits for denial/degradation of service attacks);
>> Port randomisation is also a useful feature, not only against cache
>> poisonig (see earlier email); and so on.
> 
> Even if that were correct (it's partly wrong), it would not answer
> my question.
> 
> 
>> Should the people working on DNS implementations prioritize making
>> their DNSSEC code more robust and easier to use above or below
>> addressing your issues?
>>
>> I do not think that there is a general answer to this question, as it
>> depends on the specific organisation/network.
> 
> I guess I'll play a little more by naming three specific outfits.
> 
> Should the organizations responsible for BIND, nsd, and unbound to
> work on DNSSEC improvements and bug fixes before or after your
> issues?  Please do not feel constrained to give a single general
> answer for all three organizations but please give 3 specific answers
> for those 3 specific organizations.

The organizations that you refer to are more than capable of setting
their own development priorities.  It is not the responsibility of a
graduate student researcher to set development priorities for these
organizations, nor would those organizations likely accept those
recommendations.

While you apparently would have preferred the conclusion of this paper
to be "Nothing to see here.  DNSSEC fixes everything.".  That isn't the
case, or the case for the internet as we find it today.

Whether or not the organizations responsible for writing/maintaining DNS
server code decide to address the issues raised in this paper (if their
code is in fact vulnerable) or not is a discussion that those
organizations will have with their customers.  I suspect that none of
these organizations will be putting in their release notes - "There are
known/published vulnerabilities that this software exposes users to if
they have not deployed DNSSEC.  Fully deploy DNSSEC (and make certain
that all other hosts with which you interoperate have fully deployed
DNSSEC) to mitigate these isses.".

>> Which should be built or fixed first, mechanisms such as auto-signing
>> that make DNSSEC easier to deploy and more robust (e.g. reducing
>> accidental signature expiration), or your cache pollution issues?
>>
>> Should requests for proposals and requests for quotes rank DNSSEC
>> features including ease of DNSSEC use above or below fixes for your
>> cache pollution issues?
>>
>> Should you spend most of your own time looking for improvements and
>> bugs in DNSSEC or looking for more ways to pollute DNS caches where
>> DNSSEC is not used?
>>
>> Both are important: (1) disclosing attacks raises awareness to the
>> significance of systematic defenses, and motivates deployment thereof; it
>> also enables the networks to protect themselves in the meanwhile. I would
>> not be surprised if similar attacks were deployed in the Internet, without
>> anyone being aware of their existence.
>>
>> (2) I also study deployment challenges and improvements (and not only
>> attacks).
> 
> Do you think anyone sees that as responsive to any of my questions?
> 
> 
> 
>> I think that is neither a response to my claim, accurate, nor
>> relevant to what I understood of your claim about forwarders.
>>
>> How can something that introduces a security vulnerability not always
>> be a bug in your or anyone's opinion?
> 
>> Sure, permissive mode is an explicit feature. I believe a bug is
>> something that is not intentionally introduced.... (well, at least not
>> as a general rule).
> 
> On the contrary, in the real world, any and all computer sins of
> commission and many sins of admission are "bugs" according to the
> people who matter, users and customers.  The programmer, vendor, or
> whatever can sometimes escape censure by pointing at a specification,
> but even when it works, that tactic never wins respect, friends, or
> more business, and it can lose old business.
> 
> 
>> If you meant instead to say that permissive verification is a less
>> important bug that other things, then how do you rank your cache
>> pollution issues against other bugs starting with not deploying DNSSEC?
> 
>> I would hope that disclosure may help some organisations and networks
>> protect themselves. The other option is to be unaware of the
>> vulnerabilities (and their exploits).
>> Do you think vulnerabilities are better left for attackers to take care of?
> 
> That implication that I have ever said or suggested that you should
> not have published your findings is disingenuous and offensive.
> 
> My problem with your findings is that your are grossly overstating
> their significance.  None of them will ever be seen in the wild.  As
> As http://link.springer.com/chapter/10.1007/978-3-642-33167-1_16 and
> as I've said, showing the inevitiable weakness of port randomization
> is good.
> 
> 
>>  BTW, we withheld some of the works from publication, and tried to
>> coordinate disclosure.
> 
> That is the right thing to do except when exploits have already
> been seen in the wild or are likely to be seen soon.  However, given
> the practical certainty that none of your vulnerabilities will ever
> be seen in the wild, no one should have complained if you had not.
> 
> 
>> Your work would be valuable if it helped pressure people to get
>> busy on DNSSEC.  However, instead of saying "Use DNSSEC because
>> port randomization has these newly discovered weaknesses", you only
>> grudgingly and under pressure admit that DNSSEC even exists.
>>
>>  Many networks cannot deploy DNSSEC overnight, due to different factors.
>> Port randomisation algorithms that were proposed have weaknesses, but
>> proper randomisation should solve these problems.
> 
> I doubt the implication in that sentense, because I give you more
> credit than to think that any of the recommendations in your 19 Oct 2013
> mail could and would be deployed "overnight" or easier than DNSSEC by
> any except a very few individuals.  The only recommendation that might
> be done quickly is forcing TCP to proxies.  That could be done with a
> firewall ACL against UDP, but no one should do that.  The others require
> changes to source.  For example, several of your recommedations are
> to "randomise ports."  Any code that doesn't already do that will
> continue not doing it at least until its next release.
> 
> Fixing your vulnerabilities would be technically easy for many people,
> including those whose resumes are like mine.  However, what is easy
> for professional kernel and DNS server hacks is irrelevant.
> 
> 
>> I was under pressure to catch a flight when I responded and forgot DNSSEC;
>> it is as dear to me as it is to you :-)
> 
> I'm sorry, but I think the mention of DNSSEC in your paper exists only
> because others forced it.  I'm forced to that belief by various things
> including your refusal admit the obvious about relative priorities and
> by statements like that sentence above that suggests that fixing port
> randomization could be easier than deploying DNSSEC in any except quite
> exceptional cases.
> 
> You directed Paul Vixie to a copy of your paper on your web site, but
> I didn't see a URL.  Is http://www.ec-spride.de/ your web site and if
> so, is your paper there?  I can't find any other likely URLs.
> 
> 
> Vernon Schryver    vjs at rhyolite.com
> _______________________________________________
> dns-operations mailing list
> dns-operations at lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
> dns-jobs mailing list
> https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
> 

-- 

-______________________
David Miller
dmiller at tiggee.com