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

Man kan nämna att en vanligen använd Bash-wiki redan tidigare hade detta att skriva om att använda Bash som CGI-backend:

…så det är inte precis "best practices" att använda Bash på detta sätt, även om det går.

Dock så är det fortfarande rätt oklart exakt vilka attackvektorer som kan komma att dyka upp, då Bash kan kallas på från både möjliga och närapå omöjliga ställen, så det är definitivt värt att uppdatera. Fördelen är ju åtminstone att ett uppdaterat Bash täpper igen alla dessa luckor på en gång (när väl alla liknande luckor i Bash identifierats, vill säga).

env x='() { :;}; echo vulnerable' bash -c "echo this is a test"

env foo='() { echo "foo body";}; echo "evaluated when interpreting foo definition, bad idea!"' bash -c 'echo "Bash started, calling foo"; foo'

evaluated when interperting foo definition, bad idea!
Bash started, calling foo
foo body

Problemet här är väl att det är så fruktansvärt svårt att överblicka alla attackvektorer.
Och DHCP-problemet skulle jag vilja kalla ganska stort, idag när folk glatt ansluter till alla öppna vlan de kan hitta.

Så, nej, inte riktigt lika allvarligt som heartbleed, men i min förståelse enklare att utnyttja utan riktigt djupa kunskaper.
Tycker även det är lite oroande att patchen som pumpas ut nu inte är komplett (i och med CVE-2014-7169). Så många kommer tro att de uppdaterat, utan att egentligen löst problemet.

Håller med om att Heartbleed hade klart större konsekvenser.

SweClockersartikeln använder inte benämningen "värre än Heartbleed" utan bara säger att buggen är "allvarlig" vilket ju är sant, men vissa andra platser tar tillfället i akt att slå på största trumman. DN:s artikel blandar exempelvis in ord som "cyberexperter" och säger att buggen "kan enligt experter innebära ett ännu större hot mot säkerheten än buggen Heartbleed, som upptäcktes i april och har beskrivits som den hittills värsta i internets historia.". En stor majoritet av experter skulle nog inte hålla med dessa (smidigt nog anonyma) experter som DN (eller kanske snarare TT-Reuters i detta fall) hänvisar till, men visst: det måste ju inte vara en direkt lögn .

Men visst, denna bugg tillåter ju direkt exekvering av kod, vilket Heartbleed aldrig gjorde, så på vissa sätt är den värre. Ur en samlad synvinkel så skulle jag dock inte kalla den generellt "värre".

Kör du Bash genom Cygwin? Svarar du "nej" och/eller "va?" på dessa frågor: då är du personligen inte* drabbad. Även ifall du kör detta så är du ändå högst troligen inte utsatt för risk (det beror vad du använder det till). Ifall du förlitar dig på en fjärrtjänst så är det bara att (som alltid) hoppas/anta att dess admin har koll på läget.

*: "Troligen inte". Bash packas med tredjepartsverktyg här och var (såsom msysgit), och det kommer nog dröja ett tag innan alla dessa lösningar uppdaterats, och för den delen innan utnyttjningsbara sårbarheter hittas.

Riktade inte min kommentar mot SweC, men var otydligt med det. Tvärt om så tycker jag det beskrivs väldigt icke-färgat här. Men de flesta andra som ens hört talas om Hearbleed verkar passa att slå på katastroftrumman (ingen nämnd ingen glömd...).

För oss som kör Cygwin lär det vara ett ännu mindre problem. Cygwin har inget med DHCP-klienten att göra på Windows och det är nog rätt få som kör sina Windows-server-program under Cygwin.

Håller med om att "allvarlig" är helt rätt nivå på detta problem.

Lika bra att sätta upp ett stort folietält där vi alla kan sitta och gunga fram och tillbaka tillsammans.

LC_CTYPE="() { id; }; /bin/bash"; ssh user@host

