Как была обнаружена уязвимость Shellshock Bash?

Question

Чтобы успокоить некоторых, я не нашел ошибку, наблюдая за эксплойтами, у меня нет причин полагать, что она была использована до того, как была раскрыта (хотя, конечно, я не могу этого исключить). Я bashтакже не нашел ее, просматривая код.

Не могу сказать, что точно помню ход своих мыслей в тот момент.

Это более или менее пришло из некоторых размышлений о поведении некоторых программ, которые я обнаружил.опасный(поведение, а не программное обеспечение). Тип поведения, который заставляет вас думать:это не звучит как хорошая идея.

В этом случае я размышлял о распространенной конфигурации ssh, которая позволяет передавать переменные окружения без очистки от клиента, если их имя начинается с LC_. Идея в том, чтобы люди могли продолжать использовать свой собственный язык при sshвходе на другие машины. Хорошая идея, пока вы не начнете рассматривать, насколько сложна обработка локализации, особенно когда в уравнение вводится UTF-8 (и как плохо она обрабатывается многими приложениями).

Еще в июле 2014 года я уже сообщал об уязвимости в обработке локализации glibc, которая сочеталась с этой sshd конфигурацией, идва другихопасное поведениеоболочкиbash позволял (аутентифицированным) злоумышленникам взламывать серверы git при условии, что они могли загружать туда файлы, и bashиспользовался в качестве оболочки входа пользователя git unix (CVE-2014-0475).

Я подумал, что это, вероятно, плохая идея использовать его bashв качестве оболочки входа пользователей, предлагающих услуги через ssh, учитывая, что это довольно сложная оболочка (когда все, что вам нужно, это просто разобрать очень простую командную строку) и она унаследовала большинство ошибок ksh. Поскольку я уже определил несколько проблем с bashиспользованием в этом контексте (для интерпретации ssh ForceCommands), мне было интересно, есть ли там потенциально больше.

AcceptEnv LC_*позволяет любую переменную, имя которой начинается с LC_и у меня было смутное воспоминание, чтоbash экспортируемые функции(аопасныйхотя в какой-то момент это была полезная функция) использовали переменные окружения, имена которых были примерно такими myfunction(), и задавались вопросом, нет ли там чего-нибудь интересного, на что можно было бы посмотреть.

Я собирался отмахнуться от этого, поскольку худшее, что можно было бы сделать, это переопределить команду, LC_something которая на самом деле не может быть проблемой, поскольку это не существующие имена команд, но затем я начал задаваться вопросом, какbash импортированныйэти переменные среды.

А что если бы переменные были вызваны, LC_foo;echo test; f()например? Поэтому я решил рассмотреть поближе.

А:

$ env -i bash -c 'zzz() { :;}; export -f zzz; env'
[...]
zzz=() {  :
}

показал, что мои воспоминания были неверны, поскольку переменные не были вызваны, myfunction()но myfunction(и это ценитькоторый начинается с ()).

И быстрый тест:

$ env 'true;echo test; f=() { :;}' bash -c :
test
bash: error importing function definition for `true;echo test; f'

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

Хуже, намного хуже,ценитьтакже не была подвергнута дезинфекции:

$ env 'foo=() { :;}; echo test' bash -c :
test

Это означало, чтолюбойпеременная окружения может быть вектором.

Именно тогда я осознал масштаб проблемы, убедился, что ее можно эксплуатировать и через HTTP ( HTTP_xxx/ QUERYSTRING... переменные окружения), и через другие службы обработки почты, а позже и через DHCP (и, вероятно, длинный список), и сообщил об этом (осторожно).

Answer 1