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

Trädvy Permalänk
Dalek
Registrerad
Dec 1999

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

Ett säkerhetshål i kommandotolken Bash kan utnyttjas för att snappa upp lösenord och exekvera kod, vilket lämnar en stor del av världens webbservrar sårbara.

Läs hela artikeln här

Observera att samma trivselregler gäller i kommentarstrådarna som i övriga forumet och att brott mot dessa leder till avstängning. Kontakta redaktionen om du vill uppmärksamma fel i artikeln eller framföra andra synpunkter.

Trädvy Permalänk
Medlem
Plats
Kyoto, Japan
Registrerad
Jul 2011

Here we go again! *tar på foliehatt*

Gamingrig | Intel Core i7-6700K @ 4.2 GHz | Nvidia GeForce GTX 980 Ti | ASUS ROG Maximus VIII Formula | 16GB 2133MHz HyperX DDR4 | SSD: Samsung 850 Pro 512GB + Intel 535 480GB + Samsung 840 Pro 256GB | HDD: 2x WD Black 2TB + 2x WD Green 4TB | Creative Sound Blaster ZxR+Sennheiser HD650 | Corsair RM1000 | Corsair H100i V2 | Phanteks P400S Tempered glass | Asus ROG Swift 1440p 165Hz + Asus 1440p PLS | Retina Macbook Pro | i7-3820QM | 8GB RAM | MS Surface Pro 3&4 | Intel i5 | 8GB RAM | 256GB SSD |

Trädvy Permalänk
Medlem
Plats
Göteborg
Registrerad
Jul 2004

Dags att gömma sig under en sten igen.

[Intel 6700K @ 4500MHz]--[MSI Core Frozr L]--[MSI Z170 Gaming M5]--[Corsair 16GB 2666MHz DDR4]--[MSI 2080Ti Gaming X Trio @ 2010/15600MHz]--[EVGA Supernova G2 850W]--[Fractal Design Define S]--[Windows 10 x64]--[Acer X34A @ 95Hz]--[Corsair Strafe RGB MX Silent]--[Corsair Ironclaw RGB]--[HyperX Cloud II]

Trädvy Permalänk
Medlem
Registrerad
Okt 2011

Bash är väl mer av ett användarskal, och många servrar använder väl 'sh' som default skal istället?

Jag tror det här kommer patchas och fixas rätt snabbt. Jag tror inte det är en så allvarlig säkerhetsbugg.

Den låter ganska svårexploaterad.

Trädvy Permalänk
Hedersmedlem
Registrerad
Okt 2002

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:

Citat:

Now of course we know you would never write a CGI script in Bash. So for the purposes of this entry we will assume that terrorists have kidnapped your spouse and children and will torture, maim, kill, "or worse" them if you do not comply with their demands to write such a script.

…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).

Nu med kortare användarnamn, men fortfarande bedövande långa inlägg.

Trädvy Permalänk
Hedersmedlem
Registrerad
Okt 2002
Skrivet av rektor:

Bash är väl mer av ett användarskal, och många servrar använder väl 'sh' som default skal istället?

Jag tror det här kommer patchas och fixas rätt snabbt. Jag tror inte det är en så allvarlig säkerhetsbugg.

Den låter ganska svårexploaterad.

Debianbaserade system sedan ~2006 om jag minns rätt länkar `/bin/sh` till Dash (åtminstone Unstable-grenen; Ubuntu som bygger på Debian började med detta i 6.10, och första Debian Stable-versionen som gjorde det verkar vara Squeeze som släpptes 2011), som inte är sårbart. Red Hat-baserade system verkar dock fortfarande använda Bash som `/bin/sh`. Dessutom finns det ju de skript som explicit kallar på `/bin/bash`, så som exempelvis `/sbin/dhclient-script` ifall man använder ISC DHCP (vilket Linuxdistributioner generellt gör), så det är nog värt att uppdatera Bash innan faktiska exploits börjar hitta ut i det vilda.

Kan nämna att NIST gav detta säkerhetshål (CVE-2014-6271; "extrabuggarna" som nämns i artikeln är registrerade som CVE-2014-7169) högsta betyg i alla kategorier, så visst är det potentiellt problematiskt, men relativt lätt att patcha, samtidigt som det ska till en del för att det ska gå att utnyttja enkelt. Det är snarare en möjlighet för riktade attacker mot enskilda servrar än massattacker i nuläget, skulle jag säga, om det inte visar sig att spridda programsviter som PhpMyAdmin eller liknande gör något huvudlöst någonstans. Inget sådant har ännu framkommit, dock.

