Voor een aantal Linux distributies (waaronder Ubuntu) is al een update verschenen. Als je je systeem update en het commando uitvoert in bash, dan zul je niet langer het woordje "kwetsbaar" zien maar de foutmelding "bash: warning: x: ignoring function definition attempt; bash: error importing function definition for 'x'". Je systeem is dus niet meer kwetsbaar voor deze aanval.

Update dus snel je pakketten, beste Linuxgebruikers!

Het lastige aan deze kwetsbaarheid is dat bash (Bourne Again SHell) onder onverwachte omstandigheden kan worden gebruikt. Ga ervan uit dat alle *nix systemen gepatched moeten worden, de meest kwetsbare (internet facing) eerst.

Hopelijk hebben we niet te maken met software die bash functionaliteit in de code zelf heeft opgenomen (dat was wel het geval met het Heartbleed lek on OpenSSL, waardoor je niet klaar was met 1 patch per OS).

In http://blog.erratasec.com/ heeft Robert Graham dit de "Shellshock" bug genoemd en stelt "Bash bug as big as Heartbleed". Dat denk ik niet, maar patchen is wel dringend nodig (nog steeds zijn er zeer veel kristische servers lek voor Heartbleed, waaronder VPN/firewalls en mailservers).

Ook SSH servers kunnen kwetsbaar zijn, zoals Solar Designer uitlegt in http://seclists.org/oss-sec/2014/q3/651: als op de server in .ssh/authorized_keys een "set" commando voorkomt is unauthenticated remote code execution mogelijk met:

Meer info:
http://www.theregister.co.uk/2014/09/24/bash_shell_vuln/
https://blogs.akamai.com/2014/09/environment-bashing.html

Aanvullingen 2014-09-25 09:54:
1) In http://blog.erratasec.com/2014/09/bash-shellshock-bug-is-wormable.html meldt Robert Graham dat masscan wordt gebruikt om kwetsbare webservers van malware te voorzien.
2) In http://seclists.org/oss-sec/2014/q3/659 schrijft Florian Weimer onder meer: Hij verzoekt iedereen terughoudend te zijn met openbare discussies hierover en bugs via de reguliere kanalen te melden. Ik leid hieruit af dat er de komende dagen nog meer updates zullen volgen (de Red Hat teller staat al op 2).

Update 2014-09-25 1048: De URL bij "1)" was onjuist (wees naar de bash homepage), en "Shel Shock" gecorrigeerd in "ShellShock".

Update 2014-09-25 18:24:
Patch CVE-2014-6271 is niet alleen voor Red Hat onvolledig, maar voor alle besturingssystemen die bash gebruiken.

In de FAQ van https://access.redhat.com/articles/1200223 heeft Red Hat een tijdelijke workaround gepubliceerd (c code) maar waarschuwt zelf voor de risico's van het inzetten daarvan. Red Hat was er dus al geruime tijd van op de hoogte dat de patch voor CVE-2014-6271 onvolledig is, en heeft kennelijk CVE-2014-7169 aangevraagd voor het "nieuwe" lek.

De bron van het "nieuwe" bash lek is waarschijnlijk een discussie op de oss-sec maillijst, waarin Solar Designer schrijft dat:
nog werkt ondanks de huidige patch voor CVE-2014-6271. Aanvulling 2014-09-27 16:16: Tavis Ormandy (van Google) was de bron van kwetsbaarheid CVE-2014-7169, zie https://twitter.com/taviso/status/514887394294652929.

Na enige discussie heeft Chet Ramey (maintainer van bash) een laatste update gepost naar die maillijst. Die post, met gequote geschiedenis, is o.a. hier http://seclists.org/oss-sec/2014/q3/690 te lezen (de bijlage is een diff van zijn laatste patch). Ik vermoed dat deze nieuwe wijziging in de bash sourcecode nu uitgebreid getest wordt (en onderzocht wordt of nog meer kwetsbaarheden denkbaar zijn). Ik ga er vanuit dat er binnenkort een 2e set updates voor bash kwetsbaarheid CVE-2014-7169 zullen verschijnen (voor alle getroffen besturingssystemen).

