A surprising (to me) amount of press coverage on these two vulnerabilities. I am usually more alarmed when vulnerabilities are revealed.
I wrote kernel level code for microprocessors back in the 1970s and have used that experience in modern day computer forensics for many years.
There are currently many ways to exploit similar vulnerabilities, but those till now were application and/or operating system dependent. These two vulnerabilities are processor dependent.
Modern processors have multiple threads, multiple cores, and can have multiple chips making up the Central Processing Unit (CPU). To take advantage of all these threads, cores, chips processors now "predict" program behaviours, prefetching blocks of memory for opcode decoding and cache population. This allows system speed up. A problem occurs when the application does not take the code path the processor "predicted". Now a block of code is in cache that will not be executed. That unused cached block of memory will be overwritten with new "predicted" pre-fetch blocks soon, but until it is the code running on the processor can access that block. That's the problem. That is the vulnerability.
IF (big if) that pre-fetched block in cache has a memory copy of secret session keys, unencrypted passphrases, or other sensitive data and is accessed (read) by the processes running on the processor before the cache has the "dirty" bit set - the vulnerability as been exploited.
Meltdown allows a process to access memory mapped by that process. Some applications run multiple process threads (different from processor threads) to save memory and processor time, the vulnerability allows a covert channel between the multiple users of that application. In any case the process can gain access to kernel memory which it should not be able to do.
Sepctre allows a process to read memory belonging to another process.
Vulnerabilities and exploits are both required to affect a compromise. Several years ago a savvy attacker could work months attempting a compromise. Now with many many attackers focused on the vulnerability compromises should appear more rapidly.Now ass machine learning and Artificial Intelligence. Once a compromise is found, it is available to anyone made aware.
The linux kernel is open source. Kernel level developers and maintainers around the world work on the linux kernel. An increase in activity around memory management for the kernel was noted recently. The comments to the code were cryptic, then redacted. Most linux distributions have been patched.
The patches may cause slower performance on high performance applications with lots of unpredictable branches (eg. games).
The patches may cause problems with applications that rely on kernel code analysis and/or analyzing process behaviors (security suites). Security suite vendors are working on patches as well.
The primary method of exploit in my view will be browsers and tabs. For
safer browsing:
Use a different browser for sensitive sites (banks, brokers, shopping, etc.)
Use security add-ons and extensions on that browser so used
Before every sensitive session, check for browser, add-on, and extension updates. Apply if they are available
Use the newly invoked browser for ONE session. Exit the browser. Then repeat for the next session.
AVOID multiple tabs for multiple sensitive sessions.
The Chrome browser has "Strict site isolation" that can be enabled
Type chrome://flags in the address bar
Turn on "Strict site isolation"
Then relaunch Chrome. I would recommend doing both Strict site isolation AND a separate browser session for sensitive sites as common best practice.
This may be a story / issue for some time. I will attempt to update the blog posts with information as I am able.
