Software Security Group - Project Paper | CS 4235, Papers of Computer Science

Download Software Security Group - Project Paper | CS 4235 and more Papers Computer Science in PDF only on Docsity! Software Security Group Project Paper November 17, 2006 Operating System Exploits Amit Tambe Ben Hubbard Jason Fletcher Keith Gargano Ryan Smith Szabolcs Palinko Abstract There is a continuing controversy over the vulnerability of popular Operating Systems; in particular Windows and the plethora of Linux distributions. Despite their differences they can often both share similar vulnerabilities. Those vulnerabilities, implemented through exploits, can be placed into universal classes. The purpose of our research is to examine four particular vulnerability classes through analysis of code, concept, and exploit application. We will examine how the following exploits affect different systems: • Data Validation • Buffer Overflow • SQL Injection • Cross-Site Scripting 1. Introduction What Causes Software Security Problems? Security problems related to software are usually caused by one of two reasons: • Non-conformance, or a failure to satisfy requirements: A non-conformance may be simple; the most common is a coding error or defect, or more complex (i.e., a subtle timing error or input validation error). application. For e.g.: Adding parameters in the URL formed Original hyperlink: http://www.example.corsaire.com/buySpatula.jsp?modelNumber=234 Manipulated hyperlink: http://www.example.corsaire.com/buySpatula.jsp?modelNumber=234&price=0.1 Code Injection When data is processed it is passed to a program that operates in a particular processing context (Perl, PHP, SQL, HTML and the UNIX shells are all examples of processing contexts). This context has its own rules for distinguishing between data and commands. This distinction is important from a security perspective because commands are issued from a trusted source, whereas data could be supplied from a non-trusted source. Code injection attacks attempt to subvert this mechanism so that data is interpreted as commands. For e.g: SQL injection, Cross Site Scripting Principles of validation Reduce data to canonical form Before any processing can be performed on the data it should first be reduced to its canonical form, that is to say its simplest form. Data can be encoded in a number of different formats including ASCII, Unicode, URL encoded, UTF-8 and more. If the application fails to correctly decode this data before the validation functions are performed, they will be of little use, and may allow malformed data or attacks through to the data processor. Validation Strategies Reject Bad Data This is often the first strategy that springs to mind when thinking about data validation: simply define the set of attack data and reject it. This is known as the “black list” approach. Accept only known good data This is opposite of the “black list” approach and hence is known as the “white list approach”. Here, data is rejected unless it specifically matches the criteria for known good data. It allows the developer to define a restricted range for valid data and reject everything that does not fit this set. The set of valid data should be constrained by: • Type – String, integer, unsigned integer, float etc; • Length; • Character set – for example, only alphabetic characters [a-zA-Z]*; • Format – if appropriate the data could be further constrained by specifying a format, e.g.: \d\d\/\d\d\/\d\d • Reasonableness – where possible, values should be compared to expected ranges. For example, a customer ordering 1000 televisions could be suspicious. Where should validation be performed? Client side validation Data validation must always be enforced on the server side. Perimeter validation This method adopts the approach of inserting a data validation layer at the entry point to the application so that all requests are properly validated before being processed by the business logic. A sample attack arising due to data validation vulnerability Name: Linux kernel do_mremap VMA limit local privilege escalation vulnerability Details: A critical security vulnerability exists in the Linux kernel memory management code inside the mremap(2) system call due to missing function return value check. The Linux kernel manages a list of user addressable valid memory locations on a per process basis. Every process owns a single linked list of so called virtual memory area descriptors (called from now on just VMAs). Every VMA describes the start of a valid memory region, its length and moreover various memory flags like page protection. Every VMA in the list corresponds to a part of the process's page table. The page table contains descriptors (in short page table entries PTEs) of physical memory pages seen by the process. The VMA descriptor can be thus understood as a high level description of a particular region of the process's page table storing PTE properties like page R/W flag and so on. The mremap() system call provides resizing (shrinking or growing) as well as moving of existing virtual memory areas or any of its parts across process's addressable space. Moving a part of the virtual memory from inside a VMA area to a new location requires creation of a new VMA descriptor as well as copying the underlying page table entries described by the VMA from the old to the new location in the process's page table. To accomplish this task the do_mremap code calls the do_munmap() internal kernel function to remove any potentially existing old memory mapping in the new location as well as to remove the old virtual memory mapping. Unfortunately the code doesn't test the return value of the do_munmap() function which may fail if the maximum number of available VMA descriptors has been exceeded. This happens if one tries to unmap middle part of an existing memory mapping and the process's limit on the number of VMAs has been reached (which is currently 65535). One of the possible situations can be illustrated with the following picture. The corresponding page table entries (PTEs) have been marked with o and x. Before mremap(): (oooooooooooooooooooooooo) (xxxxxxxxxxxx) [----------VMA1----------] [----VMA2----] [REMAPPED-VMA] 3. Buffer Overflow The first well known buffer overflow attack was by a worm exploiting the application fingerd; the Morris Worm (Reynolds, Darby). The worm would overflow the gets library routine with too many characters, which in turn would allow it to execute an arbitrary program (Reynolds). It caused widespread damage and radically changed the way people would then forever look at the security, or lack there of, of networks. The Morris worm was launched by Robert Morris, and its widespread damage was largely a mistake. Gene Spafford created a Phage mailing list to respond to the emergency, marking the first widespread collaborative effort to combat a cyber threat (Reynolds, Darby). The Buffer Overflow vulnerability, and all its cousins, involve injecting more data than a particular abstract container can hold, and then that data spilling over into places it should not be in order to cause changes to the system, ranging from overwriting data to executing particular code (Balaban). Murat Balaban provides a specific Unix based example in his “Buffer Overflows Demystified” article. The idea behind the attack is to press in data up to the point in which a stack reaches its limit. At this point, the instructions given to the processor involve pushing the overflowing data to overwrite base system file locations. It is known where certain key files are located and where the locations of them are stored. As the commands come in, unable to be stored, and are processed by the processor, the processor interprets them to overwrite the stored locations which can then be directed to particular shell scripts. Those shell scripts, then, can contain malicious code that the adversary was targeting to utilize (Balaban). The example provided by Balaban refers to particular code one designs for oneself in order to demonstrate the dangers of buffer overflows. It is, then, a danger to download that malicious software, but software that is otherwise benign can be manipulated and exploited to implement the buffer overflow concept. JavaScript and ActiveX are the most readily exploited platforms of injection, which will be discussed later, but first one must consider how buffer overflows can be stopped. Buffer overflows can be eliminated with little hassle; they always come in the format of information being stored without bound. Thus, the primary defense against buffer overflows within software design alone come through creating hard caps when information is being stored in tandem (Balaban). In the case of a character array in which memory is allocated up to 256 characters, the array still only has a soft cap. An adversary can flood the array with more characters than it can otherwise handle, and the characters will be stored into memory past the allocation, potentially causing damage to other blocks of memory (Balaban). Some methods, such as strncpy in the standard C programming library, will automatically check for the bound of a supplied input, but others, such as strcpy, will not. If no method provides the safety, then one can discretely assure that any input is of the correct size, either by examining and validating, rejecting anything that is too large, or cutting any data that is too large in order to fit. Although this simple filtering method could be used to eliminate the vulnerability, it is often overlooked in software design. Furthermore, OS controls can sometimes be implemented that make certain any time an application requests data be assigned to memory, there is nothing currently at the address being requested that could be overwritten. Even in secure systems, such as Linux, this OS protection can nevertheless be surpassed (Aleph One). Examples There are a multitude of malicious applications for the buffer overflow vulnerability. It can be conducted both remotely and locally. The remote applications of buffer overflow come in the context of primarily browser implementations. ActiveX and JavaScript are commonly encountered platforms for buffer overflows, and a vast majority of such overflows on vulnerability list sites are from one of the two sources (milw0rm). Simply visiting a website implementing one of these exploits can instantly bypass one's system, and despite attempts to eliminate said vulnerabilities from browser code, they nevertheless remain. Local exploits often come in the form of Trojan horses, viruses, or worms which use software ranging from Adobe Photoshop to the OS itself in order to inject and execute itself. Moreover, a remote exploit can be used to insert the code to produce a local exploit (US-Cert) . Jamikazu exploit The Jamikazu exploit (Appendix A.1) is a remote VML buffer overflow. It utilizes JavaScript and is a Heap overflow attack. The code begins by defining a variety of variables: the address to deliver a playload, the payload, the size of a heap block, size of a spray. Continuing from that, it calls the size of the spray slide utilizing a custom function. Then the core of the code is exceedingly simple; it merely fills an array equal to the number of heap blocks with the location to deliver the payload concatenated by the payload itself, over and over. Eventually the buffer will overflow, and then those two commands will spill out into resident memory. That then causes a program, the Calc.exe calculator application in this particular case, to execute. Merely visiting a website containing this code, which would be invisible and undetectable until instantiating the program, would cause the exploit to work. The payload could as easily contain an entire and far more malicious virus that could do more damage, or even hijack the computer. TippingPoint exploit The TippingPoint exploit (Appendix A.2) is a remote Firefox 1.5.0.4 exploit that also utilizes JavaScript. It works on Windows, Linux, and Macintosh, and thus, is largely OS independent. For Windows it will open the Calc.exe application, for Linux it will create a directory, and for Mac it will bind a terminal. The code begins by defining how it behaves for each operating system, and then it proceeds to detect which OS is being used. If it cannot detect which OS is being used, it will try to cause the browser to crash. Then, using the same pattern as before, the code will merely create a simple array and then run the payload (defined earlier by the OS or lack there of) until the code in question is executed. Unlike the previous example, it does not use a dynamically determined array Preventing XSS There are two types of prevention involved with XSS, user-side prevention and server-side prevention (Microsoft Security). For a user that wants the lowest possible level of risk, they can disable all scripting languages in their browser. While this provides the lowest level of risk, it will probably disable features and functionality that are necessary for fluid web browsing (Microsoft Security). The other solution for users is to exercise caution when browsing the web. Users should only browse websites they know are trustworthy and only follow links that are from trustworthy sources (Microsoft Security). Note that neither of these prevention techniques will completely protect you from XSS attacks because it is really in the hands of the web page developers to prevent these attacks. The first way a web developer can help prevent XSS attacks is the most obvious, that is to patch the web server products that are in use. Even if a web page is not dynamic, some dynamic pages are included in the default installation of the server such as the “404 Not Found” page (Microsoft Security). The other prevention methods are a little more hands on. Web developers should encode output based on input parameters. This will prevent code from running that is supplied by the user and is not validated during input (Microsoft Security). Another prevention method is to filtering input and removing special characters that allow execution of scripts. This can be problematic because some input may require some of the characters that are used to enable scripts (Microsoft Security). The last basic prevention method is to filter special characters from the output based on input parameters. This will allow the input of special characters, but will prevent them from being written out directly to the dynamic page. This can also cause problems to web pages that may write out HTML elements (Microsoft Security). In general, it is up to the web developer to decide which prevention methods will be the most effective for their needs. The XSS vulnerability has been getting a lot more attention recently. Some XSS vulnerabilities are discovered by the result of a malicious attack, but a lot are reported by programmers looking to prove the concept that XSS continues to be a major threat. These programmers then notify the companies that have vulnerabilities on their website so that they can fix them before real hackers can exploit it. The following are examples of real world vulnerabilities that have been discovered in the past couple of years, including at least one of each type of XSS vulnerability. Example exploit In December 2004, a type 0 XSS vulnerability was discovered in Bugzilla (Dotzler). When an internal error occurred, it would send the requested URL to an admin through the use of the JavaScript: document.write("<p>URL: " + document.location + "</p>") If an error was forced and had injected javascript in the URL such as: bugzilla.example.org/attachment.cgi?id=&action=force_internal_error<script> alert(document.cookie)</script> then it could be used to steal session cookie or fake content on the website (Dotzler). In order to fix this vulnerability, the special characters in the document.location string were encoded before writing out to the page (Dotzler). A type 1 XSS vulnerability was found on www.cbsnews.com and www.bbc.co.uk and exploited humorously by Russians at Security Lab. On the CBS site, there was a zip code box that was used to check the weather in your area (Bejtlich). By going to the URL www.cbsnews.com/stories/2002/02/15/weather_local/main501644.shtml?zipcode=1-- %3E%3Cscript%20src=http://www.securitylab.ru/test/sc.js%3E%3C/script%3E%3C!-- it would direct you to cbsnews.com, but would also download sc.js from Security Labs which contained a fabricated story about President Bush appointing a 9 year old to be the chairperson of the Information Security Department (Bejtlich). The resulting website looked like an official news report from CBS. A similar vulnerability was exploited on the BBC website. This has since been fixed by validating the zip code input parameter. One of the most popular XSS exploits was a type 2 vulnerability dubbed Samy, the MySpace worm. This was actually the first self-propagating XSS worm ever created. The technical details of the exploit are too complicated for the scope of this document, but it would be good to point out that he used some clever tricks to get around some filtering of data allowed in myspace. For example, MySpace would strip out the word “javascript” from any input (Samy). However, Samy was able to get around this roadblock by cleverly disguising his code like this: <div id="mycode" expr="alert('hah!')" style="background:url('java\nscript:eval(document.all.mycode.expr)')"> The “new line” character between java and script is still interpreted as “javascript” in some browsers (Samy). Many other strings were stripped out as well, but he was able to sidestep those roadblocks as well with more clever code (Samy). For example, “onreadystatechange” was a needed string for XML-HTTP requests but was stripped out of all input to MySpace. To get around this, Samy used: eval('xmlhttp.onread' + 'ystatechange = callback'); which effectively puts the two statements together to form the needed “onreadystatechange” (Samy). This worm was made with just the intention of getting Samy a few new friends to be popular on MySpace, but within 20 hours, Samy had over 1 million friends and had thus infected over 1 million profiles on MySpace (Samy). 5. SQL Injection watch” UNION SELECT * FROM userinformation WHERE “a”=”a Because the application simply insert the user input into the final SQL statement, the corresponding SQL expression compiled by the application would look like as follows (user input dependent part is shown is bold): SELECT * FROM productdetails WHERE productname=”watch” UNION SELECT * FROM userinformation WHERE “a”=”a” This SQL expression retrieves all the details of the watch product along with every information stored in the userinformation table. In our particular example, let us assume that the userinformation table contains all the registered users with their related information such as address and credit card number. By inserting carefully chosen SQL code in a user input field, the attacker could gain access to data that the application developer and provider obviously did not want to reveal. Insert, modify, or delete data Some database management systems accept multiple SQL expressions in one single call. By allowing multiple SQL commands in one call, an attacker could not only modify the built in queries to access data, but could also execute arbitrary SQL commands against the database. As an example, considering that SQL statements are separated by semicolons and comments start with two hyphens, the attacker could enter the following input as a product name on the web site to delete all the product data from the database: watch”; DELETE FROM productdetails-- The corresponding SQL expression compiled by the application would then be as follows (user input dependent part is shown is bold): SELECT * FROM productdetails WHERE productname=”watch”; DELETE FROM productdetails--“ As a result of this SQL expression, the DBMS would first retrieve the details of the watch product and then execute the second SQL command, which would delete everything stored in the productdetails table. Finally, the DBMS would ignore everything after the two hyphens – treating that part of the SQL expression as comment. Exploit other vulnerabilities in the server system Because modern databases such as Oracle or Microsoft SQL Server are complex software containing several extensions and additional modules, an attacker could also exploit vulnerabilities found in the additional modules or extensions. Often some of the additional modules are vulnerable to buffer overflow when called with a carefully compiled SQL statement. Again, the attacker could use the SQL Injection technique demonstrated above to execute an SQL command that triggers buffer overflow in the database system. By exploiting buffer overflow vulnerabilities using SQL Injection, an attacker could remotely run arbitrary code on the server computer hosting the database, and therefore not only compromise the database system, but any part of the server – including the operational system itself. Gain access to underlying operating system Some database management systems, Oracle and Microsoft SQL Server for instance, provide mechanisms to execute other applications or scripts inside the server’s operating system. In general, only privileged database users should have access to these mechanisms. However, if the database was not carefully configured and the web application was allowed to access these program execution mechanisms, an attacker could take advantage of this vulnerability and execute arbitrary operating system commands, applications, or scripts in the server system. In the Microsoft SQL Server database, the master..xp_cmdshell function can be used to execute a command in Windows XP’s command shell (Watts). Using our scenario described earlier, the attacker could execute the following SQL statement against the database to create a new user and password in the operating system (attacker’s web application input is shown in bold): SELECT * FROM productdetails WHERE productname=”watch”; EXEC master..xp_cmdshell “net user attacker attackpassword /add” --“ Running this SQL expression in the database would result in first retrieving the information related to the watch product and then creating the attacker user with attackpassword password inside the operating system. The Oracle database system does not allow direct execution of operating system command line expressions. However, it allows compiling and running Java code inside the database, and it is possible to execute operating system commands from within Java code (Lorentz). Therefore, an attacker could create Java code inside an Oracle database and then invoke the Java code to execute arbitrary operating system commands. The injected SQL command that creates a Java class inside the Oracle database and can be used to execute arbitrary operating system commands should look similar to the following: CREATE AND COMPILE JAVA SOURCE NAMED "OSExecCommand” AS import java.lang.Runtime; public class OSExecCommand { public static void execCommand(String[] cmd) { try { Runtime.getRuntime().exec(cmd) ; } catch(Exception e) {} } } After the above code was successfully executed in the database (using SQL Injection), an <http://www.cert.org/advisories/CA-2000-02.html>. 7) "Cross-Site Scripting Security Vulnerability." Microsoft Security. 2 Feb. 2000. 15 Nov. 2006 <http://www.microsoft.com/technet/archive/security/news/crssite.mspx?mfr=true>. 8) "Cross Site Scripting (XSS) Questions and Answers." CGISecurity. May 2002. 14 Nov. 2006 <http://www.cgisecurity.com/articles/xss-faq.shtml>. 9) "Cyber Security Belletin 2005 Summary" Us-Cert.Gov. 29 Dec. 2005. 10 Nov. 2006 <http://www.us-cert.gov/cas/bulletins/SB2005.html>. 10) Dotzler, Asa. "Bugzilla Bug 272620 - XSS Vulnerability in Internal Error Messages." Bugzilla. 3 Jan. 2005. 14 Nov. 2006 <https://bugzilla.mozilla.org/show_bug.cgi?id=272620>. 11) Finisterre, Kevin. "Apple Mac OS Buffer Overflow Exploit." Milw0rm. 13 Mar. 2006. <http://www.milw0rm.com/exploits/1583>. 12) "Firefox." Milw0rm. 28 July. 10 Nov. 2006 <http://www.milw0rm.com/exploits/2082>. 13) Grossman, Jeremiah. "The Origins of Cross-Site Scripting (XSS)." 30 July 2006. 15 Nov. 2006 <http://jeremiahgrossman.blogspot.com/2006/07/origins-of-cross-site-scripting-xss.html>. 14) Lettice, John. "Windows V Linux Security: the Real Facts." The Register. 22 Oct. 2004. 17 Nov. 2006 <http://www.theregister.co.uk/2004/10/22/linux_v_windows_security/>. 15) Lorentz, Diana. Oracle Database SQL Reference 10g Release 2 (10.2). Oracle, 2005. Oracle SQL Reference. 9 Nov. 2006 <http://download- east.oracle.com/docs/cd/B19306_01/server.102/b14200/toc.htm>. 16) "Microsoft Internet Explorer VML Remote Buffer Overflow Exploit." Milw0rm. 9 Sept. 2006. 10 Nov. 2006 <http://www.milw0rm.com/exploits/2425>. 17) "Milw0rm." Milw0rm. 10 Nov. 2006 <http://www.milw0rm.com>. 18) Petreley, Nicholas. "Security Report: Windows Vs Linux." The Register. 22 Oct. 2004. 17 Nov. 2006 <http://www.theregister.co.uk/security/security_report_windows_vs_linux/#winpatchs>. 19) Reynolds, J. "The Helminthiasis of the Internet." www.ietf.org. Dec. 1989. 10 Nov. 2006 <http://www.ietf.org/rfc/rfc1135.txt>. 20) Samy. "I'm Popular." 4 Oct. 2005. 15 Nov. 2006 <http://namb.la/popular/>. 21) Schmidt, Charles, and Tom Darby. "The What, Why, and How of the 1988 Internet Worm." Snowplow.Org. 2001. 10 Nov. 2006 <http://snowplow.org/tom/worm/worm.html>. 22) Starzetz, Paul and Purczynski, Wojciech. “About.com” About.com 11 Oct 2006 <http://netsecurity.about.com/gi/dynamic/offsite.htm?zi=1/XJ&sdn=netsecurity&zu=http%3A %2F%2Fwww.isec.pl%2Fvulnerabilities%2Fisec-0013-mremap.txt> 23) Spett, Kevin. "SQL Injection." SPI Dynamics. 2005. 11 Nov. 2006 <http://www.spidynamics.com/papers/SQLInjectionWhitePaper.pdf>. 24) Us-Cert, comp. "CVE - Common Vulnerabilities and Exposures." CVE - Common Vulnerabilities and Exposures. 09 Aug. 2004. United States Computer Emergency Readiness Team. 11 Oct. 2006 <http://cve.mitre.org/> 25) Watts, Dave. "Securing Database Access Using the Cfqueryparam Tag." Adobe. June 2006. 5 Nov. 2006 <http://www.adobe.com/devnet/coldfusion/articles/cfqueryparam.html>. 26) "XSS - Cross Site Scripting." Blackhat SEO. 2 Aug. 2006. 15 Nov. 2006 <http://weblog.blackhat-seo.com/40/xss-cross-site-scripting/>.