Насколько безопасный это - кошке произвольный файл?

Нет никакого механизма для использования аргументов в тексте замены, как в csh. Если аргументы необходимы, функция оболочки должна использоваться. См. Справочник Bash:: 6.6 Псевдонимы

78
27.04.2013, 02:40
7 ответов

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

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

Но всегда существуют (как Hauke, таким образом, законно отметил 'braindead'), люди, готовые добавлять такую опцию, если это решает проблему для них, не понимая лазейку они создают. По моему опыту, с программным обеспечением с открытым исходным кодом то, что, из-за многих глаз, смотрящих на код, это, менее вероятно, произойдет как с закрытым исходным кодом. (Я помню, что в почтовой программе на Irix Grahpics Кремния, в середине девяностых, Вы могли включать команды, которые будут выполняться на машине получателей, реальных путях к исполняемым файлам....),

34
27.01.2020, 19:30
  • 1
    "Вы могли включать команды, которые будут выполняться на машине получателей", Вы имеете в виду что-то как включение в почтовый VBScript, который обращается к Windows Scripting Host? :) –  a CVn 26.04.2013, 10:46
  • 2
    No точно, Вы могли запустить исполняемый файл, который уже был на машине, как проигрывание звука. Я не вспоминаю точный синтаксис (который был почти 20 лет назад), ни могли ли Вы переключить ту 'функцию' прочь в установку. У нас была некоторая забава хотя с автоматическим воспроизведением видео, сохраненных в нашей сети. –  Anthon 26.04.2013, 10:54
  • 3
    Вы не говорите о NeWS, Вы? IIRC SGI был одним из последних несогласных. –  luser droog 26.04.2013, 11:55
  • 4
    @luserdroog No это был стандартной основанной на GUI почтовой программой под Irix –  Anthon 26.04.2013, 12:00
  • 5
    @Anthon, я не уверен, возможно ли это все еще, но возможность использования управляющих кодов, чтобы заставить терминал "повторять" текст, прибывающий в него от write команда - таким образом выполняющиеся команды/сценарии как пользователь, владеющий терминалом. Это - предположительно, причина, почему многие рекомендуют выключить сообщения mesg -n для пользователей большую часть времени, и для root всегда. AFAIK, это было на самом деле сделано - хотя я не знаю, использовался ли он когда-нибудь. Так случайный текст от a catворошите исполняемый файл, мог, возможно, быть выполнен. –  Baard Kopperud 26.04.2013, 12:29

