Статья Не доверяйте своему заголовку: абузим эмуляторы терминалов с помощью управляющих символов ANSI

[Artem N]

Однажды, работая над OpenShift, дистрибутивом Kubernetes от RedHat, в котором основное внимание уделяется профессионализму разработчиков и безопасности приложений, я заметил, что могу вводить в веб-приложения управляющие символы ANSI. Когда пользователь прочитал данные с внедрёнными символами, он выполнил внедрённые команды - в моём случае изменился цвет терминала. Я подумал, что это интересно, но не был уверен, что это что-то серьёзное.

В тот момент мои знания об управляющих ANSI-символах сводились в основном к изменению цвета. Мне было интересно - существует ли уязвимость в разборе цветов, которая может привести к выполнению произвольных команд. Но помимо моего первоначального любопытства, я не сразу приступил к дальнейшему исследованию.

Когда пришло время начать новое исследование, я вспомнил о тикете, который видел в OpenShift. И подумал, что это было бы интересно исследовать. Это и привело меня к изучению управляющих символов ANSI. Честно говоря, я не понимал во что ввязался. Я обнаружил, что существует множество управляющих кодов, что убедило меня в интересности данного исследования.

В этой статье я расскажу вам о том, как исследование эмуляторов терминала приняло другой оборот, когда я обнаружил уязвимость Отказа в обслуживании (DoS) косвенно злоупотребляя системными вызовами Windows. Я покажу как эта проблема затрагивает другие компоненты, что может вас удивить. Это исследование привело в общей сложности к девяти уязвимостям в различных терминалах. Пристегните ремни, начинаем.

Вкратце

Это исследование привело к:
- пяти уязвимостям высокой степени серьёзности: CVE-2021-28847, CVE-2021-28848, CVE-2021-32198, CVE-2021-33500 и CVE-2021-42095. Мы нашли способ вызвать DoS на хосте клиента терминала;
- уязвимость инъекции символов ANSI в OpenShift и Kubernetes (CVE-2021-25743);
- три дополнительных уязвимости: CVE-2021-31701, CVE-2021-37326 и CVE-2021-40147. Мы нашли способ обойти механизм режима вставки скобок внутри терминалов.

Эмуляторы терминалов

Почти каждый, кто работает с компьютером, имел возможность использовать эмулятор терминала. Эмулятор терминала (Рисунок 1) - это компьютерная программа, имитирующая видеотерминал с доступом к локальному или удалённому хосту. Это чёрное окно, которое вы обычно видите в фильмах о хакерах. Эмулятор терминала предоставляет нам только экран и набор команд для выполнения в системе, он снимает все накладные расходы связанные с графикой, делает работу быстрее и эффективнее в случае, если нам нужно выполнить конкретные команды, не требующие графического интерфейса. Его можно рассматривать как текстовую систему для навигации по операционной системе.

Рисунок 1 - эмулятор терминала PuTTY

История

Эмуляторы терминалов существуют с момента появления операционных систем. До появления ПК люди использовали терминалы - физические машины, похожие на ПК, которые использовались в университетах в 1970-х годах. Одним из них был VT100. Терминалы состояли из монитора и клавиатуры и были связаны с мейнфреймом (сервером).

Сегодня у нас всё ещё есть терминалы - например, стандартный терминал CMD в Windows или bash/sh в Linux. Но есть и множество других, таких как PuTTY, MobaXterm, Terminator и т.д. Это приводит к вопросу: что произойдёт, если в одном из них обнаружится критическая уязвимость?

Проблема в том, что она может затронуть любого, кто использует терминалы для подключения к удалённому серверу. Это могут быть как обычные пользователи, так и IT-администраторы, разработчики - то есть множество пользователей.

Поиск векторов атаки

Я начал с проверки атак, которые были осуществлены на терминалы, путём поиска соответствующих CVE. Это даёт понимание о потенциальном риске и влияет на разработку новых методов.

Стандартный способ доступа к терминалу начинается когда пользователь запускает терминал и подключается к серверу. Поэтому векторы атак, на которых я сосредоточился, были направлены на клиента:
- мы находимся внутри сервера. Создадим вредоносную строку внутри файла, которая использует уязвимость в терминале и при печати которой пользователь непреднамеренно запустит код. Когда пользователь подключится к терминалу и откроет этот файл, он выполнит произвольную команду. Другим результатом может быть удалённое выполнение кода на хосте клиента;
- уязвимость в соединении между терминалом и сервером в конечном итоге позволит запустить код на хосте клиента.

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