(Kan tillägga att jag personligen skapat någon enkel webbtjänst som använder `/bin/sh` som backend, som jag vet körs på en Red Hat-baserad maskin på ett ställe . Dock så skulle jag aldrig låta en sådan lösning vara publikt åtkombar, utan den är låst till ett intranät, med lösenordsautentisering ovanpå det, och de få som har tillgång till tjänsten skulle lika gärna kunna gå och fysiskt bära med sig hela servern i fråga, så jag ser det inte som mycket av ett "säkerhetshål".)

Nu med kortare användarnamn, men fortfarande bedövande långa inlägg.

Trädvy Permalänk
Datavetare
Plats
Stockholm
Registrerad
Jun 2011

Är det inte lite att ta i att kalla det en värre bugg än Heartbleed?

För att utnyttja buggen måste man endera ha access till systemet via SSH, är det inte enklare att bra köra programmet efter man loggat in då eftersom det man skickar in via miljövariabler i alla fall kör med "effective UID" av dig (så är inte något som kan användas för root-access)?

DHCP-client problemet är värre, men det kräver fysisk access till det nät för de maskiner man vill hacka. Är man fysiskt på plats finns det betydligt enklare sätt att ta total kontroll över systemet.

Stora problemet verkar vara ihop med Git och vissa användarfall av CGI (används det än i någon större utsträckning?). Kör man t.ex. mod_php så är det i sig ingen attack-vektor.

Detta är helt klart ett stort problem, men absolut inte i Heartbleed nivå.

Tycker detta exempel gör det lite svårt att se exakt vad problemet är

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

Detta borde göra det enklare att förstå vari problem ligger. Det som står efter kroppen för foo borde aldrig evalueras vilket det nu gör när den nya bash-instansen initieras

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

Blir detta när man kör i ett system som har problemet

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

Care About Your Craft: Why spend your life developing software unless you care about doing it well? - The Pragmatic Programmer

Trädvy Permalänk
Medlem
Plats
Malmö
Registrerad
Mar 2004
Trädvy Permalänk
Medlem
Registrerad
Dec 2001
Skrivet av Yoshman:

Är det inte lite att ta i att kalla det en värre bugg än Heartbleed?

För att utnyttja buggen måste man endera ha access till systemet via SSH, är det inte enklare att bra köra programmet efter man loggat in då eftersom det man skickar in via miljövariabler i alla fall kör med "effective UID" av dig (så är inte något som kan användas för root-access)?

DHCP-client problemet är värre, men det kräver fysisk access till det nät för de maskiner man vill hacka. Är man fysiskt på plats finns det betydligt enklare sätt att ta total kontroll över systemet.

Stora problemet verkar vara ihop med Git och vissa användarfall av CGI (används det än i någon större utsträckning?). Kör man t.ex. mod_php så är det i sig ingen attack-vektor.

Detta är helt klart ett stort problem, men absolut inte i Heartbleed nivå.

Tycker detta exempel gör det lite svårt att se exakt vad problemet är

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

Detta borde göra det enklare att förstå vari problem ligger. Det som står efter kroppen för foo borde aldrig evalueras vilket det nu gör när den nya bash-instansen initieras

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

Blir detta när man kör i ett system som har problemet

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.

Trust me, I'm an engineer!

Trädvy Permalänk
Medlem
Plats
Karlshamn
Registrerad
Jan 2008

ang Windows. Någon som vet om webmail med Exchange https://mail.domän.se/OWA eller https://mail.domän.se/remote sidor är drabbade?
Likså så om man kör en Windows 2008 R2 som Webserver

Eftersom det stod att även Windows kan vara drabbat? Någon som vet?

Trädvy Permalänk
Hedersmedlem
Registrerad
Okt 2002
Skrivet av Yoshman:

Är det inte lite att ta i att kalla det en värre bugg än Heartbleed?

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".

Nu med kortare användarnamn, men fortfarande bedövande långa inlägg.

Trädvy Permalänk
Hedersmedlem
Registrerad
Okt 2002
Skrivet av Geckod:

ang Windows. Någon som vet om webmail med Exchange https://mail.domän.se/OWA eller https://mail.domän.se/remote sidor är drabbade?
Likså så om man kör en Windows 2008 R2 som Webserver

Eftersom det stod att även Windows kan vara drabbat? Någon som vet?

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.

Nu med kortare användarnamn, men fortfarande bedövande långa inlägg.

