"Запустити будь-яку команду, яка передасть недовірені дані командам, які інтерпретують аргументи як команди"

З посібника з findutils:

Наприклад такі конструкції, як ці дві команди

# risky
find -exec sh -c "something {}" \;
find -execdir sh -c "something {}" \;

дуже небезпечні. Причиною цього є те, що "{}" розширено на ім'я файлу, яке може містити крапку з комою або інші символи, спеціальні для оболонки. Якщо, наприклад, хтось створює файл, /tmp/foo; rm -rf $HOMEто дві вищевказані команди можуть видалити чиїсь домашні каталоги.

Тому з цієї причини не запускайте жодної команди, яка передасть недовірені дані (наприклад, імена fi les) командам, які інтерпретують аргументи як команди, які слід далі інтерпретувати (наприклад, "sh").

Що стосується оболонки, то для цієї проблеми є розумне рішення:

# safer
find -exec sh -c 'something "$@"' sh {} \;
find -execdir sh -c 'something "$@"' sh {} \;

Цей підхід не гарантується, щоб уникнути кожної проблеми, але він набагато безпечніший, ніж заміщення даних вибору зловмисника в текст команди оболонки.

1. Чи є причиною проблеми в find -exec sh -c "something {}" \;тому, що заміна на {}не цитується і тому не трактується як одна рядок?

2. У рішенні find -exec sh -c 'something "$@"' sh {} \;,

   • спочатку {}замінюється, але оскільки {}це не цитується, чи не "$@"виникає така ж проблема, як оригінальна команда? Наприклад, "$@"буде розширена "/tmp/foo;", "rm", "-rf"і "$HOME"?

   • чому {}не уникнути і не цитувати?

3. Чи можете ви навести інші приклади (як і раніше sh -c, або без цього, якщо це застосовується; з чи без findцього, можливо, не потрібно), коли застосовуються однакові проблеми та рішення, і які є мінімальними прикладами, щоб ми могли зосередити увагу на проблемі та вирішенні якомога менше відволікання? Див. Розділи Способи надання аргументів команді, виконаній `bash -c`

Спасибі.

Це насправді не пов’язано з цитуванням, а скоріше з обробкою аргументів.

Розглянемо ризикований приклад:

find -exec sh -c "something {}" \;

• Це обробляється інтерпретатором, і розбитий на шість слів: find, -exec, sh, -c, something {}(без лапок більше), ;. Нема чого розширювати. Оболонка працює findз цими шістьма словами як аргументи.

• Коли findщо - то знаходить в процесі, скажімо foo; rm -rf $HOME, він замінює {}з foo; rm -rf $HOME, і працює shз аргументами sh, -cі something foo; rm -rf $HOME.

• shтепер бачить -c, і в результаті аналізує something foo; rm -rf $HOME( перший аргумент, що не є варіантом ) та виконує результат.

Тепер розглянемо більш безпечний варіант:

find -exec sh -c 'something "$@"' sh {} \;

• Оболонка працює findз аргументами find, -exec, sh, -c, something "$@", sh, {}, ;.

• Тепер , коли findзнахідки foo; rm -rf $HOME, він замінює {}знову, і працює shз аргументами sh, -c, something "$@", sh, foo; rm -rf $HOME.

• shбачить -c, і аналізує , something "$@"як команду для запуску, а також shі foo; rm -rf $HOMEяк позиційні параметри ( починаючи з$0 ), розширюється "$@"до foo; rm -rf $HOME як одне значення , і працює somethingз одним аргументом foo; rm -rf $HOME.

Ви можете побачити це за допомогою printf. Створіть новий каталог, введіть його та запустіть

touch "hello; echo pwned"

Перший варіант працює наступним чином

find -exec sh -c "printf \"Argument: %s\n\" {}" \;

виробляє

Argument: .
Argument: ./hello
pwned

тоді як другий варіант працює як

find -exec sh -c 'printf "Argument: %s\n" "$@"' sh {} \;

виробляє

Argument: .
Argument: ./hello; echo pwned

Частина 1:

find просто використовує заміну тексту.

Так, якщо ви зробили це без котирування, ось так:

find . -type f -exec sh -c "echo {}" \;

і зловмисник зміг створити файл, який називається ; echo owned, тоді він буде виконаний

sh -c "echo ; echo owned"

що призвело б до оболонки працює echoтоді echo owned.