Det kräver att autentiseringen lyckas innan Bash startas, och dessutom körs Bash då som den användare som ändå loggat in, och bara ifall Bash ändå var definierat som standardskal. Det blir generellt inte mycket av en lucka i sig, om jag inte missar något.

Det skulle potentiellt kunna användas för att komma runt konfigurationer där användaren "egentligen" är nedlåst till att bara få köra ett visst kommando över SSH, `/bin/bash` är angivet som skal (vilket vore märkligt konfigurerat i ett sådant fall; vissa servrar länkar ju dock fortfarande `/bin/sh` till Bash enligt tidigare diskussioner i tråden) och användaren samtidigt tillåts sätta sina egna miljövariabler, men det blir nog sammanlagt ett ganska litet attackmål. Dessutom så måste ju användaren likväl kunna autentisera sig mot servern, och det poppar inte upp något root-skal, precis.

Jag tänkte direkt på:

Om din dator ansluter till en DHCP-server så används `/sbin/dhclient-script` för att utföra vissa operationer, och den får variabler som till viss del kontrolleras av servern tilldelade genom miljövariabler. Det har inget med attack genom en webbserver att göra.

Det finns ännu inga kända liknande hål i stora programvaror. Problemet är att de innehåller så mycket kod att det kan ta ett tag att genomsöka hela kodbasen.

Det måste inte vara ett direkt anrop via CGI till Bash, utan det räcker med vilket anrop som helst som kallar på Bash där miljövariabler sätts, antingen implicit eller explicit. En programsvit skulle kunna ha ett till synes oskyldigt anrop till `mkdir` eller vad som helst genom ett skal någonstans, där miljövariabler som kan påverkas av en yttre användare passas vidare (exempelvis språkinställningar). Alla tillfällen då skalet anropas är potentiellt problematiska om man inte har koll på detta, och tidigare har det inte funnits någon direkt anledning att strippa felaktiga definitioner som de som utnyttjas i denna bugg när miljövariabler definieras.

CGI-anrop till Bash är extra utsatta då anropets "query string", som användaren har full kontroll över, automatiskt skickas till Bash som miljövariabeln `$QUERY_STRING`, och med nyttjande av buggen alltså kan exekvera främmande kod innan skriptet i sig ens börjat köras. Lägg därtill de som, mot bättre vetande, kör webbserverprocessen med root-kontot så får man ett stort problem där en användare direkt skulle kunna skapa sitt eget root-skal. Även om den körs som en specifik webbserveranvändare så skulle det kunna användas för att skriva ut exempelvis anslutningsdetaljer till interna databaser i klartext.

PhpMyAdmin var bara ett exempel på en väl spridd programvara, som om den skulle visa sig sårbar snabbt skulle bli ett favoritmål för bottar som söker genom nätet efter sårbara servrar (vilket det redan är, för den delen). Eftersom det finns många liknande stora sviter så kommer det ta lång tid innan de alla är genomgångna. Som "tur" är så negeras ju alla dessa attacker samtidigt med en enkel uppdatering av Bash likväl.

`mod_php`, `mod_perl`, etc., är inte direkt sårbara i sig, men kan bli en del av en attack genom oförsiktig hantering av systemprocesser inuti de skript som kallas.

I nuläget handlar det mycket om att spekulera kring vilka situationer där det potentiellt skulle kunna vara risk, och med lite fantasi så går det att komma på rätt mycket, utan att för den delen ha hittat något ställe där det faktiskt är möjligt att utnyttja.

Den här typen av buggar som gör det möjligt att blir root som användare/process är inte ovanliga. Det som gör den här buggen mer allvarligt är att spridning är enorm och det finns nog en en hel del gamla fulhack där ute som är aktiva som drabbas.

Ja det är det andra scenariot du pekar ut som kommandot är effektivt mot. Man måste ju dock inte bli root på en gång, det kan ju finnas lokala exploiter. Så det är ju en flerstegsraket, men det är ju ofta så.

https://gist.github.com/anonymous/929d622f3b36b00c0be1