This blog post details CVE-2017-17562, a vulnerability which can be exploited to gain reliable remote code execution in all versions of the GoAhead web server < 3.6.5.
The vulnerability is a result of Initialising the environment of forked CGI scripts using untrusted HTTP request parameters, and will affect all user’s who have CGI support enabled with dynamically linked executables (CGI scripts). This behavior, when combined with the glibc dynamic linker, can be abused for remote code execution using special variables such as LD_PRELOAD (commonly used to perform function hooking, see preeny).
For those unfamiliar with GoAhead, its marketing page says that it’s “the world’s most popular, tiny embedded web server” and is used by such companies as IBM, HP, Oracle, Boeing, D-link, and Motorola. We did a search on shodan, and found over 735,000 devices using it on the internet today.
 Update 28/12:It’s important to note that this number only reflects which set of servers responded to Shodan requests with a “Server: GoAhead” header. This does not reflect the actual subset of devices affected by this issue - which is limited to servers running *nix, have CGI enabled, and are compiled using dynamically linked executables.
The exploitation of this issue serves as an interesting case study, and could be applied to other types of software with the same insecure construct.
This vulnerability has existed in all versions of the GoAhead source since at least 2.5.0 (we could not find earlier versions to test against) with the optional CGI support enabled. You can follow along by cloning and compiling the repository as follows:
The vulnerability resides in the cgiHandler function, which starts by allocating an array of pointers for the envp argument of the new process, followed by initialising it with the key-value pairs taken from HTTP request parameters. Finally, the launchCgi function is called which fork’s and execve’s the CGI script.
Besides filtering REMOTE_HOST and HTTP_AUTHORIZATION, all other parameters are considered trusted and passed along unfiltered. This allows an attacker control over arbitrary environment variables for the new CGI process. This is quite dangerous, as you will see later in the exploitation section.
This issue was fixed by skipping special parameter names, and prefixing all others with a static string. This appears to remediate the issue even against parameters of the form a=b%00LD_PRELOAD%3D - but please let me know if you find otherwise, I’d love to hear about it!
Although the ability to inject arbitrary environment variables into a new process may seem relatively benign, there are cases where “special” environment variables can lead to alternative control flows for the dynamic linker.
ELF dynamic linker
Reading the ELF header of the goahead binary, we can see that it’s a 64-bit dynamically-linked executable. The program interpreter is specified in the INTERP section and points to /lib64/ld-linux-x86-64.so.2 (this is the dynamic linker).
The dynamic linker is the first code which runs in a dynamically linked executable, and is responsible for linking and loading shared objects and resolving symbols. To get a list of all the shared objects the goahead binary loads, we can set a special environment variable LD_TRACE_LOADED_OBJECTS to 1, which prints the loaded libraries and then exits.
We can also find this information statically (without running the dynamic linker), by grepping for DT_NEEDED entries defined in each of the ELF shared objects recursively:
Note: For the astute reader who noticed these binaries are missing linux-vdso.so.1, that’s correct! vDSO is a special shared library mapped into user-space processes by the kernel. See man 7 vdso.
Special Environment Variables
So that’s good and all, but what does any of this have to do with injecting environment variables? Well … we know the dynamic linker is the first code to execute for a new process - and if we read man 8 ld.so we discover there are special environment variables which modify default behavior.
As I’m a fan of looking at the source, let us take a journey into what’s happening. The dl_main function is essentially the main entry point of the dynamic linker.
One of the first things this function does is call process_envvars.
We see that the linker is parsing the envp array and exercising different code paths if special variable names are found. What is particularly interesting is case 7’s processing of LD_PRELOAD, where preloadlist is initialised.
Further down in dl_main, if preloadlist is not NULL then the handle_ld_preload function is called.
The handle_ld_preload function will parse the preloadlist and treat its value as a list of shared objects to be loaded!
If we put all this together; with goahead enabling us to inject arbitrary environment variables, we can abuse the fact that glibc handles special cases such as LD_PRELOAD differently to load arbitrary shared objects that aren’t even listed in the binary!
So, that’s cool and all - we can force arbitrary shared objects to be loaded. But how does this allow us to run code?
Sweet! What does this look like if we try this out against GoAhead on our test system?
We can clearly see that our shared objects code was executed by the cgitest process via LD_PRELOAD.
There is still one critical piece of the puzzle that we are missing. Even though we know it’s possible to load arbitrary shared objects from disk, and constructors will allow for code execution - how do we actually inject a malicious shared object into the remote server? After all, if we can’t do that then it’s really unlikely a legitimate shared object on disk will help us.
Fortunately, the launchCgi method will actually dup2() the stdin file descriptor which points to a temporary file containing the request body of the POST request. This means that there will be a file on disk containing user-supplied data and could be referenced with something like LD_PRELOAD=/tmp/cgi-XXXXXX.
Still, this is kind of annoying (but not impossible) having to remotely guess the temporary filename containing our POST payload. Fortunately, the Linux procfs filesystem has a nice symbolic link that we can use to reference the stdin descriptor, which points to our temporary file. This can leveraged by pointing LD_PRELOAD to /proc/self/fd/0. This can also be accessed using /dev/stdin.
If we put all this information together, we can reliably exploit the vulnerability by sending a POST request containing a malcious shared object which contains a constructor to be called when loaded. We also specify an HTTP parameter containing ?LD_PRELOAD=/proc/self/fd/0 which will point to the temporary file on disk containing the attackers payload. At this point it’s game over.
If you would like a ready-to-go exploit please check out our advisory repo on GitHub.
This vulnerability was an interesting case study in how to remotely exploit LD_PRELOAD, and was tested (and worked) against all versions of the GoAhead web server that we compiled with CGI support enabled. The construct itself may exist in other services, and it would be interesting to investigate. It may be possible to just use the exploit string and do this blind without actually auditing any code.
Although the CGI handling code remained relatively stable in all versions of the web server (which made it the ideal target), there has been a significant amount of code churn over the years in other modules. It’s possible there are other interesting vulnerabilities - and for those interested I’d recommend starting with a grep for websDefineHandler entry points.
If you’re interested in learning more about linking and loading, there’s a great article here and here that we suggest you check out.