Войти в систему

Home
    - Создать дневник
    - Написать в дневник
       - Подробный режим

LJ.Rossia.org
    - Новости сайта
    - Общие настройки
    - Sitemap
    - Оплата
    - ljr-fif

Редактировать...
    - Настройки
    - Список друзей
    - Дневник
    - Картинки
    - Пароль
    - Вид дневника

Сообщества

Настроить S2

Помощь
    - Забыли пароль?
    - FAQ
    - Тех. поддержка



Пишет dibr ([info]dibr)
@ 2010-09-26 14:49:00


Previous Entry  Add to memories!  Tell a Friend!  Next Entry
огромные боевые человекоподобные вирусы
     «Почему у прямых людей болезни всегда прямые: перелом оконечностей, стригучий лишай, белая горячка? Почему как интеллигент, так сразу "авторемонтные изменения коронарных сосудов?"»
     (с) кажется, Хазанов. Навеяно тем фактом, что "почесуха овец", "коровье бешенство" и "губчатая энцефалопатия" - это, вообще-то, одно и то же заболевание, только первые два у животных, а последнее - у человека :-)

     А я, собственно, о компьютерной микробиологии. Если проводить аналогию между живым миром, и миром программ, то компьютерные вирусы окажутся ближе всё-таки к бактериям, чем к вирусам: биологические вирусы сами размножаться не умеют, умеют только доставлять "программу" к клетке и впрыскивать её внутрь, остальное делает обманутая вирусом клетка, компьютерные же вирусы ничем принципиально не отличаются от обычных программ - точно такой же программный код, на общих правах выполняющийся процессором и так же как все использующий "сторонние" функции (сисколлы, dll, прочее). Разве что узкий подкласс вирусов, заражающих веб-сайты, вставляя туда ссылку на себя, близок к биологическому вирусу: код вируса при распространении не выполняется, работает штатный www-сервер, но раздаёт вирус.

     Но я немного о другом. И в природе, и в компьютерах, есть множество странных и сложных исторически возникших зацепок (вроде например такой сложной цепочки, использовавшейся одной бабочкой при размножении). Вирусы и бактерии используют уязвимости в организме/системе, чтобы проникнуть внутрь и получить доступ на выполнение - в природе обычно "брутфорсом", в компьютерах - "хитростью". При этом сложность системы такова, что "зацепки" бывают весьма неочевидными - чтобы добиться перехвата управления, вирусы иногда используют нетривиальные подходы...
     ...скажем, упоминавшийся ранее "боевой вирус StuxNet", тот самый, предположительно отработавший по Иранскому уранообогатительному заводу, можно сказать "заражает взглядом". Для заражения достаточно просто посмотреть на иконку зараженного файла - используется уязвимость в процедуре показа иконок в винде, в результате чего сам факт показа иконки приводит к передаче управления телу вируса. Причём показ иконки не только в "проводнике", но и например в total commander - он использует ту же системную процедуру. Привет тем, кто считает "альтернативные файлменеджеры" безопасными - у меня синие панельки FAR, он иконки не показывает, но после подобных случаев я как-то тоже начинаю задумываться...

     Но я опять немного о другом. Идея собственно уязвимости здесь наверняка тривиальная, что-нибудь вроде переполнения буфера, но внешнее проявление - довольно неочевидно: "показали иконку - выполнился вирус". По сравнению с тем же autorun-вирусом это куда менее понятный путь заражения: мало кто догадывается, что просто посмотреть содержимое каталога может быть уже опасным. А при таких вот неочевидных зависимостях внутри системы, возможны всякие неожиданности...
     Скажем, в живой природе, кроме вирусов и бактерий, существуют ещё "прионные инфекции" - та самая "почесуха овец", она же "губчатая энцефалопатия". Возбудитель - обычный белок, но имеющий изменённую структуру. Но изменённую так, что сам факт присутствия этого белка "автокаталитическим образом" влияет на синтез аналогичного "естественного" белка так, что естественный белок получается точно так же измененным. Далее по нарастающей - и единственная попавшая в организм молекула белка "размножается", а через несколько лет значительная часть белка оказывается изменённой, и организм умирает.
     Фишка в том, что прионы оказываются "ещё менее живыми" чем вирусы. Вирусы имеют оболочку, обеспечивающую проникновение вируса в клетку. Вирусы имеют "программу" (РНК), которая начинает исполняться клеткой после проникновения. Прион же не делает вообще ничего: это просто молекула, которая околачивается рядом с рибосомой (не потому что активно приползла именно к рибосоме, а потому что броуновским движением вынесло), в результате чего то, что вылазит из рибосомы, сворачивается чуть по другому. Сама молекула ни-че-го не делает, никаких программ синтеза не содержит, просто в её присутствии изменяется поведение других частей клетки.

     А вот интересно, могут ли существовать компьютерные прионы? Так, чтобы самостоятельных действий "компьютерным прионом" не предпринималось вообще - то есть, никакой код не исполнялся бы (биологические вирусы сами впрыскивают себя в клетку и содержат "исполняемый код", компьютерные - вообще являются полноценными программами), но при этом какие-то штатно выполняемые системой действия в присутствии "компьютерных прионов" модифицировались бы так, чтобы получались бы опять "компьютерные прионы".

     Навскидку вспоминается только одна из разновидностей щелчка смерти на iomega zip приводах.
     В некоторых, очень редких, случаях (пыль/грязь, механическое повреждение), загрузка zip-"дискеты" в zip-привод приводила к зацеплению головок с диском, и как следствие - отрыванию головок нахрен. Остатки головок немедленно после этого зацарапывают край диска "в лохмотья", привод при этом громко щёлкает (пытаясь всё-таки прочитать данные), данные естественно не читаются. Пользователь задумчиво вынимает дискету, и несёт её к соседнему приводу - авось там прочитается (дискета закрыта, состояние поверхности не видно, отодвигать шторку во-первых категорически запрещено инструкцией, во-вторых - несколько сложнее чем у 3.5" дискет). Соседний привод мгновенно срывает себе головки лохмотьями дискеты. Тем временем в первый привод ("раз не читается ни там ни там, значит привод исправен, проблема в дискете") суют другую дискету, которая тоже превращается в лохмотья... и есть немалый шанс, что через полчаса попыток чтения в офисе не окажется ни одного живого привода, а половина дискет будут излохмачены и смертельны для приводов.
     Правда, это всё равно не совсем "прион" - дискета всё-таки лично срывает головки дисководу. Но - "на выполнение" никакой код не передаётся :-)

     ...а потом они осознают себя, и завоюют мир. Я так думаю :-)


