Як було виявлено вразливість 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 (і, мабуть, довгий список), і повідомив про це (уважно) .