Можно ли вызвать бесконечный цикл интерпретатора?
Это безопасно, если у вас правильно настроено ядро (безопасно, потому что оно не будет работать)
На странице руководства память (4):
/dev/mem is a character device file that is an image of the main memory of the computer. It may be used, for example, to examine (and even patch) the system.
Таким образом, теоретически dd if=/dev/urandom of=/dev/memдолжно перезаписать все адресное пространство физической памяти, которую вы установили, и, поскольку ядро и другие программы запускаются из памяти, это должно привести к краху системы. На практике есть предел. С той же справочной страницы:
Since Linux 2.6.26, and depending on the architecture, the CONFIG_STRICT_DEVMEM kernel configuration option limits the areas which can be accessed through this file.
Попытка сделать это на виртуальной машине Ubuntu 18.04 возвращает ошибку dd: writing to '/dev/mem': Operation not permittedдаже с sudoи несмотря на права root crw-r-----. Из Ubuntu Wiki:
/dev/mem protection
Some applications (Xorg) need direct access to the physical memory from user-space. The special file /dev/mem exists to provide this access. In the past, it was possible to view and change kernel memory from this file if an attacker had root access. The CONFIG_STRICT_DEVMEM kernel option was introduced to block non-device memory access (originally named CONFIG_NONPROMISC_DEVMEM).
Так что технически это небезопасно (, так как это приведет к сбою системы )и если опция ядра CONFIG_STRICT_DEVMEMотключена, это дыра в безопасности, но из того, что я вижу на данный момент, команда не запустится. если эта опция включена. Согласно перекрестному -дубликату сайта , перезагрузка устранит любые проблемы с ним, но, конечно, данные в ОЗУ в это время будут потеряны и не сброшены на диск (, если потребуется ).
Существует рекомендуемый метод для дубликата, связанного ранее с использованием busybox devmem, поэтому, если вы полны решимости возиться с оперативной памятью, в конце концов, может быть способ.
В Linux я получаю следующее:
Скрипт с несуществующим интерпретатором строки hashbang(execve()даетENOEXEC):
$ cat brokenhashbang.sh
#!/bin/nonexisting
echo hello
$./brokenhashbang.sh
bash:./brokenhashbang.sh: /bin/nonexisting: bad interpreter: No such file or directory
Скрипт с рекурсивным хеш-бангом(ELOOP):
$ cat /tmp/recursivehashbang.sh
#!/tmp/recursivehashbang.sh
echo hello
$ /tmp/recursivehashbang.sh
bash: /tmp/recursivehashbang.sh: /tmp/recursivehashbang.sh: bad interpreter: Too many levels of symbolic links
Сценарий с существующим, но не -исполняемым интерпретатором(EACCESS):
$ cat noexechashbang.sh
#!/etc/passwd
echo "hello?"
$./noexechashbang.sh
bash:./noexechashbang.sh: /etc/passwd: bad interpreter: Permission denied
Это не только Bash. :Dash, ksh и zsh дают аналогичные ошибки.
Если в скрипте нет хэш-банга или хэш-банг указывает на исполняемый файл (, не являющийся другим -, который должен иметь +x, вы получаете ENOEXEC), тогда поведение немного отличается. Bash запускает сам файл как сценарий оболочки, в то время как zsh, кажется, заглядывает внутрь, чтобы увидеть, есть ли строка hashbang, а затем либо пытается запустить этот интерпретатор, либо запускает его с помощью /bin/sh. Запуск скрипта через оболочку в ENOEXEC является POSIX -определенным поведением для оболочки и для функций execlp()/ execvp().
(В случае с несуществующим интерпретатором Dash просто приводит в замешательство dash: 1:./brokenhashbang.sh: not found, как будто самого скрипта не существовало. Но я думаю, что это та же самая ошибка из базового системного вызова, и Dash слишком прост, чтобы проверить, какой файл отсутствует.)
В любом случае, я не вижу, какая здесь будет атака, поскольку, если они запускают команду по вашему выбору, вы уже можете делать все, что захотите. Не наличием несуществующего интерпретатора скрипта, а работающего.
ПРИМЕЧАНИЕ. Следующее проверено на macOS Big Sur 11.5.2.
В соответствии со стандартом (, а также существующей практикой ), оболочка попытается интерпретировать файл и выполнить содержащиеся в нем команды, если вызов функции execзавершается с ошибкой.
Вот третий вектор атаки:
#!/usr/local/bin/recurse
eval 'printf "%s\n" xxx'
После присвоения этому файлу имени /usr/local/bin/recurseи его выполнения на стандартный вывод выводилась строка xxx.несмотря на то, что цикл интерпретатора должен предотвращать оценку команды.
Если для вызова сценария с помощью функции execvиспользуется программа на C, значение errno, установленное вызовом функции, равно ENOEXEC.