De vraag van beheerders wanneer Red Hat patch CVE-2014-7169 zal uitbrengen, beantwoordt Ranjith Rajaram (van Red Hat) onderaan https://access.redhat.com/articles/1200223 nog steeds met: "We are working on CVE-2014-7169 with the highest priority, but I'm unable to offer a specific time-frame at this time. Please contact Red Hat Technical Support for further information".

Ik vrees dat er niets anders opzit dan afwachten, de Red Hat workaround installeren, zelf prutsen of servers uitzetten.

bash is vrij breed in gebruik, ook als "/bin/sh" (wat nogal eens compatabiliteitsproblemen oplevert met systemen waar dat niet het geval is), en ook in bv. allerlei embedded devices. Maar lang niet overal. *BSDs hebben bash standaard niet eens aan boord en debian gebruikt standaard dash in plaats van bash. Apparaten met embedded linux hebben veeleer busybox als shell. Dus het is niet zo dat alle Unix-achtige systemen kwetsbaar zijn. Maar het is wel zaak alle apparaten waar het op zou kunnen zitten even goed na te kijken.

Hoe groot is de kans dat je geexploit wordt als je geen CGI scripts draait en genoemde services verder niet open hebt staan vanaf het internet? (bepaald oa de CVE score en deze paniek volgens mij)
CGI scripts draait hopelijk bijna niemand meer en OpenSSH/Cups/Postfix zet je beperkt open en harden je.
Vooral intern lijkt me dit mooi exploitable maar we gaan de lijst volgen op oa; https://access.redhat.com/articles/1200223

OS X (*BSDs) heeft dit wel

Bug zit niet in unix of linux maar in bash. En dat is een groot verschil. Android draait ook linux maar geen bash en is dus niet vatbaar. Dit is net als roepen dat alle operating systems lek zijn als er een bug zit in VLC media player.

Anyway. Alle systemen dat bash gebruiken of cgi-bin zijn in principe kwetsbaar... je moet je alleen afvragen of bash aan de buitenkant benaderbaar is. Rechtstreeks, dan wel via scripts of applicaties. Zo nee. Dan heb je nog even de tijd. Zoja. Patch nu. De manier waarop deze bug gexploiteerd kan worden lijkt het erop of deze door de NSA geinjecteerd is en dat betekent dat er veel mensen zijn die deze informatie al heel lang hebben.

Je weet zelf ook wel dat Android zich niet houdt aan de volledige POSIX standaard (net als de meeste Linux based OS-en trouwens) en daarom geen BASH commando's 'pakt'. Op de meeste server/ontwikkel omgevingen kom je er echter niet onder uit en dus hangt het wel degelijk zeer dicht tegen het OS aan.

BASH is trouwens als app wel te installeren op Android.

Ook vmWare ESXi gebruikt bash; weliswaar hernoemd naar /bin/sh, maar het is wel vatbaar

[/quote]
Mijn MAC met 10.10 (Yosimite) is in elk geval gewoon kwetsbaar, ik ga er maar vanuit dat alle MAC's het potentieel zijn.

Update:

Zelfs met de laatste versie en patch ben je niet veilig!

Er werd een alternatieve manier gevonden om alsnog deze fout te misbruiken:
https://ictscripters.com/Thread/22629-Zware-beveiligingsfout-linux-bash/

Er is op dit moment dus geen oplossing voor dit probleem!

Het blijkt maar weer eens: geen enkel OS is waterdicht, ook Linux niet

ach gut..jarenlang werd arrogant en lacherig over windows gedaan maar nu blijkt dat linux zelf swiss cheese is.
heel stoer geen viruscanner zeggen nodig te hebben maar de werkelijke 'veiligheid' lag in de niet bestaande aandacht van hackers.
nou ja, dikke DUH ! toch?
alle linuxers aan de prozac en naar stichting korrelatie.
massaal netwerkverbindingen afsluiten want je bent tenslotte internet paranoide of niet...

Aan flamen hebben we niets, leer eerst, kom dan met een nuttige post, want de post is zoals je nick aangeeft: een 'potshot', nutteloos!

