TL; DR
Уразливість в оболонках повністю зафіксована
- На гілці bash-2.05b: 2.05b.10 і вище (патч 10 включений)
- На гілці bash-3.0: 3.0.19 і вище (виправлення 19 включено)
- На гілці bash-3.1: 3.1.20 і вище (патч 20 включений)
- На гілці bash-3.2: 3.2.54 і вище (патч 54 включений)
- На гілці bash-4.0: 4.0.41 і вище (патч 41 включено)
- На гілці bash-4.1: 4.1.14 і вище (патч 14 включений)
- На гілці bash-4.2: 4.2.50 і вище (патч 50 включено)
- На гілці bash-4.3: 4.3.27 і вище (виправлення 27 включено)
Якщо ваш bash демонструє старішу версію, ваш постачальник ОС може все-таки власноруч зафіксувати його, тому краще перевірити.
Якщо:
env xx='() { echo vulnerable; }' bash -c xx
показує "вразливий", ти все ще вразливий. Це єдиний релевантний тест (чи все ще аналізатор bash піддається дії коду в будь-якій змінній середовища).
Деталі.
Помилка була в початковій реалізації функції експорту / імпорту введений 5 - го серпня 1989 Брайан Фокс і перший випущений в Баш-1.03 близько місяця тому , в той час , коли баш не був у такому широко використовується, перш, ніж безпека викликала велике занепокоєння, і HTTP та Інтернет або Linux навіть існували.
Із зміни журналу в 1,05 :
Fri Sep 1 18:52:08 1989 Brian Fox (bfox at aurel)
* readline.c: rl_insert (). Optimized for large amounts
of typeahead. Insert all insertable characters at once.
* I update this too irregularly.
Released 1.03.
[...]
Sat Aug 5 08:32:05 1989 Brian Fox (bfox at aurel)
* variables.c: make_var_array (), initialize_shell_variables ()
Added exporting of functions.
Деякі дискусії в gnu.bash.bug та comp.unix.questions того часу також згадують про цю особливість.
Неважко зрозуміти, як воно потрапило.
bash експортує функції в env vars, як
foo=() {
code
}
І при імпорті все, що він повинен зробити, - це інтерпретувати те, що із =заміненим пробілом ... за винятком того, що він не повинен сліпо його тлумачити.
Це також порушено в тому, що в bash(на відміну від оболонки Борна) скалярні змінні та функції мають інший простір імен. Насправді, якщо у вас є
foo() { echo bar; }; export -f foo
export foo=bar
bash буде радісно розміщувати обидва в оточенні (так, записи з однаковою назвою змінної), але багато інструментів (включаючи багато оболонок) не поширюватимуть їх.
Можна також стверджувати, що bash повинен використовувати BASH_префікс простору імен для цього, оскільки це env vars, що стосується лише bash до bash. rcвикористовує fn_префікс для подібної функції.
Кращим способом її реалізації було б поставити визначення всіх експортованих змінних у змінну на зразок:
BASH_FUNCDEFS='f1() { echo foo;}
f2() { echo bar;}...'
Це все-таки потрібно санітувати, але принаймні це не може бути більш корисним, ніж $BASH_ENVабо $SHELLOPTS...
Існує патч, який заважає bashінтерпретувати щось інше, ніж визначення функції там ( https://lists.gnu.org/archive/html/bug-bash/2014-09/msg00081.html ), і це той, що має застосовувались у всіх оновленнях безпеки з різних дистрибутивів Linux.
Однак bash все ще інтерпретує код там, і будь-яка помилка в інтерпретаторі може бути використана. Один з таких помилок уже знайдений (CVE-2014-7169), хоча його вплив значно менший. Тож незабаром з’явиться ще одна латка.
Поки виправлення жорсткості, що не заважає Bash інтерпретувати код у будь-якій змінній (наприклад, використовуючи BASH_FUNCDEFSпідхід вище), ми точно не будемо знати, чи не вразливі ми від помилки в bash синтаксичному аналізі. І я вірю, що рано чи пізно буде випущено таке виправлення твердінь.
Редагувати 2014-09-28
Знайдено дві додаткові помилки в аналізаторі (CVE-2014-718 {6,7}) (зауважте, що більшість оболонок обов'язково мають помилки у своєму аналізаторі для кутових випадків, що не викликало б занепокоєння, якби цей аналізатор не мав не зазнавали недовірених даних).
Хоча всі 3 помилки 7169, 7186 і 7187 були виправлені в наступних патчах, Red Hat натиснув на виправлення твердіння. У своєму патчі вони змінили поведінку, так що функції експортувались у змінні, що називаються BASH_FUNC_myfunc()більш-менш випереджаючими дизайнерські рішення Чета.
Пізніше Chet опублікував це виправлення як офіційний патч bash .
Цей загальнозміцнюючий патч або його варіанти тепер доступні для більшості основних дистрибутивів Linux і, зрештою, перейшли в Apple OS / X.
Це підключає стурбованість будь-якою довільною середовищем, що експлуатує аналізатор через цей вектор, включаючи дві інші вразливості в аналізаторі (CVE-2014-627 {7,8}), які були розкриті пізніше Міхалом Залевським (CVE-2014-6278 майже так само погано, як CVE-2014-6271), на щастя, після того, як більшість людей встигли встановити затверджуючий пластир
Помилки в аналізаторі також будуть виправлені, але вони вже не є великою проблемою, коли аналізатор вже не так легко піддається недовірливому вводу.
Зауважте, що в той час як вразливість безпеки виправлена, можливо, ми побачимо деякі зміни в цій області. Первісне виправлення уразливості CVE-2014-6271 зламалася зворотну сумісність в тому , що вона припиняє імпортування функції з .або :або /від їхнього імені. Вони все ще можуть бути оголошені башем, хоча це призводить до непослідовної поведінки. Оскільки функції з іменем .та :їх іменем зазвичай використовуються, швидше за все, патч відновить, приймаючи принаймні ті з оточення.
Чому його не знайшли раніше?
Це теж щось, про що я задумався. Я можу запропонувати кілька пояснень.
По-перше, я думаю, що якби дослідник безпеки (а я не професійний дослідник безпеки) спеціально шукав уразливості в bash, вони, ймовірно, знайшли б це.
Наприклад, якби я був дослідником безпеки, моїми підходами можуть бути:
- Подивіться, звідки
bashберуть участь і що з цим роблять. А довкілля очевидно.
- Подивіться, в яких місцях
bashвикликається перекладач і за якими даними. Знову ж таки, він би виділявся.
- Імпорт експортованих функцій - одна з особливостей, яка вимикається, коли
bashвстановлено / встановлено жорсткість, що робить його ще більш очевидним місцем для пошуку.
Зараз я підозрюю, що ніхто не думав вважати bash(перекладача) загрозою, або що загроза могла прийти саме таким чином.
bashІнтерпретатор не призначений для обробки ненадійного введення.
Сценарії оболонки (а не перекладач) часто пильно дивляться з точки зору безпеки. Синтаксис оболонки настільки незручний, і є так багато застережень із написанням надійних сценаріїв (коли-небудь бачив, як я або інші згадують оператора split + glob або чому, наприклад, слід цитувати змінні?), Що в скриптах, які обробляють, досить часто можна знайти вразливості безпеки. ненадійні дані.
Ось чому ви часто чуєте, що не слід писати сценарії оболонки CGI або встановлені сценарії вимкнено в більшості Unices. Або що ви повинні бути особливо обережними при обробці файлів у світових каталогах, що записуються (див., Наприклад, CVE-2011-0441 ).
Основна увага приділяється тому, що сценарії оболонки, а не інтерпретатор.
Ви можете виставити інтерпретатор оболонки для ненадійних даних (харчування зовнішніх даних , як код оболонки витлумачити) через evalабо .або зателефонувавши по телефону його при умови , призначених для користувача файли, але тоді вам не потрібен вразливість , bashщоб використовувати його. Цілком очевидно, що якщо ви передаєте несанітовані дані для оболонки для інтерпретації, вона буде інтерпретувати їх.
Отже оболонка викликається у довірених контекстах. Дано фіксований сценарій для інтерпретації і частіше за все (оскільки так важко писати надійні сценарії) фіксованих даних для обробки.
Наприклад, у веб-контексті оболонка може викликати щось подібне:
popen("sendmail -oi -t", "w");
Що може піти не так у цьому? Якщо передбачається щось не так, це стосується даних, що подаються до цієї sendmail, а не про те, як розбирається сам командний рядок оболонки або які додаткові дані подаються до цієї оболонки. Немає причини, щоб ви хотіли розглядати змінні середовища, які передаються в цю оболонку. І якщо ви це зробите, ви розумієте, що це все env vars, ім'я яких починається з "HTTP_", або добре відомі CGI env vars, SERVER_PROTOCOLабо QUERYSTRINGні з якими оболонка або sendmail не мають жодного стосунку.
У контекстах підняття привілеїв, таких як під час встановлення setuid / setgid або через sudo, середовище, як правило, вважається, і в минулому було багато вразливостей, знову ж таки не проти самої оболонки, а проти речей, що підвищують такі привілеї sudo(див., Наприклад, CVE -2011-3628 ).
Наприклад, bashне довіряє середовищу під час встановлення або виклику командою setuid (подумайте, mountнаприклад, що викликає помічників). Зокрема, вона ігнорує експортовані функції.
sudoробить очистку навколишнього середовища: всі за замовчуванням для білого списку , за винятком, і якщо не налаштований на, принаймні чорних списків кілька , які , як відомо, впливають на оболонку або інший (як PS4, BASH_ENV, SHELLOPTS...). Він також робить чорний список змінних оточення, вміст яких починається ()(саме тому CVE-2014-6271 не дозволяє ескалацію привілеїв через sudo).
Але знову ж таки, це стосується контекстів, у яких середовищі не можна довіряти: будь-яку змінну з будь-яким іменем та значенням може встановити зловмисний користувач у цьому контексті. Це не стосується веб-серверів / ssh або всіх векторів, які експлуатують CVE-2014-6271, де керується середовищем (принаймні, назва змінних середовищ контролюється ...)
Важливо заблокувати змінну на зразок echo="() { evil; }", але ні HTTP_FOO="() { evil; }", тому що HTTP_FOOвона не буде називатися командою будь-яким скриптом оболонки або командним рядком. І apache2 ніколи не збирається встановлювати echoабо BASH_ENVзмінну.
Цілком очевидно, що деякі змінні середовища повинні бути занесені до чорного списку в деяких контекстах залежно від їх імені , але ніхто не думав, що вони повинні бути в чорному списку залежно від їх вмісту (крім sudo). Або іншими словами, ніхто не думав, що довільна середовище може бути вектором для введення коду.
Щодо того, чи може обширне тестування, коли було додано функцію, її наловило, я б сказав, що це малоймовірно.
Під час тестування на функцію ви перевіряєте функціональність. Функціонал працює чудово. Якщо ви експортуєте функцію в одному bashвиклику, він імпортується добре в іншому. Дуже ретельне тестування могло б виявити проблеми, коли експортується змінна та функція з тим самим іменем або коли функція імпортується в місцевість, відмінну від тієї, в яку було експортовано.
Але щоб побачити вразливість, це не тест на функціональність, який вам довелося б робити. Аспект безпеки мав би зосереджуватись, і ви б не тестували функціональність, а механізм та спосіб його зловживання.
Це не те, що розробники (особливо в 1989 р.) Часто мають у своїй думці, і розробник оболонок може бути виправданий, вважаючи, що його програмне забезпечення навряд чи може бути мережевим.