ATLANTIS - Assembly Trace Analysis Environment

Transcription

1 ATLANTIS - Assembly Trace Analysis Environment Brendan Cleary, Margaret-Anne Storey, Laura Chan Dept. of Computer Science, University of Victoria, Victoria, BC, Canada bcleary@uvic.ca, mstorey@uvic.ca, lkchan@uvic.ca Martin Salois, Frederic Painchaud Defense Research and Development Canada Valcartier, Quebec, QC, Canada martin.salois@drdc-rddc.gc.ca, frederic.painchaud@drdc-rddc.gc.ca For malware authors, software is an ever fruitful source of vulnerabilities to exploit. Exploitability assessment through fuzzing aims to proactively identify potential vulnerabilities by monitoring the execution of a program while attempting to induce a crash. In order to determine if a particular program crash is exploitable (and to create a patch), the root cause of the crash must be identified. For particular classes of programs this analysis must be conducted without the aid of the original source code using execution traces generated at the assembly layer. Currently this analysis is a highly manual, text-driven activity with poor tool support. In this paper we present ATLANTIS, an assembly trace analysis environment that combines many of the features of modern IDEs with novel trace annotation and navigation techniques to support software security engineers performing exploitability analysis. I. INTRODUCTION A zero-day exploit occurs when a vulnerability in a software program is discovered and malware exploiting the flaw is developed and released before a patch is available. Software security engineers attempt to protect against zeroday exploits by proactively finding vulnerabilities in programs before malware authors can develop code that exploits those vulnerabilities. Exploitability analysis is the process of determining if a given program may be susceptible to exploitation. One way of determining if a program may have a hidden vulnerability is to attempt to make the program crash and then to analyze the resulting execution trace. The main steps in this process are: fuzzing, crash prioritization, root cause analysis and exploitability assessment. Fuzzing is a process whereby an engineer attempts to induce a program crash by feeding that program random or planned program inputs until it crashes [1]. One of the major limitations with this type of approach is that it can find too many crashes. Crash prioritization attempts to identify crashes that are more likely to expose potential vulnerabilities [2]. While these steps can be somewhat automated, assessing the actual exploitability of a crash and performing root cause analysis requires a great deal of human reasoning. Software security engineers typically use a combination of static and dynamic analysis techniques to determine the cause of a crash and if the program is vulnerable to exploitation. In cases where access to the source code of the program under analysis is not available, engineers must instead rely on analyzing assembly-level execution traces generated during fuzzing. ATLANTIS is an integrated assembly trace analysis environment designed to assist engineers perform and manage this analysis. It provides engineers with features typical of integrated development environments as well as novel comment and tagging features designed to facilitate recording and sharing of analysis insights. II. BACKGROUND There is a large body of related work in the field of dynamic analysis for reverse engineering and performance analysis that studies methods and tools for aiding software engineers in understanding execution traces. However, tools from these fields tend to assume the availability of source code and use extra structural information present in the source (package names, meaningful function and variable names, etc.) to assist engineers in visualizing, navigating and understanding a program s execution trace. More recently, security researchers have started building tools specifically for binary security analysis that work directly with the program executable. For example the BitBlaze platform [3] provides a set of tools for performing static and dynamic analysis of binaries as well as tools designed specifically for analyzing execution traces. ATLANTIS is designed to work with and present the execution traces generated by these types of analysis tools, providing security engineers with a user-friendly environment to explore, perform, record and share their analysis. III. ATLANTIS ATLANTIS is built on the Eclipse Rich Client Platform (RCP) and provides the following views to support exploitability and trace analysis; trace view, search view, regions view, tagging view, comments view and project view (Figure 1). The trace view provides users with a familiar way to view and navigate the trace or traces under analysis. Using syntax highlighting similar to that found in programming language editors, the trace view automatically color codes different parts of each line of the execution trace. If the user selects a particular memory address in the trace, the trace view automatically highlights all other references to that address. The search view provides users with regular-expressionbased search functionality allowing them to define and execute queries over the execution trace. When the user

