The Troubled State of Security in 2018
The start of the new year has been fraught with peril on many fronts. The tandem of Meltdown and Spectre were a considerable blow to assumed paradigms of technological safety and security. Enough time has passed to enable a more reliable stream of information related to mitigation techniques, underlying system dependencies, and potential pitfalls related to compatibility between software elements within a given system. The massive quantity of missteps along the way by Intel, AMD, Microsoft, and hardware vendors that produce solutions has raised serious concerns related to their independent abilities to process a vulnerability of this scope and to provide relief without compromising system stability or application integrity. Meltdownattack.com was implemented early in the cycle and continues to function as an excellent resource for understanding the scope of these vulnerabilities.
Patches, hotfix packages, and firmware that released during the month of January were ultimately more trouble than they were worth. What we’ll refer to as “version 1.0” of microcode and BIOS updates resulted in compromised system stability, a dramatic increase in unexpected reboots, and miscellaneous errata that has sent Intel back to the drawing board. Tier 1 manufacturers have pulled the recent updates from their respective sites and will republish once a better solution is made available. When the creator of Linux calls out Intel’s proposed fixes as garbage, the impact of Intel’s resource cuts and lack of proper investment or understanding in security become evident. AMD’s initial response on these vulnerabilities had to be walked back due to inaccuracies. A subsequent update to the page dedicated to information on this threat better aligns with the facts. As the ecosystem of vendors producing AMD-based solutions is not as prevalent in comparison to those that produce Intel-based solutions, any subsequent BIOS and related AGESA updates may take longer to be released.
Considering that Microsoft has reverted or updated a number of patches after initial release at the beginning of last month, solving this problem is going to take a longer cycle than most of the major 2017 security vulnerabilities. We believe Red Hat’s approach is the best option at this point; don’t take provided code and false assertions of a fix at face value. If the fix is worse than keeping the vulnerability present until such time that a less disruptive and more thorough solution is made available, don’t implement the fix.