Время проверки до времени использования - Time-of-check to time-of-use

В разработка программного обеспечения, от времени проверки до времени использования (ТОКТУ, ТОКТУ или же TOC / TOU) является классом программные ошибки вызвано состояние гонки с участием проверка состояния части системы (например, учетных данных безопасности) и использовать результатов этой проверки.

Условия гонки TOCTOU обычны в Unix между операциями на файловая система,[1] но может происходить в других контекстах, в том числе Розетки и неправильное использование транзакции базы данных. В начале 1990-х почтовая утилита BSD 4.3 UNIX имела пригодный для использования условие гонки для временных файлов, потому что он использовал mktemp () функция.[2] Ранние версии OpenSSH имел пригодное для использования состояние гонки за Доменные сокеты Unix.[3] Они остаются проблемой в современных системах; по состоянию на 2019 год условие гонки TOCTOU в Докер разрешает root-доступ к файловой системе хост-платформы.[4]

Примеры

В Unix, следующее C код, когда используется в Setuid программа имеет ошибку TOCTOU:

если (доступ("файл", W_OK) != 0) {   выход(1);}fd = открыто("файл", O_WRONLY);записывать(fd, буфер, размер(буфер));

Здесь, доступ предназначен для проверки того, был ли реальный пользователь, выполнивший Setuid программе обычно разрешается записывать файл (т. е. доступ проверяет реальный идентификатор пользователя скорее, чем эффективный идентификатор пользователя ).

Это состояние гонки уязвимо для атаки:

ЖертваЗлоумышленник
если (доступ("файл", W_OK) != 0) {   выход(1);}fd = открыто("файл", O_WRONLY);// Фактически пишем поверх / etc / passwdзаписывать(fd, буфер, размер(буфер));
// //// После проверки доступасимволическая ссылка("/ etc / passwd", "файл");// Перед открытием "файл" указывает на базу паролей////

В этом примере злоумышленник может использовать состояние гонки между доступ и открыто обмануть Setuid жертва перезаписывает запись в базе данных системных паролей. Гонки TOCTOU можно использовать для повышение привилегий, чтобы получить административный доступ к машине.

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

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

Надежно тайминг TOCTOU

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

В случае почтовой утилиты BSD 4.3 и mktemp (),[5] злоумышленник может просто запускать почтовую утилиту в одном процессе, угадывать имена временных файлов и создавать символические ссылки в другом процессе. Атака обычно может быть успешной менее чем за одну минуту.

Методы пошагового выполнения программы-жертвы включают лабиринты файловой системы[6] и атаки с алгоритмической сложностью.[7] В обоих случаях злоумышленник манипулирует состоянием ОС, чтобы управлять расписанием работы жертвы.

Лабиринты файловой системы вынуждают жертву прочитать запись каталога, отсутствующую в кеше ОС, а ОС переводит жертву в спящий режим, пока она читает каталог с диска. Атаки с алгоритмической сложностью вынуждают жертву тратить весь квант планирования внутри единственного системного вызова, просматривая хэш-таблицу имен кэшированных файлов ядра. Злоумышленник создает очень большое количество файлов с именами, хеширующими то же значение, что и файл, который будет искать жертва.

Предотвращение ТОКТУ

Несмотря на концептуальную простоту, условия гонки TOCTOU трудно избежать и устранить. Один общий прием - использовать Обработка исключений вместо проверки, согласно философии EAFP - «Проще просить прощения, чем разрешения», а не LBYL - «смотреть, прежде чем прыгнуть» - в этом случае проверки нет, и при использовании обнаруживаются несоблюдения предположений время, в виде исключения.[8]

В контексте состояния гонки TOCTOU файловой системы фундаментальной проблемой является обеспечение невозможности изменения файловой системы между двумя системными вызовами. В 2004 году был опубликован результат невозможности, показывающий, что не существует портативного детерминированного метода, позволяющего избежать условий гонки TOCTOU.[9]

Поскольку это невозможно, библиотеки для отслеживания файловые дескрипторы и обеспечение правильности были предложены исследователями.[10]

Альтернативное решение, предложенное в исследовательском сообществе, состоит в том, чтобы системы UNIX использовали сделки в файловой системе или ядре ОС. Транзакции обеспечивают контроль параллелизма абстракция для ОС и может использоваться для предотвращения гонок TOCTOU. Хотя ни одно производственное ядро ​​UNIX еще не приняло транзакции, для Linux были разработаны экспериментальные исследовательские прототипы, включая файловую систему Valor.[11] и ядро ​​TxOS.[12] Майкрософт Виндоус добавил транзакции в свой NTFS файловая система,[13] но Microsoft не рекомендует их использование и указала, что они могут быть удалены в будущей версии Windows.[14]

