On Fri, Jan 02, 2015 at 01:44:49PM -0800, Ben Pfaff wrote:
> Open vSwitch needs some kind of process for handling vulnerabilities. So
> far, we've been pretty lucky that way, but it can't last forever, and I
> think we'll be better off if we have at least the outline of an established
> process whenever a significant vulnerability comes along. Here's my draft
> of a process based on the documentation of the OpenStack process at
> https://wiki.openstack.org/wiki/Vulnerability_Management.
>
> I don't have a lot of experience with this kind of thing myself, so I'd
> appreciate critical review from anyone who does.
>
> Signed-off-by: Ben Pfaff <[email protected]>
I received the following suggestions in private email from a person who
said that I could pass them along to the list as long as I do not use
his name because he prefers "not to be associated with the security
field." Fair enough! Here they are:
1) Consider provisions for ensuring privacy and integrity of
communications around disclosure (eg, use PGP for all comms).
2) Consider provisions for handling the vuln info to prevent it from
being leaked / stolen from developers (this info can often be worth a
lot of money to certain parties with a lot of interest and motivation to
get hold of them). This means keeping info in some sort of secured
enclaves, and perhaps mixing patch code with other commits to obfuscate
the presence of the flaw. Parts of OVS are in kernel space, making it a
quite an “interesting” target, so I wouldn’t take this one lightly.
3) Consider revising patch release process to ensure patched code
reaches deployments without disclosing the vulnerability; and release
the vuln info after allowing sufficient time for fixed code to percolate
into running environments. Currently proposed process does not appear to
allow for this.
_______________________________________________
dev mailing list
[email protected]
http://openvswitch.org/mailman/listinfo/dev