Trädvy Permalänk
Datavetare
Plats
Stockholm
Registrerad
Jun 2011
Skrivet av phz:

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

SweClockers artikel 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 .

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.

Care About Your Craft: Why spend your life developing software unless you care about doing it well? - The Pragmatic Programmer

Trädvy Permalänk
Medlem
Registrerad
Nov 2008
Skrivet av XFTality:

Here we go again! *tar på foliehatt*

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

Intel i7 6700K | ASUS Z170 Pro Gaming | Palit Geforce GTX 1080 GameRock | 16GB DDR4 | Fractal Design Define R5 | EVGA Supernova G2 750W

Trädvy Permalänk
Medlem
Registrerad
Okt 2007
Skrivet av Geckod:

ang Windows. Någon som vet om webmail med Exchange https://mail.domän.se/OWA eller https://mail.domän.se/remote sidor är drabbade?
Likså så om man kör en Windows 2008 R2 som Webserver

Eftersom det stod att även Windows kan vara drabbat? Någon som vet?

Följande står i artikeln:
"ibland även i Microsoft Windows, det sistnämnda med Cygwin eller liknande paket. "

Skickades från m.sweclockers.com

Trädvy Permalänk
Medlem
Plats
Sikfors
Registrerad
Feb 2007

Dash over here, exploiten verkar vara bash exklusivt. Oh well.

Trädvy Permalänk
Medlem
Plats
/bin/bash
Registrerad
Mar 2002

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

Cisco - Linux - VMWare
-- Citera mig om ni vill få återkoppling --

Trädvy Permalänk
Medlem
Registrerad
Okt 2011
Skrivet av phz:

Debianbaserade system sedan ~2006 om jag minns rätt länkar `/bin/sh` till Dash (åtminstone Unstable-grenen; Ubuntu som bygger på Debian började med detta i 6.10, och första Debian Stable-versionen som gjorde det verkar vara Squeeze som släpptes 2011), som inte är sårbart. Red Hat-baserade system verkar dock fortfarande använda Bash som `/bin/sh`. Dessutom finns det ju de skript som explicit kallar på `/bin/bash`, så som exempelvis `/sbin/dhclient-script` ifall man använder ISC DHCP (vilket Linuxdistributioner generellt gör), så det är nog värt att uppdatera Bash innan faktiska exploits börjar hitta ut i det vilda.

Men /sbin/dhclient-script kan ju inte nås via cgi-bin/ katalogen.

Skrivet av phz:

Kan nämna att NIST gav detta säkerhetshål (CVE-2014-6271; "extrabuggarna" som nämns i artikeln är registrerade som CVE-2014-7169) högsta betyg i alla kategorier, så visst är det potentiellt problematiskt, men relativt lätt att patcha, samtidigt som det ska till en del för att det ska gå att utnyttja enkelt. Det är snarare en möjlighet för riktade attacker mot enskilda servrar än massattacker i nuläget, skulle jag säga, om det inte visar sig att spridda programsviter som PhpMyAdmin eller liknande gör något huvudlöst någonstans. Inget sådant har ännu framkommit, dock.

phpMyAdmin körs ju inte över CGI, och använder inte några CGI script, det är bara PHP som körs på mod_php.

Trädvy Permalänk
Hedersmedlem
Registrerad
Okt 2002
Skrivet av deegan:

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.

Nu med kortare användarnamn, men fortfarande bedövande långa inlägg.

Trädvy Permalänk
Medlem
Plats
Stockholm
Registrerad
Mar 2004

Jag tänkte direkt på:

“Problems that remain persistently insoluble should always be suspected as questions asked in the wrong way.” ― Alan W. Watts

Trädvy Permalänk
Hedersmedlem
Registrerad
Okt 2002
Skrivet av rektor:

Men /sbin/dhclient-script kan ju inte nås via cgi-bin/ katalogen.

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.

Skrivet av rektor:

phpMyAdmin körs ju inte över CGI, och använder inte några CGI script, det är bara PHP som körs på mod_php.

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.

Nu med kortare användarnamn, men fortfarande bedövande långa inlägg.

Trädvy Permalänk
Medlem
Plats
Karlshamn
Registrerad
Jan 2008
Skrivet av betan:

Följande står i artikeln:
"ibland även i Microsoft Windows, det sistnämnda med Cygwin eller liknande paket. "

Skickades från m.sweclockers.com

Okej, antar att OWA inte använder sig av det då.

Då är det nog lungt. Tänkte om man behövde göra nått på de Exchange servrar som kör OWA.

