Antonio Barresi reports: We discovered a new attack vector against memory deduplication in Virtual Machine Monitors (VMM) where attackers can effectively leak randomized base addresses of libraries and executables in processes of neighboring Virtual Machines (VM). The details are described in the security advisory below and in our WOOT'15 paper: https://www.usenix.org/conference/woot15/workshop-program/presentation/barresi Several vendors were notified about this issue in the beginning of June. This issue has CVE-2015-2877 assigned. An overview can also be found here: http://www.antoniobarresi.com/security/cloud/2015/07/30/cain/
There are four suggested workarounds for this issue. Please note that several have a potentially significant impact on system performance ans stability, and should be carefully tested prior to deployment: VMM layer: Deactivation of memory deduplication Deactivating memory deduplication will effectively mitigate all attack vectors. This measure unfortunately eliminates all the highly appreciated benefits of memory deduplication, namely the increase of operational cost-effectiveness through inter-VM memory sharing. Deactivating memory deduplication is the simplest way to prevent exploitation of this attack. However this will cause an increase in the amount of memory required and in some situations may adversely impact performance (e.g. due to slower swap space being used). It is recommended that customers test this workaround before using it in production. VMM layer: Attack detection Instead of preventing the attack directly, the VMM can observe the guest VM and detect an ongoing attack based on memory creation and page fault behavior. We do not propose any specific heuristic but we suggest the concept of detecting the attack instead of preventing it. Using cgroups to limit or warn when a large number of memory IO operations occur is possible in certain situations however setting the appropriate upper bounds will be dependant on each use case, as such it is recommended that administrators profile applications through all use cases before considering this workaround in order to limit the false positives that may be generated. ASLR layer: Increase ASLR entropy One of the factors making the attack feasible is the limited entropy in RBAs. We suggest to further increase ASLR entropy to not only mitigate the attack described here, but to continue making ASLR more effective. Unfortunately this solution would require a significant number of changes to the Linux system (Kernel, GCC, userspace, etc.) and as such is unlikely to be implemented at this time. Process layer: More entropy in sensitive memory pages The pages we use in the attack are good candidates because their entropy consists solely on the ASLR entropy i.e., we can reliably construct the page once a base address is known or guessed. Increasing entropy in these pages or making sure that no such pages exist can mitigate the issue. Unfortunately this solution would require a significant number of changes to the Linux system (Kernel, GCC, userspace, etc.) and as such is unlikely to be implemented at this time.
External References: http://www.antoniobarresi.com/files/cain_advisory.txt
Statement: This issue affects the versions of the Linux Kernel as shipped with Red Hat Enterprise Linux 4, 5, 6 and 7. Red Hat Product Security has rated this issue as having Low security impact. Additionally a workaround is available. A future update may address this issue. For additional information, refer to the Issue Severity Classification: https://access.redhat.com/security/updates/classification/.