Как терминалы могут быть скомпрометированы

Есть интересная статья 2003 года от Digital Defense Incorporated о проблемах безопасности терминальных эмуляторов. В ней представлен хороший обзор проблем с которыми мы сегодня и столкнёмся. Некоторые из этих проблем также описаны в статье A Blast From the Past, поэтому я не буду рассматривать их все - только ту, которую использовал в своём исследовании.

В моём случае я хотел найти проблему в том, как терминал разбирает текст. Это привело меня к изучению управляющих символов ANSI.

Управляющие символы ANSI

Это специальные символы, которые терминал не будет рассматривать как обычный текст. Они будут восприняты как команда. Обычно они начинаются с ASCII-символа ESC (0x1B в шестнадцатеричной системе счисления), а затем следует определённый набор аргументов. Эти управляющие символы могут изменять атрибуты текста (цвета), перемещать позицию курсора, изменять заголовок окна и т.д. Они делятся на категории, которые подробно описаны здесь.

Например, есть категория последовательностей OSC (Operating System Command) с командами, начинающимися с ESC ], за которыми следует набор команд, и заканчивается это всё знаком BEL (Bell 0x7) или ST (String Terminator 0x9C) (Рисунок 2).

Мы можем изменить заголовок окна нашего терминала, напечатав строку \e]0;Заголовок\a.

Рисунок 2 - разбор OSC-последовательности

Заметьте, что это не будет работать в ряде терминалов из-за файла .bashrc, который обновляет заголовок каждый раз, когда вы нажимаете ENTER. Поэтому сначала вам нужно будет отключить его в конфигурационном файле.

Вы можете подумать: "Это всего лишь заголовок; что вы собираетесь сделать, установить мне заголовок?". Что ж, обратите внимание на эти восемь уязвимостей 2003 года (Рисунок 3) для заголовка окна, которые позволяли выполнить код на терминале. Из-за схожести терминалов одна уязвимость могла повлиять на многие из них.

Рисунок 3 - уязвимости в изменении заголовка окна (взято из MITRE)

Уроки прошлого: выполнение кода путём изменения заголовка окна

Я проверил как эксплуатировались предыдущие ошибки. Одна из них, CVE-2015-8971 (найденная Nicolas Braud-Santoni), была ошибкой в Terminology версии 0.7.0, которая не фильтровала символ перехода на новую строку (\n) при изменении заголовка окна. Это позволило изменить заголовок, а затем снова вставить его в буфер ввода, что приводило к выполнению произвольного кода. Вредоносную строку (Рисунок 4) можно было вставить в файл. Когда пользователь открывал его, он загружал эту строку:

\e]2;echo 'evil'\n\a\e]2;?\a

Рисунок 4 - разбор уязвимости выполнения кода в заголовке окна

Когда эта вредоносная строка печатается, echo ‘evil’\n записывается в входной буфер пользовательского терминала, в результате чего эта команда выполняется оболочкой.

От изменения Заголовка окна до DoS

Уязвимости натолкнули меня на несколько идей. Я открыл терминал на удалённом сервере Linux и попробовал несколько странных комбинаций ANSI, нелогичных хаков, рандомный набор символов - что угодно. Но ничего не сработало с заголовком окна. В этот момент я немного приуныл, казалось, что всё что остаётся - это перейти к следующему вектору атаки. Хоть и чувствовал потенциал использования escape-символов. Мне просто нужно было найти способ...

За несколько секунд до блокировки рабочего ПК, я пошёл себе на встречу и написал следующий кусок кода (выражающий моё настроение), который в цикле изменяет заголовок окна:

perl -e 'while(1){print "\e]0;pwn\a"};'

Я сказал терминалу: "Получи это" и уехал на совещание.

