Linux and Windows Address Page Cache Vulnerabilities

In early January security researchers located further vulnerabilities in how Windows and Linux operating systems use a memory page cache.

How severe are these vulnerabilities and what is their impact?
One of the co-authors of the academic paper disclosing these vulnerabilities described the work as mostly “a matter of academic interest” meaning that attackers are less likely to take advantage of these vulnerabilities.

Local attacks:
For the localised rather than remote variant of utilizing these vulnerabilities; the attacker must already have gained access to the victim system to read the target memory page. The attacker could do this by “[having a] malicious process on the operating system or when processes run in sandboxes that have shared files”.

Other actions an attacker could potentially carry out are:

• Cloning an open window and replacing the legitimate application window
• Gathering the root (Linux) or administrator (Windows) password

Remote attack:
To exploit the vulnerabilities remotely; the researchers leveraged “timing differences between memory and disk access, measured on a remote system, as a proxy for the required local information”. This was achieved by measuring the times when soft page faults (the page is erroneously mapped, with the help of a process that runs on a remote server) occurred. The researchers were successful in sending data covertly from an unprivileged malicious process within the victim system to a remote server fulfilling the role of a web server. They used a technique from previous research namely the NetSpectre attack to distinguish cache hits and misses over a network connection. This was successful on systems with mechanical hard drives (HDDs) and solid-state disks (SSDs). SSDs were more complex since the timing differences were smaller but the researchers compensated by using larger files to distinguish between cache hits and misses.

How can I protect my organization/myself from these vulnerabilities?
Since these vulnerabilities are more academic in nature; attackers are less likely to exploit them. Linus Torvalds has explained that the code to resolve this vulnerability has been checked in and is undergoing testing before being more widely rolled out. For Windows; Build 18305 of the upcoming Windows 19H1 (otherwise known as Version 1903) due for release in April 2019 contains fixes for these vulnerabilities. It is anticipated Microsoft will back-port this patch to earlier Windows versions.

In addition; the mitigations for the Spectre vulnerabilities from last year should address the remote attack vector using the NetSpectre attack method.

Why are there so many timing attacks being disclosed lately?
Since modern systems rely on timing for almost every component e.g. the CPU (internal caches and registers respond in nanoseconds (ns)), the memory/RAM (e.g. CAS latency), HDDs (measured in milliseconds (ms) e.g. 8.9 ms), SSDs (e.g. 0.05 ms , much faster) we are likely to continue to see further vulnerabilities disclosed as further scrutiny is applied to devices and architectures that have been in use for many years.

E.g. the affected code from Linux was timestamped in 2000 and stated that further revision should be carried out when more information was known. 19 years later we know more and are revising that code. It’s a similar situation with Windows where the revised code works to ensure low privilege processes can no longer access page cache information or shared cache information. As The Register points out; “something complex that’s just working can remain untouched for a very long time, lest someone breaks it” and is more likely to contain vulnerabilities since nobody has taken the time to look for what has been there for years.

Thank you.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.