Как работает обновленный тест уязвимости Shellshock для CVE-2014-7169?

Я понимаю оригинальный тест для CVE-2014-6271, который был:

$ env x='() { :;}; echo vulnerable' bash -c "echo this is a test"

Но меня смущает обновленный тест и соответствующий вывод для CVE-2014-7169:

$ env X='() { (a)=>\' sh -c "echo date"; cat echo
sh: X: line 1: syntax error near unexpected token `='
sh: X: line 1: `'
sh: error importing function definition for `X'
Thu 25 Sep 2014 08:50:18 BST

Может кто-нибудь кратко объяснить, что здесь происходит и как обходит патч для CVE-2014-6271?

Я копался в сети с тех пор, как впервые опубликовал этот вопрос.

Согласно первоначальному обнаружителю ошибки, bash до исправления CVE-2014-6271 импортировал такую ​​функцию, как:

foo=() {
  code
}

заменяя знак равенства пробелом и интерпретируя его ... что означало, что интерпретация за пределами определения функции была возможна.

Патч для ССО-2014-6271 введен специальный режим функции parse_and_execute () для предельной оценки для определения функции, а не за его пределами.

Однако, как объясняется в этом потоке , специально созданная переменная среды теста уязвимости CVE-2014-7169 предназначена для 1) путаницы синтаксического анализатора до смерти 2) оставления записок в буфере 3) полного изменения действий исходной команды bash, когда он объединяется с записками уже в буфере.

Итак, рассмотрим переменную среды:

X='() { (a)=>\'

• Парсер проанализирует () { (a)=>\. Обратите внимание, что \является частью строки; это не ускользает от конечной одиночной кавычки.

() {

• Парсер идентифицирует это как определение функции.

(a)=

• Это смущает парсер до смерти.

>\

• Парсер оставляет последние два символа в буфере.

>\[NEWLINE]

• В какой-то момент перед shзапуском команды в буфер помещается новая строка.

>\[NEWLINE]echo date

• Когда shвызывается (в данном случае это, вероятно, символическая ссылка на bash), он добавляет свои аргументы команды echo dateк уже существующим в буфере символам.

>echo date

• Поскольку символ новой строки экранирован, bash проанализирует буфер как >echo date, что имеет тот же эффект, что и date > echo. Файл с именем echoсоздан, и стандартный вывод dateкоманды перенаправляется в него.

; cat echo

• Вторая команда просто отображает содержимое вновь созданного файла.

Это не дает хороший чистый вывод, но это демонстрирует ошибку.

Без ошибок переменная окружения Xдолжна игнорироваться, bash должен запускаться echo date, и cat должен жаловаться, что нет файла с именем echo. Например, рассмотрим, как ведет себя приборная панель:

me@myserver$ rm -f echo && env -i  X='() { (a)=>\' dash -c 'echo date'; cat echo
date
cat: echo: No such file or directory

Я не буду повторять вывод, который вы показываете в своем вопросе, и я не буду притворяться, что понимаю, как он работает, но bash работает dateи помещает вывод в файл с именем 'echo'. Вы можете поиграть с альтернативами, чтобы dateубедить себя, что это полезно и опасно.