Säkerhetshålet Shell Shock drabbar världens webbservrar

Samt fler språk än PHP (Perl, Python, Ruby, etc.). Samt det som kanske inte finns installerat just idag. Dessutom är det många ställen som använder Bash som behöver göra detta, men ändå inte är utsatta, vilket dock skulle behöva kontrolleras.

Uppdaterar man Bash så är man säker på sitt personliga system, men det finns ju miljoner andra system runt om i världen, och på många av dessa lagras säkert information om både dig och mig. Problemet med storskaliga attacker är inte bara att just min dator skulle vara utsatt för risk, utan att stora mängder av datorer runt om i världen är utsatta. Problemet är inte löst bara för att min dator säkrats upp.

Konstigt: tja, vanligen så har språk interna funktioner för sådana enkla saker. Omöjligt att hitta i kod: verkligen inte. Skalanrop via `system()`, backticks, etc., är lätta att hitta i skarpa kodexempel. Det ger direkta möjligheter att exempelvis använda skalomdirigering, vilket kan förenkla kod betydligt.

Det handlar generellt inte om hur världen borde se ut, utan om hur världen ser ut.

Sällsynt måhända, men det existerar.

Perl körs nog vanligare genom `mod_perl` idag, men likväl är de sekundära angreppen som beskrevs tidigare öppna.

På många system är `/bin/sh` länkat till `/bin/bash`. `sh` är idag generellt inte en egen binär, utan bara något som garanteras vara en Bourne shell-kompatibel tolk. På Debianbaserade system sköts detta av Dash (dels med baktanken om att snabba upp skriptkörning, men även just för att minska attackytan som hjälp till att förebygga sådana här problem), men på andra fortfarande av just Bash.

"Brukar" är att ta i — jag rekommenderar generellt att använda `#!/bin/sh` som tolk till shellskript, tills man eventuellt tydligt märker att man behöver Bash. Det betyder inte att alla följer en sådan praxis, och dessutom så väljer man ibland att använda Bash, då det stöder många saker som Bourne shell inte definierar.

Bashisms behöver bara undvikas om man explicit anger `#!/bin/sh`; om man anger `#!/bin/bash` så är det ju fritt fram att nyttja Bashspecifika funktioner (om man inte utnyttjar några Bashspecifika funktioner så borde man ju inte explicit kalla på Bash överhuvudtaget, kan tyckas).

Och återigen så används Bash som `/bin/sh` på flera system. Det är ofta också grunden till problematiken bakom "Bashisms" — folk skriver `#!/bin/sh`-skript, säger "det funkar på min maskin", för att sedan se dem krascha på ett system som inte använder Bash som `/bin/sh`.

De bör inte göra det, och gör det inte som standard om man använder distributionens verktyg för att initiera servertjänsten hos de stora distributionerna, men i verkligheten så ser det återigen ibland annorlunda ut.

I vilket fall så har webbserverns användare läsrättigheter till just de uppgifter som webbservern behöver kunna läsa, vilket ofta inkluderar exempelvis databasanvändaruppgifter i klartext.

Eventuella luckor gäller ej heller bara enkom webbservrar, även om en av de mest uppenbara attackerna kan ske den vägen. Det kommer säkert dyka upp förslag till hur man kan utnyttja liknande attacker via mailservrar och annat, eller DHCP som redan nämnts.

Den stora osäkerheten, vilket nämnts av flera i tråden, är att alla attackvektorer ännu inte är upptäckta eller genomgångna.

Det handlar inte om att "logga in" som användaren. Om man kan få användaren att exekvera ett skal genom vilket man exempelvis kan skapa omvänd anslutning till en fjärrkontrollerad dator så har man i praktiken fått åtkomst till systemet. Det kvittar vad användaren i sig har för angivet loginskal då man får dem att exekvera en ny process från en inloggad session. Det behöver ej heller vara så långt gånget som att få ett fullt skal; det kan räcka gott med att be dem att spotta ut innehållet av en konfigurationsfil direkt över HTTP (exempelvis med databasinloggningsuppgifter) till användarens webbläsare för att kunna öppna upp andra attacker.