Heb je toch mooi een slak gevonen om zout op te leggen. "OS X" is de combinatie van een boel proprietary grafische meuk bovenop "darwin". Dat darwin baseert inderdaad op BSD code. Losjes. En ze gebruiken inderdaad bash als standaardshell, de prutsers. Maar om nou te gaan steggelen of het "een *BSD" is; ik denk er niet als eerste aan als ik aan de BSD familie denk. Valt wel onder de categorie "nakijken graag".


Zo, heb jij even mooi een reden gevonden wat van jezelf rond te schieten. Wist je dat dit gat ook windows kan treffen? Nee? Nou, dan heb je nu huiswerk uitzoeken hoe dat nou toch kan. Oh wacht, daar heb je helemaal geen zin in. Veel liever gewoon een grote bek opentrekken en herrie maken dan constructief bezig zijn.

Tja, dat heb je dan met een gratis OS; goedkoop is duurkoop: gatenkaas met veel lucht erin. eet smakelik!

Ja daar ben ik nu dus ook tegenaan gelopen... :(

Linxu heeft geen lekken

Voor de flamers linksom om rechtsom is mis nog wat denkwerk.
Iflamers omdat er genoeg draadjes te vinden zijn waar onderbuikgevoelens de boventoon voeren. Microsoft haat, apple fans Linux loekies met daarbij de alu hoedjes.

Volgens mij is het concept van deze vulnerability niet echt nieuw, zie:
https://www.owasp.org/index.php/Code_Injection
Of dat via shell-code sql-code of wat anders gaat maakt niet echt heel veel uit.
Heb je je systemen open op internet gehangen voor een stuk kritisch beheer (high priviledged), wat is er dan met de risico-analyse en bijbehorende zaken gebeurd? Ik wil niets bagatalliseren, maar dat stuk denkwerk mist hier.

Dat is fijn voor je, het gros van de mensen werkt met een OS X laptop in het bedrijfsleven en voor hun is dit dus relevant, wel/niet een BSD - mij is het eender, de exploit wordt er niet minder om.
Veel plezier met je andere shells en andere geniale BSD.

BashHeisa ..

Snappen doe ik het nog niet, ben ik de enige?
Zou iemand in meer gewone inizchtelijke mensentaal kunnen uitleggen wat nu eigenlijk de meer concrete security risico's zijn voor een gewone thuis gebruiker die verder geen webserver draait?

Mac OS X als voorbeeld genomen (#1) daar er daarvoor nog geen patches zijn verschenen (#2) en dit dus voor alle OS X versies lijkt op te gaan (heb ze nog niet allemaal getest maar denk dat dat ook niet hoeft ;-).

Klopt mijn indruk bij onderstaande mogelijke aanvalsvectoren of zit ik er geheel naast?

1) Remote acces poging / (targeted) attack via een geopende ssh verbinding en bij succes onder aanroepen van je terminal.app het gebruik van Bash commando's om 'remote taken uit te voeren'?

2) Geïmplementeerde (ongewenste) script functionaliteit in de code van een webpagina die je browser (ongewenste) Bash commando's op je systeem laat uitvoeren?

3) Bash commando's/scripts verborgen in zelfstandige file's (drive by downloads?) op je Mac die Terminal.app aanroepen voor uitvoer van Bash commando's op het moment dat je het file opent?

4) Gemodificeerde App's of programma versies die (als extraatje) ongewenste Bash commando's uitvoeren bij openen van het programma?

5) .. ?

'Niets' van dat alles? Hoe zit het dan wel?

Graag hoor ik het van wie het wel weet en beter snapt (voorbeelden erbij?).
Want pas als er een idee is van de mogelijke manieren van misbruik kan je (met enige creativiteit ook) nadenken over manieren om dit tegen te gaan, zolang er nog geen patches beschikbaar zijn, of zelfs voor systemen die geen support meer krijgen van de leverancier.

Alvast bedankt
;-)


#1 Laat svp uitgelokte Os flamebaits voor wat ze zijn en blijf bij de kern van deze website svp :
security issues bespreken & oplossingen vinden/bedenken
veel constructiever, nuttiger en leuker ook.

#2 Wat niet onverlet laat dat gebruikers oplossingen proberen te vinden
https://discussions.apple.com/thread/6558974
https://apple.stackexchange.com/questions/146849/how-do-i-recompile-bash-to-avoid-the-remote-exploit-cve-2014-6271-and-cve-2014-7/146851#146851
http://alblue.bandlem.com/2014/09/bash-remote-vulnerability.html

