{"id":306362,"date":"2009-11-23T11:00:30","date_gmt":"2009-11-23T19:00:30","guid":{"rendered":"https:\/\/www.microsoft.com\/en-us\/research\/?p=306362"},"modified":"2016-10-16T18:07:32","modified_gmt":"2016-10-17T01:07:32","slug":"nozzle-counteracting-memory-exploits","status":"publish","type":"post","link":"https:\/\/www.microsoft.com\/en-us\/research\/blog\/nozzle-counteracting-memory-exploits\/","title":{"rendered":"Nozzle: Counteracting Memory Exploits"},"content":{"rendered":"

By Janie Chang, Writer, Microsoft Research<\/em><\/p>\n

Computer security has been described as a game of one-upmanship, an ongoing escalation of techniques as both sides attempt to find new ways to assault and protect system vulnerabilities. The most prevalent forms of incursion over the last decade have been aimed at computer memory\u2014and of these, the newest, most popular weapon of choice for attackers is a technique known as heap spraying.<\/p>\n

Heap spraying works by allocating multiple objects containing the attacker\u2019s exploit code in the program\u2019s heap, the area of memory used for dynamic memory allocation. Many recent high-profile attacks, such as an Internet Explorer exploit in December 2008 and one of Adobe Reader in February 2009, were examples of heap spraying.<\/p>\n

\"Nozzle\"Heap-spray attacks are difficult to detect reliably, but Ben Livshits<\/a> and Ben Zorn<\/a>, researcher and principal researcher at Microsoft Research Redmond<\/a>, respectively, have been studying this problem. They are confident that, in Nozzle<\/a>, they have a tool for identifying heap-spray attacks that is reliable, general, and practical. During the 18th Usenix Security Symposium<\/a>, held in August in Montreal, not only did they present their paper, Nozzle: A Defense Against Heap-spraying Code Injection Attacks<\/em><\/a>,<\/em> co-authored with Paruj Ratanaworabhan of Cornell University, but they also showed a live demo of their solution while on stage.<\/p>\n

A Brief History of Memory Exploits<\/h2>\n

The goal of any attack is to get the targeted computer to run exploit code supplied by the attacker. To achieve this, two things must happen: The code must end up on the computer, and the computer must run that code.<\/p>\n

The earliest type of memory exploit took advantage of buffer-stack overflows. Attackers found ways to overwrite a buffer on the stack and used that vulnerability to change or insert program code to make the program jump to instructions provided by the attacker. Stack-overflow attacks diminished in effectiveness as programming languages evolved to prevent buffer overflows.<\/p>\n

Memory exploits then focused on heap-based overflows, in which, instead of placing instructions on the stack, attackers found ways to insert them into the program\u2019s heap. Nowadays, heap-based exploits are more difficult to achieve. Operating systems such as Windows Vista use a technique called address-based layout randomization, in which the base address of the code, the heap, and the stack change each time the program runs. This prevents attackers from reliably predicting target addresses for code locations, and if there is one copy of the exploit code in a large heap, it\u2019s akin to finding the proverbial needle in a haystack.<\/p>\n

Heap spraying circumvents this challenge by allocating, or \u201cspraying,\u201d multiple copies of exploit code to increase the odds of finding a copy in the heap. The attacker can allocate hundreds of thousands of copies of exploit code into the heap. All that\u2019s needed is for one random program jump to land on one copy of such code, and a successful attack begins.<\/p>\n

But how does an outside entity manage to allocate thousands of copies of exploit code onto a remote computer?<\/p>\n

It Begins with JavaScript<\/h2>\n
\"Ben

Ben Zorn<\/p><\/div>\n

\u201cEvery time you download a Web page,\u201d Zorn says, \u201cit can contain JavaScript, which is executable code. It\u2019s perfectly valid for JavaScript to allocate objects. So attackers use JavaScript to propagate copies of malicious objects and then exploit some known bug in the browser to execute malicious code.\u201d<\/p>\n

Such an approach may not work every time; there is always an element of luck involved. But if the attacker lures enough users to the page, enough of the attempts will succeed, and enough machines would be compromised to cause nuisance or damage.<\/p>\n

Adds Zorn: \u201cThe interesting thing about heap spraying is that, from the attacker\u2019s point of view, it\u2019s easy to implement. The actual spray is just a loop written in JavaScript, and the exploit code is a JavaScript string. Ten lines of code in JavaScript are sufficient to create a heap-spray attack.\u201d<\/p>\n

Kittens of Doom<\/h2>\n

It\u2019s disturbing enough to know how little effort it takes to create a heap spray, but browsers are not the only programs at risk. Any program that enables JavaScript execution is vulnerable. Attacks on Adobe Reader and Acrobat proved that PDF files, which users consider passive and read-only, can be a source of heap-spraying attacks, too.<\/p>\n

\u201cApplications such as Adobe Reader have evolved to be more dynamic,\u201d Livshits says. \u201cThey allow some scripting, to support more extensibility, and rely on languages such as JavaScript to enable that. This is a widespread phenomenon, and, as a result, heap spraying as an attack vector is also widespread. In fact, another program susceptible to this is Flash, since you can embed script in a Flash player in a similar way. So it\u2019s important to understand it\u2019s not just Web pages that are vulnerable.\u201d<\/p>\n

Just about any form of data can be used for exploitation, Zorn says. To drive this point home during the Usenix Security Symposium, the researchers displayed a slide titled \u201cKittens of Doom: Is No Data Sacred?\u201d<\/p>\n

\"Kittens

Kittens of Doom: Be it a Web page, a PDF, or a Flash files, any form of data can be used for exploitation. Malicious code has been found embedded in image-file comment fields, documents, and dynamic-link libraries.<\/p><\/div>\n

\u201cWe wanted to convey that the most innocent of files can be used for exploitation,\u201d Livshits says. \u201cThis is an apparently harmless image of a kitten, but there is a malicious payload in the comment field of the image that initiates a heap-spraying attack on the browser.<\/p>\n

\u201cNot every heap-spraying attack works, so it\u2019s possible the data you receive had passed harmlessly through other users, because the spray worked but the exploit failed. What\u2019s benign to another user else could be a problem for you.\u201d<\/p>\n

All Roads Lead to Shell Code<\/h2>\n

Given that any data can be used for exploitation, the researchers took the perspective that they should examine all objects on the heap. In some cases, data can look like code and vice versa, making it even more difficult to reliably identify harmful objects.<\/p>\n

The first breakthrough for the team came when they decided that, instead of looking at individual instructions in an object, they would analyze its control flow.<\/p>\n

\u201cThe ultimate goal of these objects is to get to the shell code.\u201d Zorn says, \u201cThat\u2019s what we call the code that causes actual damage. If the object can\u2019t direct control to the shell code, the attack fails.<\/p>\n

\u201cIf there is an object and, no matter where we jump into it, we almost always end up going to the same place, then it qualifies as suspicious. Now, there could be non-malicious objects in the heap that contain what look like instructions\u2014but it\u2019s very unlikely that they will also try to make you go to the same place. So control flow is a semantic property that helped us zero in on malicious objects.\u201d<\/p>\n

This approach proved more reliable than other detection schemes, with only a 10 percent false-positive rate. The researchers, though, were aiming for zero false-positives, if possible.<\/p>\n

\u201cWe are talking about stopping the program each time we detect a suspicious object,\u201d Livshits says. \u201cIf objects are actually harmless 10 percent of the time, it\u2019s an unacceptable amount of disruption to the user.\u201d<\/p>\n

Profile of an Exploit<\/h2>\n

Fortunately, there is another characteristic of heap spraying the researchers could leverage: To be successful, attackers have to allocate thousands of objects into the heap. This understanding led to the researchers\u2019 second breakthrough: the notion of the global heap metric index, an aggregate of measurements across all heap objects.<\/p>\n

\"The

The Economist Web site\u2019s normal number of heap allocations is shown in blue. The purple line shows the number of allocations resulting from an attack named exploit-612, a sharp jump that Nozzle would flag.<\/p><\/div>\n

\u201cIn a spray attack, we don\u2019t have just a few suspicious objects.\u201d Zorn says. \u201cThere are thousands, representing a large percentage of the heap. So we came up with an index that would indicate the health of the entire heap\u2014essentially a measure of the fraction of the heap that contains suspicious objects.\u201d<\/p>\n

A few suspicious objects won\u2019t raise an alarm. But a high density of suspicious objects is a reliable indication of a heap-spraying attack. The global heap metric index dramatically reduced the false-positive rate.<\/p>\n

\u201cWe take advantage of the very scheme attackers depend on for exploitation,\u201d Zorn says. \u201cIn order for such attacks to work, they must allocate many, many objects; so we monitor whether a significant percentage of the heap contains suspicious objects.\u201d<\/p>\n

Putting Results to Work<\/h2>\n

Using their findings, the team built Nozzle, a run-time tool that takes a two-level approach to detecting heap-spraying attacks.<\/p>\n

Nozzle\u2019s lightweight emulator scans heap-allocated objects and treats them as though they are code: It disassembles the code, follows the flow, and builds a control-flow graph. This analysis identifies potentially unsafe code within a safe environment. Nozzle also maintains the global heap metric index.<\/p>\n

During testing, Nozzle proved its effectiveness by detecting 100 percent of 12 published and 2,000 synthetically constructed heap-spraying exploits. Even with a detection threshold set six times lower than what is required to detect published malicious attacks, Nozzle reported zero false positives when run against 150 popular Internet sites.<\/p>\n

\"Ben

Ben Livshits<\/p><\/div>\n

But how does Nozzle affect application performance?<\/p>\n

\u201cWhen we designed the algorithms,\u201d Livshits says, \u201cgiven that our primary target for protection is the highly competitive browser market, we had to minimize overhead. If browsers slow down to a crawl when Nozzle is running, the technology just wouldn\u2019t be interesting to manufacturers.<\/p>\n

\u201cIf we examine every single heap object, Nozzle slows down execution by 2 to 14 times. However, by using sampling, we can achieve effective detection and reduce overhead significantly. A sampling rate of 1 in 20 worked for us and incurred only a 5 to 10 percent performance overhead.\u201d<\/p>\n

Not Just for Browsers<\/h2>\n

When the researchers started work on the Nozzle project, they had browsers in mind. But when they heard about the PDF exploit earlier this year, they tried an experiment.<\/p>\n

\u201cWe downloaded the latest copy of Adobe Reader.\u201d Zorn recalls. \u201cWe instrumented it using Nozzle, and everything worked without any extra effort on our part. We were thrilled, because this suggested that Nozzle is very general and that its techniques can be applied to any attack that uses embedded JavaScript to fill the address space with malicious code objects.\u201d<\/p>\n

Adds Livshits: \u201cThe point is that Nozzle raises the bar considerably for the state of the art in this space. It is the first defensive technology to explicitly go after heap spraying. Plus, there is evidence to show that it can be an effective and reliable general tool.\u201d<\/p>\n

Always a Next Step<\/h2>\n

Zorn and Livshits would never suggest that Nozzle alone is sufficient protection against heap spraying. Defense in depth is their recommendation, a combination of tactics to counteract memory exploits.<\/p>\n

\u201cNozzle is orthogonal to other defensive strategies,\u201d Zorn says. \u201cDefensive programming will always be important, and as more systems support mechanisms such as Data Execution Prevention (DEP), there will be more obstacles to heap exploits.\u201d<\/p>\n

But doesn\u2019t enabling DEP to prevent execution of code within the heap effectively block all instances of heap exploits?<\/p>\n

\u201cThere are technical and compatibility issues that prevent DEP from being used in some environments,\u201d Livshits says. \u201cPlus, we are already hearing of attacks that start by turning off DEP. Also, there have been code-injection-spraying attacks in areas where DEP can\u2019t be used. So DEP is not the silver bullet\u2014and neither is Nozzle.\u201d<\/p>\n

There is no doubt that once heap-memory exploits are a thing of the past, other threats will appear. Livshits and Zorn relish the challenge, though, because the results of their work are so satisfyingly obvious and demonstrable.<\/p>\n

For now, they are interested in those recent code-injection-spraying attacks that foil DEP. They plan to show that Nozzle also can be effective in detecting such attacks\u2015and that the forces for good can count on another tool to help keep software secure.<\/p>\n","protected":false},"excerpt":{"rendered":"

By Janie Chang, Writer, Microsoft Research Computer security has been described as a game of one-upmanship, an ongoing escalation of techniques as both sides attempt to find new ways to assault and protect system vulnerabilities. The most prevalent forms of incursion over the last decade have been aimed at computer memory\u2014and of these, the newest, […]<\/p>\n","protected":false},"author":39507,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"msr-url-field":"","msr-podcast-episode":"","msrModifiedDate":"","msrModifiedDateEnabled":false,"ep_exclude_from_search":false,"footnotes":""},"categories":[194489],"tags":[214727,214721,214703,201057,214709,214718,214706,214724,186529,214712,214700,214715],"research-area":[13558],"msr-region":[],"msr-event-type":[],"msr-locale":[268875],"msr-post-option":[],"msr-impact-theme":[],"msr-promo-type":[],"msr-podcast-series":[],"class_list":["post-306362","post","type-post","status-publish","format-standard","hentry","category-security","tag-address-based-layout-randomization","tag-buffer-stack-overflows","tag-computer-memory","tag-computer-security","tag-dynamic-memory-allocation","tag-exploit-code","tag-heap-spraying","tag-heap-based-overflows","tag-javascript","tag-nozzle","tag-system-vulnerabilities","tag-usenix-security-symposium","msr-research-area-security-privacy-cryptography","msr-locale-en_us"],"msr_event_details":{"start":"","end":"","location":""},"podcast_url":"","podcast_episode":"","msr_research_lab":[199565],"msr_impact_theme":[],"related-publications":[],"related-downloads":[],"related-videos":[],"related-academic-programs":[],"related-groups":[],"related-projects":[170075],"related-events":[],"related-researchers":[],"msr_type":"Post","byline":"","formattedDate":"November 23, 2009","formattedExcerpt":"By Janie Chang, Writer, Microsoft Research Computer security has been described as a game of one-upmanship, an ongoing escalation of techniques as both sides attempt to find new ways to assault and protect system vulnerabilities. The most prevalent forms of incursion over the last decade…","locale":{"slug":"en_us","name":"English","native":"","english":"English"},"_links":{"self":[{"href":"https:\/\/www.microsoft.com\/en-us\/research\/wp-json\/wp\/v2\/posts\/306362"}],"collection":[{"href":"https:\/\/www.microsoft.com\/en-us\/research\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.microsoft.com\/en-us\/research\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.microsoft.com\/en-us\/research\/wp-json\/wp\/v2\/users\/39507"}],"replies":[{"embeddable":true,"href":"https:\/\/www.microsoft.com\/en-us\/research\/wp-json\/wp\/v2\/comments?post=306362"}],"version-history":[{"count":2,"href":"https:\/\/www.microsoft.com\/en-us\/research\/wp-json\/wp\/v2\/posts\/306362\/revisions"}],"predecessor-version":[{"id":306404,"href":"https:\/\/www.microsoft.com\/en-us\/research\/wp-json\/wp\/v2\/posts\/306362\/revisions\/306404"}],"wp:attachment":[{"href":"https:\/\/www.microsoft.com\/en-us\/research\/wp-json\/wp\/v2\/media?parent=306362"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.microsoft.com\/en-us\/research\/wp-json\/wp\/v2\/categories?post=306362"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.microsoft.com\/en-us\/research\/wp-json\/wp\/v2\/tags?post=306362"},{"taxonomy":"msr-research-area","embeddable":true,"href":"https:\/\/www.microsoft.com\/en-us\/research\/wp-json\/wp\/v2\/research-area?post=306362"},{"taxonomy":"msr-region","embeddable":true,"href":"https:\/\/www.microsoft.com\/en-us\/research\/wp-json\/wp\/v2\/msr-region?post=306362"},{"taxonomy":"msr-event-type","embeddable":true,"href":"https:\/\/www.microsoft.com\/en-us\/research\/wp-json\/wp\/v2\/msr-event-type?post=306362"},{"taxonomy":"msr-locale","embeddable":true,"href":"https:\/\/www.microsoft.com\/en-us\/research\/wp-json\/wp\/v2\/msr-locale?post=306362"},{"taxonomy":"msr-post-option","embeddable":true,"href":"https:\/\/www.microsoft.com\/en-us\/research\/wp-json\/wp\/v2\/msr-post-option?post=306362"},{"taxonomy":"msr-impact-theme","embeddable":true,"href":"https:\/\/www.microsoft.com\/en-us\/research\/wp-json\/wp\/v2\/msr-impact-theme?post=306362"},{"taxonomy":"msr-promo-type","embeddable":true,"href":"https:\/\/www.microsoft.com\/en-us\/research\/wp-json\/wp\/v2\/msr-promo-type?post=306362"},{"taxonomy":"msr-podcast-series","embeddable":true,"href":"https:\/\/www.microsoft.com\/en-us\/research\/wp-json\/wp\/v2\/msr-podcast-series?post=306362"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}