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 in all 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 Contents provides 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 properties author 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_svn module 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 use CHECKOUT 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 in Figure 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.
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 in Figure 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 in Figure 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
and PROPPATCH 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
No comments:
Post a Comment