728x90
1. Summary
So a while back, a colleague and I looked at Apache mod_dav, and we noticed an issue with it. We reported the vulnerability to Apache and have waited for a few months to disclose. Today, Apache finally made it public.
And now we can post our summary of the vulnerability that has been assigned CVE-2013-6438. The issue exists inall versions of Apache prior to 2.4.8.
2. Apache WebDAV Module (mod_dav)
The Apache mod_dav module ships with all the recent stable Apache source code (2.0, 2.2, and 2.4). It provides WebDAV functionality, allowing Apache to utilize the extensions noted by WebDAV for the HTTP protocol to create, move, copy, and delete resources and collections, and modify their properties on a remote web server [5]. Figure 4. WebDAV File Upload provides an example of a file upload and response from Apache with mod_dav enabled.
Figure 4. WebDAV File Upload
We can easily see that this makes uploading files to the web server very easy. Figure 5. WebDAV Get Contentsprovides an example of fetching contents of a specific file from the web server.
Figure 5. WebDAV Get Contents
We can also modify property attributes of a file by sending XML formatted data using a PROPPATCH HTTP/1.1 extended WebDAV request. Figure 6. WebDAV Resource Property Update provides an example of a property update on the file test.txt. The XML data sent uses the XML namespace DAV: defined by xmlns:D=”DAV:”. The propertiesauthor and notes of the file are modified with the contents provided. You can see that this is performed by placing the request inside the WebDAV propertyupdate method. The entire request is in XML format. Note also the server’s response of HTTP/1.1 200 OK informing us of successful update of the two properties for the file file.txt.
Figure 6. WebDAV Resource Property Update
As noted, WebDAV provides a great flexibility for managing resources and collections using HTTP and a web server. Many websites today use Apache along with the mod_dav WebDAV module for performing routine operational tasks.
3. Apache Subversion WebDAV Module (mod_dav_svn)
Apache Subversion is Apache Software Foundation’s collaborative open-source project for the version control system originally developed by CollabNet Inc. in 2000 [6]. The subversion project includes a suite of version control tools for managing resources (files, directories, properties). It includes client, server, and administrative binaries for version control across systems using local or network file:/// path access scheme, WebDAV/DeltaV over HTTP or HTTPS, and a custom SVN protocol over tcp:3690 [6].
The Apache Subversion source distribution includes the mod_dav_svn module for the Apache web server. This module provides the WebDAV/DeltaV based SVN capabilities across HTTP/HTTPS using the http(s)://host/path access scheme [7]. In order to leverage existing modules within the Apache web server source distribution, the mod_dav_svnmodule includes the mod_dav module as part of its source inclusions. mod_dav_svn utilizes methods in mod_dav which in turn expose the vulnerable mod_dav functions noted above. Details of this relationship are provided in the next section.
4. Vulnerability Analysis
As noted above, the vulnerability is mainly due to a string length counter issue in the dav_xml_get_cdata() function of the util.c source file of the mod_dav module. As leading whitespace is removed and the string pointer is updated, the length of the string is not updated (len variable). This is noted in section 3.1. util.c : dav_xml_get_cdata(…).
Overall, this vulnerability will allow an adversary to inject NULLs into memory locations to cause memory corruption and denial of service. The memory utilized by the function is the Apache memory resource pool (apr_pool), which is implemented as a doubly linked list. By padding requests with whitespace to make the string size slightly less than 8KB (the page size), we can force a new malloc to be called. With a few requests to the server, the vulnerability can cause a segmentation fault (SIGSEGV) when trying to write outside process memory space, or data corruption in the header sections of the current malloc block in the Apache (apr_pool). When the Apache process or thread tries to walk the list or free memory, the corruption causes a crash with a SIGBUS signal. The remaining sections provide a detailed overview of the vulnerability and how the Apache mod_dav_svn module exposes it.
4.1. util.c : dav_xml_get_cdata( … )
The dav_xml_get_cdata(…) function is declared in the mod_dav.h file. Figure 7. dav_xml_get_cdata Declaration shows the declaration.
Figure 7. dav_xml_get_cdata Declaration
The function variables passed to it include a pointer to XML element of type apr_xml_elem, pointer to the current memory pool of type apr_pool_t, and an integer controlling whether to strip whitespace or not. The int stripwhite variable is a critical variable. As you can see in Figure 8. Vulnerability, strip_white is checked using an if-statement. The vulnerable instructions are only executed if strip_white is a positive value yielding a Boolean True.
Figure 8. Vulnerability
The pointer to the XML data passed is char* cdata and the length of this character array is apr_size_t len. Prior to reaching the vulnerable instructions, the function initially parses through the XML data (linked list apr_xml_elem *elem) finding all elements and noting the size and count. This can be seen in Figure 9. XML Element Walk.
Figure 9. XML Element Walk.
After completing an inventory of all XML elements, the function checks for quick cases where there is no element, or just one element and strip_white is set to false. Otherwise, it allocates enough memory using apr_palloc(pool, len+1). This can be seen in Figure 10. Memory Allocation.
Figure 10. Memory Allocation
Note that both cdata and s point to the same Apache apr memory pool. After allocating enough memory, all the XML elements are copied into the allocated Apache apr memory pool buffer. This is shown in Figure 11. XML Element Copy.
Figure 11. XML Element Copy
After completing the copy, a check is made whether to strip leading and trailing whitespace from the buffer. At this point, cdata points to the beginning of the buffer. As shown in Figure 8, the while loop walks across the buffer incrementing cdata if whitespace is found. Keep in mind that the len variable is not decremented as cdata is incremented. Next, the trailing whitespace is removed and the length is decremented for each trailing whitespace. Finally, a NULL is written at the end of the string using the length variable len. Knowing this, any whitespace introduced at the beginning of the XML element input will cause a shift to the end of the buffer tracked by the len variable.
This allows an adversary to inject leading whitespace and cause the NULL value to be written (when not causing a SIGSEGV) into arbitrary memory locations depending on the length of the leading white space and injected content. Keep in mind, that the vulnerable instructions are only executed when the variable flag strip_white is true. In the mod_dav implementation, this flag is only set in two function calls in mod_dav.c:
· static int dav_method_checkout(request_rec *r)
· static int dav_method_merge(request_rec *r)
Figure 12. Checkout Exposure and Figure 13. Merge Exposure show the mod_dav functions that call dav_xml_get_cdata() with the strip_white value set to true. This enables the vulnerable instructions allowing for leading whitespace to cause a shift in the boundary referencing by len.
Figure 12. Checkout Exposure
Figure 13. Merge Exposure
However, these function calls that enable the vulnerability are inherently not implemented as part of the WebDAV implementation. Hooks are placed and the functions are exposed when mod_dav_svn is enabled.
4.2. mod_dav_svn Exposures
Requests are handled by the mod_dav_svn module as part of the SVN to WebDAV mapping. As requests are received, with mod_dav_svn module enabled, hooks are placed for the CHECKOUT and MERGE [3][4] requests utilizing mod_dav to fulfill requests. This exposes the function calls noted above. In addition, the mod_dav_svn module exposes other functions as well that utilize the same dav_xml_get_cdata() function with the strip_white variable set to true. These are listed in Figure 14. mod_dav_svn Exposures.
Figure 14. mod_dav_svn Exposures
5. Exploitation of Vulnerability
The vulnerability can be easily exploited with basic WebDAV based CHECKOUT and MERGE requests. One can also send requests related to SVN based functions as listed above. However, the easiest approach is to just useCHECKOUT and MERGE. For the purposes of this research, we developed two small exploit frameworks that create attack payloads and subsequently send the requests along with the payloads to cause the memory corruption. The frameworks are basic BASH shell scripts that create the payloads and utilize curl [18] to send the requests via HTTP. The following sections provide an overview of both exploits.
5.1. WebDAV Checkout Exploit
The CHECKOUT exploit sends a CHECKOUT request to the Apache server. Initially, a template (attack.template) is used to generate various payloads where whitespace is introduced. Each new payload introduces additional leading whitespace causing the shift for the end of the cdata buffer pointed to by cdata[len+1] where a NULL is written causing memory corruption. Figure 15. Checkout Payload Template shows the initial payload template used.
Figure 15. Checkout Payload Template
We need an XML header followed by enough WebDAV fields for a CHECKOUT request. This includes the<D:checkout xmlns:D=”DAV:”>, <D:activity-set>, and <D:href> elements. The payload inside the <D:href> tag consists of 4096 A’s and a little over 4k of whitespace followed by the URL to check out. The attack-gen.sh script, shown inFigure 16. attack-gen.sh, uses the template to generate in.X payload files where X is from 1 to 300. Once the payloads are generated, the attack.sh (Figure 17. attack.sh) will perform the attack against the Apache web server. In our testing, about 4-6 requests are needed with enough whitespace using in.30 to in.36 payloads to cause a crash as shown in Figure 18. Attack Console and Figure 19. Apache Crash.
Figure 16. attack-gen.sh
Figure 17. attack.sh
Figure 18. Attack Console
Figure 19. Apache Crash
5.2. WebDAV Merge Exploit
The MERGE exploit sends a MERGE request to the Apache server. Initially, a template (attack.template) is used to generate various payloads where whitespace is introduced. Each new payload introduces additional leading whitespace causing the shift for the end of the cdata buffer pointed to by cdata[len+1] where a NULL is written causing memory corruption. Figure 20. Merge Payload Template shows the initial payload template used.
Figure 20. Merge Payload Template
We need an XML header followed by enough WebDAV fields for a MERGE request. This includes the <D:merge xmlns:D=”DAV:”>, <D:source>, and <D:href> elements. Again, the payload inside the <D:href> tag consists of 4096 A’s and a little over 4k of whitespace followed by the URL to check out. The attack-gen.sh script, shown in Figure 21. attack-gen.sh, uses the template to generate in.X payload files where X is from 1 to 300. Once the payloads are generated, the attack.sh (Figure 22. attack.sh) will perform the attack against the Apache web server. On average, about 4-6 requests are needed with enough whitespace using in.30 to in.36 payloads to cause a crash as shown inFigure 23. Attack Console and Figure 24. Apache Crash.
Figure 21. attack-gen.sh
Figure 22. attack.sh
Figure 23. Attack Console
Figure 24. Apache Crash
6. Patch for Vulnerability
The fix for the vulnerability is very easy. The function simply needs to decrement the len value each time a leading whitespace is found. Therefore, the source code just needs the addition of a –len; in the while loop that trims leading whitespace as shown by Figure X. Patch below.
Figure 25. Patch
7. Suggestions
Signature based IDS/IPS detection can be effective for known and non-polymorphic attacks. In our case, you can establish some signatures for the specific exploits mentioned in this paper. The main thing to look for is a large total size for the CHECKOUT and MERGE requests, as the adversary would need to send payloads slightly less than the normal 8KB page size used by malloc to make each request effective. In addition, the adversary is required to use leading whitespace characters prior to the actual URL in the <D:href> element. Other signatures for the REPORT andPROPPATCH requests can be created as well using similar pattern matching for leading whitespace.
More importantly, patch your system!
Apache's announcement: http://www.apache.org/dist/httpd/Announcement2.4.html
8. References
[1] “About the Apache HTTP Server Project,” Apache Software Foundation, 2012. http://httpd.apache.org/ABOUT_APACHE.html.
[2] “December 2013 Web Server Survey,” Netcraft, December 2013. http://news.netcraft.com/archives/2013/12/06/december-2013-web-server-survey.html.
[3] HTTP Extension for Web Distributed Authoring and Versioning (WebDAV). RFC 4918, IETF, June 2007. http://tools.ietf.org/html/rfc4918.
[4] Versioning Extensions to Web Distributed Authoring and Versioning (WebDAV). RFC 3253, IETF, March 2002. http://tools.ietf.org/html/rfc3253.
[5] “Distributed Authoring and Versioning (WebDAV) functionality,” Apache Software Foundation, 2013. http://httpd.apache.org/docs/2.4/mod/mod_dav.html.
[6] Apache Subversion. Apache Software Foundation, June 16, 2003, http://subversion.apache.org.
[7] “Subversion’s use of the WebDav/DeltaV protocol”. Apache Software Foundation, accessed December 7, 2013.http://svn.apache.org/repos/asf/subversion/trunk/notes/http-and-webdav/webdav-protocol.
[9] “Vulnerability Summary for CVE-2013-4558”, National Vulnerability Database. National Institute of Standards and Technology (NIST), 2013.http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2013-4558&cid=1
[10] “Vulnerability Summary for CVE-2013-4131”, National Vulnerability Database. National Institute of Standards and Technology (NIST), 2013.http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2013-4131&cid=1
[11] “Vulnerability Summary for CVE-2013-1896”, National Vulnerability Database. National Institute of Standards and Technology (NIST), 2013.http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2013-1896&cid=1
[12] “Vulnerability Summary for CVE-2013-1884”, National Vulnerability Database. National Institute of Standards and Technology (NIST), 2013.http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2013-1884&cid=1
[13] “Vulnerability Summary for CVE-2013-1849”, National Vulnerability Database. National Institute of Standards and Technology (NIST), 2013.http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2013-1849&cid=1
[14] “Vulnerability Summary for CVE-2013-1847”, National Vulnerability Database. National Institute of Standards and Technology (NIST), 2013.http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2013-1847&cid=1
[15] “Vulnerability Summary for CVE-2013-1846”, National Vulnerability Database. National Institute of Standards and Technology (NIST), 2013.http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2013-1846&cid=1
[16] “Vulnerability Summary for CVE-2013-1845”, National Vulnerability Database. National Institute of Standards and Technology (NIST), 2013.http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2013-1845&cid=1
[17] Extensible Markup Language (XML) 1.0 (Fifth Edition), W3C Recommendation, W3C, November 26, 2008. http://www.w3.org/TR/REC-xml/
[18] Daniel Stenberg, CURL. Haxx, 1996 – 2013. http://curl.haxx.se.
[19] G. Stein, “Contents of /httpd/httpd/trunk/modules/dav/main/util.c,” Apache Software Foundation, February 7, 2001.http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/dav/main/util.c?revision=88007&view=markup
728x90
'취약점 정보1' 카테고리의 다른 글
| 중국 포털사이트 baidu 안티바이러스 업데이트안내 (0) | 2014.03.20 |
|---|---|
| 시만텍 노턴 안티바이러스 업데이트 안내 (0) | 2014.03.20 |
| avast 2014R3 베타 안내 (0) | 2014.03.20 |
| pale moon 업데이트 안내 (0) | 2014.03.20 |
| java SE runtime environment 8업데이트 안내 (0) | 2014.03.20 |