Obtaining root access is the holy grail of exploitation. Essentially, if you can code to execute from a program with root access, you may be able to spawn a shell (terminal) thus allowing you to alter data, add users, add kernel modules, and perform actions you cannot perform with a normal account. There are a few known kernel exploits that can exploit things like race conditions, but there are no known root access exploits in the Linux Kernel 3. I had originally planned on making race conditions an entire section, but I realized there‟s no more than a paragraph or so that I could write about it simply because I don‟t know all there is to know about it. I will go over them somewhat:
Race Conditions occur when two separate threads try to access the same information simultaneously. When this happens, a „race‟ occurs. However, if a thread with high privileges executes or opens something, it would execute with that level of privileges.. There was a commonly known and exploited race condition in a program called “pulseaudio” and I‟ll go ahead and explain it. Firstly, here is the vulnerable code they used:
Code:
if (!getenv("LD_BIND_NOW")) {
char *rp;
putenv(pa_xstrdup(LD_BIND_NOW=1))
pa_assert_se(rp = pa_readlink("/proc/self/exe"));
/* Ironically, they had originally used /proc/self/exe
* directly which is safe. Instead, they read the link
* to get the real path name
*\
pa_assert_se(execv(rp, argv) == 0);
}
If you know about symbolic links in some amount of depth, you can easily see this race condition. The symlink “/proc/self/exe” refers to the program currently executing. Essentially, it is reading this link (thus getting the actual path name) and executing it. Since this is executing with root privileges, the true path name, if altered, will be executed with root privileges. Replace that with a symlink to “/bin/sh” and the shell will spawn with root access.
One major way of obtaining root access is by exploiting programs with SUID (Set Userid) which allows programs to be executed with root privileges despite being executed from a non-root account. Many SUID files and scripts (such as ones that I create) are made simply to perform tedious tasks such as removing or parsing logs, changing settings, running updates, etc... That being said, many people are not as careful as I try to be when programming or scripting, especially when it comes to small, simple programs that they think only they will use. Other ways of maintaining root access would be to simply brute force the root account. This is an incredibly slow and terrible method, not to mention noisy. Kernel exploits are common in kernels younger than 2.6 (and some 2.6 kernels) and, fortunately for us, many servers don‟t bother to update when a new kernel comes out, especially if they have to completely reinstall the operating system or recompile the kernel.
-H
Houga@entropy.cat
[/code]
