[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <0805220805320.31721@mjc.redhat.com>
Date: Thu, 22 May 2008 08:15:45 +0100 (BST)
From: Mark J Cox <mjc@...hat.com>
To: oss-security@...ts.openwall.com
Subject: Re: Root name server changes -> bind
> #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.
This is what I bet most of the vendors represented here do; for example
the Red Hat Network client 1) contacts the server at Red Hat over SSL, 2)
verifies that the certificate of the site it's connecting to was issued by
a CA hardcoded into the distro, 3) will only install packages without
prompting that are digitally signed by a previously-imported public key.
If any one of those mechanisms failed I would expect it to generate a CVE
(even though the security of the system as a whole isn't broken unless all
of them break together).
This sort of update mechanism isn't that difficult to implement. So
should you give a CVE to an update mechanism that fails to implement a
secure update process? absolutely.
Mark
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.