2 executes a search, matching occurrences of the search string are automatically highlighted in the trace view, while the search results view shows all occurrences as an easily navigable list. Users can use keyboard or navigation buttons in the search results view to quickly navigate between results. The regions view allows a user to right click in the trace view to create a new region based on the selected section of trace. The regions view then provides a hierarchical list of all regions defined in the trace. Regions can be used by security engineers to collapse or hide all non-relevant parts of a trace after successfully performing a root cause analysis or to single out parts of the trace that are of interest. The commenting and tagging views provide a way for users to quickly record hypotheses as they traverse the trace. Building on previous work on tagging in software development [4], tags allow a user to annotate a particular line and column (or entire sections) in the trace. There can be multiple occurrences of a tag. Using the tags view, the user can navigate between all occurrences of a tag. Tags can also be grouped. Comments function in a similar way but are unique and allow a user to express more complex ideas about a particular location or section of trace. Unlike traditional source code editors, where comments and tags are expressed in-line with the source, in ATLANTIS comments and tags are displayed in a layer floating above the trace view. This allows the user to selectively display only particular groups of comments and tags. For example, a user analyzing a trace might have different comment groups for different features they are investigating in the trace. Comment and tag layering allows a user to quickly show or hide all comments from one or both of those features. Often users will not be concerned with analyzing a single trace but rather multiple related traces. To accommodate this, we have implemented a project view that allows users to treat multiple traces as part of a single project. Another feature provided by this view is the ability to import comment and tag files from other users who might be analyzing the same trace file. This feature enables lightweight collaboration in an environment where, due to the sometime dangerous and disconnected nature of the work (e.g. where one does not want to accidentally release malware), sharing information and collaboration across networks can be difficult. IV. CONCLUSION This paper presents ATLANTIS, a tool designed to assist software security engineers with identifying potentially exploitable programs based on analysis of their execution traces. In our previous work [5], we reported on a first-of-itskind field study of the work practices of software security engineers where we identified the tools and processes used, as well as the unique constraints and challenges those engineers face. ATLANTIS directly follows from that research and has been designed in collaboration with software security engineers to meet their requirements. Future work will add features such as trace comparison, visualization and investigate integration of software understanding techniques like software reconnaissance. We will also perform empirical studies on how well this tool assists engineers performing trace and exploitability analysis. REFERENCES [1] Sutton, M., Greene, A., Amin, P., Fuzzing: Brute Force Vulnerability Discovery, Addison-Wesley, [2] Microsoft,!exploitable Crash Analyzer - MSEC Debugger Extensions, 7/11/2012 [3] Song, D., Brumley, D., Yin, H., Caballero, J., Jager, I., Kang, M., Liang, Z., Newsome, J., Poosankam, P., Saxena, P., Sekar, R., Pujari, A., BitBlaze: A New Approach to Computer Security via Binary Analysis Book Title: Information Systems Security, Lecture Notes in Computer Science, Springer Berlin / Heidelberg, 2008, pp [4] Storey, M.A., Ryall, J., Singer, J., Myers, D., Li-Te Cheng, Muller, M., How Software Developers Use Tagging to Support Reminding and Refinding, IEEE Transactions on Software Engineering, Vol 43, No 4, July-Aug [5] Treude, C., Figueira Filho, F., Storey, M.A., Salois, M., "An Exploratory Study of Software Reverse Engineering in a Security Context", 18th Working Conference on Reverse Engineering (WCRE), pp , Figure 1 - ATLANTIS User Interface

3 Appendix. Demonstration Outline The ATLANTIS trace analysis environment provides a set of plugins to help security engineers perform program exploitability analysis using program traces. Our demonstration will provide the audience with an introduction to the problem of exploitability analysis followed by a detailed description of each of these plugins using a simple exploitability analysis scenario to help explain how the tool can be used by security engineers. ATLANTIS User Interface ATLANTIS is an Eclipse RCP (Rich Client Platform) application. Being an RCP application allows ATLANTIS to leverage the file handling, windowing, view docking and plugin capabilities of the Eclipse platform as well as rich user interface customization abilities. ATLANTIS is composed of a set of views, each of which provides specific functionality useful to security engineers performing exploitability analysis. An overview of the ATLANTIS user interface with major views outlined is provided in Figure 1. The next sections will describe each view in turn. Figure 1 - ATLANTIS User Interface A. Project Management

