Facts piling up and we have complete picture of the approach we cannot trust anymore – proprietary codes. Facts first – 2005/2006 University of Michigan (UoM) VMBR/SubVirt research – the prove of vulnerability of Intel software based virtualization solution, 2007/2008 - hidden hypervisor was found in Intel motherboards MBC firmware shipped to Russia and which supported hardware virtualization and nested hypervisors, 2012/2013 – UoM research found numerous vulnerabilities in motherboards management software (including Intel), 200x/2018 – Intel (95%) – speculative execution vulnerability and exploits, multiple security flaws found in SecureBoot, server management software, etc. Basically it is about insecure implementation in firmware of all levels – from microcode to management software applications. That leads to various APTs including Malicious Hypervisors.
Should we really trust as default when a vendor gives us a solution while nobody outside of the vendor premises assessed it? With Intel CPU security vulnerability (and others from the list) we likely have to change our trust model from default “we do!” to “we deny!”. We do not see yet the wave of CPU vulnerability exploits which likely to come within a few months.
I would propose the solution – at least independent security review of all firmware developed by critical infrastructure IT vendors dominating market like Intel, Cisco, etc. However, disclosure of the code of critical firmware would be appropriate. After all, our lives depend on the security of codes.
Additional information concerning the matters in question are available at www.rubos.com