Trädvy Permalänk
Medlem
Registrerad
Okt 2007
Skrivet av Geckod:

Okej, antar att OWA inte använder sig av det då.

Då är det nog lungt. Tänkte om man behövde göra nått på de Exchange servrar som kör OWA.

Vet du inte vad cygwin är har du det inte som, någon skrev innan. Cygwin och Exchange har inget att göra med varandra. Varifrån fick du att det just skulle vara Exchange?

Skickades från m.sweclockers.com

Trädvy Permalänk
Medlem
Registrerad
Nov 2005

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.

Trädvy Permalänk
Medlem
Registrerad
Okt 2011
Skrivet av phz:

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.

grep exec|passthru|shell_exec|system # Funktioner i PHP
grep /bin/*sh # Filer, sh, bash, dash, zsh, fish, tsh, etc
grep "`" # Backtick operator i PHP

Skrivet av phz:

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.

Om du anropar `mkdir` so förmodar jag att den inte anropar mkdir via Bash, det vore ju konstigt.

Skrivet av phz:

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.

Tror det är sällsynt med CGI skript som anropar Bash.
CGI blir mer och mer sällsynt, och dom som använder det brukar använda Perl skript.
Shell scripts används sällan för CGI, och används det så brukar man väl använda 'sh', inte 'Bash'.
Bash är mer för slutanvändare, för att exekvera script brukat man använda 'sh' och när man skriptar brukar man vilja undvika sk "Bashisms" (bash-specifik syntax och funktioner).

Webbservern (och daemons i övrigt) körs normalt inte som root och bör heller inte göra det. Dom brukar köras som "nobody", alternativt en specifik användare för varje daemon. Dessa går heller inte att logga in på, då deras shell i /etc/passwd är konfigurerat att peka mot /bin/nologin.
Sedan bör de vara jailade med chroot, och köra AppArmor.

Trädvy Permalänk
Avstängd
Registrerad
Sep 2013

sudo kill 1

För er som fattar. Haha.

Trädvy Permalänk
Inaktiv
Registrerad
Sep 2011

Ubuntu teamet var riktigt snabba med att täppa igen säkerhetshålet!

USN-2362-1: Bash vulnerability

Trädvy Permalänk
Medlem
Plats
/bin/bash
Registrerad
Mar 2002
Skrivet av phz:

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.

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å.

Cisco - Linux - VMWare
-- Citera mig om ni vill få återkoppling --

Trädvy Permalänk
Medlem
Plats
/bin/bash
Registrerad
Mar 2002

Cisco - Linux - VMWare
-- Citera mig om ni vill få återkoppling --

Trädvy Permalänk
Hedersmedlem
Plats
Stockholm
Registrerad
Dec 2002
Skrivet av rektor:

grep exec|passthru|shell_exec|system # Funktioner i PHP
grep /bin/*sh # Filer, sh, bash, dash, zsh, fish, tsh, etc
grep "`" # Backtick operator i PHP

Om du anropar `mkdir` so förmodar jag att den inte anropar mkdir via Bash, det vore ju konstigt.

Tror det är sällsynt med CGI skript som anropar Bash.
CGI blir mer och mer sällsynt, och dom som använder det brukar använda Perl skript.
Shell scripts används sällan för CGI, och används det så brukar man väl använda 'sh', inte 'Bash'.
Bash är mer för slutanvändare, för att exekvera script brukat man använda 'sh' och när man skriptar brukar man vilja undvika sk "Bashisms" (bash-specifik syntax och funktioner).

Webbservern (och daemons i övrigt) körs normalt inte som root och bör heller inte göra det. Dom brukar köras som "nobody", alternativt en specifik användare för varje daemon. Dessa går heller inte att logga in på, då deras shell i /etc/passwd är konfigurerat att peka mot /bin/nologin.
Sedan bör de vara jailade med chroot, och köra AppArmor.

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.

Backticks (`anrop`) exekveras i åtminstone Perl och Ruby (tror även PHP) som /bin/sh -c 'anrop', så jo de kan vara drabbade om sådant görs.
I exempelvis Red Hat-baserade system är /bin/sh fortfarande en symlänk till /bin/bash och då spelar det ingen roll om skript använder /bin/sh som shebang eller ej.

EDIT: Verkar som att även PHP anropar /bin/sh för backticks.

[mikael@laptop:1] php -r '`asdf`;' sh: 1: asdf: not found

Vim
Kinesis Classic Contoured (svart), Svorak (A5)
Medlem i signaturgruppen Vimzealoter.