Рис. 2.4. Внешний вид файла, зараженного вирусом PolyEngine.Linux.LIME.poly; вирус внедряет свое тело в конец секции данных и устанавливает на него точку входа. Наличие исполняемого кода в секции данных делает присутствие вируса чрезвычайно заметным

Далее по тексту просто «секции», хотя применительно к ELF-файлам это будет несколько некорректно, так как системный загрузчик исполняемых ELF-фай-лов работает исключительно с сегментами, а секции игнорирует.

Строго говоря, это утверждение не совсем верно. Последней секцией файла, как правило, является секция. bss, предназначенная для хранения неинициа —

лизированных данных. Внедряться сюда можно, но бессмысленно, поскольку загрузчик не настолько глуп, чтобы тратить драгоценное процессорное время на загрузку неинициализированных данных с медленного диска. Правильнее было бы сказать «последней значимой секции», но давайте не будем придираться, это ведь не научная статья, верно?

Перед секций. bss обычно располагается секция. data, содержащая инициализированные данные. Вот она-то и становится основным объектом вирусной атаки! Натравив дизассемблер на исследуемый файл, посмотрите – в какой секции расположена точка входа. И если этой секцией окажется секция данных, исследуемый файл с высокой степенью вероятности заражен вирусом.

При внедрении в а. out-файл вирус в общем случае должен проделать следующие действия:

1. Считав заголовок файла, убедиться, что это действительно a.out-файл.

2. Увеличить поле a_data на величину, равную размеру своего тела.

3. Скопировать себя в конец файла.

4. Скорректировать содержимое поля a_entry для перехвата управления (если вирус действительно перехватывает управление таким образом).

Внедрение в ELF-файлы происходит несколько более сложным образом:

1. Вирус открывает файл и, считывая его заголовок, убеждается, что это действительно ELF-файл.

2. Просматривая Program Header Table, вирус отыскивает сегмент, наиболее подходящий для заражения (для заражения подходит любой сегмент с атрибутом PLL0AD; собственно говоря, остальные сегменты более или менее подходят тоже, но вирусный код в них будет смотреться несколько странно).

3. Найденный сегмент «распахивается» до конца файла и увеличивается на величину, равную размеру тела вируса, что осуществляется путем синхронной коррекции полей p_filez и pjnemz.

4. Вирус дописывает себя в конец заражаемого файла.

5. Для перехвата управления вирус корректирует точку входа в файл (e_entry) либо же внедряет в истинную точку входа jmp на свое тело (впрочем, методика перехвата управления – тема отдельного большого разговора).

Маленькое техническое отступление. Секция данных, как правило, имеет всего лишь два атрибута: атрибут чтения (read) и атрибут записи (write). Атрибут исполнения (execute) у нее по умолчанию отсутствует. Означает ли это, что выполнение вирусного кода в ней окажется невозможным? Вопрос не имеет однозначного ответа. Все зависит от особенностей реализации конкретного процессора и конкретной операционной системы. Некоторые из них игнорируют отсутствие атрибута исполнения, полагая, что право исполнения кода напрямую вытекает из права чтения. Другие же возбуждают исключение, аварийно завершая выполнение зараженной программы. Для обхода этой ситуации вирусы могут присваивать секции данных атрибут execute, выдавая тем самым себя с головой; впрочем, такие экземпляры встречаются крайне редко, и подавляющее большинство вирусописателей оставляет секцию данных с атрибутами по умолчанию.

Другой немаловажный и неочевидный на первый взгляд момент. Задумайтесь, как изменится поведение зараженного файла при внедрении вируса в непоследнюю секцию. data, следом за которой расположена. bss? A никак не изменится! Несмотря на то что последняя секция будет спроецирована совсем не по тем адресам, программный код об этом «не узнает» и продолжит обращаться к неинициализированным переменным по их прежним адресам, теперь занятым кодом вируса, который к этому моменту уже отработал и возвратил оригинальному файлу все бразды правления. При условии, что программный код спроектирован корректно и не закладывается на начальное значение неинициализированных переменных, присутствие вируса не нарушит работоспособности программы.

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

Взгляните, например, на строение утилиты Is, позаимствованной из следующего дистрибьютива UNIX: Red Hat 5.0 (листинг 2.5).

Листинг 2.5. Так выглядит типичная карта памяти нормального файла

Секция. data расположена в самой «гуще» файла, и, чтобы до нее добраться, вирусу придется позаботиться о модификации семи остальных секций, скорректировав их поля p_offset (смещение секции от начала файла) надлежащим образом. Некоторые вирусы этого не делают, в результате чего зараженные файлы не запускаются.

Вместе с тем секция. data рассматриваемого файла насчитывает всего 10h байт, поскольку львиная часть данных программы размещена в секции. rodata (секции данных, доступной только для чтения). Это – типичная практика современных линкеров, и большинство исполняемых файлов организованы именно так. Вирус не может разместить свой код в секции. data, поскольку это делает его слишком заметным, не может он внедриться и в. rodata, так как в этом случае он не сможет себя расшифровать (выделить память на стеке и скопировать туда свое тело – не предлагать: для современных вирусописателей это слишком сложно). Да и смысла в этом будет немного. Коль скоро вирусу приходится внедряться не в конец, а в середину файла, уж лучше ему внедриться не в секцию данных, а в секцию.text, содержащую машинный код. Там вирус будет не так заметен (но об этом мы поговорим позже, см. далее «Заражение посредством расширения кодовой секции файла»).