(Читать комментарии) - (Добавить комментарий)


[info]starcat13@lj
2010-09-26 15:27 (ссылка)
тогда - всякие картинки (те же демотиваторы) - никаких команд в них нет, но разсылают их пачками :)

(Ответить) (Уровень выше) (Ветвь дискуссии)

(Комментарий удалён)

[info]dibr@lj
2010-09-26 16:39 (ссылка)
Красивая идея - но при этом вирусный код существует и выполняется - он встроен в компилятор (и встраивается в компилятор компилятором же при компиляции компилятора из "чистых" исходников). То есть, внешне похоже - вируса при беглом осмотре нигде не видно, но из компилятора лезет завирусованный код, но это не "прион", это очень хитрый вирус/троян :-) Кстати, он даже не очень-то и "размножается" - чтобы он "размножился" нужно переносить зараженный бинарник компилятора, а это обычно делается только в одну сторону, "от создателя компилятора к пользователям".

Несколько ближе к прионам было бы, если бы в компиляторе была подменён libc (например), так, что созданные компилятором программы сами искали бы компилятор и подменяли ему libc. Распространение есть, компилятор не выполняет вирусный код, но создаёт зараженные программы... правда, на "прион" опять не тянет: зараженные программы таки содержат _выполняемый_ вирусный код, который должен выполниться для заражения.

Вот если бы этот libc удалось подменять, используя какие-то штатные возможности и не выполняя собственный код (к примеру, если бы инсталлятор программы сам подкладывал бы изменённый libc в нужное место - например, "потому что у изменённого libc выше номер версии, надо найти и проапгрейдить его в системе"). При этом, что интересно, собственно вирусный код-то при этом и не нужен - весь механизм работает только на выполнении стороннего кода (компилятор, инсталлятор), "прион" только инициирует его выполнение :-)

> И еще, на мой взгляд, баг должен сохраняться при кросскомпиляции для произвольной платформы :)

В принципе да - если вставка бага происходит до того, как компилятор опустился до платформенно-специфического уровня (грубо говоря, при разборке исходника, а не перед тасовкой ассембрерных команд в целях оптимизации под конкретный процессор), баг должен сохраниться.

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]tilimilitram@lj
2010-09-27 01:10 (ссылка)
>не "прион", это очень хитрый вирус/троян :-)
>Кстати, он даже не очень-то и "размножается" - чтобы он "размножился" нужно
>переносить зараженный бинарник компилятора, а это обычно делается только в одну сторону,
>"от создателя компилятора к пользователям".

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

Перенос в одну сторону злой хакер может обратить себе на пользу -- точно известно самое уязвимое и вдобавок нечувствительное место большущей системы. Модифицированный хакером компилятор, читающий из чистого кода больше, чем в том коде записано, может передавать эту особенность последующим версиям и портам до тех пор, пока невидимая закладка сможет опознавать место своей вклейки. Действительно, вернее взять не исходник компилятора, а исходник стандартной библиотеки, ее большуший заголовочный файл простой структуры. Переопределить в нем метод стандартного ввода так, чтобы при чтении заголовочного файла следующей версии этой библиотеки _только_ в процессе компиляции (узнаем это по характерной последовательности открытий других заголовочных файлов) в него добавлялся код закладки. После того, как очередная версия компилятора воспользуется новой версией стандартной библиотеки закладку можно убирать из исходников. Теперь и аудит кода и проверка официальных контрольных сумм и цифровых подписей ее присутствие не обнаружат. Пользователи получат модифицированные компилятор и библиотеку и ту же библиотеку уже встроенную в код множества фирменных дистрибутивов, в том числе и за счет работы служб вроде Windows Update или Линуксовых менеджеров пакетов. Поведением закладки можно управлять, скажем, научив ее извлекать новый исходный код хитро запрятанный в hex-коде какого-нибудь логотипа или комментария из жутко полезной для проекта-мишени сторонней библиотеки...

Наверняка кто-нибудь такие фокусы уже не раз проделал :(

(Ответить) (Уровень выше)


[info]tilimilitram@lj
2010-09-26 16:17 (ссылка)
Их так иногда и называют -- вирусная реклама :)

>А вот если придумать такое "письмо", чтобы прочитав его я начал добавлять его в те письма...

А коротенькую "Критику доверчивости" (http://khpi-iip.mipk.kharkiv.edu/library/extent/prog/ken/ken.html), Тьюринговскую лекцию Кена Томпсона 84 года встречали? Там о кратчайшей программе выводящей свой код и о похожем способе встроить баг в компилятор компилирующий самого себя так, что его не останется в исходном коде, но он будет воспроизводиться при каждой трансляции самого себя в машинный код.

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

(Ответить) (Уровень выше)


(Читать комментарии) -