Using Data Bounce, we now start at the lower end of the address range and test all of the 512 possible offsets. If the kernel is mapped at a tested location, we will observe a store-to-load forwarding identifying the tested location as having a valid mapping to a physical address. Table 3 shows the performance of Data Bounce in de-randomizing kernel ASLR. We evaluated our attack on both an Intel Skylake i7-6600U (without KAISER) and a new Intel Coffee Lake i9-9900K that already includes fixes for Meltdown [51] and Foreshadow [74]. We evaluated our attack on both Windows and
Linux, achieving similar results.
For the evaluation, we tested 10 different randomizations (i.e., 10 reboots). In each, we try to break KASLR 100 times, giving us a total of 1000 samples. For evaluating the effectiveness of our attack, we
use the F1-score. On the i7-6600U and the i9-9900K, the F1-score for finding the kernel ASLR offset is 1 when testing every offset a single time, indicating that we always find the correct offset. In terms
of performance, we outperform the previous state of the art [45] even though our search space is 8 times larger. Furthermore, to evaluate the performance on a larger scale, we tested a single offset
100 million times. In that test, the F1-score was 0.9996, showing that Data Bounce virtually always works. The few misses that we observe are possibly due to the store buffer being drained or that our test program was interrupted.
For our evaluation, we use three Intel machines with Skylake (i7-6700), Kaby Lake (i7-7600) and Coffee Lake R (i9-9900K) processors, each running a fully updated Ubuntu 16.04. As Figure 6 shows, the kernel module needs to perform 10 or more writes (to different addresses) before returning to the user for the attack to succeed at recovering the last kernel store with 50–80% success rate. Finally, recovering values from a kernel performing a single write before returning can be done with a success rate of 0.05%. On processors vulnerable to Meltdown, disabling the KAISER patch exposes the machine to Meltdown attacks on the kernel. However, on the Coffee Lake R processor, which includes hardware countermeasures for Meltdown, KAISER is disabled by default. In particular, the experiments for this processor in Figure 6 are with the default Ubuntu configuration. This means that the presence of the hardware countermeasures in Intel’s latest CPU generations led to software behavior that is more vulnerable to our attack compared to systems with older CPUs.
<code lang="javascript">
/** Здесь мы передаём функцию clicker как параметр, не вызывая её */
document.getElementById('A').addEventListener('click', clicker1);
// Функция clicker1() будет вызываться когда нажимаем на кнопку A
function clicker1(event1){
let target1 = event1.target;
// Здесь мы вызываем функцию nonClicker(), которая возвращает функцию clicker2(), которую передаём параметром к addEventListener
document.getElementById('B').addEventListener('click', nonClicker(event1, target1));
}
// Эта функция nonClicker() вызывается не по клику на B, но вызывается по клику на A
function nonClicker(event1,target1){
// Функция clicker2() будет вызываться при клике на кнопку b
return function clicker2(event2){
// В этой функции доступны все три переменные
console.log(event1,event2,target1);
}
}
</code>/** Код полностью рабочий */
document.getElementById('a').addEventListener('click', clicker);
function clicker(event1){
let target1 = event1.target;
// Здесь мы вызываем функцию clicker2(), которая возвращает функцию, которую передаём параметром к addEventListener
document.getElementById('b').addEventListener('click', clicker2(event1, target1));
}
// Эта функция вызывается не по клику на b, но вызывается по клику на a
function clicker2(event1,target1){
// Функция после return будет вызываться при клике на кнопку b
return function(event2){
// В этой функции доступны все три переменные
console.log(event1,event2,target1);
}
}