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

Поскольку эта ошибка затрагивает очень много платформ, мы могли бы кое-что узнать из процесса, с помощью которого была обнаружена эта уязвимость: это был момент εὕρηκα (eureka) или результат проверки безопасности?

Поскольку мы знаем, что Стефан обнаружил ошибку Shellshock, и другие могут знать об этом процессе, нам будет интересна история о том, как он пришел, чтобы найти ошибку.

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

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

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

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

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

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

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

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

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

A:

$ 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... env vars), другие, такие как службы обработки почты, позже DHCP (и, вероятно, длинный список), и сообщил об этом (осторожно) ,