CVE-2019-5097
A denial-of-service vulnerability exists in the processing of multi-part/form-data requests in the base GoAhead web server application in versions v5.0.1, v.4.1.1 and v3.6.5. A specially crafted HTTP request can lead to an infinite loop in the process. The request can be unauthenticated in the form of GET or POST requests and does not require the requested resource to exist on the server.
EmbedThis GoAhead Web Server v5.0.1 EmbedThis GoAhead Web Server v4.1.1 EmbedThis GoAhead Web Server v3.6.5
https://www.embedthis.com/goahead/
5.3 - CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L
CWE-835: Loop with Unreachable Exit Condition (‘Infinite Loop’)
GoAhead Web Server is a popular embedded web server designed to be a fully customizable web application framework and server for embedded devices. GoAhead Web Server provides all of the base HTTP server functionality and provides a highly customizable platform for developers of embedded web applications.
When processing a multi-part/form-data HTTP request, the HTTP process can be put in an infinite loop state resulting in 100 percent CPU utilization. If the client connection terminates before the service has received the amount of data specified in the Content-Length header, the server attempts to send a response to the disconnected socket continuously. While the process is still able to handle requests during this time, the potential for creating further denial of service conditions is possible and would depend entirely on other available system resources.
Both HTTP GET and POST methods allow access to the vulnerable condition but are restricted by the methods defined in the route configuration. In the default build configuration, it is not required that the page requested exist as it seems to inherit permissions from the parent path. During testing on additional devices, it has been observed that there may be other route restrictions that affect access to the vulnerability.
With logging enabled, you are able to see that the loop occurs attempting to call websFlush on a closed connection: … goahead: 2: Read error: connection lost goahead: 6: websFlush: buflen 2047 goahead: 6: websFlush: buflen 2047 goahead: 6: websFlush: buflen 2047 goahead: 6: websFlush: buflen 2047 goahead: 2: Read error: connection lost goahead: 6: websFlush: buflen 2047 goahead: 6: websFlush: buflen 2047 goahead: 6: websFlush: buflen 2047 goahead: 6: websFlush: buflen 2047 …
#3 0x00007ffff7b5d6f8 in websFlush (wp=0x60da40, block=0x1) at src/http.c:2072
#4 0x00007ffff7b5f4f4 in websWriteBlock (wp=0x60da40, buf=0x7ffff7ba9fc9 "\r\n", size=0x2) at src/http.c:2196
#5 0x00007ffff7b5f035 in websResponse (wp=0x60da40, code=<optimized out>, message=0x6076d0 "<html>\r\n <head><title>Document Error: Internal Server Error</title></head>\r\n <body>\r\n <h2>Access Error: Internal Server Error</h2>\r\n </body>\r\n</html>\r\n") at src/http.c:1604
#6 0x00007ffff7b5fc76 in websError (wp=0x60da40, code=0x226, fmt=<optimized out>) at src/http.c:3386
#7 0x00007ffff7b6208a in readEvent (wp=0x60da40) at src/http.c:807
#8 0x00007ffff7b5d99b in socketEvent (sid=<optimized out>, mask=0x6, wptr=0x60da40) at src/http.c:756
#9 0x00007ffff7b6d207 in socketDoEvent (sp=0x60d900) at src/socket.c:653
#10 0x00007ffff7b6d199 in socketProcess () at src/socket.c:627
#11 0x00007ffff7b5e600 in websServiceEvents (finished=0x602104 <finished>) at src/http.c:1363
#12 0x00000000004012f8 in main (argc=<optimized out>, argv=<optimized out>, envp=<optimized out>) at src/goahead.c:170
Given the the wide distribution of architectures and operating systems GoAhead Web Server supports, exploitability will more than likely be heavily dependent on the specific target. In addition, given the customizations available for the project, this vulnerability may not be reachable on all builds. We have observed that the ME_GOAHEAD_UPLOAD compile time flag be enabled as well as the existence of path specified in ME_GOAHEAD_UPLOAD_DIR. By default, these are set so the vulnerability should be reachable. Additionally, pages that require authentication do not allow access to the vulnerability without authentication as the authentication is handled before reaching the upload handler.
2019-08-28 - Vendor Disclosure
2019-11-21 - Vendor patched
2019-12-02 - Public Release
Discovered by a Cisco Talos researcher.