Когда вернулся, то увидел нечто странное. Всё было заморожено (кроме мышки, что также известно как "Белый экран смерти" (WSOD). Я не мог работать. Единственный выход - перезагрузить компьютер. Меня заинтересовало, почему изменение заголовка окна терминала влияет на весь компьютер, делая невозможным что-либо сделать.

Анализ SetWindowText

Помните, я работал с PuTTY. Проверив, какая функция используется для изменения заголовка окна, обнаружил что есть функция do_osc (в terminal.c), которая обрабатывает OSC-последовательности и в одном из условий вызывает win_set_title, которая в конечном итоге вызовет wintw_set_title (Рисунок 5).

Рисунок 5 - функция wintw_set_title из файла window.c PuTTY

Видно, что заголовок изменяется макросом SetWindowText (Рисунок 6), который может быть SetWindowTextW или SetWindowTextA:

Рисунок 6 - макрос SetWindowText из WinUser.h

В моём случае PuTTY использовал SetWindowTextA (Рисунок 7).

Рисунок 7 - мониторинг SetWindowTextA с помощью программы для мониторинга API-вызовов

Но такое же поведение было и с SetWindowTextW, поэтому в дальнейшем я буду использовать SetWindowText.

Согласно документации, функция SetWindowText делает следующее:

Изменение заголовка указанного окна (если он есть).

Чтобы было проще понять, как работает SetWindowText, я написал небольшую программу на GUI C++, которая изменяет заголовок:

while (1) {
   SetWindowText(hWnd, L"AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA");
}

Когда я запустил её, компьютер стал работать крайне медленно. Было ощущение что система зависла. Это намного хуже, чем то, что произошло с PuTTY. Когда PuTTY менял название, то это происходило по сети. Поэтому терминал работал немного медленнее, чем моя программа без сетевых накладных расходов. С локальным приложением я сразу получал WSOD и неработоспособность системы. Придётся перезагружать компьютер.

Я продолжал анализировать и записывать трассировку:

Рисунок 8 - трассировка

Трудно сказать какой объект вызывает проблему производительности, потому что эта функция в конечном итоге вызывает win32u.NtUserMessageCall и обращается к ядру:

Рисунок 9 - вызов NtUserMessageCall из IDA

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

Кажется, что выполняется множество действий, которые и приводят к замедлению работы. Мы сообщили об этом в Microsoft. Вы можете увидеть их ответ в разделе "Краткое описание атаки SetWindowText" ниже. TL;DR: Они смогли воспроизвести эту проблему и сообщили о ней как об ошибке своей команде разработчиков.

Мы сообщили об этой проблеме и она была исправлена в версии 0.75, получив CVE-2021-33500. Подробнее об этой ошибке вы можете прочитать в отчёте PuTTY.

Затронутые терминалы и GdiDrawString

Были протестированы все известные терминалы для Windows для проверки - не затронуты ли они этим DoS. Большинство из них уязвимы. Так же было обнаружено, что это происходит не только из-за функции SetWindowText, но и из-за другой похожей функции, ведущей себя аналогичным образом.

В одном из случаев я тестировал терминал MobaXterm и был удивлён тем, что для изменения заголовка окна он использовал не функцию SetWindowText, а функцию GdipDrawString. Интересно то, что в данном случае это не повлияло на всю систему. Это повлияло только на само приложение, завершившееся аварийно.

Рисунок 10 - мониторинг GdiDrawString

GdipDrawString является одной из функций, предоставляемых Windows GDI+ (задокументирована здесь). Похоже, что использование функции при многократной записи текста может вызвать DoS, если это оставить без контроля. Мы сообщили об этом компании MobaXterm и они быстро исправили эту проблему (CVE-2021-28847).

Ещё одно интересное открытие: я не смог вызвать DoS с помощью терминалов Windows по умолчанию (cmd, Powershell, Windows Terminal и WSL). Они используют функцию SetConsoleTitle, которая, по словам Microsoft, больше не является частью их roadmap. Они рекомендовали использовать последовательности виртуальных терминалов для максимальной совместимости в кросс-платформенных сценариях. Это может увеличить поверхность атаки, т.к. требует от программиста убедиться что никто не злоупотребляет этими терминальными последовательностями. Как пример, рассмотрим ситуацию, когда кто-то пишет что-то вроде:

printf("\x1b\x5d\x30\x3b%s\x07", userTitle);

\x1b\x5d\x30\x3b → начало заголовка ESC ] 0 ;.
\x07 → конец заголовка.

Если злоумышленник контролирует userTitle и может вызвать его несколько раз, то это может вызвать DoS.

Вот сводная таблица по терминалам Windows:
...skipped...

Ещё сюрпризы: создание DoS из браузера

