Looking back on #Spectre and #Meltdown : a human perspective review.

The barrage of firecrackers that went off on January 3rd were enough to have most of the Information Security Professionals and Info-Sec enthusiasts racing for a screen to get hold of the latest news. The reports on performance impact as high as 30% were widespread and persistent paired with rumors of being able to read 'everything'.

From the start it was clear this was to be unlike anything, the keywords thrown around were nothing short of alarming and lacked context. To me, this meant reading the first resource on topic stating 'replace the processor' as the only solution. That page has since, fortunately for all involved, received many updates and some nuance.

Cutting a long story short.

The #intelbug disappeared and became known as #Meltdown which was quickly fixed on all platforms affected. The other bug #spectre (x 2) received much less attention but proves not only much harder to exploit, but also much harder to fix.

In all original #intelbug became a many-more-processors- than-we-thought bug (including AMD, ARM, IBM/PowerPC, Oracle/SPARCv9, ?) affecting over 3000 different processor models and variations.

However, things are not that simple.

Facing the facts

The cold hard truth, though vastly impractical, still holds. Replacing the processor is the only approach which does not impart a sizable investment of time and resources on the customer side. Consider, this involves building a detail inventory for all devices from mobiles to servers, from printers to firewalls.

Fortunately, the naked truth brings choices as often as it offers solace.

Thanks to the many smart people involved mitigation were readily available for the now name side-channel processor bug variants of which 2 x Spectre and 1 x Meltdown. None of the bugs were known to be remotely exploitable so it was not like if you left a server on the internet people could just walk in and steal all available information on it.

Meltdown was quickly fixed and is reportedly adequately contained in the long run.

For the 2 Spectre variants however the real-world fix requirements involve many deep technical components which are not as easy to fix as publishing an update.

Such components as BIOS, Compilers, Operating Systems, Applications, Application Libraries, JIT Engines (JavaScript, .NET, Android etc. ) and what not more require attention. Fortunately, for now, the difficulty for executing a Spectre attack is high in both technical complexity as well as the time required to do so (10-30 minutes)

I have found unverified but repeated reports by experts they have managed to turn one or more of the side-channel bugs into working and workable exploit code. Limitations remain notable however.

However

However, one cannot but notice just one out of three (Spectre variant 2) requires a low-level fix in the form of a microcode update. The other two do not and are (and rightly so for as far as we know) considered operating system design flaws by the hardware makers. Which may be a motivation for some to remain silent, or prudent, regarding.

When it comes to patching and the trade off between security and performance there are some things worth considering. The first being performance impact is real and still quite unpredictable. Efforts are being made by all vendors to resolve the issues.

Secondly, and valid for both Spectre bugs. While an update for a compiler may seem like just any other update, in this case it means quite a bit of software must be recompiled to adequately protect against Spectre variant 1 and 2. At this time it is not always clear what level of protection is gained vs what level of performance loss.

Then again

With no known or imminent threat on the horizon many feel inclined to not patch and maintain the performance benefits of not patching. The weak-points presented by vulnerable OS permitting exploitation of (server-side and client-side) JavaScript were patched. Effectively mitigating the only immediate threat, the user experience.

Security researchers working with the Proof of Concept code note improvements were made to initially slow exploits for these bugs and they expect threat actors may start using these bugs in the near future.

There are notable objections to this by other researchers who state it is "threatonomically" not interesting to do so. Many other bugs exist and are far easier to exploit and are chain-able into equally devastating cyber attacks.

In the end

In general there is notable consensus Meltdown was and is adequately addressed, which posed the greatest threat. Spectre remains hard to fix because it involves a lot of work and follow-up but is also hard to effectively exploit.

The bottom line is these side-channel bugs have more technical people dumbfounded when it comes to assessing the real-world impact than most are willing to admit.

In this case i can only suggest to stay vigilant and track updates and news regarding.

When it comes to BIOS updates i'd recommend to implement these but consider these may actually also cause performance penalties and other mischief. Read any release notes regarding and compare them with those for applications under heavy load.

Take care,

You are welcome to share your questions or observations regarding for discussion.