[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Pine.LNX.4.64.0805220542160.16716@forced.attrition.org>
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 1.2.3.4 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.