4 Often when performing exploitability analysis over traces engineers will not be concerned with analyzing a single trace but rather multiple related traces such as comparing a good trace (normal behavior) with a bad trace (crash) (Figure 2). Figure 2 - Project Management View For the demonstration we will show how the Project Management View allows security engineers to: - Create a new project - Group multiple traces and associated annotation files together into a hierarchical project structure - Import and export existing trace analysis projects - Import and export annotation files from other users such as comments and tags B. Search Being able to quickly search over the trace is an important part of the functionality required by security engineers when they perform exploitability analysis of execution traces. The Search View allows a user to create and execute a regular expression like search. Search results are presented in the Search Results View and highlighted in the Trace View. For the demonstration we will show how the user can use the search and results views to: - Define and execute a simple search Figure 3 - Review the search results in the Search Results View Figure 4 - Navigate between search results using the keyboard and the Search Results View - How the search results are highlighted in the Trace View Figure 5

5 Figure 3 - Search View Figure 4 - Search Results View

6 Figure 5 - Trace View Search Result Highlighting C. Trace View The Trace View is the main component of the ATLANTIS environment and provides users with a way to view and navigate through execution traces. The trace view provides security researchers with many of the features of a source code editor found in a software development IDE such as syntax highlighting and automatic reference highlighting. For the demonstration we will show the following features of the Trace View: - Annotating trace lines with comments and tags Figure 6 A - A trace overview showing the locations of items of interest such as comments, tags and search results Figure 6 B - Memory location reference highlighting Figure 6 C - Display 2 or more traces side by side Figure 7 Figure 6 - Trace View

7 Figure 7 - Trace View (two traces side by side) D. Regions The Regions View allows a user to selectively collapse or expand parts of a trace. This feature is similar to that which a programmer might use in a programming IDE for hiding irrelevant parts of a program s source file. For the demonstration we will show: - How to create a new region Figure 9 - How to expand and collapse regions Figure 10 - How to create sub-regions Figure 11 - Navigating through the trace using the regions view Figure 8

8 Figure 8 - Regions View Figure 9 - Trace View with regions collapsed

9 Figure 10 - Expanding a region

10 Figure 11 - Trace View with collapsed (B) and expanded regions (A) E. Metadata Layers A unique feature of ATLANTIS is the facilities it offers for separation of annotations and metadata from the trace and controlling what annotations like comments and tags are displayed and how. The Layers View allows a user to quickly and easily control the types of metadata or annotations that are displayed in the Trace Viewer. This design is a departure from traditional approaches to annotations in source code which tend to be made inline in the code rather than separate. This layering approach to metadata allows the engineer to decide what annotations they want to see and when they want to see them rather than the all-or-nothing approach of source code IDEs.

11 Figure 12 - Layers View Currently ATLANTIS has the capability to display two metadata layers; comments and tags (Figure 12). Future versions will include more layers, for example, Taint information. Annotations like comments and tags appear both as icons in the left hand gutter of the Trace View Figure 6 A and as floating tooltips above the Trace View Figure 13. For the demo we will show how to: - Show or hide layers - How annotations float and scroll with the trace view - How to use color coding for annotation types or groups F. Tags The Tags View allows a user to annotate a particular line and column (or entire sections) in the trace with a tag. There can be multiple occurrences of a tag. Using the tags view, the user can navigate between all occurrences of a tag Figure 13. Tags can also be grouped and groups of tags can be selectively displayed or hidden from the user Figure 14.

12 Figure 13 - Tag View & tag occurrences For the demonstration we will show; - How to create a new tag - How to add a tag to a character, line or section of trace - How to manage tag groups - How to navigate the trace using tags - How to selectively display or hide tag groups

13 Figure 14 - Tag View (hide tags) G. Comments Comments in ATLANTIS function in a similar way to tags but are unique and allow a user to express more complex ideas about a particular location or section of trace Figure 15. For the demonstration we will show: - How to create a new comment - How to add a comment to a character, line or section of trace - How to manage comment groups - How to navigate the trace using comment - How to selectively display or hide comment groups Figure 16

14 Figure 15 - Comments View and floating comments in Trace View

