未加星标

ASLR-security-busting JavaScript hack demo'd by university boffins

字体大小 | |
[前端(javascript) 所属分类 前端(javascript) | 发布者 店小二05 | 时间 2017 | 作者 红领巾 ] 0人收藏点击收藏

Researchers in Europe have developed a way to exploit a common computer processor feature to bypass a crucial security defense provided by modern operating systems.

By abusing the way today's CPUs manage system memory, an attacker can discover where software components, such as libraries and RAM-mapped files, are located in virtual memory. With these locations in hand, malicious code can find and use particular instructions and data within these components to start hijacking a computer system.

Specifically, the researchers have shown how to defeat address space layout randomization ( ASLR ). This is a mechanism provided by operating systems from windows and linux to macOS and the BSDs that randomly places each application's dependencies in their virtual memory spaces. This makes it tough for attackers to run exploit code that expects widgets of code and data in specific spots in memory. Without the base addresses for these components, attackers are blindfolded and their hack attempts usually fail.

If naughty code such as javascript running on a malicious webpage can discern where these libraries and other objects are positioned at runtime, a follow-up exploit on the page can use this leaked information to reliably attack browser bugs and move onto the next stage of the intrusion: usually this involves performing system calls to spawn new processes, download payloads, and gain control of the host system.

Dutch researchers Ben Gras, Kaveh Razavi, Erik Bosman, Herbert Bos, and Cristiano Giuffrida of Vrije Universiteit (VU) in Amsterdam have come up with clever JavaScript that, while running silently on a webpage, can observe the processor's memory management unit (MMU) in operation by measuring precise timings between memory accesses, work out where key data and code is mapped in memory, and render ASLR protections ineffective.

The MMU present in desktop, mobile and server chips is programmed by the operating system kernel to control where objects in virtual memory are held in physical memory. The time it takes for the unit to look up a physical address from a virtual memory access can be used, when performed over and over, to gradually leak the location of components.

The team has been able to write a proof-of-concept demonstration of the security weakness entirely in JS, and they say the code works on multiple architectures including Intel and AMD x86 chips, and ARM-compatible cores.

"The memory management unit of modern processors uses the cache hierarchy of the processor in order to improve the performance of page table walks. This is fundamental to efficient code execution in modern processors," the team explained today.

"Unfortunately, this cache hierarchy is also shared by untrusted applications, such as JavaScript code running in the browser."

This, the VU team says, is what makes this vulnerability so significant. An attacker could embed the malicious JavaScript code in a webpage, and then run the assault without any user notification or interaction.

Because the assault does not rely on any special access or application flaws, it works on most browsers and operating systems. The researchers say that when tested on up-to-date web browsers, the exploit could fully unravel ASLR protections on 64-bit machines in about 90 seconds.

Infecting a system does not end there, of course: it just means ASLR has been defeated. The next step is to use this memory location information to launch a viable and reliable attack on bugs within the browser. Without this location information, the follow-up exploit would be fumbling in the dark. With the information, it's easier to fully exploit the browser bugs. Below is a video of the JS code working in Firefox on a 64-bit Linux machine.

Youtube Video

The researchers conclude that developers should not rely on ASLR as a strong security protection, and they should implement other measures to harden their browsers against exploits. Apple has already done just that, and acknowledged the VU researchers in its latest WebKit update see the final note on that page.

For normal folk, the VU team suggests the best defense for now is to block untrusted JavaScript from executing with the use of a browser plugin such as NoScript. Future editions of browsers could come with builtin measures to potentially thwart MMU timing attacks.

Fully eliminating the vulnerability, however, will be difficult, and the group suggests effective protections may not be feasible until next-generation processors feature hardware mechanisms to defeat MMU side-channel snooping. The vulnerability is similar to the jump-over-ASLR technique we reported on in October.

We asked the Amsterdam team if their MMU timing vulnerability, dubbed AnC, is, honestly, practical to exploit. A lot of these types of flaws can be leveraged easily in a research lab, where conditions are quiet, controlled and ideal for attackers.

However, in the real world, computer systems are far more noisy, with CPU cores accessing all kinds of patterns of data, and processes being switched in and out of context as the user does their thing. That randomness tends to mess up timing-based attacks by introducing unexpectedly large latencies.

"There is no doubt that this side channel attack works and is practical on everyday browsers," Gras told The Register . He continued:

Most previous work on side-channel attacks assumes that the attacker is running in a different process or virtual machine but on the same machine. Further, they usually attack cryptographic operations, something that the average Internet user does not usually do. The difference with AnC is that it runs from JavaScript and targets something that every Internet user relies on for security, namely ASLR.

The attack is also quite practical: it runs on any architecture that we tried and can quickly break 27 bits of entropy within a few seconds. As a reference, Microsoft Windows only provides 24 bits of entropy for its heap.

The prototype implementation was implemented it on normal browsers on normal Linuxes. The video on the AnC projects page visualizing the attack in Firefox is real and not cherry-picked. Just for completeness sake however, this does not mean the prototype is ready to be deployed as an in-the-wild attack our goal is to prove that it is possible to use this work in a realistic attack, not to actually do it. The Chrome version relies on a feature that is still being standardized and not enabled by default ( Javascript Shared memory ), but is on schedule to be in the future. Also, the scope of this work is that we are breaking ASLR and therefore an additional memory corruption bug is needed to complete an exploit chain. This greatly reduces the burden on the attacker however, who would normally need another bug to leak ASLR information.

"We are confident that with additional engineering effort, this work can be part of a realistic attack," Gras concluded.

本文前端(javascript)相关术语:javascript是什么意思 javascript下载 javascript权威指南 javascript基础教程 javascript 正则表达式 javascript设计模式 javascript高级程序设计 精通javascript javascript教程

主题: JavaJavaScriptLinuxCPUWindowsChromeAppleAMDVUFirefox
分页:12
转载请注明
本文标题:ASLR-security-busting JavaScript hack demo'd by university boffins
本站链接:http://www.codesec.net/view/533886.html
分享请点击:


1.凡CodeSecTeam转载的文章,均出自其它媒体或其他官网介绍,目的在于传递更多的信息,并不代表本站赞同其观点和其真实性负责;
2.转载的文章仅代表原创作者观点,与本站无关。其原创性以及文中陈述文字和内容未经本站证实,本站对该文以及其中全部或者部分内容、文字的真实性、完整性、及时性,不作出任何保证或承若;
3.如本站转载稿涉及版权等问题,请作者及时联系本站,我们会及时处理。
登录后可拥有收藏文章、关注作者等权限...
技术大类 技术大类 | 前端(javascript) | 评论(0) | 阅读(20)