oss-security - Re: Root name server changes -> bind

Openwall Project		/home Owl JtR Pro crypt pam_passwdqc tcb phpass scanlogd popa3d msulogin / Linux BIND / advisories presentations / services donations / wordlists passwords / NEWS community lists Wiki CVSweb mirrors signatures
bringing security into open environments

Password Recovery Resources on the Net

[<prev] [next>] [<thread-prev] [thread-next>] [month] [year] [list]

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

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.