PPage Cache Attacks
Daniel Gruss , Erik Kraft , Trishita Tiwari , Michael Schwarz , Ari Trachtenberg , Jason Hennessey , Alex Ionescu , Anders Fogh Graz University of Technology, Boston University, NetApp, CrowdStrike, Intel Corporation
Abstract
We present a new hardware-agnostic side-channel attack thattargets one of the most fundamental software caches in mod-ern computer systems: the operating system page cache. Thepage cache is a pure software cache that contains all disk-backed pages, including program binaries, shared libraries,and other files, and our attacks thus work across cores andCPUs. Our side-channel permits unprivileged monitoring ofsome memory accesses of other processes, with a spatial res-olution of 4 kB and a temporal resolution of 2 µs on Linux(restricted to 6 . Modern processors are highly optimized for performanceand efficiency. A large share of these optimizations is basedupon caching - taking advantage of temporal and spatial lo-cality to minimize slower memory or disk accesses. Indeed,caching architectures typically fetch or prefetch code anddata into fast buffers closer to the processor.Although side-channels have been known and utilized pri-marily in military contexts for decades [41, 78], the idea ofcache side-channel attacks gained more attention over the last twenty years [3, 40, 53]. Osvik et al. [51] showed thatan attacker can observe the cache state at the granularity ofa cache set using Prime+Probe, and later Yarom et al. [77]showed this with cache line granularity using Flush+Reload.While different cache attacks have different use cases, theaccuracy of Flush+Reload remains unrivaled.Indeed, virtually all Flush+Reload attacks target pages inthe so-called page cache [30, 33, 34, 35, 42, 77]. The pagecache is a pure software cache implemented in all major op-erating systems today, and it contains virtually all pages inuse. Pages that contain data accessible to multiple programs,such as disk-backed pages (e.g., program binaries, shared li-braries, other files, etc.), are shared among all processes re-gardless of privilege and permission boundaries [24]. Theoperating system uses the page cache to store frequentlyused pages in memory, this obviating slow disk loads when-ever a process needs to access said pages. There is a largebody of works exploiting Flush+Reload in various scenariosover the past several years [30, 33, 34, 35, 42, 77]. Therehave also been a series of software (side-channel) cacheattacks in the literature, including attacks on the browsercache [5, 20, 36, 37, 72] and exploiting page deduplica-tion [2, 6, 26, 52, 55, 68, 75, 76]; however, page dedupli-cation is mostly disabled or limited to deduplication within asecurity domain today [46, 56, 71].In this paper, we present a new attack on the operating sys-tem page cache. We present a set of local attacks that workentirely without any timers, utilizing operating system calls( mincore on Linux and
QueryWorkingSetEx on Windows)to elicit page cache information. We also show that pagecache metadata can leak to a remote attacker over a networkchannel, producing a stealthy covert channel between a ma-licious local sender process and an external attacker.We comprehensively evaluate and characterize thesoftware-cache side channel by comparing it to hardware-cache side channels. Like the recent DRAMA attack [54,73], our side-channel attack works across cores and acrossCPUs with a spatial granularity of 4 kB. For comparison, thespatial granularity of the DRAMA attack is 2 kB on dual- a r X i v : . [ c s . CR ] J a n hannel systems up to and including the Haswell processorarchitecture, and 1 kB on more recent dual-channel systems.The temporal granularity of the DRAMA attack is around300 ns, whereas the temporal granularity of our attack is 2 µson Linux (restricted to 6 . We begin with a brief discussion of hardware and softwarecache attacks, followed by some background on the operat-ing system page cache that we exploit.
The suggestion of cache attacks harks back to the timing at-tacks of Kocher [40]. Osvik et al. [51] presented a techniquewith a finer granularity called Prime+Probe. Yarom et al.[77] presented Flush+Reload, which is still today the cacheattack technique with the highest accuracy (virtually no falsenegatives or false positives) and a finer granularity than mostother attacks (one cache line). Consequently, Flush+Reloadis also used in other applications, including the covert chan-nel in Spectre [39] and Meltdown [43]. Flush+Reload re-quires shared memory with the victim application. However, all modern operating systems share code and unmodifieddata of every program and shared library (and any unmod-ified file-backed page in general) across privilege boundariesand applications.Caches also exist in software, caching remote data, datathat has been retrieved from slow or offline storage, or pre-computed results. Some of these caches have very specificuse-cases, such as browser caches used for website content;other caches are more generic, such as the page cache thatstores a large portion of code and data used. Caches makeuse of the principle of locality to retain common computa-tions closer to the processor, and consequently they can leakinformation about the cache contents.For example, browser caches leak information aboutbrowsing history and other possibly sensitive user informa-tion [5, 20, 36, 37, 72]. Requested resources may have dif-ferent access times, depending on whether the resource isbeing served from a local cache or a remote server, andthese differences can be distinguished by an attacker. Asanother example of a software-based side channel, page-deduplication attacks exploit page deduplication across secu-rity boundaries. A copy-on-write page fault reveals the factthat the requested page was deduplicated and that anotherprocess must have a page with identical content. Suzaki et al.[68] presented the first page-deduplication attack, whichdetected programs running in co-located virtual machines.Subsequently, several other page-deduplication attacks weredemonstrated [26, 52, 75, 76]. Today, page deduplication iseither completely disabled for security reasons or restrictedto deduplication within a security domain [6, 46, 55, 56].
Virtual memory creates the illusion for each involved pro-cess of running alone on the system. To do this, it providesisolation between processes so that different processes mayoperate on the same addresses without interfering with eachother. Each virtual memory page may be mapped by the op-erating system, with varying properties, to an arbitrary phys-ical memory page.When multiple processes map a virtual page to the samephysical page, this page is part of shared memory . Sharedmemory typically may arise out of inter-process communi-cation or, more broadly, to reduce physical memory con-sumption. For example, if shared library and common bi-nary pages on the hard disk are mapped multiple times bydifferent processes, they map to the same pages in physicalmemory.Indeed, any page that might be used by more than oneprocess may be mapped as shared memory. However, if aprocess wants to write to such a page, it must first securea private copy of the page, so as not to break the isolationbetween processes. The efficiency savings come because areat many pages are never modified and, instead, remainshared among multiple processes in a read-only state.The operating system page cache is a generalization of theabove memory sharing scenario, and, in fact, all modern op-erating systems (e.g., Windows, Linux, and OS X) imple-ment a page cache. The page cache contains all pages that arememory mapped files, any file read from the disk, and (de-pending on the system) possibly other pages such as anony-mous pages or shared memory [24]. The operating systemkeeps track of which pages in the page cache are clean ( i.e. ,their data is unmodified from the disk version) and whichare dirty ( i.e. , modified since they were first loaded from thedisk). Ideally, the page cache incorporates all available mem-ory, allowing the operating system to minimize the disk I/O.The introduction of a page cache disrupts the traditionalfunctioning of the operating system under a page fault. With-out a page cache, the operating system reserves a free phys-ical page frame, loads the data from the disk into that physi-cal page frame, and then maps a virtual page to the physicalpage frame accordingly. If there are no available physicalpage frames, the system swaps out pages to the disk usingan operating system-dependent page-replacement algorithm.In Linux, this algorithm had traditionally been based on avariant of the Least Recently Used (LRU) paradigm [11],and LRU-related data structures can still be found through-out the kernel code. More recent Linux versions implementan improved variant called CLOCK-Pro [38] along with sev-eral adaptions [12]. Within this improved framework, Linuxmoves pages among multiple lists (an inactive list, an ac-tive list, and a recently evicted list). In contrast to Linux,Windows uses the working-set model of page caching to in-troduce more fairness among processes competing for mem-ory [8, 16, 17]. The page replacement algorithm used onWindows was based on Clock or pseudo-random replace-ment [23, 60] in older Windows versions, and today is likelya variant of the Aging algorithm [7].With a page cache, the operating system endeavors tomake full use of all physical page frames, and a page-replacement algorithm is still needed for evicting page cachepages (swapping is less relevant on modern operating sys-tems [14, 15, 32]). Also pages from KVM virtual machinesare cached in the host-side page cache if the machine is con-figured to use a write-back caching strategy [18].Both Linux and Windows provide mechanismsfor checking whether a page is resident in the pagecache - the mincore system call for Linux, and the
QueryWorkingSetEx system call for Windows.
Our threat model is based on the threat model for Flush+Reload [30, 33, 34, 35, 42, 77].Specifically, we assume that attacker and victim have ac-cess to the same operating system page cache. On Linux, we also assume that the attacker has read access to the tar-get page, which may be any page of any attacker-accessiblefile on the system. This assumption is satisfied, for example,when attacker and victim are • processes running under the same operating system, or • processes running in isolated sandboxes with shared files(e.g., Firejail [21]).On Windows, read access to the target page is not necessaryfor our attack.Our local attacks are timing-free, in that they do not relyon hardware timing differences. Our remote attack leveragestiming differences between memory and disk access, mea-sured on a remote system, as a proxy for the required localinformation. Our attack fundamentally relies on the attacker’s capabilityto distinguish whether a page is in the page cache or not. Inthe local attack we are agnostic to the underlying hardware, i.e. , we do not exploit any timing differences although thiswould be practically possible on virtually all systems. Thus,we use the mincore system call on Linux for this purposeand the
QueryWorkingSetEx system call on Windows. The mincore system call returns which pages of a memory rangeare present in memory ( i.e. , in the page cache) and which arenot. Likewise, the
QueryWorkingSetEx system call returnsa list of pages that are in the current working set of a process,and thus are present in the page cache.Bringing the page cache into a known state is not triv-ial, as it behaves like a fully associative cache. Previous ap-proaches for page cache eviction can lead to out-of-memorysituations [28, 66, 71] or consume too much time and im-pose system pressure [27]. This is not practical when evict-ing pages often, e.g., multiple times per second. Hence,they have not been used in published side-channel attacksso far, but only to support other attacks, e.g., relocation ofa page for Rowhammer. For Linux, we devise a working-set-based eviction strategy that efficiently accesses groups ofother pages more frequently than the page to evict.On Windows, our attack is much more efficient than onLinux. On Linux, the page cache is directly influenced byall processes. In contrast, Windows has per-process workingsets [47], and the page cache is influenced indirectly throughthese working sets. Hence, for Windows, we present an at-tack which evicts pages only from the working set of thevictim process, but not from the page cache ( i.e. , not fromDRAM), i.e. , causing no additional disk accesses. Althoughboth attack variants follow the same attack methodology, wehave to distinguish between the Linux and Windows variantat several places in the remainder of the paper.In contrast to hardware cache attacks and page-deduplication attacks, our local attacks are non-destructive,allowing us to repeat measurements. Measuring whether ttack Programt t E Victim
Victim
Target Page Content oflibfoobar.soRelativeVirtual Address
Present Flag
Relative Virtual Page
10 t1 2 3 4 5 6
Target page not present: wait for victim activity
Target page present: evict target page + wait for victim activity
Target page not present: wait for victim activity
Target page not present: wait for victim activity
Target page present: evict target page + wait for victim activity
Target page not present: wait for victim activity
Target page not present: wait for victim activity0123456 ...
Figure 1: Attack overview. a memory location is cached or not manipulates the statesuch that the information is not available anymore at a laterpoint in both hardware cache attacks [51, 77] and page-deduplication attacks [52, 68]. However, it is not the casefor our local attack. As we rely on the mincore and
QueryWorkingSetEx system calls, we can arbitrarily checkwhether the page is in the page cache (on Linux) or the pro-cess working set [47] (Windows). These checks are non-destructive as they neither modify nor influence the state ofthe page cache or the process working set with respect to thetarget memory location.Our attack is illustrated in Figure 1. The attacker wantsto measure when the function foo() is called by a victimprogram. The attacker determines the page which containsthe function foo() . By observing when the page is in thepage cache, the attacker learns when foo() was called.Our attack continuously runs through the following steps:Initially, the target pages are in the page cache (on Linux)respectively the working set of the victim process (on Win-dows). After the eviction, the page is not in the page cache(Linux) or process working set (Windows) anymore. The at-tacker can now continuously probe when the page is addedback in. As soon as the page is found in the page cache(Linux) or the process working set (Windows), the attackerlogs the memory access and evicts the page again.In the following sections, we detail the two main steps ofthe attack, i.e. , determining the page cache state (defining thetemporal resolution) and performing the page cache eviction(defining the maximum frequency at which the attack can beperformed).
In this section, we discuss how to determine the page cachestate. Note that although our attack starts with the page cacheeviction, following the attack description is easier when un-derstanding how to determine the page cache state first.The attacker wants to determine when a specific page froma shared library is loaded into the page cache, as this is ex-actly the time of the access by the victim program. Thus,the shared library containing the target page an attackerwants to observe accesses to has to be mapped into the at-tacker’s address space. This is possible using mmap on Linuxand either
LoadLibraryEx or CreateFileMappingA and
MapViewOfFile on Windows.To map the shared library, the user only requires read-onlyaccess to the file containing the target page. As the attackerprocess works on its own mapping of the shared library, alladdresses are observed relative to the start of the shared li-brary. Hence, security mechanisms such as Address SpaceLayout Randomization (ASLR) have no effect on our attack.To determine whether or not a page is in the page cache,we rely on the operating-system provides APIs to query thepage cache. On Linux, this API is provided by the mincore system call. mincore expects the base address and length ofa memory area and returns a vector indicating for each pagewhether it is in the page cache or not. On Windows, thereare two variants which are discussed as follows.
On Windows, every process has a working set which is avery small subset of the page cache. We cannot query thepage cache directly as on Linux but instead we focus onthe working set. While this makes determining the cachestate more complex, the following eviction is much eas-ier and faster (cf. Section 6.2). On Windows, we relyon the
QueryWorkingSetEx system call. This functiontakes a process handle and an array specifying the vir-tual addresses of interest as arguments. It returns a vec-tor of structures which, if the page is part of the work-ing set, contain various information about the correspond-ing pages. In contrast to the official documentation [47],the
QueryWorkingSetEx system call only requires the
PROCESS QUERY LIMITED INFORMATION permission. Bydefault, the attacker process has this permission for handlesof other processes of the same user and even for some pro-cesses with a higher integrity level (as part of the genericexecute access) [48]. We devise two different variants to de-termine whether or not a page is in the working set of a pro-cess based on the return value of the
QueryWorkingSetEx system call.
Variant 1: Low Share Count and Attacker-Readable.
The
ShareCount represents the number of processes thathave this page in their working set. It is one of the mem-ers in the structure returned by
QueryWorkingSetEx . Un-fortunately, the value is capped to 7 processes, i.e. , if moreprocesses have the page in their working set, the numberremains 7. However, as the working-set size is limited to1 . ShareCount of 0 dueto the small working-set sizes. With this variant, we do notneed any permissions for other processes. Hence, we canmount the attack even across users without restrictions.
Variant 2: High Share Count or Not Attacker-Readable.
If the
ShareCount is 7 or larger, we cannot gain anyinformation by calling
QueryWorkingSetEx on our ownprocess. Instead, we can use
QueryWorkingSetEx di-rectly on the victim process, i.e. , the attacking process musthave the
PROCESS QUERY LIMITED INFORMATION permis-sion for the victim process handle. As
QueryWorkingSetEx takes virtual addresses, we need to figure out the virtual ad-dress. This is not a problem if pages from shared files aretargeted (e.g., shared libraries) as they are typically mappedto the same virtual address in different processes. How-ever, if the pages are not shared, i.e. , not attacker-readable,
QueryWorkingSetEx still leaks information if the virtualaddress is known. Hence, we can use
QueryWorkingSetEx to determine directly whether the target page is in the work-ing set of the victim process.
One limitation of our attack is the coarse spatial granular-ity of 4 kB, i.e. , one page. This is identical to a recent at-tack on TLB entries [25] and similar to the DRAMA at-tack [54, 73] on a single-channel DDR3 system, which hasthe same spatial granularity (one 4 kB page). The spatialgranularity of the DRAMA attack increases with the num-ber of banks, ranks, channels, and processors. It is 2 kB ondual-channel systems up to Haswell, and 1 kB on more re-cent dual-channel systems. If a target region contains otherfrequently used data, the signal-to-noise ratio decreases inour attack just as it does for the DRAMA attack. However,this just increases the number of measurements an attackerhas to perform.The temporal granularity of the DRAMA attack is con-strained by the time it takes to run one or two rounds ofFlush+Reload, which is around 300 ns [54, 73]. The tem-poral granularity of our attack is constrained by the timethe system call consumes, which we observed to be 2 .
04 µson average for mincore with a standard error of 20 ns, and465 .
91 ns on average for
QueryWorkingSetEx with a stan-dard error of 0 .
20 ns. Hence, on Linux, it is only 6 . i.e. , 6 . mincore and QueryWorkingSetEx
As an alternative to mincore on Linux, we also investi-gated whether it is possible to mount the same attack us-ing procfs information, namely /proc/self/pagemap .However, /proc/self/pagemap only shows the informa-tion from the page translation tables. As operating systemscommonly use lazy page mapping, the page is in practicenot mapped into the attacker process and thus, the informa-tion in /proc/self/pagemap does not change. Further-more, as a response to Rowhammer attacks [66], access to /proc/self/pagemap was first restricted and nowadays itis often not accessible by unprivileged processes.As a more generic alternative to mincore and
QueryWorkingSetEx , we investigated the timing ofpagefaults as another source of information. Accessing apage may trigger a pagefault. Measuring the time it takes tohandle the pagefault reveals whether it was a soft pagefault,mapping a page already present in the page cache, or aregular pagefault, loading data from the disk. The timingdifferences we observed there are easy to distinguish, with1 to 2 orders of magnitude between the two cases. In ourremote attack we exploit these timing differences. However,this makes page cache eviction more difficult as the accessedpage is now the least-recently used one.Finally, as stated in Section 3, our local attacks are entirelyattack hardware-agnostic. Hence, we cannot use any timingdifferences in our local attacks.
In this section, we discuss how page cache eviction canbe implemented efficiently on Linux and Windows systems.Page cache eviction is the process of accessing enough pagesin the right way such that a target page is evicted. We showthat we improve over state-of-the-art eviction algorithms by1 to 2 orders of magnitude, enabling practical side-channelattacks through the page cache for the first time.Less efficient variants of page cache eviction have beenused in previous work [27, 31]. Holen et al. [31] generates alarge amount of data, simply exhausting the physical mem-ory. Using this approach it takes 8 s or more to evict a tar-get page on Linux. Furthermore, when reproducing their re-sults we observed severe stability issues, constantly leadingto crashes and system lock-ups during eviction. The tech-nique presented by Gruss et al. [27] takes 2 .
68 s on Linux toevict a target page. On Windows, their technique is slower,with an average execution time of 10 . The optimal cache eviction for the attacker would evict onlythe target page of the victim, without affecting other cachedpages. Hence, our idea is to mostly access pages which arealready in the page cache (to keep them there) and also ac-cess a few non-cached pages in order to evict the target page.In a feasibility analysis, we measured how many pages anattacker can locate inside the page cache. On our test system,we had 1 040 542 files accessible to the attacker program,amounting to 77 GB of disk space. We found that less than1 % of the files had pages in the page cache, still amountingto 68 % to 72 % of the total page cache pages. This informa-tion is all available to an unprivileged attacker using systemcalls like mmap and mincore . The attacker creates a long listof all pages currently in the page cache. The attacker alsocreates a list of further pages that could be loaded into thepage cache to increase memory pressure. Both lists can beupdated occasionally to reflect changes in the system mem-ory use. The attacker adapts the amount of pages accessed inthese two lists to achieve efficient cache eviction.This is done by creating 3 eviction sets:
Eviction Set 1.
These are pages already in the page cache,used by other processes. To keep them in the page cache,a thread continuously accesses these pages while also keep-ing the system load low by using sched yield and sleep .Consequently, they are among the most recently accessedpages of the system and eviction of these pages becomeshighly unlikely.
Eviction Set 2.
These are pages not yet in the page cache.Using mincore , we can check whether the target page wasevicted, and stop the eviction immediately, reducing the evic-tion runtime. Pages in this eviction set are randomly ac-cessed, to avoid repeated accesses and thus any similarityto the pages in eviction set 1 for the replacement algorithm.
Eviction Set 3.
If swapping is disabled, we use anothereviction set, namely non-evictable pages, e.g., dynamic con-tent. These pages are only created and filled with content, butnever again read or written. As they cannot be swapped, theyblock a certain amount of memory, reducing the requiredeviction-set size. This reduces the runtime of the evictionsignificantly. Still, this introduces no stability issues, as wealways keep a large amount of pages ready for immediateeviction, i.e. , the previous 2 eviction sets.
Alternative Approaches and Optimizations.
We investi-gated whether the file system influences the attack perfor-mance. For our tests, we used ext4 as a file system. We compared the attack performance by running our attack on
XFS and
ReiserFS . However, we only found negligible tim-ing differences.We also investigated whether the use of the madvise and posix fadvise system calls on Linux can improvethe attack performance. These system calls allow a pro-grammer to provide usage hints for a given memory orfile range to the kernel. The advice
MADV DONTNEED indi-cates that the process will not access the specified pages anytime soon again, whereas the advice
MADV WILLNEED indi-cates that the process will soon access the specified pagesagain. Thus, the operating system will evict the corre-sponding pages from the page cache. We found that mark-ing the target page as
MADV DONTNEED and all eviction setpages as
MADV WILLNEED was often ignored by the ker-nel, which ignores these hints unless the process exclusivelyowns the pages ( madvise ) or when no other process hasthe file mapped ( posix fadvise ). Still, this allows to use posix fadvise on files regardless how frequently they areaccessed, e.g., via read() , as long as they are not mapped.Hence, we are able to mount a covert channel by using posix fadvise on a file which was not mapped by any(other) process, instead of eviction.
We measured the precision and recall of our eviction by mon-itoring a periodic event which was triggered every second.The page cache eviction using all 3 eviction sets simultane-ously achieves an average runtime of 149 ms ( σ = . . .
04 µs on Linux, the rate at which events can be ob-served in practice is lower. The reason is that, if the event oc-curs, eviction is necessary, and thus, the temporal resolutionfor events with a higher frequency is limited to 149 ms onaverage. This still allows capturing more than 6 keystrokesper second, enough to capture keystrokes accurately for mostusers [64]. In this case, the temporal resolution of theDRAMA attack is 6 orders of magnitude higher [54, 73].The temporal resolution is also significantly higher thanthat of page-deduplication attacks. The frequency at whichpage deduplication happens is lower the more memory thesystem has, and has in use, and the less power the deviceshould invest in deduplication. In practice deduplicationhappens every 2 to 45 minutes, depending on the system con-figuration [26]. Hence, our attack has an at least 800 timeshigher temporal resolution than the best page-deduplicationattacks.
Limitations.
One obvious limitation of our approach is thatthe target page has to be in the page cache. However, asdetailed in Section 2.2, virtually all pages used by user pro-grams end up in the page cache, even dynamically allocatedones.n Linux, the page must also be accessible to the attacker,e.g., file-backed memory such as binary pages, shared librarypages, or other files. This is exactly the same requirement(and limitation) of Flush+Reload attacks [30, 33, 34, 35, 42,77]. Other microarchitectural attacks, e.g., Prime+Probe,may not have this requirement but usually have other sim-ilarly constraining requirements, such as knowledge of thephysical address which is difficult to obtain in practice [45].Page-deduplication attacks also do not have this limitation,but they face other limitations such as a significantly lowertemporal resolution and, more recently, that page deduplica-tion is mostly disabled or limited to deduplication within asecurity domain [46, 56, 71]. On Windows, we do not havethis limitation, i.e. , we can also attack dynamically allocatedmemory on Windows.Due to the nature of the exploited side channel, our attackcomes with clear limitations. Like other cache attacks, theside channel experiences noise if the target location is notonly used by the event the attacker wants to spy on but alsoother events. This is the same limitation as for any othercache side-channel attack [30, 77].Another limitation which frequently poses a problem inhardware cache attacks is prefetching [30, 77]. Unsur-prisingly, software again implements the same techniquesas hardware. When accessing the SSD, the Linux kernelreads ahead to increase the performance of file accesses. Ifnot specified otherwise, the readahead window is 32 pageslarge, cf. /sys/block/sda/queue/read ahead kb . Thisis similar to the adjacent line prefetcher and the stream-ing prefetcher in hardware. Whenever a cache miss occurs,the adjacent line prefetcher always fetches the sibling cacheline region into the cache, i.e. , the adjacent 64 B. When-ever a second cache miss within a page occurs, the stream-ing prefetcher reads ahead of the cache miss and reads up to512 B ( i.e. , 8 cache lines) into the cache. Gruss et al. [30]noted that this limits their attack to a small number of mem-ory locations per page. The same limitations apply to ourwork, i.e. , monitoring multiple pages within a 32-page win-dow can be noisy. However, we found that this still leaves amultitude of viable attack targets. To avoid triggering theprefetcher, we add the pages surrounding the target pageto the eviction set 1, i.e. , we reduce their chance of beingevicted, in order to avoid all noise from prefetching, as noother page from this range will be accessed.Finally, the attacker process can, of course, only performmeasurements and evictions when it is scheduled. Hence,scheduling can introduce false negatives into our attack.Again, this is also the case for hardware cache attacks [45].Compared to previous work, we improve the state-of-the-art for page cache eviction by a factor of more than 16 andadditionally avoid cache eviction in most cases (cf. Sec-tion 5). With these two building blocks, we are able tomount practical attacks as demonstrated in the following sec-tions. The ideal target for our attack is a function or data block which is used at frequencies below 8 times per second,but where a temporal resolution of 2 µs can leak a sufficientamount of information. Furthermore, our ideal target resideson a page which is mostly accessed for this function or datablock, and not for unrelated functions or data.
As previous page cache eviction techniques [27, 31] are tooslow to mount generic side-channel attacks, we pursue adifferent approach on Windows. Windows has per-processworking sets [47], which (by default) are constrained to asize between 100 kB and 1 . VirtualUnlock that comes from a programmingerror [48]. Calling
VirtualUnlock on a page which isnot locked evicts it directly from the working set. Forreasons of backward-compatibility, the behavior was neverchanged [48]. Additionally, pages which are only read inone of the processes can be locked, so that they are never re-moved from the working set. This way, arbitrary informationcan be encoded into the
ShareCount of the page cache pages– up to 3 bits exist, which allows 7 sharers. Hence, we cantransmit arbitrary information without any special privileges(as long as the receiver is not constrained by an App Con-tainer). The default maximum working-set size is 1 . SetProcessWorkingSetSize on the otherprocess [47]. The lowest possible value for the maximumworking-set size is 13 pages (52 kB).
We found that
VirtualUnlock has a success rate of 100 %over several million tests. The average time to evict apage from the process working set with
VirtualUnlock is4 .
48 ms with a standard error of 3 . VirtualUnlock consumes4 .
48 ms, limiting the temporal resolution for high-frequencyevents to 4 .
48 ms on average. Thus, locally the tempo-ral resolution of the DRAMA attack is 4 orders of magni-tude higher than the temporal resolution of the DRAMA at-tack [54, 73]. Again, this is fast enough for inter-keystroketiming attacks [49, 64].While prefetching posed a relevant limitation on Linux,it is no problem on Windows. On Windows, features likeSuperFetch fetch memory into the page cache, acting likean intelligent hardware prefetcher or speculative execution.Indeed, SuperFetch speculatively prefetches pages from thedisk into the main memory, based on similar past usage, e.g.,same time of day, same sequence of applications started [63].However, these pages are not added to the working set of anyprocess. Thus, our side channel remains entirely unaffectedby these Windows features. This makes the side channel verywell suited for inter-keystroke timing attacks [49, 64].
Limitations.
Our attack on Windows has clearlimitations, mainly introduced by the permissionsrequired by the attacker. More specifically, the
SetProcessWorkingSetSize system call requires the
PROCESS SET QUOTA permission on the process han-dle [47]. By default, the attacker process has this permissionfor handles of other processes of the same user running onthe same or a lower integrity level. Processes with a higherintegrity level, e.g., processes running with Administratorprivileges, cannot be attacked using this system call [48].The
VirtualUnlock only works on our own process andrequires no permissions. Also, noise is again a limitation,which exists for both the Linux and the Windows variantof our attack, but this is again also true for any other cacheside-channel attack [30, 45, 77]. In our tests, we werealways able to reliably evict the page from the victim’sworking set indicating very low error rates.
In this section we present and evaluate our local attacks.The temporal resolution naturally scales with the perfor-mance of the system. We perform all performance evalu-ations on recent systems with multiple gigabytes of RAM,with off-the-shelf mid-class consumer SSDs (e.g., transferrates above 250 MB / s [69]). For our tests on Linux, wehave swapping disabled. This is recommended with re-cent processors (e.g., Haswell or newer) and to reduce diskwear [14, 15, 32]. Disabling swapping allows for a bettercomparison with related work which also focuses on suchrecent systems [34, 42, 54, 73]. To systematically evaluate the page cache side channel, weadapt different state-of-the-art hardware cache attacks toit and demonstrate that they achieve a comparable perfor-mance. In this section, we cover the first example, a covertchannel between two processes additionally isolated by run-ning them in different Firejail sandboxes [21]. The stronglyisolated sender process sends a secret file from a restrainedenvironment to a receiver process which can forward the datato the attacker.As evicting a page is comparably slow (cf. Section 6),and checking the state of a page is comparably fast (cf.Section 5), it is optimal to reduce the number of evictions.Hence, it is more efficient to transmit multiple bits at once.We took this into account for the design of our covert chan-nel. We follow the basic principle of hardware cache covertchannels [29, 44, 45, 54]. First, a large shared file (e.g., ashared library) is mapped read-only into the address space ofthe sender and receiver process. As described in Section 4,we use mmap for this purpose on Linux. On Windows, we use
CreateFileMappingA and
MapViewOfFile for the samepurpose.The covert channel works by accessing or not accessingspecific pages. We use two pages to transmit a ‘READY’signal and one page to transmit an ‘ACK’ signal. The re-maining pages up to the end of the file are used as data trans-mission bits. The two ‘READY’ pages are used alternately toavoid any race conditions in the protocol between the trans-mission of two subsequent messages. On Windows, we usetwo ‘READY’ pages and two ‘ACK’ pages, for the two trans-mission directions.The present state of each page of the mapped file (cf. Sec-tion 5) corresponds to one bit of the message. Hence, thesize of the file defines the maximum message size of a sin-gle transmission. To avoid the prefetcher, we only allow asingle access in a region of 32 pages. If the file has a size S ,the (maximum) message size is computed as w = S · bits.For instance, on Linux, Firefox’ libxul.so or Chromium’s chromium-browser binaries are more than 100 MB large.Similarly, large files can also be found on Windows.These large files allow transmitting more than 3200 bitsin a single message including the 3 pages required for thecontrol channels. To avoid the introduction of noise, the at-tacker can skip noisy pages, i.e. , pages which are also ac-cessed by other system activity. By combining pages frommultiple shared libraries, the attacker can easily find a sig-nificantly higher number of pages that can be used for trans-missions, leading to very large message sizes w . The pagesare numbered from 0 , , .., i , .., w , i.e. , it is not relevant whichfile they belong to. Instead of a static list of files to check, theattacker could also use a dynamic approach and a jamming-agreement protocol [45].o exchange a message, the sender first checks the presentstate of the ‘ACK’ page (cf. Section 5). If the ‘ACK’ pageis present, the sender knows the receiver is ready for thenext transmission. The sender then evicts (cf. Section 6) anypages that are mapped, e.g., from previous transmissions.After that, the sender reads the next w bits ( w is the mes-sage size) from the secret to transmit. If the i -th bit is set,page i page is accessed. Otherwise, page i is not accessed.As soon as the sender is done with accessing the data trans-mission pages, it accesses the currently to-be-set ‘READY’page, to signal the receiver to start reading the message.On the other side, the receiver first waits until a ‘READY’page is present. As soon as it is set, the receiver reads themessage by analyzing the present state of the pages of thememory mapped files. After that, the receiver accesses the‘ACK’ page again to inform the sender that it is ready for thenext message.While above protocol is implemented with mmap , mincore (cf. Section 5), and page cache eviction (cf. Sec-tion 6.1) on Linux, we use a slightly different mechanismon Windows as we only work with working-set eviction (cf.Section 6.2). On Windows, we lock pages in the workingset which should always remain in the working set, i.e. , the‘READY’ and ‘ACK’ bit pages of the sender and the re-ceiver process on the corresponding receiving side. Addi-tionally, we increase the minimal working-set size so thatnone of the pages we use are removed from the workingset. We temporarily add pages into the working set by ac-cessing them and remove pages surgically from the workingset by calling VirtualUnlock . Hence, the covert channelinformation is perfectly (no information loss) stored in thepage cache in the
ShareCount for the shared pages. Us-ing
QueryWorkingSetEx the receiving side can read the
ShareCount and decode the information that was encodedin the page cache.
Performance Evaluation.
We tested the implementation bytransmitting random messages between two processes. Thetest system was equipped with an Intel i5-5200U processor,8 GB DDR3-1600 RAM, and a 256 GB Samsung SSD.For the tests on Linux, we used Ubuntu 16.04 with ker-nel version 4.4.0-101-generic. We observed transmissionrates of up to 9 .
69 kB / s with an average transmission rateof 7 .
04 kB / s with a standard error of 0 .
18 kB / s. We didnot observe any influence by the core or CPU scheduling,which is not surprising, as both the system calls and the pagecache eviction can equally run on any core or CPU. We ob-served a bit-error rate of less than 0 .
000 03 %. We also eval-uated the covert channel in a cross-sandbox scenario usingFirejail [21]. Firejail was configured to prevent all outgoinginter-process communication, deny all network traffic, andonly allow read access to the file system. We did not ob-serve any influence from running the covert channel in iso-lated Firejail sandboxes. This is not specific to Firejail butworks identically on other sandbox and container solutions that utilize the host system page cache, e.g., Docker if con-figured accordingly.For the tests on Windows, we used two different hard-ware setups with fully updated Windows 10 installations. Onthe Intel i5-5200U system, we observed transmission ratesof up to 152 .
57 kB / s with an average transmission rate of100 .
11 kB / s with a standard error of 0 .
79 kB / s and a bit-error rate below 0 .
000 006 %. On a second system, an Inteli7-6700K with a SanDisk Ultra II 480GB SATA SSD (run-ning Ubuntu 19.04 with a 4.18.0-11-generic kernel), we ob-served transmission rates of up to 278 .
16 kB / s with an av-erage transmission rate of 273 .
44 kB / s with a standard errorof 0 .
23 kB / s, again with a bit-error rate below 0 .
000 006 %.For a performance comparison in a similar cross-CPU sce-nario, Pessl et al. [54] reported an error rate of 0 . . / s which is much slower than our Windows-based covert channel, but faster than our Linux-based covertchannel. Wu et al. [74] presented a cross-CPU covertchannel which achieves a channel capacity of 93 .
25 B / s.Hence, our Linux covert channel outperforms this one bytwo orders of magnitude and our Windows covert chan-nel even by three to four orders of magnitude. In partic-ular, the covert channel on the i7-6700K test system caneven compete with Flush+Reload and Flush+Flush covertchannels which require specific hardware (Intel processors)and shared memory [29]. Thus, we conclude that ourcovert channel can very well compete with state-of-the-arthardware-component-based covert channels. Yet, our covertchannel works regardless of the presence of these leakinghardware components. In this section, we present a user-interface redress attack [4,9, 22, 50, 57, 62] which relies on our side channel as a trig-ger. The basic idea is to detect when an interesting windowis opened and to place an identically looking fake windowover it. This can be so stealthy that even advanced usersdo not notice it [22]. However, to achieve this, the latencybetween the original window opening and the fake windowbeing placed over it must be very low. Fortunately, our sidechannel provides us with exactly this capability, regardlessof any other information leakage. Note that the operatingsystems authentication windows may be protected. How-ever, other password prompts, e.g., for password managers,browsers, and mail clients, are usually unprotected and canbe targeted in our attack.We use our side channel to detect when a root authentica-tion window on Ubuntu 16.04 is displayed. We detect thiswith a latency of 2 .
04 µs on average, and it does not take uslonger to make our fake window visible and move it on topof the real window. The user now types in the root passwordin our fake window. Depending on the attacker capabilities,he attacker can either forward the password to the real win-dow or simply close the fake window after the password wasentered. In the latter case, the user would see the originalauthentication window afterwards and likely think that thepassword was rejected on the first try, e.g., because of a typ-ing error occurred.To identify binary pages which are used when spawningthe root authentication window, we performed an automatedtemplate attack (cf. Section 7.3). Note that the templateattack is performed on an attacker-controlled system withidentical software installed. Hence, the attacker can takearbitrary means (e.g., side-channel attacks or a debugger)to find interesting memory locations that can be exploitedon the victim system. The attacker first runs a debugger-based or cache-based template attack [30] to identify bi-nary regions that handle the corresponding event. In a sec-ond run, the attacker templates with our page cache side-channel attack. In our specific case, the result of the templat-ing was that the strongest leakage is page 2 in the binaryfile polkit-gnome-authentication-agent-1 . Hence,on the victim system, the attacker simply uses the previouslyobtained templates to mount the attack.Mounting the same attack on Windows 10 works even bet-ter. Here, the latency is only 465 .
91 ns, which is clearly notperceivable for a human. Also, unsurprisingly, we found thatfake windows can be created on Windows just as on Linux.Events like authentication windows and password promptsare very well suited for our attack due to the low frequency inwhich they occur. This also makes the automated templatingfor leaking pages less noisy.
In this section, we present an inter-keystroke-timing at-tack [30, 49, 59, 67, 79] on keyboard input in the root au-thentication window on Ubuntu 18.04. To mount a keystroketiming attack, we first identify pages that are loaded intothe page cache when the user presses a key using a tem-plate attack [30] (cf. Section 7.2). We target the Ubuntu18.04 authentication window, where the user types in theroot password. In the template attack, we identified page14 of libgksu2.so.0.0.2 as a viable target page.Figure 2 shows two attack traces of a password entry, oneon Linux (Section 7.3) and one on Windows 10 (Section 7.3)in notepad.exe . We obtain identical traces on Windowswhen running the attack on Firefox. Note that on Linux,for an extremely fast typing person, we could miss somekeystrokes, i.e. , false negatives can occur. However, we cangather these traces multiple times and combine the informa-tion from multiple traces to recover highly accurate inter-keystroke timings [49, 64]. For Windows, the temporal res-olution is much higher, far below the timing variations ofa human [49, 64], allowing us to reliably detect and report V a l u e V a l u e Figure 2: Values returned by the page cache side channelduring a password entry on Linux (top) and while typ-ing in an editor on Windows (bottom). On Windows weobserve key up and key down events due to the page se-lected and the high attack frequency achievable. In bothcases, there is no noise between the keystrokes. all inter-keystroke timings including key down and key upevents.When running the side-channel attack on an idle systemfor one hour, we did not observe a single false positive, nei-ther on Windows nor on Linux. This is not surprising, if thememory region is used by unrelated events we would havealready seen such noise in the template phase. However, asthe attacker can and will choose the memory region based onthe templating, the attacker chooses memory regions whichare not really used by any unrelated events. Thus, in the op-timal case, the selected memory region is completely noise-free. In such a case, there is no functionality in the operat-ing systems that could lead to false positives due to spuriouscache hits. Running the attacker binary inside a Firejail sand-box [21] had no measurable influence on the accuracy of theattack.
The PHP microtime function returns the current UNIXtimestamp in microseconds. It is carelessly used by someframeworks to initialize the PHP pseudo-random numbergenerator (PRNG) before it is used in cryptographic oper-ations or to generate temporary passwords [1, 19, 80]. Thisis known as a bad practice and considered insecure, not leastdue to side-channel attacks [80]. During our research wefound that the popular phpMyFAQ framework [58] still re-lies on this approach. We mount our page cache attack on the main PHP binary(7.0.4-7ubuntu2), on the function zif microtime . Thisfunction is read-only and shared with any unprivileged pro-cess including the attacker. In our case, the function resideson page (441) of the binary. By monitoring this page,we can determine the return value of microtime at the ini- We responsibly disclosed this vulnerability to the developers of php-MyFAQ who issued a patch following our recommendation. ialization of the PRNG. Based on this, we can reconstructany password generated based on the same PRNG initializa-tion, as the password generation algorithm is also publiclyavailable.Due to the large variance on the runtime of PHP scripts,we only detected an access to the microtime function withan accuracy of ± . ± . Our side channel also allows implementing padding- orlength-oracle attacks. For instance, a password or tokencomparison using strcmp forms a length oracle. If the at-tacker can place the string on the page boundary, the attackercan measure at which byte of the string the comparison ter-minated. By manipulating the string, the attacker can figureour the correct password or token.We verified that this attack is practical in a small proof-of-concept program. The attacker passes the string throughan API to the victim process. By using our page-cache- orworking-set-based side channel we can determine whetherthe second page was loaded into the page cache or added tothe working set. If this was the case, the attacker learns thatthe bytes on the first page were guessed correctly.As the attacker can fully control the frequency of the mea-surements here and can repeat the attack, we observed nocases where we could not successfully leak the secret.
For our remote attack we have to distinguish soft page-faults, i.e. , just mapping the page from the page cache, andregular pagefaults, i.e. , page cache misses, over a networkconnection. In this scenario, two physically separated pro-cesses wish to communicate with each other. The senderprocess runs on a server and has access to information thatthe attacker wants to have. However, it is unprivileged, fire-walled, and possibly sandboxed, so it cannot reach any net-work resources or expose files for remote access. However,the server exposes multiple files to the public internet, e.g.,over a web server. We also assume that the sender processhas read permissions to these files, e.g., Apache has world-readable permissions on files in the web server root directory F r e qu e n c y HitsMisses
Figure 3: Timing histogram of the remote covert channelwith a
100 kB file (25 pages). by default. The receiver process runs on a remote server,measuring the remote access latency to pages in these publicfiles. Hence, the sender process can encode the informationin the page cache state of these pages.
Page Cache Hits and Misses.
Of course, a remote attackercannot invoke mincore to check which pages are in cache,so the attacker needs to rely on timing. Hence, we first try todistinguish cache hits and misses over the network, similarlyto the related work in [65, 70], by performing remote ac-cesses with and without clearing the page cache. We also en-sured that there was no other intermediary network cachingor proxy caching active by passing appropriate HTTP head-ers to the server. Figure 3 shows the frequencies of remoteaccess latencies for various cached and uncached accesses;the figure shows that cache hits can be distinguished fromcache misses. Here, the mean access time was 8 . . Figure 5 depicts how the two processes communicate overthe covert channel. The local sender process is an unprivi-leged (possibly sandboxed) malware that encodes secret datafrom the victim machine into page cache hits and misses,and the remote receiver process decoding the secret data af-ter measuring the remote access latency. For this, the senderprocess uses one file to encode data, and another file for syn-chronization (control file). The sender process first evictsboth the data and control files from the file system cache(Step 1) using posix fadvise on a rarely used file, i.e. , afile which is not currently locked in memory by another pro-cess. Note that the attacker could also use any other meansof page cache eviction as described in Section 6. It then en-codes one bit of information in the data file (Step 2) by eitherbringing it into the page cache by reading the file (encodinga ‘1’), or not bringing it into the cache (encoding a ‘0’). Af-ter encoding, the sender waits for the control file to be readby the remote process (Step 3). For this, the sender uses mincore on the control file in a loop, checking how many ,
000 2 ,
010 2 ,
020 2 ,
030 2 , L a t e n c y [ m s ] Figure 4: Transmitting a sequence of alternating ‘0’s and‘1’s by accessing a
10 MB file (2560 pages). A thresholdcan distinguish the two cases.Figure 5: Illustration of the web server covert channel. of the file’s pages are in the page cache. In our case, thesender waits until 80 % of the file are cached, indicating thatthe remote attacker accessed it.The receiver process measures the access latency, infer-ring the bits the sender process was trying to transmit (Step4). In our experiments, the access time threshold that demar-cated a ‘0’ from a ‘1’ was set to 105 ms for our hard driveexperiments, as illustrated in Figure 4.Immediately after the receiver process accessed the datafile, it also accesses the control file (Step 5), to let the senderknow the next bit can be transmitted now. The sender thencontinues at Step 1 again. This happens until the sender hastransmitted all bits of secret information.
Evaluation.
Our experimental setup involved two sepa-rate, but geographically close, machines, i.e. , a network dis-tance of 4 hops. The victim machine was running the LinuxMint (kernel version 4.10.0-38) on an AMD A10-6700 with8 GB RAM and a 977 GB hard drive. The victim machineexposed two files to the network, data.jpg (10 MB) and control.jpg , used as the data and control files respec-tively. The remote machine was also running Linux Mint(kernel version 4.13.0-37) on an Intel Core i7-7700 with16 GB RAM and a 219 GB SSD. For the evaluation, we transmitted 4000 bits from the localmachine to the remote machine multiple times. The trans-mission took 517 s on average, which corresponds to an av-erage bit rate of 7 .
74 bit / s and an average bit error rate of0 . .
08 bit / s at anaverage bit error rate of 0 .
35 %. Hence, this remote timingcovert channel is also possible on a machine with an SSD.Our proof-of-concept implementation could be further op-timized to yield a higher transmission rate, to mount the at-tack over a greater geographical distance, or to use smallerfiles, simply by repeating measurements for each singlebit [65]. In our proof-of-concept we did not repeat any mea-surements to obtain a single bit, again indicating the highcapacity of this remote covert channel.
Similarly to our local side-channel attacks, we could alsomount remote side-channel attacks exploiting the pagecache. This information could be used to determine whethercertain pages or scripts have been recently accessed [70].However, in practice it is difficult to evict the cache remotelyand eviction can be tricky without the information from thelocal system. Furthermore, controlling the working set viaa huge number of remote file accesses will make the attackvery conspicuous, though it may still be practically effectivefor opportunity-based attacks (e.g., password reset pages)such as those presented in Section 7.4.
Countermeasures
Our side-channel attack targets the operating system pagecache via operating system interfaces and behavior. Hence,it clearly can be mitigated by modifying the operating systemimplementation.
Privileged Access.
The
QueryWorkingSetEx and mincore system calls are the core of our side-channel at-tack. Requiring a higher privilege level for these systemcalls stops our attack. The downside of restricting accessto these system calls is that existing programs which cur-rently make use of these system calls might break. Hence,we analyzed how frequently mincore is called by any of thesoftware running on a typical Linux installation. We used theLinux perf tools to measure over a 5 hour period wheneverthe sys enter mincore system call is called by any appli-cation. During these 5 hours a user performed regular oper-ations on the system, i.e. , running various work-related toolslike Libre Office, gcc, Clion, Thunderbird, Firefox, Nautilus,and Evince, but also non-work-related tools like Spotify. Thesystem was also running regular background tasks duringthis time frame. Surprisingly, the sys enter mincore sys-tem call was not called a single time. This indicates thatmaking the mincore system call privileged is feasible andwould mitigate our attack at a very low implementation cost.On Windows, there are multiple possible solutions to mit-igate our attacks by adapting the privileges required for thesystem calls we use. First of all, it is questionable why aprocess can obtain working-set information of another pro-cess via
QueryWorkingSetEx . Especially, as this contra-dicts the official documentation [47]. Second, the sharecount information could be omitted from the struct returnedby
QueryWorkingSetEx as it exposes information aboutother processes to the attacker. The combination of thesetwo changes mitigates all our attack variants on Windows.We responsibly disclosed our findings to Mi-crosoft, and they acknowledged the problemand will roll out these changes in Windows10 19H1. Specifically, Windows will require
PROCESS QUERY INFORMATION for
QueryWorkingSetEx instead of
PROCESS QUERY LIMITED INFORMATION toprevent lesser privileged processes from directly obtainingworking set information. Microsoft also follows our secondrecommendation of omitting the share count information,to prevent indirect observations on working set changes inother processes.It was also surprising that Windows allows changing theworking-set size for another process. If this would be re-stricted, it would be much more difficult to reliably evictacross processes. The performance of our covert channelwould decrease if
VirtualUnlock did not have the “fea- We use sudo perf stat -e ’syscalls:sys enter mincore’-a sleep 18000 for this purpose. ture” that it removes pages from the working set if they arenot locked.Alternative approaches like page locking, signal burying,or disabling page sharing are likely not practical for most usecases or impose significant overheads.
Preventing Efficient Eviction while Increasing the SystemPerformance.
On Windows, we used working set evic-tion instead of page cache eviction as on Linux. We ver-ified that the approach we used on Linux, i.e. , page cacheeviction, also works on Windows. However, it performsmuch worse than on Linux and optimizing the eviction ap-peared to be far more tricky. One reason for this is that withworking-set-based algorithms, processes cannot directly in-fluence the eviction probability for pages owned by or sharedwith other processes [8, 16, 17]. On Linux, we are only ableto evict pages efficiently because we can trick the page re-placement algorithm into believing our target page would bethe best choice for eviction. The reason for this lies in thefact that Linux uses a global page replacement algorithm, i.e. , an algorithm which does not distinguish between dif-ferent processes. Global page replacement algorithms havebeen known for decades to allow one process to perform adenial-of-service on other processes [8, 16, 17, 61].Working-set algorithms deplete these denial-of-servicesituations and they also increase the general system perfor-mance by making more clever choices for eviction candi-dates [8, 16, 17]. Hence, switching to working-set algo-rithms on Linux, as on Windows [61], makes our attackless practical. We can also transfer this insight to hardwarecaches: If hardware caches would use replacement algo-rithms that guarantee fairness in a similar way, attacks likePrime+Probe would not be possible anymore, because the at-tacker would rather evict its own cache lines, rather than theone required by the victim process. This is a larger change,but it might make remote attacks that rely on page cacheeviction less practical.
10 Conclusion
We have demonstrated a variety of local and remote attacksagainst the page cache used in modern operating systems,thereby highlighting a new source for side- and covert chan-nels that is hardware and timing agnostic. On the local front,we have demonstrated a high-speed cross-sandbox covertchannel, a UI redressing attack triggered by a side channel, akeystroke-timing side channel, and password-recovery sidechannel from a vulnerable PHP script. On the remote front,we have shown that forgoing hardware agnosticism permitsa low profile covert channel from a local malicious sender,and a higher profile side channel. The severity of this attacksurface is exacerbated by the variety of isolation techniquesthat share the page cache, including regular Unix processes,sandboxes, Function-as-a-Service platforms, managed lan-guage runtimes, web browsers, and even select remote pro-esses. Stronger permissioning, as we recommend, will helpagainst some of our local attacks.
Acknowledgments
We want to thank James Forshaw for helpful discussions onCOM use cases and Simon Gunacker for early explorativework on this topic. Daniel Gruss and Michael Schwarz weresupported by a generous gift from ARM and also by a gen-erous gift from Intel. Ari Trachtenberg and Trishita Tiwariwere supported, in part, by the National Science Founda-tion under Grant No. CCF-1563753 and Boston University’sDistinguished Summer Research Fellowship, Undergradu-ate Research Opportunities Program, and the department ofElectrical and Computer Engineering. Any opinions, find-ings, and conclusions or recommendations expressed in thispaper are those of the authors and do not necessarily reflectthe views of the funding parties.
References [1] A
RGYROS , G.,
AND K IAYIAS , A. I forgot your password: Random-ness attacks against php applications. In
USENIX Security Symposium (2012).[2] B
ARRESI , A., R
AZAVI , K., P
AYER , M.,
AND G ROSS , T. R. CAIN:silently breaking ASLR in the cloud. In
WOOT’15 (2015).[3] B
ERNSTEIN , D. J. Cache-Timing Attacks on AES, http://cr.yp.to/antiforgery/cachetiming-20050414.pdf
IANCHI , A., C
ORBETTA , J., I
NVERNIZZI , L., F
RATANTONIO , Y.,K
RUEGEL , C.,
AND V IGNA , G. What the app is that? deception andcountermeasures in the android user interface. In
S&P (2015).[5] B
ORTZ , A.,
AND B ONEH , D. Exposing private information by timingweb applications. In
WWW (2007).[6] B
OSMAN , E., R
AZAVI , K., B OS , H., AND G IUFFRIDA , C. DedupEst Machina: Memory Deduplication as an Advanced ExploitationVector. In
S&P (2016).[7] B
RUNO , L. What page replacement algorithms does the windows 7 osuses?, https://social.technet.microsoft.com/Forums/ie/en-US/e61aef24-38fd-4e7e-a4c1-a50aa226818c
Feb. 2013.[8] C
ARR , R. W.,
AND H ENNESSY , J. L. Wsclock-a simple and effectivealgorithm for virtual memory management.
ACM SIGOPS OperatingSystems Review 15 , 5 (1981), 87–95.[9] C
HEN , Q. A., Q
IAN , Z.,
AND M AO , Z. M. Peeking into your appwithout actually seeing it: Ui state inference and novel android at-tacks. In USENIX Security Symposium (2014).[10] C
OCK , D., G E , Q., M URRAY , T.,
AND H EISER , G. The last mile:An empirical study of timing channels on sel4. In
CCS (2014).[11] C
ORBATO , F. J. A paging experiment with the multics system. Tech.rep., Massachusetts Institute of Technology, Cambridge, 1968.[12] C
ORBET , J. A clock-pro page replacement implementation, https://lwn.net/Articles/147879/
Aug. 2005. [13] C
ROSBY , S. A., W
ALLACH , D. S.,
AND R IEDI , R. H. Opportunitiesand limits of remote timing attacks.
ACM Transactions on Informationand System Security (TISSEC) 12 , 3 (2009), 17.[14] C
ROWTHERS , D. Can you get more space or speed fromyour ssd?,
June 2011.[15] Ssdoptimization, https://wiki.debian.org/SSDOptimization
Mar. 2018.[16] D
ENNING , P. J. The working set model for program behavior.
Com-munications of the ACM 11 , 5 (1968), 323–333.[17] D
ENNING , P. J. Working sets past and present.
IEEE Transactionson Software Engineering , 1 (1980), 64–84.[18] D
JORDJEVI ´ C , B., M A ˇ CEK , N.,
AND T IM ˇ CENKO , V. Performanceissues in cloud computing: Kvm hypervisor’s cache modes evaluation.
Acta Polytechnica Hungarica 12 , 4 (2015), 147–165.[19] E
SSER , S. Lesser known security problems in php applications. In
Zend Conference (2008).[20] F
ELTEN , E. W.,
AND S CHNEIDER , M. A. Timing attacks on webprivacy. In
CCS (2000).[21] Firejail security sandbox, https://firejail.wordpress.com/
RATANTONIO , Y., Q
IAN , C., C
HUNG , S. P.,
AND L EE , W. Cloakand dagger: from two permissions to complete control of the ui feed-back loop. In S&P (2017).[23] F
RIEDMAN , M. B. Windows nt page replacement policies. In
Int.CMG Conference (1999).[24] G
ORMAN , M.
Understanding the Linux virtual memory manager .Prentice Hall Upper Saddle River, 2004.[25] G
RAS , B., R
AZAVI , K., B OS , H., AND G IUFFRIDA , C. TranslationLeak-aside Buffer: Defeating Cache Side-channel Protections withTLB Attacks. In
USENIX Security Symposium (2018).[26] G
RUSS , D., B
IDNER , D.,
AND M ANGARD , S. Practical memorydeduplication attacks in sandboxed javascript. In
ESORICS (2015).[27] G
RUSS , D., L
IPP , M., S
CHWARZ , M., G
ENKIN , D., J
UFFINGER , J.,O’C
ONNELL , S., S
CHOECHL , W.,
AND Y AROM , Y. Another Flip inthe Wall of Rowhammer Defenses. In
S&P (2018).[28] G
RUSS , D., M
AURICE , C.,
AND M ANGARD , S. Rowhammer.js:A Remote Software-Induced Fault Attack in JavaScript. In
DIMVA (2016).[29] G
RUSS , D., M
AURICE , C., W
AGNER , K.,
AND M ANGARD , S.Flush+Flush: A Fast and Stealthy Cache Attack. In
DIMVA (2016).[30] G
RUSS , D., S
PREITZER , R.,
AND M ANGARD , S. Cache TemplateAttacks: Automating Attacks on Inclusive Last-Level Caches. In
USENIX Security Symposium (2015).[31] H
OLEN , V. Experiments and fun with the linux disk cache,
ORN , C. Do we really need swap on modern systems?,
Feb. 2017.[33] I
NCI , M. S., G
ULMEZOGLU , B., I
RAZOQUI , G., E
ISENBARTH , T.,
AND S UNAR , B. Cache Attacks Enable Bulk Key Recovery on theCloud. In
CHES (2016), vol. 9813 of
LNCS , Springer, pp. 368–388.34] I
RAZOQUI , G., E
ISENBARTH , T.,
AND S UNAR , B. Cross processorcache attacks. In
AsiaCCS (2016).[35] I
RAZOQUI , G., I
NCI , M. S., E
ISENBARTH , T.,
AND S UNAR , B.Lucky 13 strikes back. In
AsiaCCS’15 (2015).[36] J
ACKSON , C., B
ORTZ , A., B
ONEH , D.,
AND M ITCHELL , J. C. Pro-tecting browser state from web privacy attacks. In
WWW (2006).[37] J IA , Y., D ONG , X., L
IANG , Z.,
AND S AXENA , P. I know whereyou’ve been: Geo-inference attacks via the browser cache.
IEEE In-ternet Computing 19 , 1 (2015), 44–53.[38] J
IANG , S., C
HEN , F.,
AND Z HANG , X. Clock-pro: An effectiveimprovement of the clock replacement. In
USENIX ATC (2005).[39] K
OCHER , P., H
ORN , J., F
OGH , A., G
ENKIN , D., G
RUSS , D., H
AAS ,W., H
AMBURG , M., L
IPP , M., M
ANGARD , S., P
RESCHER , T.,S
CHWARZ , M.,
AND Y AROM , Y. Spectre attacks: Exploiting specu-lative execution. In
S&P (2019).[40] K
OCHER , P. C. Timing Attacks on Implementations of Diffe-Hellman, RSA, DSS, and Other Systems. In
CRYPTO (1996).[41] L
AMPSON , B. W. A note on the confinement problem.
Communica-tions of the ACM 16 , 10 (1973), 613–615.[42] L
IPP , M., G
RUSS , D., S
PREITZER , R., M
AURICE , C.,
AND M AN - GARD , S. ARMageddon: Cache Attacks on Mobile Devices. In
USENIX Security Symposium (2016).[43] L
IPP , M., S
CHWARZ , M., G
RUSS , D., P
RESCHER , T., H
AAS , W.,F
OGH , A., H
ORN , J., M
ANGARD , S., K
OCHER , P., G
ENKIN , D.,Y
AROM , Y.,
AND H AMBURG , M. Meltdown: Reading Kernel Mem-ory from User Space. In
USENIX Security Symposium (2018).[44] M
AURICE , C., N
EUMANN , C., H
EEN , O.,
AND F RANCILLON , A.C5: Cross-Cores Cache Covert Channel. In
DIMVA (2015).[45] M
AURICE , C., W
EBER , M., S
CHWARZ , M., G
INER , L., G
RUSS ,D., A
LBERTO B OANO , C., M
ANGARD , S.,
AND
R ¨
OMER , K. Hellofrom the Other Side: SSH over Robust Cache Covert Channels in theCloud. In
NDSS (2017).[46] M
ICROSOFT . Cache and Memory Manager Improvements, https://docs.microsoft.com/en-us/windows-server/administration/performance-tuning/subsystem/cache-memory-management/improvements-in-windows-server
Apr.2017.[47] M
ICROSOFT . Programming reference for windows api, https://docs.microsoft.com/en-us/windows/desktop/api/index
July 2018.[48] M
ICROSOFT . Windows desktop applications, https://msdn.microsoft.com/en-us/library/windows/desktop/aa906039.aspx
July 2018.[49] M
ONACO , J. Sok: Keylogging side channels. In
S&P (2018).[50] N
IEMIETZ , M.,
AND S CHWENK , J. UI Redressing Attacks on An-droid Devices.
Black Hat Abu Dhabi (2012).[51] O
SVIK , D. A., S
HAMIR , A.,
AND T ROMER , E. Cache Attacks andCountermeasures: the Case of AES. In
CT-RSA (2006).[52] O
WENS , R.,
AND W ANG , W. Non-interactive OS fingerprintingthrough memory de-duplication technique in virtual machines. In
In-ternational Performance Computing and Communications Conference (2011).[53] P
ERCIVAL , C. Cache missing for fun and profit. In
BSDCan (2005). [54] P
ESSL , P., G
RUSS , D., M
AURICE , C., S
CHWARZ , M.,
AND M AN - GARD , S. DRAMA: Exploiting DRAM Addressing for Cross-CPUAttacks. In
USENIX Security Symposium (2016).[55] R
AZAVI , K., G
RAS , B., B
OSMAN , E., P
RENEEL , B., G
IUFFRIDA ,C.,
AND B OS , H. Flip feng shui: Hammering a needle in the softwarestack. In USENIX Security Symposium (2016).[56] R ED H AT . Red Hat Enterprise Linux 7 - Virtualization Tuning andOptimization Guide , 2017.[57] R EN , C., Z HANG , Y., X UE , H., W EI , T., AND L IU , P. Towardsdiscovering and understanding task hijacking in android. In USENIXSecurity Symposium (2015).[58] R
INNE , T. phpmyfaq - open source faq system for php and mysql,postgresql and other databases, https://github.com/thorsten/phpMyFAQ
ISTENPART , T., T
ROMER , E., S
HACHAM , H.,
AND S AVAGE , S.Hey, You, Get Off of My Cloud: Exploring Information Leakage inThird-Party Compute Clouds. In
CCS (2009).[60] R
USSINOVICH , M. Inside memory management, part 2,
Aug. 1998.[61] R
USSINOVICH , M. E., S
OLOMON , D. A.,
AND I ONESCU , A.
Win-dows internals . Pearson Education, 2012.[62] R
YDSTEDT , G., G
OURDIN , B., B
URSZTEIN , E.,
AND B ONEH , D.Framing attacks on smart phones and dumb routers: tap-jacking andgeo-localization attacks. In (2010).[63] S
CHMID , P. Windows vista’s superfetch and readyboost analyzed,
Jan.2007.[64] S
CHWARZ , M., L
IPP , M., G
RUSS , D., W
EISER , S., M
AURICE ,C., S
PREITZER , R.,
AND M ANGARD , S. KeyDrown: EliminatingSoftware-Based Keystroke Timing Side-Channel Attacks. In
NDSS (2018).[65] S
CHWARZ , M., S
CHWARZL , M., L
IPP , M.,
AND G RUSS , D. Net-spectre: Read arbitrary memory over network. arXiv:1807.10535 (2018).[66] S
EABORN , M.,
AND D ULLIEN , T. Exploiting the DRAM rowham-mer bug to gain kernel privileges. In
Black Hat Briefings (2015).[67] S
ONG , D. X., W
AGNER , D.,
AND T IAN , X. Timing Analysis ofKeystrokes and Timing Attacks on SSH. In
USENIX Security Sympo-sium (2001).[68] S
UZAKI , K., I
IJIMA , K., Y
AGI , T.,
AND A RTHO , C. Memory Dedu-plication as a Threat to the Guest OS. In
EuroSys (2011).[69] T
ALLIS , B. Best ssds: Q2 2018,
Mar. 2018.[70] T
IWARI , T.,
AND T RACHTENBERG , A. POSTER: Cashing in on theFile-System Cache. In
ACM SIGSAC Conference on Computer andCommunications Security (2018).[71]
VAN DER V EEN , V., F
RATANTONIO , Y., L
INDORFER , M., G
RUSS ,D., M
AURICE , C., V
IGNA , G., B OS , H., R AZAVI , K.,
AND G IUF - FRIDA , C. Drammer: Deterministic Rowhammer Attacks on MobilePlatforms. In
CCS’16 (2016).72] V AN G OETHEM , T., J
OOSEN , W.,
AND N IKIFORAKIS , N. The clockis still ticking: Timing attacks in the modern web. In
CCS (2015).[73] W
ANG , W., C
HEN , G., P AN , X., Z HANG , Y., W
ANG , X., B
IND - SCHAEDLER , V., T
ANG , H.,
AND G UNTER , C. A. Leaky cauldronon the dark land: Understanding memory side-channel hazards in sgx.In
CCS (2017).[74] W U , Z., X U , Z., AND W ANG , H. Whispers in the Hyper-space:High-bandwidth and Reliable Covert Channel Attacks inside theCloud.
IEEE/ACM Transactions on Networking (2014).[75] X
IAO , J., X U , Z., H UANG , H.,
AND W ANG , H. A covert channelconstruction in a virtualized environment. In
CCS (2012).[76] X
IAO , J., X U , Z., H UANG , H.,
AND W ANG , H. Security implica-tions of memory deduplication in a virtualized environment. In
In-ternational Conference on Dependable Systems and Networks (DSN) (2013).[77] Y
AROM , Y.,
AND F ALKNER , K. Flush+Reload: a High Resolution,Low Noise, L3 Cache Side-Channel Attack. In
USENIX Security Sym-posium (2014).[78] Y
OUNG , J. Nsa tempest documents.
CRYPTOME (2002).[79] Z
HANG , K.,
AND W ANG , X. Peeping Tom in the Neighborhood:Keystroke Eavesdropping on Multi-User Systems. In
USENIX Secu-rity Symposium (2009).[80] Z
HANG , Y., J
UELS , A., R
EITER , M. K.,
AND R ISTENPART , T.Cross-Tenant Side-Channel Attacks in PaaS Clouds. In