15 Figure 16 - Comments View hiding and changing comment colors

16 UNCLASSIFIED SECURITY CLASSIFICATION OF FORM (highest classification of Title, Abstract, Keywords) DOCUMENT CONTROL DATA (Security classification of title, body of abstract and indexing annotation must be entered when the overall document is classified.) 1. ORIGINATOR (Name and address of the organization preparing the document.) University of Victoria Computer science Victoria (BC) Canada 2. SECURITY CLASSIFICATION (Overall security classification of the document, including special warning terms if applicable.) Unclassified 3. TITLE (The complete document title as indicated on the title page. Its classification should be indicated by the appropriate abbreviation (S, C or U) in parentheses after the title.) ATLANTIS - Assembly Trace Analysis Environment 4. AUTHORS (Last name, followed by initials ranks, titles, etc. not to be used.) Chan, L.; Cleary, B.; Painchaud, F.; Salois, M.; Storey, M.A. 5. DATE OF PUBLICATION (month and year of publication of document.) October NO. OF PAGES (Including Annexes, Appendices and DCD sheet.) DESCRIPTIVE NOTES (the category of the document, e.g. technical report, technical note or memorandum. If appropriate, enter the type of report, e.g. interim, progress, summary, annual or final. Give the inclusive dates when a specific reporting period is covered.) Conference proceedings 8a. PROJECT OR GRANT NO. (If appropriate, the applicable research and development project or grant number under which the document was written. Please specify whether project or grant) 15FC04 9a. ORIGINATOR S DOCUMENT NUMBER (Official document number by which the document is identified by the originating activity. Number must be unique to this document.) 8b. CONTRACT NO. (If appropriate, the applicable number under which the document was written) DNDPJ b. OTHER DOCUMENT NOS. (Any other numbers which may be assigned to this document either by the originator or the sponsor.) SL 2012-XXX 10. DOCUMENT AVAILABILITY (Any limitation on further distribution of the document, other than those imposed by security classification.) ( X ) Unlimited distribution ( ) Distribution limited to defence departments ( ) Distribution limited to defence contractors ( ) Distribution limited to government ( ) Distribution limited to Defence R&D Canada ( ) Controlled by Source 11. DOCUMENT ANNOUNCEMENT (Any limitation to the bibliographic announcement of this document. This will normally correspond to the Document Availability (10). However, where further distribution (beyond the audience specified in (10) is possible, a wider announcement audience may be selected.) UNCLASSIFIED SECURITY CLASSIFICATION OF FORM DRDKIM December 2009

17 UNCLASSIFIED SECURITY CLASSIFICATION OF FORM 12. ABSTRACT (Brief and factual summary of the document. May also appear elsewhere in the body of the document itself. It is highly desirable that the abstract of classified documents be unclassified. Each paragraph of the abstract shall begin with an indication of the security classification of the information in the paragraph (unless the document itself is unclassified) represented as (S), (C), or (U). May be in English only). For malware authors, software is an ever fruitful source of vulnerabilities to exploit. Exploitability assessment through fuzzing aims to proactively identify potential vulnerabilities by monitoring the execution of a program while attempting to induce a crash. In order to determine if a particular program crash is exploitable (and to create a patch), the root cause of the crash must be identified. For particular classes of programs this analysis must be conducted without the aid of the original source code using execution traces generated at the assembly layer. Currently this analysis is a highly manual, text-driven activity with poor tool support. In this paper we present ATLANTIS, an assembly trace analysis environment that combines many of the features of modern IDEs with novel trace annotation and navigation techniques to support software security engineers performing exploitability analysis. 13. KEYWORDS, DESCRIPTORS or IDENTIFIERS (Technically meaningful terms or short phrases characterizing a document and could be helpful in cataloguing it. Should be Unclassified text. If not, the classification of each term should be indicated as with the title. Equipment model designation, trade name, military project code name, and geographic location may be included. If possible, should be selected from a published thesaurus. e.g. Thesaurus of Engineering and Scientific Terms (TEST) and that thesaurus-identified. ) reverse engineering, malware, tracer, visualisation, memory, taint analysis UNCLASSIFIED SECURITY CLASSIFICATION OF FORM