Look Who it Was Random video

JavaScript Attack Breaks ASLR

1,814 views · Published 19 March 2017 · 13:13 · Indexed 22 September 2026

Channel: Hands-On AI · 2017 · Howto & Style

Watch on YouTube

Let's start with the problem: pwning computers is too easy.

Bleeping Computer Article
https://www.bleepingcomputer.com/news/security/javascript-attack-breaks-aslr-on-22-cpu-architectures/

Show Notes Below,

Time jump back to the 90s 
* Every time your computer OS loads, it goes into the same, predictable memory cells. 
* Programs tend to load into contiguous cells

This makes it VERY easy to exploit your OS
* I find a way to write to memory that I shouldn't be writing to... typically with a buffer overrun.
* If I know where I'm writing, and I know what's in the next contiguous cells, then if I can fool the OS to OVERWRITING those cells.
* If those cells are the cells that are being used to EXECUTE code, then I can make the OS run anything I want

Time jump forward to 2001
* Researchers start looking at ways to make it more difficult to use simple buffer overruns to take over an OS
* The Linux PaX project offers a kernel patch that implements kernel stack randomization
* Rather that writing to contiguous memory cells, ASLR uses random memory locations
* This makes it more difficult for an attacker to simply use a buffer overflow to overwrite the program he wants to exploit.

Effect of ASLR
* OS can still get pwned, but it's more difficult
* With ASLR, there's no guarantee as to where you're writing in memory, or where in memory is the program you want to hijack.

What just happened
* VUSec is a group of Dutch security researchers
* They figured out a way to defeat ASLR by exploiting the "Memory Management Unit"
 - The MMU keeps a "page table" of where everything is stored in memory
 - The placement of data in the memory cells is random but the CPU used the MMU as a map
 - A copy of that map is kept in the CPU cache to speed processing
* VUSec figured out a way to use that cached copy to find the offsets: (DeRandomizing the randomization)

Here's how it works:
* A program isn't allowed to READ from cache, but it can (needs to be able to) WRITE to cache
* This exploit does as follows:
 1. Measure the baseline response time of the processor
 2. Write to a single cell of CPU cache
 3. Measure the response time of the processor
 4. Compare the response time against the baseline response
  ** Rinse and Repeat
* If the processor response time drops, it's most likely b/c the cell contained some of the page table.
* Since you overwrote the page table, the CPU needs to get a fresh copy from main memory, which slows the processor

** Do this enough times, and you can figure out where the code is executed in memory.

NB:
* This exploit can be done with JavaScript
* You shouldn't be allowing JS at all
* Very hard to mitigate b/c it's a hardware problem
* Most of the proposed mitigation involve playing with CPU response time to fool the malware, but that means we're giving up some of the performance.

More from this channel