Voor degenen die 'gatenkaas' roepen: mitigatie is simpel, installeer een andere shell. Klaar. Ksh, csh, sh, dash, het voldoet allemaal. :)

Waar mensen werken, worden fouten gemaakt (zal nooit veranderen).

Niemand is perfect, dit geldt ook voor je favoriete OS.
En ja Ik gebruik Linux ,BSD, OS X, Windows 7/8.1/2012/2013 regelmatig naast elkaar (heb te maken met een OS-Mix omgeving vandaar).
Mijn persoonlijke voorkeur ligt wel bij een Linux omgeving omdat je daar meer de vrijheid hebt in wat je wilt installeren, dus geen vooraf bepaalde webbrowser of spelletjes als je daar geen zin in hebt.
Bij voorkeur een "customized install" in plaats van "bloated install" met zooi die je toch niet gebruikt.

Updates installeren: doen zo snel als je kunt, deze worden niet voor niets uitgebracht.
Voor mij is het routine om minimaal 3x per week even te controleren op nieuwe updates.

Voor de IT manager(s): zet je programmeur(s) niet zo onder druk om te leveren dan worden fouten eerder gezien (ervaring uit de praktijk).

Volgens mij valt het wel mee. Het artikel heeft het vooral over poort 80 en webservers. De doorsnee macgebruiker draait echter geen webserver en heeft zijn PC niet open aan het internet hangen.

Nee, je zult dan nog altijd bash moeten disablen.

Tja,ik ben dus ook kwetsbaar,het onderstaande bewijst dat met Maverics 10.9.5
Ik hoop dat als Yosemite uitkomt,dit lek is gedicht.


Last login: Thu Sep 25 23:08:14 on console
ip-217-102-1-135:~ Merijn$ env x='() { :;}; echo vulnerable' bash -c 'echo hello'
vulnerable
hello

Gelukkig voeren ze bij *nix geen "Patch Tuesday", maar wordt het probleem vrijwel op dezelfde dag gefixt. Oké, dit probleem is met één patch nog niet opgelost, maar die zal er zéér binnenkort waarschijnlijk wel zijn.

Leuk van al die Windows-fanaten om Unix/Linux/BSD te bashen (sic!), maar volgens mij is er niemand die ooit heeft beweerd dat Linux bugvrij is. Elke software heeft zijn kwetsbaarheden, alleen is het bij alle *nixen veel sneller gepatched dan bij Windows.

Nieuwe patch voor RHEL5,6,7 beschikbaar:


RHSA-2014:1306 Important: bash security update


Summary:

Updated bash packages that fix one security issue are now available for Red Hat Enterprise Linux 5, 6, and 7.

Red Hat Product Security has rated this update as having Important security impact. A Common Vulnerability Scoring System (CVSS) base score, which gives a detailed severity rating, is available from the CVE link in the References section.

The GNU Bourne Again shell (Bash) is a shell and command language interpreter compatible with the Bourne shell (sh). Bash is the default shell for Red Hat Enterprise Linux.

It was found that the fix for CVE-2014-6271 was incomplete, and Bash still allowed certain characters to be injected into other environments via specially crafted environment variables. An attacker could potentially use this flaw to override or bypass environment restrictions to execute shell commands. Certain services and applications allow remote unauthenticated attackers to provide environment variables, allowing them to exploit this issue. (CVE-2014-7169)

Applications which directly create bash functions as environment variables need to be made aware of changes to the way names are handled by this update. For more information see the Knowledgebase article at
https://access.redhat.com/articles/1200223

Heartbleed bedreigde 500.000 computers, terwijl Shellshock een bedreiging kan vormen voor maar liefst 500 miljoen computers.

bron:

http://www.hln.be/hln/nl/4124/Multimedia/article/detail/2063453/2014/09/25/Hackers-kunnen-uw-computer-overnemen-door-angstaanjagend-Shellshock-lek-dit-moet-u-weten.dhtml

In hoever is dit waar ?

