You may have read about an emerging threat to all computers using Intel® Central Processing Units (CPUs) built since 1995. This includes Windows servers, PCs, iPhones, iPads, and Macs, among other devices.  A hardware bug could allow attackers to obtain access to sensitive information on a computer system. AMD processors are also theoretically subject to the same type of attack; however, there is no verified proof of concept for attacks on those CPUs at this time.

Hardware vulnerabilities are especially difficult to deal with, because the only foolproof solution is to scrap the hardware and go with something else that's not vulnerable -- which is a very expensive proposition.  Imagine if a large property management company owned 50 servers and 2,000 endpoints (workstations, laptops, tablets, etc.).  That could be a $4-5 million bill. And what about the cloud computing companies? They could have server farms with hundreds of thousands of systems that could be affected.

Operating system and application (say, Web browser) security patches addressing the issue are only partial solutions.  If attackers figure out a way to bypass those software protections, all systems with Intel CPUs could still be at risk.

The flaw is described in an alert issued by the United State Computer Emergency Response Team (US-CERT) No. TA18-004A:  Meltdown and Spectre Side-Channel Vulnerability Guidance, which also has a list of patches and guidance available from vendors.

While I recommend installing these patches for all affected devices immediately, you should be aware that after doing so, you may see your performance speed diminished by as much as 30%, according to the US-CERT alert. Intel has downplayed the potential performance impact and insists most users will notice little to any performance issues. Still, US-CERT says system administrators should ensure that performance is monitored for critical applications and services, and work with their vendors and service providers to mitigate the effect if possible.

Sadly, making our processors faster to support such things as gaming has come at the cost of security, and the only real fix now may end up being to slow things down. The solution for this issue is to prevent "speculative execution", which significantly slows down CPU performance.

Let me explain this bug a little further for you in layman's terms:

Program branching is an expensive process (in terms of time/power), so Intel CPUs -- the "brains" of the PC that do all of the internal calculations required for computing -- pre-fetch possible execution instructions in memory (called speculative execution). However, researchers found out that you can read those instructions because they’re not in protected memory space. This could include reading sensitive data such as passwords. So, the only way to fix this is with operating system (and application) patches that prevent you from pre-fetching or getting to unprotected memory. 

What I mean by branching is a program can have conditional execution (e.g., if-then statements), and the processor tries to speed this up by queuing possible execution paths. Unfortunately, they are queued into memory space that attackers figured out can be accessed. 

Interestingly, I saw a talk at the RSA Security Conference way back in 2005 on a similar issue – a side-channel attack that could allow an attacker to read data encrypted by the Advanced Encryption Standard (AES).  A "side channel" means that you are not guessing the key to decrypt; rather you are examining either the timing (how long it takes to do an operation) or the power (electrical emanations given off by the circuit), and using these to deduce what operations are taking place, and thereby defeating the encryption.

Operating systems do a similar thing to what the Intel CPU does - they try to cache instructions ahead of time for speed enhancement.  By examining Windows pre-fetch instructions (which are in user space; i.e., unprotected memory), the researcher showed he could just clear that pre-fetch memory and time how long it took to get rewritten, and then he would know what characters were being encrypted. He could break AES with about 15 chosen plaintexts. And his program ran in ring 3 (i.e., unprivileged) on the operating system. I remember thinking at the time that being able to access the memory of other running programs as an unprivileged user was actually the bigger flaw than being able to clear the memory to break AES.

The issue today with Spectre and Meltdown is that what was once considered to be a very complex problem now has working proof-of-concept exploits that could soon be “weaponized” by attackers.  At this time, I am not aware of any malware that makes use of these exploits out "in the wild" as yet; but we can only assume it is coming. 

I have read that “analysis of these techniques revealed that while they are extremely difficult to exploit, even by an app running locally on a Mac or iOS device, they can be potentially exploited in JavaScript running in a Web browser."  That doesn’t sound that difficult to me!  So, standby, we may see some gruesome malware coming out in the future.

What can we do about it?  The usual advice we provide is a 5-pronged approach we call Cyber SMART:

S = self-governance; making sure you have the proper cybersecurity framework in place with governing policies & procedures.

M = monitoring; you need to have visibility into your IT infrastructure and always be watching for potential attacks and indicators of compromise (IOCs).

A = assessments; get third-party audits of your systems on a regular basis, and develop a plan of actions for addressing any gaps.

R = remediation; this is not only having a system of regular vulnerability scanning & patching in place, but also having a formalized incident response policy and forensic readiness (i.e., have adequate audit logs and an investigative team standing by should something happen).

T = training; people are the first and last line of defense, and by enhancing education & awareness, we can help keep them from undermining the other security controls that are in place in the system.