Понятно, что корень проблемы лежит в графических функциях, в частности в функции SetWindowText, а не в терминале. Это означает, что если мы можем управлять любым приложением для инициации интенсивного использования SetWindowText (или GdipDrawString), то можем создать и DoS. Последствия этого выходят далеко за пределы терминального мира, как вы увидите далее.

Практически каждое GUI-приложение использует какую-либо функцию типа SetWindowText, но это не значит, что мы можем управлять ею. В каком ещё приложении мы можем управлять заголовком окна пассивно? Вы угадали правильно - это браузеры!

Вектор атаки может заключаться в отправке ссылки на вредоносный сайт, который многократно меняет заголовок окна и вызывает DoS. Некоторые браузеры (как мы увидим дальше) не считают такого рода атаку уязвимостью безопасности. Наверное, это так. Я пытался вызвать зависания, загрузив страницу с кодом JavaScript, хранящим данные для бесконечного количества переменных и это не повлияло на проверенные мной браузеры. Как вы увидите далее, некоторые результаты оказались странными.

Подвешиваем некоторые браузеры

Я начал свою проверку с браузеров Chrome, Edge и Firefox.

Создал простой HTML-файл, меняющий заголовок бесконечное количество раз. В начале Chrome отработал нормально. Причина была в том, что когда я менял заголовок несколько раз с одной и той же строкой, Chrome проверял, а не этот же самый заголовок: если тот же, то функция SetWindowText не будет вызвана. После небольших исправлений каждый раз при изменении заголовка все начинало работать как по маслу:

<script>
function myFunction() { 
  var i = 0;
 
  while(1) {
   if (i % 2 == 0) {
      document.title = "A";
    i = 1;
   } else {
      document.title = "B";
    i = 0;
   }
  }

  var x = document.title;
 
  document.getElementById("demo").innerHTML = x;
}
</script>

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

Рисунок 11 - мониторинг SetWindowTextW

Но обратите внимание: заморозился только браузер, но не компьютер и операционная система. Возможно, это потому, что современные браузеры основаны на Песочнице. Так же интересно то, что эта атака не сработала в Firefox и Internet Explorer. Firefox написал что страница тормозит (Рисунок 12), но вы всё ещё можно работать с другими вкладками.

Рисунок 12 - тормозящая вкладка Firefox

Почему это произошло только в Chrome и Edge, но не в Firefox и Internet Explorer? Общим для Chrome и Edge является то, что они построены на Chromium, но... подождите... если причина в этом, значит ли это, что любой браузер на базе Chromium подвержен этому? Да! Я проверил все браузеры, которые смог найти, все они основаны на Chromium и на всех из них это произошло (см. таблицу 2).
...skipped...

BSOD от браузера

Самое шокирующее, что мне удалось обнаружить - атака SetWindowText на браузеры на базе Chromium не только приводит к зависанию браузера, но и... подождите... вызывает BSOD\WSOD! (Рисунок 13). Это воспроизводится только на виртуальных машинах, так что, похоже, это проблема связанна с ресурсами.

Рисунок 13 - BSOD после DoS браузера

Оказалось, что после того, как браузер начинает менять заголовок несколько раз, а вы увеличиваете и уменьшаете окно, виртуальная машина начинает зависать и через пару минут происходит BSOD. Я смог воспроизвести это во всех браузерах на базе Chromium. Воспроизведение было не совсем тривиальным; в ходе первой попытки мне потребовалось два отдельных окна, но если я задействовал одно окно с моим локальным приложением (то, которое запускало SetWindowText несколько раз), то проблема воспроизводилась. Странно, что мне не удалось воспроизвести её просто запустив локальное приложение - похоже, браузер делал что-то ещё, что влияло на виртуальную машину.

Don’t Trust This Title: Abusing Terminal Emulators with ANSI Escape Characters

Другие приложения тоже могут быть подвержены этому

Выяснилось, что абуз заголовка окна в терминалах и браузерах может привести к серьезному DoS и может быть использован в качестве удалённой атаки. Есть ли другие приложения, которые могут быть уязвимы? Да, в каждом приложении, в котором можно управлять изменением текста, рано или поздно будет вызван SetWindowText или GdipDrawString, что может привести к повреждению.

Подумайте о приложениях для обмена сообщениями (Slack, Teams, Skype и т. д.). Что произойдёт, если один из ваших контактов изменит своё имя? Он может вызвать функцию SetWindowText несколько раз и, теоретически, получить DoS для любого кто находится в его списке контактов.

