stringtranslate.com

Время проверки до времени использования

В разработке программного обеспечения время проверки времени использования ( TOCTOU , TOCTTOU или TOC/TOU ) — это класс программных ошибок , вызванных состоянием гонки , включающим проверку состояния части системы (например, учетные данные безопасности) и использование результатов этой проверки.

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

Примеры

В Unix следующий код C при использовании в setuidпрограмме содержит ошибку TOCTOU:

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

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

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

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

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

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

Надежный расчет времени TOCTOU

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

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

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

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

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

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

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

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

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

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

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

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

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

  1. ^ Вэй, Цзиньпэн; Пу, Калтон (декабрь 2005 г.). «Уязвимости TOCTTOU в файловых системах UNIX-стиля: анатомическое исследование». УСЕНИКС . Проверено 14 января 2019 г.
  2. ^ ab "mktemp(3)". Страница руководства по Linux . 15 сентября 2017 г.
  3. ^ Шандэ Чжоу (周尚德) (1 октября 1991). «Лазейка безопасности в Unix». Архивировано из оригинала 16 января 2013 г.
  4. ^ Ачесон, Стив (4 ноября 1999 г.). «Часто задаваемые вопросы по Secure Shell (SSH)». Архивировано из оригинала 13 февраля 2017 г.
  5. ^ «Ошибка Docker обеспечивает root-доступ к файловой системе хоста» . Расшифровать . Дуэт безопасности. 28 мая 2019 года . Проверено 29 мая 2019 г.
  6. ^ «Windows 11, Tesla, Ubuntu и macOS взломаны на Pwn2Own 2023» . Мигающий компьютер . Проверено 24 марта 2023 г.
  7. ^ Борисов, Никита; Джонсон, Роб; Састри, Навин; Вагнер, Дэвид (август 2005 г.). «Урегулирование гонок ради развлечения и выгоды: как злоупотреблять временем». Материалы 14-й конференции по симпозиуму по безопасности USENIX . 14 . Балтимор, Мэриленд: 303–314. CiteSeerX 10.1.1.117.7757 . {{cite journal}}: CS1 maint: дата и год ( ссылка )
  8. ^ Сян Цай; Ювэй Гуй; Джонсон, Роб (май 2009 г.). «Использование гонок файловой системы Unix посредством атак на сложность алгоритма» (PDF) . 2009 30-й симпозиум IEEE по безопасности и конфиденциальности . Беркли, Калифорния. стр. 27–41. дои :10.1109/СП.2009.10. ISBN 978-0-7695-3633-0. S2CID  6393789. Архивировано из оригинала (PDF) 18 мая 2021 г.{{cite book}}: CS1 maint: отсутствует местоположение издателя ( ссылка )
  9. ^ Мартелли, Алекс (2006). «Глава 6: Исключения». Python в двух словах (2-е изд.). О'Рейли Медиа . п. 134. ИСБН 978-0-596-10046-9.
  10. ^ Дин, Дрю; Ху, Алан Дж. (август 2004 г.). «Урегулирование гонок ради удовольствия и прибыли: как использовать доступ (2)». Материалы 13-го симпозиума по безопасности USENIX . Сан-Диего, Калифорния): 195–206. CiteSeerX 10.1.1.83.8647 . {{cite journal}}: CS1 maint: дата и год ( ссылка )
  11. ^ Цафрир, Дэн; Герц, Томер; Вагнер, Дэвид; Да Силва, Дилма (июнь 2008 г.). «Портативное предотвращение атак типа «гонка файлов» с помощью разрешения путей в пользовательском режиме». Технический отчет RC24572, Исследовательский центр IBM TJ Watson . Йорктаун-Хайтс, Нью-Йорк.
  12. ^ Спиллейн, Ричард П.; Гайквад, Сачин; Чинни, Манджунатх; Садок, Эрез (24–27 февраля 2009 г.). «Включение транзакционного доступа к файлам с помощью облегченных расширений ядра» (PDF) . Седьмая конференция USENIX по файловым технологиям и технологиям хранения (FAST 2009) . Сан-Франциско, Калифорния.{{cite web}}: CS1 maint: дата и год ( ссылка )
  13. ^ Портер, Дональд Э.; Хофманн, Оуэн С.; Россбах, Кристофер Дж.; Бенн, Александр; Витчел, Эммет (11–14 октября 2009 г.). «Транзакции операционной системы» (PDF) . Материалы 22-го симпозиума ACM по принципам операционных систем (SOSP '09) . Биг Скай, Монтана.{{cite web}}: CS1 maint: дата и год ( ссылка )
  14. ^ Руссинович, Марк; Соломон, Дэвид А. (2009). Внутреннее устройство Windows . Майкрософт Пресс . ISBN 978-0735648739.
  15. ^ «Альтернативы использованию транзакционной NTFS». Сеть разработчиков Microsoft . Архивировано из оригинала 29 сентября 2022 года . Проверено 10 декабря 2015 г.
  16. ^ Хао Чен; Вагнер, Дэвид; Дин, Дрю (12 мая 2002 г.). «Сетуид демистифицирован» (PDF) .

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