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] На соревновании Pwn2Own 2023 года в Ванкувере команда хакеров смогла скомпрометировать шлюз в обновленной модели Tesla 3, используя эту ошибку. [6]

Примеры

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

если ( доступ ( "файл" , 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

Несмотря на концептуальную простоту, состояния гонки 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: анатомическое исследование». USENIX . Получено 14.01.2019 .
  2. ^ ab "mktemp(3)". Страница руководства Linux . 2017-09-15.
  3. ^ Шандэ Чжоу (周尚德) (1991-10-01). "Лазейка в безопасности в Unix". Архивировано из оригинала 2013-01-16.
  4. ^ Ачесон, Стив (1999-11-04). "The Secure Shell (SSH) Frequently Asked Questions". Архивировано из оригинала 2017-02-13.
  5. ^ "Ошибка Docker позволяет получить доступ root к файловой системе хоста". Расшифровать . Duo Security. 28 мая 2019 г. Получено 29-05-2019 .
  6. ^ "Windows 11, Tesla, Ubuntu и macOS взломаны на Pwn2Own 2023". BleepingComputer . Получено 24.03.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. doi :10.1109/SP.2009.10. ISBN 978-0-7695-3633-0. S2CID  6393789. Архивировано из оригинала (PDF) 18.05.2021.{{cite book}}: CS1 maint: отсутствует местоположение издателя ( ссылка )
  9. ^ Мартелли, Алекс (2006). "Глава 6: Исключения". Python in a Nutshell (2-е изд.). O'Reilly Media . стр. 134. ISBN 978-0-596-10046-9.
  10. ^ Дин, Дрю; Ху, Алан Дж. (август 2004 г.). «Конфискация гонок ради удовольствия и прибыли: как использовать access(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) . Big Sky, MT.{{cite web}}: CS1 maint: дата и год ( ссылка )
  14. ^ Руссинович, Марк; Соломон, Дэвид А. (2009). Внутреннее устройство Windows . Microsoft Press . ISBN 978-0735648739.
  15. ^ "Альтернативы использованию транзакционной NTFS". Microsoft Developer Network . Архивировано из оригинала 29 сентября 2022 г. Получено 10 декабря 2015 г.
  16. ^ Хао Чэнь; Вагнер, Дэвид; Дин, Дрю (2002-05-12). «Сетуид демистифицирован» (PDF) .

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