Используя gdb, мы можем получить
Используя gdb, мы можем получить полное содержание таблицы системных вызовов образа ядра, как показано ниже. Напечатанные адреса соответствуют системным вызовам, объявленным в файле entry.S в исходных кодах ядра. Например, вхождение 0 (0xc01261a0) это системный вызов sys_ni_syscall, вхождение 1 (0xc011e1d0) это sys_exit, вхождение 2 (0xc01078a0) это sys_fork и так далее.
#gdb /boot/vmlinux-2.4.*
(gdb) x/255 0xc0302c30
0xc0302c30 <sys_call_table>: 0xc01261a0 0xc011e1d0 0xc01078a0 0xc013fb70
0xc0302c40 <sys_call_table+16>: 0xc013fcb0 0xc013f0e0 0xc013f230 0xc011e5b0
0xc0302c50 <sys_call_table+32>: 0xc013f180 0xc014cb10 0xc014c670 0xc0107940
0xc0302c60 <sys_call_table+48>: 0xc013e620 0xc011f020 0xc014bcd0 0xc013e9a0
...
Мы также можем печатать адрес каждого системного вызова, вводя его имя, как показано ниже: (gdb) x/x sys_ni_syscall 0xc01261a0 <sys_ni_syscall>: 0xffffdab8 ((gdb) x/x sys_fork 0xc01078a0 <sys_fork>: 0x8b10ec83
Теперь используя утилиту gdb (или модуль scprint.o, который мы скомпилировали) мы должны снять дамп текущих значений таблицы системных вызовов. И, наконец, мы сравниваем полученные значения со значениями, сохраненными после компиляции ядра.
Чтобы напечатать текущее состояние ядра (адреса системных вызовов) мы должны запустить gdb с двумя параметрами. Первый параметр это образ ядра (vmliux-2.4.x), второй - объект /proc/kcore. Затем, мы используем адрес таблицы системных вызовов, полученный из файла System.map, чтобы вывести значения таблицы системных вызовов.
#gdb /boot/vmlinux-2.4.* /proc/kcore
(gdb) x/255x 0xc0302c30
0xc0302c30 <sys_call_table>: 0xc01261a0 0xc011e1d0 0xc01078a0 0xc88ab11a
0xc0302c40 <sys_call_table+16>: 0xc013fcb0 0xc013f0e0 0xc013f230 0xc011e5b0
0xc0302c50 <sys_call_table+32>: 0xc013f180 0xc014cb10 0xc014c670 0xc0107940
0xc0302c60 <sys_call_table+48>: 0xc013e620 0xc011f020 0xc014bcd0 0xc013e9a0
...
Как мы можем заметить из вывода выше, один из адресов системных вызовов был изменен. Это элемент 3 в таблице системных вызовов (счет начинается с 0) и для ясности он выделен в выводе выше. В файле /usr/include/asm/unistd.h мы можем найти имя этого подозрительного системного вызова, который называется sys_read.
Другой признак компрометации системы это то, что новый виртуальный адрес этой функции (sys_read) располагается выше 0xc8xxxxxx. Это очень подозрительно. ОС Linux по умолчанию может адресовать до 4 Гб памяти. Виртуальные адреса располагаются с 0x00000000 по 0xffffffff. Верхняя часть этой виртуальной области зарезервирована под код ядра (диапазон значений с 0xc0000000 по 0xffffffff). Когда загружается новый модуль ядра, функция vmalloc выделяет часть этой памяти под код модуля. Она выделяет область памяти обычно начинающейся с 0xc8800000. Таким образом, каждый раз, когда мы видим адрес системного вызова, находящийся выше этого адреса, что мы и видим в нашем примере, это показывает, что наше ядро могло быть компрометировано. Теперь посмотрим поближе на этот системный вызов.
Forekc.ru
Рефераты, дипломы, курсовые, выпускные и квалификационные работы, диссертации, учебники, учебные пособия, лекции, методические пособия и рекомендации, программы и курсы обучения, публикации из профильных изданий