Проверка теории на практике

Мне стало любопытно, возможно ли это в той или иной мере. Я решил проверить это на Slack'е.

Первым делом проверил что произойдёт, если я изменю своё имя на компьютере. Увидит ли Slack на моём компьютере с контактами это изменение сразу и вызовет SetWindowText? Ниже (Рисунок 14) показано, что да!

Рисунок 14 - мониторим Slack

Отлично! Всё, что нам нужно сделать - это много раз менять мой профиль Slack, пока он не вызовет DoS у моего контакта (или контактов, если у вас нет совести).

Немного обратной разработки (есть также документации) и я нашёл REST API, который изменяет настройки профиля: ../api/users.profile.set.

Но всего лишь после трёх попыток он потерпел неудачу из-за ограничения скорости (Рисунок 15).

Рисунок 15 - ограничения Slack

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

Резюмируем по SetWindowText

Обширное использование этой функции, похоже, имеет потенциал для DoS. Возможно, существуют и другие функции, которыми можно управлять подобным образом. В нашем случае атака SetWindowText смогла вызвать DoS для удалённого сервера.

Основная проблема заключается в этой функции. Я проверял её на Windows 7 и там не было такой проблемы.

Группа безопасности из Vivaldi Technologies написала мне следующее:

Это конструктивное ограничение Windows 10; оно не ограничивает использование памяти приложением и просто использует файл подкачки, когда ему не хватает ОЗУ. Это медленно, потому что должно быть прочитано с диска.

Я также уведомил об этом Microsoft, и они ответили:

Ещё раз благодарим вас за сообщение. Наша команда смогла воспроизвести эту проблему, но она не соответствует нашей планке для обслуживания с немедленным обновлением безопасности. Хотя это и приводит к DoS, но оно может быть вызвано только локально и является результатом исчерпания ресурсов. Злоумышленник не сможет вызвать дополнительные уязвимые условия или получить информацию, которая могла бы быть полезной при других атаках на систему.
Мы закрываем этот кейс, но мы отправили замечание об ошибке нашей команде разработчиков и они могут рассмотреть возможность устранения этой проблемы в следующих версиях Windows.

Важно отметить, что хотя Microsoft и пишет, что ошибка срабатывает локально, но она может быть выполнена и удалённо - в зависимости от использования в программе. Например, можно создать вредоносный файл на удалённом сервере с командой изменения заголовка окна, который при открытии из терминала вызовет отказ в обслуживании. Я же сообщил об этом разработчикам эмуляторов терминалов, которые исправили эту ошибку.

Давайте продолжим и посмотрим, что ещё можно сделать с помощью управляющих символов ANSI.

Подмена данных на Kubernetes и OpenShift

Помните проблему escape-символов ANSI, о которой я упоминал в начале статьи об OpenShift? Я заметил кое-что странное, когда создавал проекты. У меня как у обычного пользователя была возможность создать проект с полем «Отображаемое имя» (рис. 16). Это поле не фильтрует символы!

Рисунок 16 - создание проекта в OpenShift

Я могу добавить управляющие символы ANSI, которые изменят заголовок окна терминала, раскрасить терминал в любой цвет который выберу, удалить этот дисплей и так далее.

Когда пользователь подключится к терминалу и выполнит команду oc get projects - это вызовет ввод управляющих символов ANSI. Я показал в PoC как я могу подделать данные проекта и ввести нужные мне данные.

Don’t Trust This Title: Abusing Terminal Emulators with ANSI Escape Characters

О данной уязвимости было сообщено в компанию Red Hat. Они подтвердили наличие этой уязвимости, а также упомянули (благодаря Sam Fowler и команде), что существует более серьезное последствие:

Все не занятые текстовые поля (а их много) в OpenShift и Kubernetes API подвержены этому, не только Project `displayNames`. Например, это влияет на поле `message` события (основной объект k8s). Те, кто может создавать события, также могут вводить командные последовательности, которые не имеют кодировки при печати в эмуляторе терминала с помощью `oc` или `kubectl`.

Мы проверили и убедились, что это происходит и в Kubernetes, и предложили сообщить об этом в апстрим (Kubernetes). Проблема связана с фильтрацией объектов JSON. Этого не происходит при попытке создать такой запрос с объектами YAML, потому что kubectl отбрасывает их из-за недопустимых символов. Мы сообщили об этом в Kubernetes, и их команда безопасности попросила открыть это как публичную ошибку:

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

