The Spectre and Meltdown flaws disclosed in early 2018 were a wake-up call to the industry about side-channel attacks, and how these classes of vulnerabilities could play havoc with the security assumed to be present in microprocessors.
Now, one of the researchers behind the Spectre study -- along with four others -- has come up with a different kind of side-channel attack that has nothing to do with hardware. Instead, this flaw focuses on the caches that are used in the operating system software. (See Spectre, Meltdown Vulnerabilities Will Haunt Industry for Years.)
In the paper, "Page Cache Attacks," methods are shown that work on Linux and Microsoft Windows. Further, the researchers think the method they have described should work on Apple's macOS, although they admit they have not tested it yet.
The page cache is a purely software cache that contains all disk-backed pages that are used by the OS. The operating system uses the page cache to store frequently used pages in memory to help minimize the delay of retrieving the information from disk. These pages are shared among all processes regardless of privilege and permission boundaries.
All modern operating systems, including Windows, Linux and macOS, implement a page cache. The paper assumes that attacker and victim have access to the same operating system page cache. This is a reasonable assumption for processes running under the same operating system, or processes running in isolated sandboxes with shared files.
The new attack uses standard operating system calls -- mincore on Linux and QueryWorkingSetEx on Windows -- to find the page cache information. The minicore call returns which pages of a memory range are present in memory, while QueryWorkingSetEx returns a list of pages that are in the current working set of a process, and so are present in the page cache.
The researchers found that attack is much more efficient within Windows than on Linux due to the differences in the system functions. Windows has per-process working sets, so the page cache is influenced by these working sets. For Linux, the page cache is directly influenced by all processes that are invoked.
The attack goes on to use page cache eviction, which is the process of accessing enough pages in the right way so that a target page is evicted. By itself, this is usually too slow to allow this attack to work, but the researchers improved how eviction is performed so that at attack could succeed.
In the paper, they write about setting up specific attacks, such as a covert channel, which works by accessing or not accessing specific pages. They also tried user-interface redress attacks which use the side-channel in a chip as a trigger. The basic idea is to detect when an interesting window is opened and to place an identically looking fake window over it.
The researchers also experimented with an inter-keystroke timing attack on a keyboard input in the root authentication window on Ubuntu 18.04.
Since remote attacks cannot use mincore to check which pages are in cache, an attacker would need to rely on timing.
Mitigation would involve making it harder to use the system calls by increasing the privilege levels. For Linux, the researchers found that "making the mincore system call privileged is feasible and would mitigate our attack at a very low implementation cost," according to the paper.
For Windows, the share count information could be omitted from the structure returned by QueryWorkingSetEx as it exposes information about other processes to the attacker. Also, QueryWorkingSetEx should not allow one process to obtain working-set information of another process, according to the official documentation. The researchers note that Windows 10 19H1 will make these changes to the OS.
It seems that the OS manufacturers will need to fix this attack vector. Fortunately, it seems they can do it without too much fuss.
— Larry Loeb has written for many of the last century's major "dead tree" computer magazines, having been, among other things, a consulting editor for BYTE magazine and senior editor for the launch of WebWeek.