Автор Тема: LKM rootkit  (Прочетена 4196 пъти)

tarator

  • Участник
  • *****
  • Публикации: 849
    • Профил
Re: LKM rootkit
« Отговор #15 -: Ное 12, 2008, 17:19 »
gat3way, ще извиняваш, ама скриването при brk е напълно малоумно :) Какво ще стане ако приложението не използва glibc? Какво ще стане ако приложението просто вика fork? :P Дори и в случая когато приложението използва glibc, пак има определен интервал от време, когато процеса е видим и теоретично може да бъде открит. Което пък ми напомня, че ld-linux.so може да се използва доста успешно за откриване на "скрити" процеси :Р
Активен

A gentleman is one who is never rude unintentionally. - Noel Coward

gat3way

  • Участник
  • *****
  • Публикации: 6050
  • Relentless troll
    • Профил
    • WWW
Re: LKM rootkit
« Отговор #16 -: Ное 12, 2008, 18:29 »
И да не използва glibc, рано или късно (твърде вероятно рано) ще опре до brk(), защото heap-а му ще расте и трябва ядрото да му мап-ва физическа памет върху адресното пространство.

Освен ако разбира се не използва някаква memory allocation библиотека, която не използва brk(), а само mmap(). Например предполагам е вероятно някаква jvm да не може да се скрие по този начин. Да, при това положение няма да се скрие. Всъщност това с brk() в началото го прави ld-linux.so, значи статично-билднато нещо при форкване няма да се скрие...веднага. Ще се скрие обаче на първото място където викне malloc().

Та да, не е перфектен механизъма, защото в някои гранични случаи няма да успее. Ако прихвана и mmap() ще се гарантира по-голяма успевяемост.

Ти си прав обаче, че трябва да се прихване и fork(). Защото при създаването на child process докато не се викне brk() нямам никаква гаранция че няма да се види. А brk() може и да не вдигне, поради което разни multiprocess неща няма да могат да се скрият. Например ако реша да скрия apache (колкото и тъпо да звучи) твърде вероятно разните worker процеси ще се виждат от време на време.

А, да, друго интересно нещо, за което съм много любопитен - memcmp()  "безопасна" операция ли е? В смисъл гледам, че човекът го тества с PREEMPT ядро, кво става ако се прекъсне изпълнението на кода точно докато се изпълнява (ако е възможно)?
« Последна редакция: Ное 12, 2008, 18:34 от gat3way »
Активен

"Knowledge is power" - France is Bacon

tarator

  • Участник
  • *****
  • Публикации: 849
    • Профил
Re: LKM rootkit
« Отговор #17 -: Ное 12, 2008, 18:54 »
Доколкото виждам си пропуснал __user в дефиницията на параметъра filename на hacked_chdir. Трябва да използваш getname или strncpy_from_user преди да правиш memcmp. A защо не strcmp? :P

Иначе самата memcmp си е напълно безопасна дори и при PREEMPT.
Активен

A gentleman is one who is never rude unintentionally. - Noel Coward

gat3way

  • Участник
  • *****
  • Публикации: 6050
  • Relentless troll
    • Профил
    • WWW
Re: LKM rootkit
« Отговор #18 -: Ное 12, 2008, 20:57 »
Ами в случаят не знам дали е наложително, знам че не е хубаво толкова брутално да пипам данни от userspace-а, от друга страна, не мисля че в случаят това е толкова рисковано.

Защо?

Ами никъде в ядрото не пазя указател към тези данни, който да ми трябва при следващо влизане в kernelspace от някой syscall (и където много вероятно указателят ми ще сочи към съвсем друго място разбира се).

Обаче съм леко глупав и не знам дали на SMP системи няма вариант това да се окаже проблем.


Както и да е, много съм разочарован. Областта от памет, където се намира do_exit не съдържа адреса на panic. Пуснах objdump -D срещу /proc/kcore и установих че (на x86_64) се прави:

callq <adresa_na_panic()>, което преведено на машинен код е някаква 5-байтова (?!?) последователност, нямаща нищо общо с адреса на panic(). Понеже пак да кажа че съм тъп и не разбирам от асемблер, нямам идея как със сигурност да намеря къде се намира тая тъпа callq инструкция.


Затва ще отеба идеята да нулирам pid-ове. Минавам на план Б - ще крия procfs entries за скритите процеси, това е тъпо щото така по-лесно ще се открива моя зъл rootkit (дали с налучкване на cd /proc/<pid>, дали с налучкване с kill -signal <pid>).

Ужасно съм разочарован, но за жалост не съм особено умен да се справя с тоя проблем...
Активен

"Knowledge is power" - France is Bacon