Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 22 May 2008 08:15:45 +0100 (BST)
From: Mark J Cox <>
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.


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.