Ofta så fungerar större exploits som kombinationer av mindre delar. Även om just denna inte ger ett färdigkonfigurerat root-skal till en attackerare så kan det vara en del i en större attack. Kan man få ett kommando att köras kan man också enkelt sätta igång exempelvis en fork-bomb som sänker tjänsten, vilket dels kan vara en del i en attack, men även högst irriterande på egen hand.

Återigen många "bör" . Oavsett vilket så kan de ändå läsa känslig information; annars skulle de inte kunna fungera. Ovanstående säkerhetslösningar berör inte dessa punkter.

Helt rätt, denna lucka kommer säkert vara en standarddel av exploit-kits en lång tid framöver.

Jaha. Då blir det till att använda WAMP, tills skiten är åtgärdad -.-

Quick notes about the bash bug, its impact, and the fixes so far [lcamtuf's blog] var en i mina ögon kort och tydlig översikt över vad som händer i Bash (åtminstone vad gäller ursprungsbuggen CVE-2014-6271), inklusive en kort redogörelse om varför det är ett problem.

Mjo liknande här.

[2014-08-13 06:29] [PACMAN] upgraded bash (4.3.018-3 -> 4.3.022-1)
[2014-08-25 12:21] [PACMAN] upgraded bash (4.3.022-1 -> 4.3.024-1)
[2014-09-24 22:04] [PACMAN] upgraded bash (4.3.024-1 -> 4.3.024-2)

/bin/sh pekar i väldigt många distar på /bin/bash

Där har du fel, det är en extremt allvarlig säkerhetsbugg. Det är värre än heartbleed. Läs på lite.

Tvärtom, den är väldigt lättexploaterad (det finns många attackvektorer, och många av de som finns är ofta förekommande).

Ser fler av dina inlägg och det är inte mycket rätt info i något av inläggen. Ex.vis så räcker det inte med att en user har /bin/false som shell. system()-anrop använder sig av /bin/sh -c och om då /bin/sh är en symlänk till /bin/bash, ja, go figure.

EDIT: Nuvarande "fixen" är heller inte komplett. Den kan göra det svårare, men problemet kvarstår.

Heartbleed klassades av t.ex. Bruce Schneier som en 11 på en tiogradig skala, den gjorde det möjligt att läsa upp till 64kB RAM som med lite tålamod innehåll lösenord och kryptonycklar, helt utan att något loggades överhuvudtaget.

Detta är inte lika illa, men det är fortfarande rejält illa.

Att använda detta via SSH är totalt meningslöst, har du SSH access kan du ändå köra vad som helst i 999.99 fall av 1.000.000 och det är fortfarande med din eget user-ID. Och hur ska du utnyttja användare som har /bin/false som login-skal? Opensshd använder fork() + exec() för att starta login-skal, inte system().

Tyvärr lär väl många köra webbserver som en relativt privilegierad användare, men man är idiot om man kör den som "root". Krävs fortfarande att "/bin/sh" är en länk till "/bin/bash" + att det finns någon externt påverkbar väg att starta något via ett ska på ett sätt där man kan påverka miljövariablerna. Tyvärr verkar detta inte helt ovanligt enligt en del rapporter

Farligaste vägen för "vanliga" användare verkar vara DHCP-klienten om man kopplar upp sig via okända WiFi-hotspots. Har kan tydligen iOS potentiellt vara påverkad, vet inte om något läst om man rett ut om DHCP-klienten i iOS är påverkad eller ej.

Android verkar inte direkt påverkad då den inte länkar "/bin/sh" till "/bin/bash", inte allt för många lär köra webbserver på sin Android-enhet och här är inte DHCP-klienten påverkad.

Inbyggda system som kör Linux kör nästan uteslutande ash som skal (via BusyBox), så dessa är inte påverkade.

Så hur är det för oss som rullar OS X då? Är ganska säker på att jag kör Bash sedan jag lekte runt med wine, macports och dylikt för att få igång lite trilskande program.

Vad bör man göra för att patcha det?

Bash verkar vara standardskalet i OS X sedan en tid tillbaka, så du och mer eller mindre alla andra med OS X kör det troligen även utan att ha lekt runt bland inställningar (kanske snarare främst då).

Det är bara att invänta en ny uppdaterad programversion. Den kanske redan finns tillgänglig genom en vanlig systemuppdatering.

Och som nån nämnt använder Ubuntu, som standard, Dash till standard.

Lite retfullt, Linux som skulle vara så säkert

Det kommer från Unix-föregångaren/förebilden Multics. En person (Louis Pouzin) som jobbade med förarbete som ledde fram till Multics tänkte fram konceptet och valde helt enkelt att kalla detta för ett skal [The Origin of the Shell]:

Tanken är kanske liknelsen mellan ett "skal" som omger en "kärna". Skalet kan bytas ut, men kärnan är densamma. Termen verkar i vilket fall vara på väg att fira 50-årsjubileum.

Sedan har betydelsen vidgats, och idag pratar man väl även om exempelvis Windows grafiska gränssnitt som ett "skal".

Bash används vanligen som det "interaktiva skalet", dvs det som en användare startar när de öppnar en terminal, då det har en massa funktioner som underlättar för detta (tab completion, avancerad historik, med mycket mera). När man kallar på ett skript genom "standardskalet" `/bin/sh` så kallas dock i praktiken Dash på exempelvis ett Debianbaserat system, då `/bin/sh` egentligen är en kvarleva från äldre tider då det pekade på något som kallas Bourne shell ("Bash" står för "Bourne Again Shell" och är GNU-projektets reimplementation).

Bash stöder dock mer avancerade konstruktioner som kan underlätta skriptning i vissa fall, och överhuvudtaget möjliggöra saker som ett strikt Bourne shell-kompatibelt skal inte kan göra. Om man vill använda dessa funktioner så ska man explicit kalla på `/bin/bash` (den exakta platsen kan vara föremål för en annan utläggning), vilket också av denna anledning görs i många skript.

"Förr" så var det dock vanligt att man körde just hela Bash, med alla "bells and whistles" som `/bin/sh`, då det även är (mer eller mindre) fullt kompatibelt med Bourne shell, vilket var dess ursprungliga designidé. Det ledde dock till en del olater när personer skrev skript för `/bin/sh` som använde Bashspecifika konstruktioner och inte uppfattade att de var problematiska då det ju ändå var Bash som tolkade. När Debian började migrera systemet till Dash i stället, som är tänkt att vara ett närapå minimalt, snabbt och säkert skal med Bourne shell-kompatibilitet, så uppdagades mängder med "Bashisms" som smugit in i systemskript som kallade på `/bin/sh`. Det tog ett bra tag att reda ut alla dessa.

Om man upptäckte ett sådant problem i sitt skript så var en lösning att sätta sig in i skillnaderna [1, 2] och förhoppningsvis bara behöva fixa några enstaka problem. Ett annat sätt, som blev än mer attraktivt om det rörde sig om mer än något enstaka problem, var att helt enkelt ändra sin shebang till att peka på `/bin/bash` och köra vidare som tidigare. Detta var ju också den enda rimliga lösningen ifall man faktiskt förlitade sig på den utökade Bashfunktionaliteten.

Så: ja, Bash används fortfarande för skriptning här och var, av olika anledningar. Men om någon mjukvara generellt vill utföra något med systemets skal så kallas `/bin/sh`, vilket i exempelvis Debian alltså inte längre motsvarar Bash, utan Dash. Anropet `system()` (se `man 3 system`) som i bakgrunden kallas via flertalet programmeringskonstruktioner använder just `/bin/sh`, vilket alltså på Dash-baserade system inte innebär något problem i detta fall.

Men men men... det är ju öppen sås!!

Det scenariot du nämner ovan; vi kan applicera det i fallet med webbservern. Du får samma privilegier som webbservern i och med att den payload du skickar med exekveras som den användaren. Du kan därmed få samma utfall som Heartbleed, fast bättre, om du väljer att göra det och vet vad du gör, poängen är att möjligheten finns. Att det inte loggas med Heartbleed är en sanning med modifikation, har du övervakning på trafiken, vilket många större firmor har via proxyservrar, så kan du se exakt vad som skickas ut.

EDIT: Bruce Schneier är krypto-/säkerhetsexpert, med det sagt är det inte säkert att han är Linuxexpert och insatt i omfattningen av denna bugg. Jag är rätt säker på att vi lär få höra mer från honom om ämnet inom snar framtid.

Jag har inte nämnt något om OpenSSH eller huruvida det är meningslöst eller ej? Har ej heller påstått att OpenSSH skulle använda sig av system()-anrop, så jag vet inte varför du tar upp det som om jag gjort påståenden om det?

Jo tack jag vet, jag jobbar med firmware på inbyggda system (och är väl bekant med Busybox)

Med Heartbleed så fanns det inte många attackvektorer, de var rätt lätta att identifiera. Men detta är något helt annorlunda. Det kommer dyka upp attackvektorer som är lika obskyra som buggen själv. Den är rankad som 10/10 på allvarlighetsskalan av NIST.

Blanda inte ihop äpplen och päron nu. Vem som helst kan installera osäkra userspace-applikationer, det gör inte kärnan mindre säker.

Nämnde SSH för vad var annars din kommentar mot att det inte hjälper att sätta login-shell till /bin/false riktad mot? Att man har det som login-shell för användare för olika services är ju självklart, men för att utnyttja CGI-vägen så behöver man aldrig använda login-skal så där blir det irrelevant att ens diskutera login-skal.

Är rätt säker på att denna kommer rankas på 10/10, men det är att ropa varg för så illa är det inte. Typ alla servers som innehåller något viktigt lär redan vara patchade eller så var det nog inte såå viktigt.

Heartbleed var värre. Visst är det så att vissa loggar meta-data om trafiken, men de maskiner som loggar "ser" bara krypterade paket när det är TLS så man vet inte vad som skickats ut. Tvivlar starkt på att man sätter om infrastruktur som delar ut session-nycklar från servers till loggers, vore ju som att be om problem i den hanteringen. Om man terminerar TLS i proxyn så har man ändå ingen loggning då hearbeat-paketet då går mot den och de loggades inte av OpenSSL. Så den data som läckte är än idag total okänd och man använder typiskt SSH för att trafiken är värd att skydda.

Om AES visar sig vara värdelös imorgon, vad ska man då sätta det på skalan? Är lite det jag sätter mig emot, detta och Heartbleed var illa men det var knappast en katastrof för våra ekonomiska system. Transaktioner man utför mot sin bank är typisk signerade via en HW-token, så även om Heartbleed skulle kunna gjort så att någon kan se vad jag såg när jag var inloggad så leder det ändå inte till att den personen kan utföra transaktioner mot mitt konto. De skulle se hur mycket pengar/värdepapper jag hade och vilka räkningar jag betalade, men det är allt.

Tycker detta är ett mindre problem för det har än mindre sannolikhet att få stora (stora som i att det spelar någon roll i global skala) ekonomiska konsekvenser. Tyvärr är det ju det som räknas i vårt samhälle, om ett problem inte leder till att det svider i plånboken så är det inte speciellt många som bryr sig i slutändan. Det är då knappast ett 10/10 problem, så jag håller inte med Schneier i att det var den katastrof han vill blåsa upp det till, för honom handlar det mycket om att boosta sitt eget namn och därmed sitt marknadsvärde (vilket i sig bara visar på god känsla för "marknaden").

Min kommentar var riktad mot rektor's påstående om att de flesta users (för demoner typ httpd) har /bin/false som som login-shell och att det då skulle vara lugnt, så är alltså inte fallet, vilket är vad jag påpekade

För att patcha servrarna behövs en patch som funkar, det har inte funnits förrän just nu verkar det som (ska pushas ut imorgon enligt Chet).

Vi kan väl komma överens om att vi inte kommer enas om en gradering av denna bugg kontra heartbleed, helt enkelt för att jag tror att vi menar olika saker med graderingen. Båda är väldigt allvarliga är vi överens om

(Jag tror nog att de flesta större företag som tillhandahåller känslig information i någon skala sparar all trafik, inte bara metadata. Loggning kan också vara ett svårtolkat begrepp. Att lagra utgående datatrafik är en typ av loggning, medans den traditionella sysloggen är mer loggning så som vi tänker oss. Här krävs det också handpåläggning för att logga enskilda användares actions osv, det är inget som är default (förutom default-loggning som existerar från program som användaren använder..) ..) Det blir komplext hur man än vrider och vänder på det.

Jo men precis, lite detta jag menar med det jag skrev ovan att beroende på vad det är man graderar (utifrån vad man bedömmer) så får man olika resultat. Det är också svårt att dra några slutsatser om vilka ekonomiska konsekvenser det kan få när det bara handlar om dörröppnare. Resten är upp till attackern att ha kunskap inom ifall det är möjligt att nyttja hålet till vidare attacker som i sin tur kan få ekonomiska konsekvenser.

Det lutar enligt maillistor dels givetvis åt att den specifika "oväntade funktionaliteten" gällande att Bash exekverar eftersläntrande kod i en funktionsdefinition ska täppas till, och likaså det sekundära parsningsproblemet som var kvar efter första patchomgången (båda sakerna har i praktiken redan hänt).

Samtidigt så är det många som för första gången fått höra att det överhuvudtaget är möjligt att ge funktionsdefinitioner via miljövariabler genom specialsyntaxen `env X='() {}'`. I exempelvis Ubuntu just nu, med säkerhetsfixarna ovan applicerade, kan man fortfarande "skriva över" exempelvis `ls` enbart genom en miljövariabel enligt:

$ env ls='() { echo hej hopp;}' bash -c 'ls dokument'
hej hopp

Då detta fortfarande kan kännas lite olustigt i ljuset av vad som uppdagats (även om man kan filosofera kring vad det skulle kunna ha för säkerhetskonsekvenser i praktiken, sans buggar likt den som upptäcktes) så är en patch på väg in som visserligen fortfarande kommer tillåta detta, men bara om miljövariablerna är på en viss form, med `BASH_FUNC_` som prefix och `()` som suffix.

Debian har redan applicerat denna patch (`variables-affix.patch` i deras system), så där skulle ovanstående kodexempel faktiskt köra "vanliga" `ls`, men man kan alltså fortfarande definiera funktioner genom miljövariabler genom konstruktionen:

$ env 'BASH_FUNC_ls()'='() { echo hej hopp;}' bash -c 'ls dokument'
hej hopp

Skillnaden är att det krävs ett specifikt prefix för att Bash ens ska försöka sig på att tolka innehållet i miljövariabeln som kod (att Bash kunde exekvera innehållet i vilken variabel som helst var ju en del av problemet med CVE-2014-6271) som inte av misstag skulle råka passera en vitlista med tillåtna miljövariabler in i en process (och även vore lätt att definiera i en svartlista, om det någonstans skulle krävas).

Eventuellt kommer det i framtiden krävas någon speciell Bashflagga för att överhuvudtaget tillåta denna typ av funktionsdefinitioner, men den diskussionen kan nog dröja ett tag.

Diskussionen kring hur klokt det är att använda Bash som `/bin/sh` kommer nog också återupplivas av detta. Förhoppningsvis/troligen kommer även andra distributioner än Debian (och dess derivat) att börja använda ett mindre funktionsrikt skal för detta ändamål för att minska den möjliga attackytan.

Finns det något sätt att testa utifrån ifall ett system är sårbart? Naturligtvis är jag inte ute efter att göra något olagligt, isf hade jag inte ställt frågan här och inte under mitt vanliga nick.

Som jag fattar det så är lite mera komplext än att man bara kan köra ett enda script eller dylikt för att testa? Det verkar bero på både ditten och datten och kräva en lite mera riktad attack?

Tack för svar! Ja att testa systemet när man redan är inloggad klarar jag Känns dock inte så relevant eftersom jag antar att är man redan inloggad så finns det förmodligen andra och kanske bättre sätt att elevera sig. Hittade också någon "oneliner" för att söka efter script som anropade om det nu var '/bin/sh' eller nått. Typ.

För synology NAS se följande länk:
https://www.synology.com/sv-se/support/security/bash_shellsho...

Het läsning för din del såhär några veckor efteråt:
http://webcache.googleusercontent.com/search?q=cache:I8s8KmZh...