Блокировка файлов является распространенным методом предотвращения состояний гонки для одного файла, но он не распространяется на пространство имен файловой системы и другие метаданные, а также блокировка плохо работает с сетевыми файловыми системами и не может предотвратить условия гонки TOCTOU.

Для двоичных файлов setuid возможным решением является использование seteuid () системный вызов для смены действующего пользователя, а затем выполнить открыто(). Различия в setuid () между операционными системами может быть проблематично.[15]

Смотрите также

Рекомендации

  1. ^ Вэй, Цзиньпэн; Пу, Калтон. «Уязвимости TOCTTOU в файловых системах в стиле UNIX: анатомическое исследование». www.usenix.org. Получено 2019-01-14.
  2. ^ Шандэ Чжоу (周尚德) (1991-10-01). "Лазейка безопасности в Unix". Архивировано из оригинал на 2013-01-16.
  3. ^ Ачесон, Стив (1999-11-04). «Часто задаваемые вопросы по Secure Shell (SSH)». Архивировано из оригинал на 2017-02-13.
  4. ^ «Ошибка Docker позволяет получить root-доступ к файловой системе хоста». Расшифровать. Получено 2019-05-29.
  5. ^ "mktemp (3) - справочная страница Linux".
  6. ^ Борисов, Никита; Джонсон, Роб; Састри, Навин; Вагнер, Дэвид (2005). «Исправление гонок для развлечения и наживы: как злоупотреблять временем». Материалы 14-й конференции, посвященной симпозиуму по безопасности USENIX, Балтимор (Мэриленд), 31 июля - 5 августа 2005 г.. 14: 303–314. CiteSeerX  10.1.1.117.7757.
  7. ^ Сян Кай; Ювэй Гуй; Джонсон, Роб (2009-03-06). «Использование гонок файловой системы Unix с помощью атак с алгоритмической сложностью» (PDF). Труды IEEE Симпозиум по безопасности и конфиденциальности, Беркли (Калифорния), 17–20 мая 2009 г..
  8. ^ Мартелли, Алекс (2006). «Глава 6: Исключения». Python в двух словах (2-е изд.). O'Reilly Media. п. 134. ISBN  978-0-596-10046-9.
  9. ^ Дин, Дрю; Ху, Алан Дж. (2004). «Исправление гонок для развлечения и выгоды: как использовать доступ (2)». Материалы 13-го симпозиума по безопасности USENIX, Сан-Диего (Калифорния), 9–13 августа 2004 г.: 195–206. CiteSeerX  10.1.1.83.8647.
  10. ^ Цафрир, Дан; Герц, Томер; Вагнер, Давид; Да Силва, Дилма (Июнь 2008 г.). «Переносимое предотвращение атак на основе гонки файлов с помощью разрешения пути в пользовательском режиме». Технический отчет RC24572, IBM T. J. Watson Research Center, Йорктаун-Хайтс (Нью-Йорк).
  11. ^ Spillane, Ричард П .; Гайквад, Сачин; Чинни, Манджунатх; Задок, Эрез (2009). «Включение транзакционного доступа к файлам с помощью облегченных расширений ядра» (PDF). Седьмая конференция USENIX по файловым технологиям и технологиям хранения (FAST 2009), Сан-Франциско (Калифорния), 24–27 февраля 2009 г..
  12. ^ Портер, Дональд Э .; Hofmann, Owen S .; Россбах, Кристофер Дж .; Бенн, Александр; Витчел, Эммет (2009). «Операции с операционной системой» (PDF). Труды 22-го ACM Симпозиум по принципам операционных систем (SOSP '09), Big Sky (MT), 11–14 октября 2009 г..
  13. ^ Руссинович, Марк; Соломон, Дэвид А. (2009). Внутреннее устройство Windows. Microsoft Press. ISBN  978-0735648739.
  14. ^ «Альтернативы использованию транзакционной NTFS». Сеть разработчиков Microsoft. Получено 10 декабря 2015.
  15. ^ Хао Чен; Вагнер, Давид; Дин, Дрю (2002-05-12). "Сетуид демистифицирован" (PDF).

дальнейшее чтение