Предполагая, что вам не нужно рассматривать сам протокол rsync
, это зависит от опций компиляции, используемых для вашей версии rsync
.
Раньше rsync
по умолчанию использовал протокол rsh
(если не было изменено значение по умолчанию во время сборки), но в 2004 году значение по умолчанию во время сборки изменилось на ssh
.
Если вы сомневаетесь, запустите процесс rsync
, передающий относительно большой файл (или коллекцию файлов), и в другом терминале выполните ps -ef | grep [r]sync
. Это покажет вам, используете ли вы ssh
для передачи данных или нет. Вот пример с одного из моих серверов, который четко показывает транспорт ssh
:
root 28057 27173 1 09:48 pts/4 00:00:00 rsync -avHP --dry-run /home roaima@otherserver:
root 28058 28057 0 09:48 pts/4 00:00:00 ssh -l roaima otherserver rsync --server -vnlHogDtpre.iLsfx --partial . .
Наконец, помните, что значение по умолчанию компиляции можно отменить с помощью переменной окружения RSYNC_RSH
. (Подробности см. на странице руководства)
Краткий ответ: Во многих ситуациях Vim уязвим для такого рода атак (при вставке текста в режиме вставки) .
Используя связанную статью в качестве отправной точки, я смог быстро создать веб-страницу со следующим кодом, используя элементы диапазона HTML и CSS, чтобы скрыть среднюю часть текста так, чтобы только ls -la
виден обычному зрителю (не просматривая источник). Примечание: ^ [
- это escape-символ, а ^ M
- это символ возврата каретки. Stack Exchange очищает вводимые пользователем данные и защищает от сокрытия содержимого с помощью CSS, поэтому я загрузил подтверждение концепции .
ls ^[:echom "This could be a silent command."^Mi -la
Если вы были в режиме вставки и вставили этот текст в терминал Vim (с некоторыми квалификаторами, см. Ниже), вы бы увидели ls -la
, но если вы запустите команду : messages
, вы можете увидеть результаты скрытой команды Vim.
Для защиты от этой атаки лучше всего оставаться в нормальном режиме и вставлять, используя "* p
или " + p
. В обычном режиме, когда p выводит текст из регистра, вставляется полный текст (включая скрытую часть).Этого не происходит в режиме вставки (даже если установлен параметр : set paste
).
Последние версии Vim поддерживают режим вставки в квадратных скобках , который смягчает этот тип атаки копирования-вставки. Сато Кацура пояснил, что «поддержка вставки в скобках появилась в Vim 8.0.210, а в последний раз была исправлена в версии 8.0.303 (выпущенной 2 февраля 2017 года)».
Примечание. Насколько я понимаю, версии Vim с поддержкой режима вставки в скобках должны защищать вас при вставке с использованием Ctrl - Shift - V (большинство окружений рабочего стола GNU / Linux), Ctrl - V (MS Windows), Command - V (Mac OS X), Shift - Вставьте или средний щелчок мыши.
Позже я провел некоторое тестирование на настольном компьютере с Lubuntu 16.04, но мои результаты были запутанными и неубедительными. С тех пор я понял, что это потому, что я всегда использую экран GNU , но оказывается, что экран фильтрует escape-последовательность, используемую для включения / выключения режима вставки в скобках (есть патч , но похоже, что он был отправлен в то время, когда проект активно не поддерживался). В моем тестировании доказательство концепции всегда работает при запуске Vim через экран GNU, независимо от того, поддерживает ли Vim или эмулятор терминала режим вставки в скобках.
Дальнейшее тестирование было бы полезно, но до сих пор я обнаружил, что поддержка режима вставки в скобках эмулятором терминала блокирует мое Доказательство концепции - до тех пор, пока экран GNU не блокирует соответствующие escape-последовательности. Однако пользователь nneonneo сообщает , что для выхода из режима вставки в скобки можно использовать тщательную обработку управляющих последовательностей.
Обратите внимание, что даже с последней версией Vim Proof of Concept всегда работает, если пользователь вставляет данные из регистра *
в режиме вставки, набрав ( Ctrl ] - R * ). Это также относится к GVim, который может различать типизированный и вставленный ввод. В этом случае Vim предоставляет пользователю возможность доверять содержимому их регистров. Так что никогда не используйте этот метод при вставке из ненадежного источника (я часто это делаю, но теперь я начал приучать себя не делать этого).
Используйте обычный режим при вставке текста (из регистров +
или *
).
… или используйте Emacs. Я слышал, это приличная операционная система. :)
Если вы используете функцию буфера обмена X11 или аналог -для конкретной платформы и используете вставку средней кнопкой -с включенной поддержкой мыши или команду вставки vim, а не какую-либо команду вставки из терминала (, сдвиг -средняя кнопка -или любые сочетания клавиш, предлагаемые терминалом ), тогда вы можете быть в безопасности.
Если нет, то если у вас есть эмулятор терминала, который поддерживает режим вставки в квадратных скобках -, и вы включили его в своем терминале и в vim, и этот эмулятор терминала реализует защиту от внедрения управляющей последовательности, которая заканчивается режим вставки в квадратных скобках -, тогда вы можете быть в безопасности.
Если нет, то вы можете быть уязвимы для атаки, описанной здесь .