Большинство эмуляторов терминала передаст некоторый ответ обратно, если они получат определенные escape-последовательности (взгляните на xterm документацию управляющих последовательностей). Например, можно отправить \e[0c к подобному VT100 эмулятору и это передаст обратно атрибуты устройств, что-то как \e[?1;2c (Это, вероятно, что наблюдал Keith.), Но эти ответы не являются произвольными строками. Однако, называя исполняемый файл 2c где-нибудь в Вашей системе, которая делает что-то фатальное, плохая идея.

Обновление: риски на самом деле больше, чем я думал, из-за возможности установить заголовок xterm окна и передать заголовок обратно с помощью соответствующих escape-последовательностей (http://www.securityfocus.com/bid/6940/). В отличие от примера выше, заголовок может быть почти произвольной строкой.

34
27.01.2020, 19:30
  • 1
    Это уже сокращает его очень близко. –  Gunchars 26.04.2013, 10:32
  • 2
    Существует еще более старая функция - 'сообщение ответа', отправлена в ответ на ENQ (C-e) символ. На реальном VT100 это установлено пользователем в Установочном меню терминала; возможно, существуют эмуляторы терминала, которые позволяют устанавливать его удаленно... –  sendmoreinfo 02.05.2013, 12:18

Я определенно испытал xterm вставка произвольных символов в себя, как будто я ввел их. И при случае это, по-видимому, включало символ новой строки, так, чтобы я добрался ngwerm:0riu: command not found как ответ. Я не вижу оснований, почему кто-то не мог обработать файл, который отправит определенные, вредные команды. Таким образом да, по крайней мере некоторые терминалы восприимчивы к нападениям с произвольным влиянием.

7
27.01.2020, 19:30

Это изменяет терминальный заголовок в Терминале 3.6.1 GNOME, если не переопределено чем-то как PS1:

printf "\033]2;Script Kiddie was here\007"

Теперь откройте новое Окно терминала GNOME для тестирования cat версия:

printf "\033]2;Script Kiddie was here\007" > test.bin
cat test.bin

Да, это также устанавливает терминальный заголовок.

Раньше была проблема безопасности с управляющим кодом, приводящим к заголовку, распечатанному к командной строке, таким образом, Вы могли эффективно создать файл, который когда catредактор распечатал бы (я не уверен, могли ли Вы поместить новую строку там), произвольные команды. Ай!

17
27.01.2020, 19:30

Ну, эмулятор терминала в основном просто распечатывает символы, отправленные в него.

Что-либо помимо простой печати символа на текущей позиции, как установка нового положения, изменение цвета, изменение заголовка, и т.д., сделано escape-последовательностями.

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

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

2
27.01.2020, 19:30

В целом обычно нет никакого риска для catting произвольного файла. Мой обычный метод для анализа файла должен сделать следующее:

$ file <mystery file>
$ strings <mystery file> | less

Вышеупомянутое позволяет мне определять тип файла через file команда и strings команда позволяет мне выводить любые идентифицируемые строки от потенциальных двоичных файлов что я "m не уверенный в их происхождении.

пример

файл производится
$ file /bin/ls
/bin/ls: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, stripped
строки производятся
$ strings /bin/ls|less
...
across
vertical
single-column
force
never
auto
if-tty
slash
%b %e  %Y
%b %e %H:%M
long-iso
main
posix-
sort_files
?pcdb-lswd
dev_ino_pop
Try `%s --help' for more information.
Usage: %s [OPTION]... [FILE]...
List information about the FILEs (the current directory by default).
Sort entries alphabetically if none of -cftuvSUX nor --sort.
Mandatory arguments to long options are mandatory for short options too.
  -a, --all                  do not ignore entries starting with .
  -A, --almost-all           do not list implied . and ..
...
0
27.01.2020, 19:30
  • 1
    на неизвестном файле могут также иметь проблематичные последствия. lcamtuf.blogspot.fi/2014/10 / … –  Jan Wikholm 26.10.2014, 12:43
  • 2
    @IncnisMrsi - читают первое предложение!!!! –  slm♦ 18.09.2015, 06:54
  • 3
    OK, отрекаясь от моего предыдущего оператора, ответ короток, с помощью запутывающей терминологии, необоснованной, и очевидно неполной. Обратите внимание на это в безопасности, “произвольной” ≠ случайный, как распределено в Вашей любимой ОС. –  Incnis Mrsi 18.09.2015, 13:13

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

Вот пример, управляют, чтобы можно было работать, который создаст "злонамеренный" сценарий оболочки:

echo -e '#!/bin/sh\necho "...doing something bad here..."\nexit\n\033[A\033[Aecho "Hello dear reader, I am just a harmless script, safe to run me!"' > demo.sh
chmod a+x demo.sh

При осмотре файла это кажется достаточно безопасным:

$ cat demo.sh
#!/bin/sh
echo "Hello dear reader, I am just a harmless script, safe to run me!"

Но если Вы на самом деле выполняете его...

$ ./demo.sh 
...doing something bad here...

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

Почти любая другая программа покажет сценарий для того, каково это. Только программы, которые не обрабатывают содержание файла (как cat, more и less -r) произведет вводящий в заблуждение вывод.

Отметьте это tail и head также произведите тот же вводящий в заблуждение вывод. Используя "меньшее количество +F" поэтому более безопасно, чем "хвост-f".

9
27.01.2020, 19:30
  • 1
    Это довольно проблематично... Вы видите то, что на самом деле продолжается путем выполнения echo $(cat demo.sh), cat demo.sh | grep . --color=yes (Примечание: --color=yes то, что показывает "злонамеренный" код здесь), или сборка - в cat -v demo.sh. –  Charlie 25.04.2015, 01:02
  • 2
    TRUE или FALSE, это - ответ для другого вопроса: насколько защищенный cat в отображении содержания файла. –  Incnis Mrsi 18.09.2015, 00:37
  • 3
    @IncnisMrsi: это не действительно ответ для другого вопроса. Этот ответ предупреждает, что кошка покажет управляющие коды и предоставляет простому примеру только один тип управляющего кода, но существуют многие другие. В сочетании с определенными терминалами они могут повторно отобразить ключи, файлы перезаписи и в теории, даже выполнить команды. Таким образом, после того как Вы понимаете опасность отобразить управляющие коды, Вы поймете, что может иногда быть небезопасно cat произвольный файл, как вопрос, который задают! –  Malvineous 19.09.2015, 02:22

Теги

Похожие вопросы