Bug 2258514 (CVE-2024-0564)
Summary: | CVE-2024-0564 kernel: max page sharing of Kernel Samepage Merging (KSM) may cause memory deduplication | ||
---|---|---|---|
Product: | [Other] Security Response | Reporter: | Rohit Keshri <rkeshri> |
Component: | vulnerability | Assignee: | Product Security <prodsec-ir-bot> |
Status: | CLOSED WONTFIX | QA Contact: | |
Severity: | low | Docs Contact: | |
Priority: | low | ||
Version: | unspecified | CC: | 1601409389, aarcange, acaringi, allarkin, aquini, aubaker, bhu, chwhite, cye, cyin, dbohanno, debarbos, dfreiber, drow, dvlasenk, ezulian, hkrzesin, jarod, jburrell, jdenham, jfaracco, jforbes, jlelli, jobselko, joe.lawrence, jshortt, jstancek, jwyatt, kcarcia, kyoshida, ldoskova, lgoncalv, lzampier, mmilgram, mstowell, nmurray, ptalbert, rogbas, rparrazo, rrobaina, rvrbovsk, rysulliv, scweaver, security-response-team, tglozar, tyberry, vcowan, vkumar, wcosta, williams, wmealing, ycote, ykopkova, zhijwang |
Target Milestone: | --- | Keywords: | Security |
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | If docs needed, set a value | |
Doc Text: |
A flaw was found in the Linux kernel's memory deduplication mechanism. The max page sharing of Kernel Samepage Merging (KSM), added in Linux kernel version 4.4.0-96.119, can create a side channel. When the attacker and the victim share the same host and the default setting of KSM is "max page sharing=256", it is possible for the attacker to time the unmap to merge with the victim's page. The unmapping time depends on whether it merges with the victim's page and additional physical pages are created beyond the KSM's "max page share". Through these operations, the attacker can leak the victim's page.
|
Story Points: | --- |
Clone Of: | Environment: | ||
Last Closed: | 2024-04-25 18:34:58 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Bug Depends On: | 2259410 | ||
Bug Blocks: | 2258513 |
Description
Rohit Keshri
2024-01-15 18:50:23 UTC
Created kernel tracking bugs for this issue: Affects: fedora-all [bug 2259410] Here's my take on this one, and I don't think it deserves to be classified as "medium" severity level. As far as I understand it, the premise of this issue is that one bad actor can prepare a page with (a) data that is expected to be present on a given target VM, then map it N times on a compromised VM, where N should be the value set at /sys/kernel/mm/ksm/max_page_sharing in the host, (b) wait for KSM to perform a full deduplication scan for the compromised VM, which time will be calculated via the values set for /sys/kernel/mm/ksm/pages_to_scan and /sys/kernel/mm/ksm/sleep_millisecs and the amount of RAM available to the compromised VM, to then measure the time it takes to unmap the crafted pages to determine, by latency values, if the crafted pages were merged with the target "secret" page, or not. I think this kind of attack is highly unlikely to work outside of the controlled environment described on the paper. To begin with, all the sysfs values that are needed to have the timing factor working in favor of the bad actor are unknowns, given these are HOST values that can -- and should -- be modified by sysadmins on a case-by-case basis and this addresses (b), IMO. The real elephant in the room, however, is the fact that the bad actor has to prepare a page with data thought to exist on the target (a). On the experiment, they worked with a convenient string 0xDEADCAFE filing the whole page, but in real life an attacker would have to produce a 4096 byte stream of data that matches exactly the content of their target secret, otherwise KSM won't de-duplicate that page. If we take the complete combination of bytes in a 4k page we get the astronomical value of 1.66 X 10^421, which means it borders the impossible to produce random data that will match with any other page candidate to be merged by KSM. Even if the attacker has knowledge of some strings that can potentially be present within the memory of their targeted VM, it is still required that they produce a 4kB string that perfectly matches with that data as it is laid out on the target page to have a chance to use the timing side-channel to infer that the victim does indeed has that data resident. In a glance, I'd argue that unless the bad actor knows beforehand that a VM has a particular page holding a specific pattern -- which defeats the purpose of such attacks -- the issue discussed at this paper has little practical application as well as such exploit can be easily defeated by simply changing KSM's default settings for max_page_sharing, pages_to_scan and sleep_millisecs, in the virtualization host (as those will not be known by the attacker). A couple of things here: (1) I stand by and reinforce my comment #8: this CVE doesn't deserve the current 'medium' severity classification it holds; (2) There are several ways to mitigate the problem without pushing any code changes to upstream or RHEL, one of them by simply disabling KSM altogether. We should just close this tracker. |