Они также отметили, что "пока будут рассматривать этот баг как обычный (не связанный с безопасностью)".

Я открыл публичный тикет, и вот пример PoC для подделки данных в Kubernetes Event.

Don’t Trust This Title: Abusing Terminal Emulators with ANSI Escape Characters

Через несколько дней после сообщения об этом разработчик Kubernetes Paco Xu упомянул, что оно также влияет на kubectl log. 19.11.2021 они присвоили ему номер CVE-2021-25743.

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

Обход вставки скобок

Одним из малоизвестных механизмов является режим вставки скобок (ещё одно хорошее объяснение), который был создан для защиты от вставляемого текста. При копировании команды типа echo 'Hello' и вставке её в терминал, он выполнит команду. Если включен режим вставки скобок, код не запустится. Скорее, он будет заключён в ESC [ 200 ~ и в ESC [ 201 ~. Ваш код будет выглядеть так: ESC[200~<code>ESC[201~. Код не будет выполнен при вставке его в терминал.

Зачем это нужно? Из-за атак copy\paste. Эти атаки показывают вам легитимную команду для копирования, в то время как некоторые трюки HTML скрывают вредоносную команду. Есть замечательное описание на этом сайте.

Чтобы включить режим вставки скобок, вы можете выполнить в терминале: echo -ne "\e[?2004h"
Чтобы отключить - echo -ne "\e[?2004l"

Когда я увидел это, мне стало интересно: "А что, если мой код будет начинаться с ESC [ 200 ~, а затем другой вредоносный код?". Мой код будет выглядеть так (обратите внимание, что в нём две строки; вторая строка - это новая строка):

ESC[201~clear; echo "Bypass Bracketed Paste Mode"

Скобки преобразуются в:

ESC[200~ESC[201~clear; echo "Bypass Bracketed Paste Mode"ESC[201~

Здесь она будет закрыта в начале и позволит нашей команде выйти из режима вставки скобок. Когда кто-то вставит её, она выйдет и запустит команду в терминале:

Don’t Trust This Title: Abusing Terminal Emulators with ANSI Escape Characters

Обнаружены три терминала, подверженные этой уязвимости: MinTTY (CVE-2021-31701), Xshell (CVE-2021-37326) и ZOC (CVE-2021-40147). Они уже исправлены. Обратите внимание, что Git-Bash для Windows и Cygwin также были уязвимы, поскольку они используют MinTTY.
...skipped...

Меры

Запрет SetWindowText

Почти все терминалы, подверженные уязвимости SetWindowText, уже исправили данную ошибку. Но её можно предотвратить, настроив терминал таким образом, чтобы пользователь не мог изменить заголовок окна. В каждом терминале эта настройка может выглядеть по-разному.

В PuTTY вы можете предотвратить это, установив флажок "Disable remote-controlled window title changing" (Рисунок 17).

Рисунок 17 - запрет удалённой сессии изменять заголовок окна

В MobaXterm вы можете запретить это, щёлкнув ПКМ на сеансе и выбрав "Редактировать сеанс". В разделе "Настройка закладок" установите флажок "Блокировать заголовок терминала" (Рисунок 18).

Рисунок 18 - запрет изменения заголовка

Не во всех терминалах имеется подобная опция.

Предотвращение режима вставки скобок

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

Итог

В этой статье мы познакомились с управляющими символами ANSI. Узнали, что они используются не только для цветов, но и для команд. Узнали как изменение заголовка окна оказывает серьёзное влияние на всю операционную систему.

Мы проверили не только это, но и вставку скобок - то, что менее известно - также нашли уязвимость.

Есть ещё много вещей, которые предстоит обнаружить. Например, соединение между клиентом и сервером, другие сложные управляющие ANSI-последовательности и так далее. Мы призываем вас использовать предложенные нами меры по снижению уязвимости, чтобы уменьшить площадь атак.



---
Оригинал статьи: https://www.cyberark.com/resources/...erminal-emulators-with-ansi-escape-characters
Переведено специально для xss.pro.

От себя: Eviatar Gerzi, моё почтение! Видит б-г, в начале декабря 2021 года я хотел копнуть эту тему поглубже, что последовательности можно использовать не только для изменения цветов в логе. Ты успел первым