Але якщо ви додали котирування, зловмисник може просто закінчити ваші котирування, а потім поставити після нього зловмисну ​​команду, створивши файл під назвою '; echo owned:

find . -type f -exec sh -c "echo '{}'" \;

що призведе в управлінні оболонки echo '', echo owned.

(якщо ви поміняли подвійні лапки на одиничні лапки, зловмисник також може використати інший тип лапок.)

Частина 2:

У find -exec sh -c 'something "$@"' sh {} \;, команда {}спочатку не інтерпретується оболонкою, вона виконується безпосередньо execve, тому додавання цитат оболонок не допоможе.

find -exec sh -c 'something "$@"' sh "{}" \;

не має ефекту, оскільки оболонка знімає подвійні лапки перед запуском find.

find -exec sh -c 'something "$@"' sh "'{}'" \;

додає лапки, що оболонка не обробляє спеціально, тому в більшості випадків це просто означає, що команда не буде робити те, що ви хочете.

Маючи це розширюватися /tmp/foo;, rm, -rf, $HOMEне повинно бути проблемою, тому що ті аргументи something, і , somethingймовірно , не відноситься до його аргументи як команди для виконання.

Частина 3:

Я припускаю, що подібні міркування застосовуються до всього, що приймає ненадійний вхід і виконує його як (частину) команди, наприклад xargsі parallel.

1. Чи є причина проблеми в find -exec sh -c "something {}" \;тому, що заміна на {}не цитується і тому не трактується як одна рядок?

У певному сенсі, але цитування тут не може допомогти . Ім'я файла, яке замінюється замість, {}може містити будь-які символи, включаючи лапки . Яка б форма котирування не використовувалася, ім'я файлу могло б містити те саме і "вибиватися" з лапок.

2. ... але оскільки {}це не цитується, чи не "$@"виникає така ж проблема, як у вихідній команді? Наприклад, "$@"буде розширено до "/tmp/foo;", "rm", "-rf", and "$HOME"?

№ "$@"розширюється на позиційні параметри, як окремі слова, і не розділяє їх далі. Тут {}є findсамим аргументом і findпередає поточне ім'я файлу також як окремий аргумент sh. Він прямо доступний як змінна в сценарії оболонки, не обробляється як сама команда оболонки.

... чому {}не уникнути і не цитувати?

У більшості оболонок цього не потрібно. Якщо ви запустите fish, це повинно бути: fish -c 'echo {}'друкує порожній рядок. Але не має значення, чи цитуєте ви його, оболонка просто видалить лапки.

3. Чи можете ви навести інші приклади ...

Кожного разу, коли ви розширюєте ім’я файлу (або інший неконтрольований рядок) як є всередині рядка, який приймається як якийсь код ^(*) , існує можливість довільного виконання команди.

Наприклад, це розширює $fбезпосередньо код Perl і спричинить проблеми, якщо ім'я файлу містить подвійну лапочку. Цитата в імені файлу закінчить цитату в коді Perl, а решта імені файлу може містити будь-який код Perl:

touch '"; print "HELLO";"'
for f in ./*; do
    perl -le "print \"size: \" . -s \"$f\""
done

(Ім'я файлу повинно бути трохи дивним, оскільки Perl аналізує весь код на передній частині, перш ніж запустити будь-який з них. Тому нам доведеться уникати помилки розбору.)

Хоча це безпечно передається через аргумент:

for f in ./*; do
    perl -le 'print "size: " . -s $ARGV[0]' "$f"
done

(Немає сенсу запускати іншу оболонку безпосередньо з оболонки, але якщо це зробити, вона схожа на find -exec sh ...випадок)

_{(* якийсь код включає SQL, тому обов'язковий XKCD: https://xkcd.com/327/ плюс пояснення: https://www.explainxkcd.com/wiki/index.php/Little_Bobby_Tables )}

Ваша стурбованість є саме причиною, чому GNU Parallel цитує вхід:

touch "hello; echo pwned"
find . -print0 | parallel -0 printf \"Argument: %s\\n\" {}

Це не запуститься echo pwned.

Він запустить оболонку, так що якщо ви розширите свою команду, ви не зненацька отримаєте сюрприз:

# This _could_ be run without spawining a shell
parallel "grep -E 'a|bc' {}" ::: foo
# This cannot
parallel "grep -E 'a|bc' {} | wc" ::: foo

Докладніші відомості про проблему з нерестовою оболонкою див: https://www.gnu.org/software/parallel/parallel_design.html#Always-running-commands-in-a-shell