- 1
- 2
- 3
- 4
> We demonstrate key extraction even from an implementation of Curve25519 Elliptic Curve Diffie-Hellman, which was explicitly designed
to minimize side channel leakage, but becomes susceptible due to use of high-level JavaScript
> Concretely, we have embedded the attack code in an advertisement, which we submitted to a commercial web advertisement service
Тут свежую атаку из жабаскрипта подвезли, они там опять ебут процессорный кэш и угадывают поведение control flow и составляющие ключа по времени доступа к памяти
https://eprint.iacr.org/2018/119
О. Годно.
Но уязвимы ли жс-интерпретаторы?
Что это такое?
> Thus, we use an alternative technique, based on an intentional inter-thread
race condition (see [62] for a recent survey of JavaScript timing sources, including this one).
In this approach, we allocate a SharedArrayBuffer array within the main JavaScript context,
and pass it to a "Timer" Web Worker which iteratively increments the value in the first cell of the
array in a tight loop. To acquire the value of our timer, the main context simply has to read that
value from the array. The naive implementation, accessing the array directly, did not work due to
runtime optimizations: since the incrementing iteration runs in a separate context of Web Worker,
the engine assumes that repeatedly reading the same memory location will yield the same result,
and optimizes the code to return a constant value. To overcome this, we used the Atomics API to
force reading from the array (with sufficiently small performance penalty).
[62], судя по всему, тоже тот еще охуенчик: Fantastic Timers and Where to Find Them: High-Resolution Microarchitectural Attacks in JavaScript