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

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

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

  • как можно использовать shellshock через SSH?
  • Какие исправления Debian исправляют shellshock lcamtuf CVE-2014-6277 и CVE-2014-6278?
  • Можно ли запустить экземпляр shellshock для запуска команды в качестве привилегированного пользователя?
  • решение shellshock для nexenta / solaris
  • Почему способность определять функции в переменной окружающей среды не является угрозой безопасности сама по себе?
  • Как применить исправление уязвимости bash для CVE-2014-6271 на cygwin?
  • Нужно ли предпринимать дальнейшие действия над ShellShock
  • Как работает `env X = '() {(a) => \' sh -c" эхо-дата "?
  • One Solution collect form web for “Как обнаружена уязвимость Shellshock Bash?”

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

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

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

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

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

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

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

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

    Что делать, если переменные назывались LC_foo;echo test; f() 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 (и, вероятно, длинный список) и сообщили об этом ( внимательно).

    Linux и Unix - лучшая ОС в мире.