Niet relevant, het het verschil zit hem in de mogelijke remote kwetsbaarheid. Die is tot nu toe bij heartbleed velen maken groter.

O?
Wat bedoel je daar precies mee? Welke maatregelen heeft de doorsnee gebruiker dan standaard genomen?

aan anoniem 09.01

achter een router

Dat heeft er helemaal niets mee te maken. Het organiseren van patches naar een vaste dag is gewoon een goed idee, ook organisatorisch. En gemiddeld worden linux systemen helemaal niet sneller gepatched. Door automatische updates is Windows sneller en niet afhankelijk van het initiatief of de kennis van de gebruiker. Overigens is er geen sprake van Linux bashen, waar normaal gesproken WEL sprake is van Windows bashen. Met name beginnende ICT'ers/studenten hebben nog wel eens de eniging om religieus met de OS discussie om te gaan. De nuance komt dan later, als er meer ervaring is. Wat dit geval (en heartbleed en alle gevallen die de laatste jaren niet het nieuws haalden) in ieder geval bewijst is dat Linux-fans niet zo hoog van de toren moeten blazen over security. Ervaren ICT'ers weten dit al lang, hopelijk snappen de beginners het nu ook.

Ik heb mijn Mac's ook niet open aan het intenet hangen,normaal gesproken ook met een virusscanner en binnen het eigen netwerk.
Dat hou ik goed in de gaten en spijker het goed dicht,zodat alleen apparaten die ik toewijs erin kunnen.
Een heel verhaal.
Maar ja ik vind wel dat apple deze serieuze bug in de bash moet verhelpen met een originele patch die via de update binnen is te halen,en niet moeilijk met een workaround verholpen moet worden.
Ook vind ik dat dit in de final release van OSX Yosmite verholpen moet zijn.

Troll alert

- "Overigens is er geen sprake van Linux bashen, waar normaal gesproken WEL sprake is van Windows bashen."
- "Met name beginnende ICT'ers/studenten hebben nog wel eens de eniging om religieus met de OS discussie om te gaan."
- "De nuance komt dan later, als er meer ervaring is. "
- "Wat dit geval (en heartbleed en alle gevallen die de laatste jaren niet het nieuws haalden) in ieder geval bewijst is dat Linux-fans niet zo hoog van de toren moeten blazen over security."
- "Ervaren ICT'ers weten dit al lang, hopelijk snappen de beginners het nu ook.

Aha! Daar had ik niet aan gedacht, in de bekende standaard fabrieksinstelling; àlle poorten gesloten?

Ik heb hier in Linux alweer een update gekregen, zou dit probleem voorkomen op Windows dan had ik er weer weken op moeten wachten voordat de update doorgevoerd zou worden. O ja, hoef niet eens opnieuw op te starten. ;)

ja en? ik doe niet hysterisch over een lek in windows.
linux gelovigen wel, en hang niet de heile boon uit wil je?
de jaaarenlange arrogantie dat linux zoveel beter is zorgt eindelijk eens voor wat realisme en hopelijk wat nederigheid.
en jij kan het gewoon niet zetten dat je een koekje van eigen deeg krijgt denk ik..
'constructief '' windows bashen was jarenlang een sport toch?
gaf je die ook een arrogant standje?
naaah.

Informatie van VMware:
vSphere ESXi Hypervisor
ESXi is not affected as it uses the ash shell (through busybox), which is not affected by the vulnerability reported for the bash shell.

Zie: http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2090740

Wel zou je dan misschien een beter geteste update gehad hebben, zodat er niet 3 of meer updates nodig waren om het
probleem haastig te fixen.

Voor Mac OS X gebruikers

Niet dat ik het er geheel mee eens ben, het is een informatief inkijkje.

What does the “Shellshock” bug affect?

http://www.thesafemac.com/what-does-the-shellshock-bug-affect/

Inderdaad de andere kant van de open source medaille is open chaos.

Wat een heibel,de mac is gewoon virusvrij.En daarmee basta.We (mac-gebruikers)laten ons niet bangmaken door een stelletje pro-microsoft gebruikers.
B.d.w.je moet wel verschil maken tussen virus of malware.Velen is dit niet helemaal duidelijk.
M.vr.gr.Kleis.