Date: Thu, 22 May 2008 05:51:55 +0000 (UTC) From: security curmudgeon <jericho@...rition.org> To: oss-security@...ts.openwall.com Subject: Re: Root name server changes -> bind : On Wed, 21 May 2008, Marcus Meissner wrote: : : > Not sure if this warrants a CVE id. : : Gut reaction here, but I would say that if a software package has : hard-coded those IP addresses and doesn't check them e.g. through a : reverse lookup, then the issue in that package would require a CVE. : : I have a feeling I could regret that statement :-/ Oh hey great lead-in to a question plaguing OSVDB, partially courtesy of ... drumroll.. CVE! =) In our NDM queue, i've been sitting on "dns cache poisoning (maybe)" for some time, a collection of CVE's that represent this exact issue. It seems pretty straight forward until you start looking for the solution, and then it blurs and the line isn't so clear on where a VDB should stop tracking it as a vulnerability. #1: SomeProgram uses a DNS name to contact home-base for updates in some fashion. It relies on DNS resolution to contact update.vendor.com to receive this information. If an attacker has control of the DNS, the software contacts the attacker's server and receives malicious code. This is pretty nasty and what you regret to think of as CVE-worthy because we all know a *ton* of software does exactly this. It's hard to blame them since networks change, companies move or get bought. #2: First solution is to use an IP address instead of DNS name. This will prevent DNS spoofing as a form of attack and elevate the skill required to subvert the update process. Problem is that networks change, companies move, etc. So what happens when that old install contacts 184.108.40.206 to find that it is now in the hands of badguys.us? This is relying on an untrusted host to get the information, just like scenario #1 above. Is this worth inclusion in VDBs? #3: Second solution, and the better one that is harder to implement I imagine, is to care a lot less about where it is contacting and care a lot more about the information it is receiving. Digital signatures, MD5 hashes (where would it get those from though) or some other form of validation of the content it receives would help reduce risk significantly. Reverse the solution and this may be the real criteria for inclusion into VDBs. The overall lack of a secure update process, be it DNS trust, hard coded IP or the lack of a trust-worthy signature system. So which of these scenarios are vulnerabilities that a public VDB would agree meets standards for inclusion? I've gone back and forth on this one for just over two years and never found the time to make a decision as far as OSVDB is concerned. I'd love to get feedback here or a discussion to help make up our minds. And now, fuel for the fire: http://cve.mitre.org/cgi-bin/cvename.cgi?name=2005-3899 http://cve.mitre.org/cgi-bin/cvename.cgi?name=2005-4582 http://cve.mitre.org/cgi-bin/cvename.cgi?name=2005-3725 http://cve.mitre.org/cgi-bin/cvename.cgi?name=2006-0375 http://cve.mitre.org/cgi-bin/cvename.cgi?name=2006-2324 http://cve.mitre.org/cgi-bin/cvename.cgi?name=2006-2479 http://cve.mitre.org/cgi-bin/cvename.cgi?name=2006-5901 Brian OSVDB.org
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.