• Шлюзы интернета вещей, включая хабы и облачные системы.
• Обычные программы, такие как 7-zip.
В связи с этим у вас может возникнуть вопрос: а есть ли что-то, что не является представителем? Да. Большинство видеоигр таковыми не являются. Классические программы, такие как Microsoft Word, таковыми не являются, но они могут стать ими по мере того, как все больше интегрируются в облако, особенно если облако может указывать, где хранить или кэшировать файлы; где им хранить, устанавливать или запускать шрифты; где им хранить темплеты и как их называть или иным образом влиять на то, как они действуют.
Мы познакомились с проблемами zipslip в главе 5 «Отказ в обслуживании и доступность». Возможно, вы помните, что это то, что происходит, когда создатель zip-файла указывает полные пути, а распаковщик пишет туда, куда предписывают эти пути. При этом он использует полномочия человека, выполняющего unzip от имени человека, создавшего zip-файл. Было логично вспомнить об этом, поскольку мы узнали об удивительных вещах, которые происходят при распаковке данных. Но на самом деле путаница заключается в том, как используются полномочия. Раньше мы говорили о воздействии, а не об угрозе.
Другой, более старой проблемой zip было сохранение файловых атрибутов. Злоумышленник создавал zip-архив, содержащий файл с атрибутом setuid, и распаковщик бережно сохранял его при распаковке [Galacia, 2005]. Программа с атрибутом setuid будет иметь этот атрибут независимо от того, какой пользователь запустил unzip. Если вы обычно используете учетную запись root, то она будет setuid root; в противном случае она приведет к горизонтальному расширению полномочий (от пользователя к пользователю), как показано в таблице 6.1.
Веб-сервер является примером представителя-демона. Ранние веб-серверы зеркалировали файловые системы: сделать каталог /users/obiwan/public_html/ доступным под названием jedicouncil.galaxy/~obiwan/ упрощало развертывание веб-сервера и регистрацию пользователей путем создания каталога. Компромиссы в схеме с «представителем» способствовали быстрому росту интернета, а также создали возможность сбить с толку эти веб-серверы.
В каждом случае проблема заключается в том, что кто-то может указать достаточно управляющей информации, чтобы программа действовала от его имени. Это может произойти из-за сбоев синтаксического анализа имен файлов, состояния гонки, спецификации политики или проблем интерпретации. Каноническим примером проблемы с разбором имени файла было чтение../../etc/password, или, в современном мире, /etc/shadow. Наивные фильтры могут удалить… до, скажем, декодирования Unicode, которое удобно переводит %2E2E в… и вот ваша строка снова проблематична. Состояние гонки возникает, когда временное имя файла предсказуемо, когда ссылка может быть вставлена и изменена, или иным образом, когда разрыв между временем проверки и временем использования позволяет злоумышленнику переопределить то, на что смотрит представитель.
Но «представитель» – это прекрасное описание для самого разного кода, который пытается ослабить полномочия или даже просто обрабатывать сложные типы данных (например, распаковщик). Мы создаем представителей так же, как мы строим слои абстракции или границу изоляции. Точно так же в мире очень маленьких устройств представители являются распространенным шаблоном проектирования, позволяющим этим очень маленьким устройствам взаимодействовать более широко.
Как правило, проблемы синтаксического анализа, которые приводят к тому, что злоумышленник может запустить произвольный код (описанный в разделе «Распознавание и порча»), не рассматриваются как проблемы запутанности.
Угрозы и последствия
Если кто-то угрожает подать на вас в суд, угроза – это судебный иск. Судебный процесс может иметь множество последствий: ваше время и деньги тратятся на адвокатов. Суд может взыскать убытки. Если вы пререкаетесь с судьей, он может пригрозить вам обвинением в неуважении к суду, и вашим наказанием окажется тюрьма. Даже если ваше поведение вызывает недоумение, мало кто будет настолько педантичен, чтобы спорить с предложением «Судья угрожает бросить меня в тюрьму за неуважение к суду!». Это совпадение между угрозой и воздействием является частью того, как мы говорим. Даже опытные безопасники будут смешивать их, возможно, в ущерб нам.
В главе 1 «Спуфинг и аутентичность» мы рассмотрели набор сценариев с точки зрения спуфинга, что имеет решающее значение, но нам также нужно рассмотреть авторизацию в более широком смысле. «Ключ парковщика» не позволяет получить доступ к багажнику или бардачку автомобиля. Многие термостаты имеют «гостиничный режим», который ограничивает доступную температуру. Если кто-то продает устройство на дворовой распродаже, легко ли новому владельцу удалить облачную авторизацию? Точно так же, когда пара расстается, может ли тот, кто в конечном итоге получит устройство или устройства, быстро и уверенно установить новые разрешения?
Полномочия на устройствах часто распределяются сложным или даже причудливым образом между производителем, владельцем устройства и авторизованными пользователями. К распространенным шаблонам относятся команды, отправляемые из облачных служб, часто в качестве прокси-сервера для приложений. Такие платформы, поддерживающие концентраторы (хабы) устройств, как Zigbee, встроенная в устройства Alexa или Apple Home Pod, также уполномочены выполнять команды, возможно, с участием приложения. Так, например, если вы используете Alexa, чтобы указать саундбару стороннего производителя воспроизвести песню, Alexa (и, следовательно, AWS) имеет право управлять саундбаром. Если вы используете Apple Home для управления замком на двери, хаб и серверы Apple iCloud, вероятно, имеют право разблокировать вашу дверь. Детали очень зависят от реализации. Лучшие из них могут передавать подписанные команды и не могут сами инициировать команды. В самом лучшем случае подписанные команды также будут содержать как даты, так и одноразовые случайные числа, чтобы предотвратить повторные атаки.
На мобильных устройствах приложения изолированы. Таким образом, вы можете не только повышать, но и расширять: «перемещаться вбок» между разрешениями различных приложений. Это тоже повышение привилегий. Если вы работаете от имени приложения А и берете на себя управление приложением Б, вы переходите от набора разрешений А, предоставленного вашему приложению, к набору разрешений А + Б, который может быть небольшим, но не был предусмотрен разработчиком Б или операционной системой, которая должна была ограничивать эти разрешения или управлять ими. Называть это повышением как-то странно, и именно это нелепое выражение, «горизонтальное повышение», способствовало тому, что я предпочел термин расширение.
Также существуют проблемы джейлбрейка или загрузки неопубликованных приложений. Джейлбрейк относится к нарушению контроля производителя над тем, какие приложения могут быть выполнены; загрузка неопубликованных приложений относится к различным способам обхода этих элементов управления или их ослабленных версий. Это может включать загрузку пакета для Android через USB или установку с помощью сертификата разработчика IoS.
В зависимости от вашей точки зрения, джейлбрейк и загрузка неопубликованных приложений – это либо возможность для человека взять под контроль устройства, за которые он заплатил, либо нарушение важных элементов управления, предназначенных для защиты мобильных систем от угроз, которые обычно преследуют компьютеры (Windows). Как бы вы ни относились к моральной стороне этих вопросов, суть вопроса – технические полномочия. Производители телефонов и операционных систем оставляют за собой право решать, какой код будет выполняться на том или ином устройстве. Правила полномочий не становятся более понятными, когда мы добавляем корпоративные инструменты управления мобильными устройствами.
Когда мы рассматриваем инфраструктуру или платформы как услугу, мы по привычке запускаем код в облаке и принимаем гарантии, что поставщик облачных услуг не будет вмешиваться в наши дела. Является ли это решение технически обоснованным? (Мы можем рассматривать этот вопрос отдельно от договорных обязательств.) Большинство облачных систем работают на чем-то похожем на другие компьютеры-серверы: Linux на процессорах Intel или ARM. Номинально они управляются программным обеспечением, которое работает под виртуальными машинами, контейнерами или «бессерверными» процессами, которые мы используем при развертывании наших облачных систем. У этого программного обеспечения есть полномочия, как у root. Программное обеспечение облачной инфраструктуры, как правило, ослабляет то, как эти полномочия осуществляются. Либо никто, либо очень ограниченный набор людей может интерактивно войти в систему. Мы ожидаем, что интерактивные оболочки будут запрещены, потому что они не масштабируемы и являются источником ошибок реализации, но у нас есть ограниченный набор инструментов, с помощью которых это можно проверить. (Существуют более надежные конструкции, которые позволяют программному обеспечению обрабатывать зашифрованные данные или выполнять операции баз данных с данными, которые никогда не находятся в открытом виде. Есть также проекты, которые, кажется, разбрызгивают волшебную криптографическую пыль вокруг, даже не обращая внимания на тот факт, что оператор сервиса имеет право изменять программное обеспечение, использующее этот ключ, считывать память с хост-уровня виртуальной машины или иным образом обходить эту дорогостоящую волшебную пыль.)
Когда мы переходим к программному обеспечению как услуге, нужно учитывать, что разработчик программного обеспечения, вероятно, реализовал на этой платформе систему полномочий. Это может быть хорошо продумано, а может быть и нет. Часто системы распределяют полномочия с помощью перехватчиков для таких событий, как вход в систему или получение квитанции сообщения, обеспечивающих большую гибкость для клиента или злоумышленника, который взломал систему. Даже если проектировщики не реализовали их, на них могут наслаиваться «программные роботы» или другие системы автоматизации. Рассуждения о безопасности этих систем могут быстро стать очень сложными.