Программирование для Linux. Профессиональный подход.
10.6. Дополнительные проблемы безопасности.
В этой главе мы рассматриваем лишь несколько наиболее общих проблем, связанных с безопасностью. Но существует великое множество других "дыр", и далеко не все из них еще раскрыты. Поэтому в ответственных случаях без помощи экспертов не обойтись.
10.6.1. Переполнение буфера.
Почти псе основные Internet-демоны, включая демоны таких программ, как sendmail, finger, talk и др., подвержены атакам типа переполнение буфера. О них следует обязательно помнить при написании программ, которые должны выполняться с правами пользователя root, а также программ, осуществляющих межзадачное взаимодействие или читающих файлы, которые не принадлежат пользователю, запустившему программу.
Суть атаки заключается в том, чтобы заставить программу выполнить код, который она не собиралась выполнять. Типичный механизм достижения этой цели — перезапись части стека программы. В стеке, помимо всего прочего, сохраняется адрес памяти, по которому программа передает управление после завершения текущей функции. Следовательно, если поместить код взлома в памяти, а затем изменить адрес возврата так. чтобы он указывал на этот код, то по завершении текущей функции программа начнет выполнять код хакера с правами текущего процесса. Если процесс принадлежит пользователю root, последствия будут катастрофическими. Если атаке подвергся процесс другого пользователя, катастрофа наступит "только" для него (а также для любого пользователя, который работает с файлами пострадавшего).
Хуже всего обстоит дело с программами, которые работают в режиме демона и ожидают поступление запросов на подключение. Демоны обычно принадлежат пользователю root. Если в программе есть описываемая "дыра", любой, кто сможет подключиться к этой программе, способен захватить контроль над компьютером, послав по сети "смертельную" последовательность данных. Программы, не работающие с сетью, гораздо безопаснее, так как их могут атаковать только пользователи, уже зарегистрировавшиеся в системе.
Старым версиям программ finger, talk и sendmail присущ один общий недостаток: все они работают со строковым буфером фиксированной длины. Предельный размер строки предполагается по умолчанию, но ничто не мешает сетевым клиентам вводить строки, вызывающие переполнение буфера. В программах содержится примерно такой код, как показан ниже.
#include <stdio.h>
Int main() {
/* Никто, будучи в здравом уме, не выбирает имя пользователя.
длиной более 32 символов. Кроме того, я думаю, что в UNIX.
допускаются только 8-символьные имена. Поэтому выделенного.
буфера должно быть достаточно. */
char username[32];
/* Предлагаем пользователю ввести свое имя. */
printf("Enter your username: ");
/* Читаем введенную строку. */
gets(username);
/* Выполняем другие действия... */
Return 0;
}
Комбинация 32-символьного буфера и функции gets() делает возможным переполнение буфера. Функция gets() читает вводимые данные до тех пор, пока не встретится символ новой строки, после чего помещает весь результат в массив username. В комментариях к программе предполагается, что пользователи выбирают себе короткие имена, не превышающие в длину 32 символа. Но при написании защищенных программ необходимо помнить о существовании хакеров. В данном случае хакер может выбрать сколь угодно длинное имя. Локальные переменные, в частности username, сохраняются в стеке, поэтому выход за пределы массива оборачивается тем, что в стек помещаются произвольные данные.
К счастью, предотвратить переполнение буфера относительно несложно. При чтении строк следует всегда пользоваться функцией наподобие getline(), которая либо динамически выделяет буфер достаточной длины, либо прекращает принимать входные данные, когда буфер оказывается заполнен. Вот вариант выхода из положения:
Char* username = getline(NULL, 0, stdin);
Функция getline() автоматически вызывает функцию malloc(), которая выделяет буфер для введенной строки и возвращает указатель на него. Естественно, следует не забыть вызвать функцию free(), чтобы по окончании работы с буфером вернуть память системе.
Ситуация еще проще, если используется язык C++, где есть готовые строковые примитивы. В C++ ввод строки осуществляется так:
String username;
Getline(cin, username);
Буфер строки username удаляется автоматически, поэтому даже не придется вызывать функцию free().
Проблема переполнения буфера возникает при работе с любыми статическими массивами, а не только со строками. При написании безопасных программ следует тщательно проверять, не осуществляется ли запись в массив за его пределами.
10.6.2. Конкуренция доступа к каталогу /tmp.
Другая распространенная проблема безопасности связана с созданием файлов с предсказуемыми именами, в основном в каталоге /tmp. Предположим, что программа prog, выполняющаяся от имени пользователя root, всегда создает временный файл /tmp/prog и помещает в него важную информацию. Тогда злоумышленник может заранее создать символическую ссылку /tmp/prog на любой другой файл в системе. Когда программа попытается создать временный файл, функция open() завершится успешно, но в действительности вернет дескриптор символической ссылки. Любые данные, записываемые во временный файл, окажутся перенаправленными в файл злоумышленника.
В такой ситуации говорят о конкуренции. Она неявно существует между автором программы и хакером. Кто первым успеет создать временный файл, тот и победит.
Посредством этой атаки часто уничтожаются системные файлы. Создав нужную символическую ссылку, хакер может заставить программу, выполняющуюся с правами суперпользователя, затереть важный системный файл, например /etc/passwd.
Один из способов избежать такой атаки — создавать временные файлы со случайными именами. Например, можно прочитать из устройства /dev/random случайные данные и включить их в имя файла. Это усложнит задачу хакеру, но не остановит его полностью. Он может попытаться создать большое число символических ссылок с потенциально верными именами. Даже если их будет 10000, одна верная догадка приведет к непоправимому.
Другой подход заключается в вызове функции open() с флагом O_EXCL. Он заставляет функцию завершиться неудачей, если обнаруживается факт существования файла. К сожалению, это не срабатывает, если программа работает через NFS. Нельзя заранее предсказать, в какой файловой системе будет находиться программа, поэтому рассчитывать только на флаг O_EXCL нельзя.
В разделе 2.1.7, "Временные файлы", рассказывалось о применении функции mkstemp() для создания временных файлов. К сожалению, в Linux эта функция открывает файл с флагом O_EXCL после того, как было выбрано трудно угадываемое имя. Другими словами, применять функцию небезопасно, если каталог /tmp смонтирован через NFS.[35].
Прием, который всегда работает, заключается в вызове функции lstat() (рассматривается в приложении Б, "Низкоуровневый ввод-вывод") для созданного файла. Она отличается от функции stat() тем, что возвращает информацию о самой символической ссылке, а не о файле, на который она ссылается. Если функция сообщает, что новый файл является обычным файлом, а не символической ссылкой, и принадлежит владельцу программы, то все в порядке.
В листинге 10.5 представлена функция, которая пытается безопасно открыть файл в каталоге /tmp. Возможно, у этой функции есть свои слабости. Мы не рекомендуем читателям включать показанный код в свои программы без дополнительной экспертизы, просто мы хотим убедить читателей в том, что создание безопасных приложений — непростая задача,
Листинг 10.5. (temp-file.c) Безопасное создание временного файла.
#include <fcntl.h>
#include <stdlib.h>
#include <sys/stat.h>
#include <unistd.h>
/* Функция возвращает дескриптор созданного временного файла.
Файл будет доступен для чтения и записи только тому.
пользователю, чей идентификатор равен эффективному.
идентификатору текущего процесса. Если файл не удалось создать,
возвращается -1. */
Int secure_temp_file() {
/* Этот дескриптор ссылается на устройство /dev/random, из.
которого будут получены случайные данные. */
static int random_fd = -1;
/* Случайное целое число. */
unsigned int random;
/* Буфер для преобразования числа в строку. */
char filename[128];
/* дескриптор создаваемого временного файла. */
int fd;
/* информация о созданном файле. */
struct stat stat_buf;
/* Если устройство /dev/random еще не было открыто,
открываем его. */
if (random_fd == -1) {
/* Открытие устройства /dev/random. Предполагается, что.
это устройство является источником случайных данных,
а не файлом, созданным хакером. */
random_fd = open("/dev/random", O_RDONLY);
/* Если устройство /dev/random не удалось открыть,
завершаем работу. */
if (random_fd == -1).
return -1;
}
/* чтение целого числа из устройства /dev/random. */
if (read(random_fd, &random, sizeof(random)) != sizeof(random)).
return -1;
/* Формирование имени файла из случайного числа. */
sprintf(filename, "/tmp/%u", random);
/* Попытка открытия файла. */
fd = open(filename,
/* Используем флаг O_EXCL. */
O_RDWR | O_CREAT | O_EXCL,
/* Разрешаем доступ только владельцу файла. "/
S_IRUSR | S_IWUSR);
if (fd == -1).
return -1;
/* Вызываем функцию lstat(), чтобы проверить, не является ли.
файл символической ссылкой */
if (lstat(filename, &stat_buf) == -1).
return -1;
/* Если файл не является обычным файлом, кто-то пытается.
обмануть нас. */
if (!S_ISREG(stat_buf.st_mode)).
return -1;
/* Если файл нам не принадлежит, то, возможно, кто-то успел.
подменить его. */
if (stat_buf.st_uid != geteuid() ||
stat_buf.st_gid != getegid()).
return -1;
/* Если у файла установлены дополнительные биты доступа,
что-то не так. */
if ((stat_buf.st_mode & ~(S_IRUSR | S_IWUSR)) != 0).
return -1;
return fd;
}
Рассмотренная функция вызывает функцию open() для создания файла, а затем функцию lstat() для проверки того, что файл не является символической ссылкой. Внимательный читатель обнаружит здесь то, что называется состоянием гонки. Между вызовами функций open() и lstat() злоумышленник может успеть удалить файл и заменить его символической ссылкой. Это не вызовет разрушающих последствий, но приведет к тому, что функция завершится ошибкой и не сможет выполнить свою задачу. Такой тип атаки называется отказом от обслуживания.
В данной ситуации на помощь приходит sticky-бит. Поскольку для каталога /tmp он установлен, никто не сможет удалить файлы из этого каталога, не будучи их владельцем. Естественно, пользователю root разрешено делать все что угодно, но если хакер сумел получить привилегии суперпользователя, вас уже ничто не спасет.
Грамотный системный администратор не допустит, чтобы каталог /tmp был смонтирован через NFS, поэтому на практике можно пользоваться функцией mkstemp(). Если же речь идет о другом каталоге, то нельзя ни доверять флагу O_EXCL, ни рассчитывать на установку sticky-бита.
10.6.3. Функции system() и popen().
Третья распространенная проблема безопасности, о которой должен помнить каждый программист, заключается в несанкционированном запуске программ через интерпретатор команд. В качестве наглядной демонстрации рассмотрим сервер словарей. Серверная программа ожидает поступления запросов через Internet. Клиент посылает слово, а сервер сообщает, является ли оно корректным словом английского языка. В любой Linux-системе имеется файл /usr/dict/words, в котором содержится список 45000 слов, поэтому серверу достаточно выполнить такую команду:
% grep -х слово /usr/dict/words.
Код завершения команды grep сообщит о том, обнаружено ли указанное слово в файле /usr/dict/words.
В листинге 10.6 показан пример реализации поискового модуля сервера.
Листинг 10.6. (grep-dictionary.c) Поиск слова в словаре.
#include <stdio.h>
#include <stdlib.h>
/* Функция возвращает ненулевое значение, если аргумент WORD.
встречается в файле /usr/dict/words. */
Int grep_for_word(const char* word) {
size_t length;
char* buffer;
int exit_code;
/* Формирование строки 'grep -x WORD /usr/dict/words'.
Строка выделяется динамически во избежание.
переполнения буфера. */
length =
strlen("grep -х ") + strlen(word) +
strlen(" /usr/dict/words") + 1;
buffer = (char*)malloc(length);
sprintf(buffer, "grep -x %s /usr/dict/words", word);
/* Запуск команды. */
exit_code = system(buffer);
/* Очистка буфера. */
free(buffer);
/* Если команда grep вернула значение 0, значит, слово найдено.
в словаре. */
return exit_code == 0;
}
Обратите внимание на подсчет числа символов в строке и динамическое выделение буфера, что позволяет обезопасить программу от переполнения буфера. К сожалению, небезопасна сама функция system() (описана в разделе 3.2.1, "Функция system()"). Функция вызывает стандартный интерпретатор команд и принимает от него код завершения. Но что произойдет, если злоумышленник вместо слова введет показанную ниже строку?
Foo /dev/null; rm -rf /
В этом случае сервер выполнит такую команду:
Grep -х foo /dev/null; rm -rf / /usr/dict/words.
Теперь проблема стала очевидной. Пользователь запустил одну команду, якобы grep, а на самом деле их оказалось две, так как интерпретатор считает точку с запятой разделителем команд. Первая команда — это по-прежнему безобидный вызов утилиты grep, зато вторая команда пытается удалить все файлы в системе. Даже если серверная программа не имеет привилегий суперпользователя, она удалит все файлы, доступные запустившему ее пользователю. Похожая проблема возникает и при использовании функции popen() (описана в разделе 3.4.4, "Функции popen() и pclose()"), которая создает канал между родительским и дочерним процессами, но тоже вызывает интерпретатор для запуска команды.
Существуют два способа устранения подобных проблем. Первый заключается в использовании функции семейства exec() вместо функции system() или popen(). Специальные символы интерпретатора команд (например, точка с запятой) не подвергаются обработке, если они присутствуют в списке аргументов функции exec(). Естественно, при этом пропадают преимущества таких функций, как system() и popen().
Второй способ — проверка строки на предмет "благонадежности". В случае сервера словарей следует убедиться в том, что слово содержит только буквы (для этого предназначена функция isalpha()). Такое слово не представляет угрозы.
- 1.
- 2.
- 3.
- 4.
- 5.
- 6.
- 7.
- 8.
- 9.
- 10.
- 11.
- 12.
- 13.
- 14.
- 15.
- 16.
- 17.
- 18.
- 19.
- 20.
- 21.
- 22.
- 23.
- 24.
- 25.
- 26.
- 27.
- 28.
- 29.
- 30.
- 31.
- 32.
- 33.
- 34.
- 35.
- 36.
- 37.
- 38.
- 39.
- 40.
- 41.
- 42.
- 43.
- 44.
- 45.
- 46.
- 47.
- 48.
- 49.
- 50.
- 51.
- 52.
- 53.
- 54.
- 55.
- 56.
- 57.
- 58.
- 59.
- 60.
- 61.
- 62.
- 63.
- 64.
- 65.
- 66.
- 67.
- 68.
- 69.
- 70.
- 71.
- 72.
- 73.
- 74.
- 75.
- 76.
- 77.
- 78.
- 79.
- 80.
- 81.
- 82.
- 83.
- 84.
- 85.
- 86.
- 87.
- 88.
- 89.
- 90.
- 91.
- 92.
- 93.
- 94.
- 95.
- 96.
- 97.
- 98.
- 99.
- 100.
- 101.
- 102.
- 103.
- 104.
- 105.
- 106.
- 107.
- 108.
- 109.
- 110.
- 111.
- 112.
- 113.
- 114.
- 115.
- 116.
- 117.
- 118.
- 119.
- 120.
- 121.
- 122.
- 123.
- 124.
- 125.
- 126.
- 127.
- 128.
- 129.
- 130.
- 131.
- 132.
- 133.
- 134.
- 135.
- 136.
- 137.
- 138.
- 139.
- 140.
- 141.
- 142.
- 143.
- 144.
- 145.
- 146.
- 147.
- 148.
- 149.
- 150.
- 151.
- 152.
- 153.
- 154.
- 155.
- 156.
- 157.
- 158.
- 159.
- 160.
- 161.
- 162.
- 163.
- 164.
- 165.
- 166.
- 167.
- 168.
- 169.
- 170.
- 171.
- 172.
- 173.
- 174.
- 175.
- 176.
- 177.
- 178.
- 179.
- 180.
- 181.
- 182.
- 183.
- 184.
- 185.
- 186.
- 187.
- 188.
- 189.
- 190.
- 191.
- 192.
- 193.
- 194.
- 195.
- 196.
- 197.
- 198.
- 199.
- 200.
- 201.
- 202.
- 203.
- 204.
- 205.
- 206.
- 207.
- 208.
- 209.
- 210.
- 211.
- 212.
- 213.
- 214.
- 215.
- 216.
- 217.
- 218.
- 219.
- 220.
- 221.
- 222.
- 223.
- 224.
- 225.
- 226.
- 227.
- 228.
- 229.
- 230.
- 231.
- 232.
- 233.
- 234.
- 235.
- 236.
- 237.
- 238.
- 239.
- 240.
- 241.
- 242.
- 243.
- 244.
- 245.
- 246.
- 247.
- 248.
- 249.
- 250.
- 251.
- 252.
- 253.
- 254.
- 255.
- 256.
- 257.
- 258.
- 259.
- 260.
- 261.
- 262.
- 263.
- 264.
- 265.
- 266.
- 267.