От Классика Shell, Пишущий сценарий книги:
Сценарии оболочки обычно запускаются с
#! /bin/sh
. Используйте путь к совместимой POSIX оболочке если Ваш/bin/sh
не совместимый POSIX. Существуют также некоторые "глюки" низкого уровня, чтобы не упустить:
- Необходимо знать, что полный путь к интерпретатору выполняется. Это может предотвратить мобильность перекрестного поставщика, так как различные поставщики помещают вещи в различные места (например,
/bin/awk
по сравнению с/usr/bin/awk
).
Это не дефект безопасности; Вы можете к strace процесс, потому что это - Ваш процесс. Вы не можете просто присоединить strace
к любому рабочему процессу. Например:
$ sudo sleep 30 &
[1] 3660
$ strace -p 3660
attach: ptrace(PTRACE_ATTACH, ...): Operation not permitted
su
сообщает неправильный пароль, потому что он не имеет достаточных полномочий читать /etc/shadow
больше. /etc/shadow
то, где Ваш хэш пароля хранится, и он установлен поэтому, только корень может считать его из соображений безопасности. su
имеет setuid набор битов, таким образом, он будет эффективно выполнен как корень, неважно, кто выполняет его, но когда Вы прокручиваете его strace
это не работает, таким образом, это заканчивает тем, что работало в соответствии с Вашей учетной записью
Я не уверен, под чем Вы подразумеваете, "сколько ущерба могло быть нанесено". Как Вы видели, su
не работает из strace
, таким образом, Вы собираетесь представить его нефункциональный. Если бы Вы имеете в виду, "мог кто-то использовать это для кражи моего пароля", им была бы нужна способность установить псевдонимы в оболочке, которую у них не должно быть разрешения сделать, если Вы не сделали свои файлы входа в систему мировыми перезаписываемыми или что-то подобное. Если бы у них действительно было разрешение установить псевдонимы, то они могли бы просто исказить su
к исправленной версии, которая записывает Ваш пароль непосредственно; нет ничего специального о strace
Я верю причине, Вы видите, что это вызвано тем, что необходимо войти su
и ssh
пароли в простом тексте до них хешируемый и обработанный. Когда Вы работаете strace
, Вы берете все системные вызовы, и это ловит незашифрованный пароль до него хешируемый и обработанный. Просто, потому что терминал не показывает, что текст не означает, что Вы не вводите простой текст.
http://blog.vpetkov.net/2013/01/29/sniffing-ssh-password-from-the-server-side/ предполагает, что существует возможная проблема защиты в том, что, если у взломщиков есть полномочия пользователя root на сервере, работающем openssh, они могли бы собрать пароли людей кто ssh к серверу путем выполнения strace
на "сетевом" процессе:
ps aux | grep ssh | grep net | awk {‘ print $2′} | xargs -L1 strace -e write -p
...
Process 17681 attached – interrupt to quit
write(4, “\0\0\0 \v”, 5) = 5
write(4, “\0\0\0\33thisismysupersecretpassword“, 31) = 31
write(3, “\345+\275\373q:J\254\343\300\30I\216$\260y\276\302\353″…, 64) = 64
Process 17681 detached
strace
наименьшее количество Ваших проблем.
– Bananguin
06.06.2016, 10:30
Хотя это можно сделать только с правами суперпользователя, но это все еще очень опасно: вы используете ssh с этой машины для доступа к другим критически важным машинам, а затем злоумышленник с привилегиями суперпользователя крадет ваш пароль или передает фраза без вашего ведома.