Tweede Bash-fix laat gaten over

De tweede patch voor het beveiligingsprobleem in Bash, dat aanvallers code laat uitvoeren op een systeem, blijkt net als de eerste patch onvoldoende. Het blijkt soms nog steeds mogelijk om code op een systeem uit te voeren.

De nieuwe kwetsbaarheid, die de Japanse beveiligingsonderzoeker Norihiro Tanaka ontdekte, is wel lastiger te misbruiken dan de oude kwetsbaarheid, die woensdag naar buiten kwam. Daarbij kon een aanvaller zijn eigen code toevoegen aan een environment-variabele, waarna hij werd uitgevoerd zodra de code een Bash-shell aanriep.

In de nacht van donderdag op vrijdag kwam een tweede patch voor het beveiligingsprobleem uit, maar ook die blijkt dus in bepaalde gevallen te omzeilen. Een aanvaller kan van een normaal Linux-commando, zoals 'cat' voor het uitlezen van bestanden, een environment-variabele maken en daar code in verstoppen. Vervolgens wordt de code die in de environment-variabele is verstopt 'vaker wel dan niet' uitgevoerd, schrijft Tanaka.

Volgens beveiligingsonderzoeker David Wheeler is de patch van donderdagnacht te waarderen, maar ligt het onderliggende probleem dieper. Bash moet volgens hem stoppen met het automatisch verwerken van environment-variabelen. Gebeurt dat niet, dan is het probleem niet volledig te verhelpen, denkt hij. "Ik heb er geen vertrouwen in dat de huidige patches iemand tegen zullen houden", aldus Wheeler, die aantekent dat hij websites uit de lucht heeft gehaald en niet online durft te winkelen uit vrees voor het probleem.

Het probleem is dat Bash niet meer backwards compatible zou zijn als environment-variabelen niet meer automatisch worden geparset, waardoor veel oudere software niet meer zal werken. Tegelijkertijd zal dat het probleem niet volledig oplossen. Het probleem is dat gebruikers apparaten als routers, nas-systemen en zelfs draadloze webcams met een ingebouwde webserver vaak minder snel patchen dan een desktop-besturingssysteem, en daardoor nog jarenlang kwetsbaar kunnen zijn.

Dat laatste 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.

Reacties (99)

[Sfynx]

Perfect, dan worden mensen misschien eens geforceerd om niet klakkeloos Bash als dependency aan te nemen voor hun scripts, maar gewoon de boel zo schrijven dat het op ieder systeem met een Bourne shell (/bin/sh) werkt. Als FreeBSD gebruiker erger ik me dood aan dergelijke Linuxisms.

(alleen wel jammer dat veel Linux distro's het nodig vinden om /bin/sh keihard te verwijzen naar /bin/bash )

[Reactie gewijzigd door Sfynx op 26 juli 2024 18:02]

[TheMak]

Nou ja, keihard...., bash probeert zich als sh te gedragen als hij aangeroepen wordt als /bin/sh. Je zou kunnen zeggen dat bash twee verschillende shells zijn: bash en iets dat lijkt op sh.

[elmuerte]

Bourne shell is dood, geen enkele distributie van de afgelopen 15 jaar gebruikt het nog. Ook op BSD is /bin/sh een Bourne shell clone (mogelijk ash, ksh or een csh variant). En allemaal hebben ze non-POSIX extensies die men zou kunnen gebruiken.

[CyBeR]

Ook hier weer telegraaf-niveau titels door de redactie van t.net. Die tweede fix laat op dit moment helemaal geen bekende gaten over maar laat *mogelijk* gaten over vanwege de manier van fixen die inherent (conceptueel) problematisch is. Het probleem is dat bash code uitvoert in environment variables. Helaas is dat iets wat niet zomaar gewoon er uit te halen is vanwege compatibiliteit. Dus doet bash nu een soort input-validatie maar daarmee pak je, is de mening van de auteur van de bron, nooit alles.

[HKLM_]

Hoe komt het dat we na twee fixen nogsteets dit probleem niet de wereld uit geholpen kunnen krijgen ?

[Niemand_Anders]

Een simpele oplossing is natuurlijk door gewoon geen bash in CGI scripts te gebruiken op je webserver. Daar zijn veel betere script talen voor zoals Perl, PHP, Python en Ruby.

Als je bash niet blootstelt aan remote access zoals bij CGI scripts op je webserver, dan is de bug vele malen minder erg. Immers iedere shell heeft zijn eigen set environment variables en je kunt niet de environment variabelen van een andere users veranderen.

De shellshock bug welke nu nog aanwezig wordt gebruikt in vrijwel elk bash script. Bijvoorbeeld om de locatie van een utility te bepalen (mysqlbackup bijv).
MYSQLBACKUP=`which mysqlbackup`
of
MYSQLBCKUP=$(which mysqlbackup)


En vervolgens gebruik je $MYSQLBACKUP in je scipts. En juist daar zit nu het probleem.
Bij shellshock plaats je bijvoorbeeld in je 'X' variable een extra opdracht welke op dezelfde manier wordt uitgevoerd als de $MYSQLBACKUP variable.

Command substitution een van de belangrijkste pijlers van bash is en juist dat wordt nu misbruikt.
Het gevaar zit nu nog vooral in scripts welke door verschillende users op een systeem worden gebruikt. Mijn editor onder linux is 'joe' en deze ruimt niet alle rommel op. Als JOE crashed heb je een DEADJOE bestand en verder maakt joe ook een backup van een bestand zodra je hem wijzigt. Hoera voor backups! Alleen als jij een init script wijzigt wil je dergelijke backup bestanden niet tot in de eeuwigheid bewaren. Dus heb ik een 'cleanjoe' script geschreven welke vanaf het huidige path een simpele find doet en daarna de resultaten verwijderd. Maar als ik nu dit script wijzig en tevens ook een command in de environment variabele 'EDITOR/VISUAL' set, dan is elke user welke mijn cleanjoe script vulnerable. Op het moment dat zijn bijvoorbeeld 'crontab -e' uitvoeren wordt automatisch EDITOR uitgevoerd.

Je kunt proberen te voorkomen dat een bash script variabelen van het caller-process niet kan veranderen, maar heeft Debian weer een probleem omdat dan niet meer de /etc/default directory werkt. En dan moeten beheerders weer rechtsstreeks de init bestanden gaan aanpassen. Daar zitten we ook niet op te wachten.

Maar is dit nu echt nog een probleem? Ik vind persoonlijk van niet. Kijk ik kan ook een Windows programma schrijven welke een aantal registry aanpassingen doet zodat als jij een .pdf wilt printen vanuit de explorer, ineens een ander programma wordt gestart.

Bash is nooit geschreven om gebruikt te worden in een webserver omgeving. Waarom gebruikt men dan toch bash? Omdat het een aantal features heeft, welke standaard niet terug vind in andere commandline script talen. Bash gebruiken via mod_(fast)cgi is eigenlijk net zo fout als 'php -i' als login shell toewijzen. Het werkt, je kunt je collega er erg mee zieken, maar je gerbuikt de taal niet in de context waarvoor deze origineel is geschreven..

[takis]

't Zijn niet enkel CGI bash scripts die kwetsbaar zijn, ook b.v. Python scripts die indirect bash gebruiken via b.v. os.system of subprocess zijn kwetsbaar (mits gebruik van terminal=True).

[goarilla]

Python scripts die indirect bash gebruiken via b.v. os.system

Er is ook nog de popen familie van functies. Dit is wel enkel zo als /bin/sh bash is. De systemen, met een systeem shell (/bin/sh) die niet bash is: *BSD's en ubuntu's (dash), zijn dus minder kwetsbaar voor deze problemen. Moedigen kunnen hun /bin/sh ook veranderen naar iets anders dan bash maar dat zal dingen breken !

[Reactie gewijzigd door goarilla op 26 juli 2024 18:02]

[GekkePrutser]

Nou, in principe is /bin/sh ook gewoon een bepaalde shell, namelijk de Bourne Shell. Bash is een doorontwikkeling hiervan (het staat voor Bourne Again Shell, natuurlijk een woordgrapje )

Deze shell is erg oud en heeft geen last van de bash bug, hij is niet zo vriendelijk in interactief gebruik (geen tab completion bijv.) maar kan shell scripts nog steeds prima runnen! Hij is bovendien een stuk effcienter aangezien bash maar liefst bijna een hele megabyte is. De Bourne Shell is maar 20kB ofzo, veel efficienter voor scripting (en door minder code minder kans op fouten).

Veel oudere Unix systemen hebben gewoon deze bourne shell als /bin/sh, het is pas de latere Linuxen die /bin/sh naar /bin/bash gesymlinked hebben. Het is dus niet zo dat /bin/sh op een Unix systeem gelinkt zou moeten zijn aan een of andere shell, voor de compatibiliteit is het juist beter van niet.

[Reactie gewijzigd door GekkePrutser op 26 juli 2024 18:02]

[goarilla]

Veel oudere Unix systemen hebben gewoon deze bourne shell als /bin/sh, het is pas de latere Linuxen die /bin/sh naar /bin/bash gesymlinked hebben. Het is dus niet zo dat /bin/sh op een Unix systeem gelinkt zou moeten zijn aan een of andere shell, voor de compatibiliteit is het juist beter van niet.

Voor de compatibiliteit laat je best je /bin/sh voor wat het is. Genoeg bashismen in de init scripts van een (bash) distro vandaag de dag.

[GekkePrutser]

Hangt ervan af waarmee je compatible wil zijn Met Linux, inderdaad. Maar andere unixen zoals FreeBSD, OpenBSD, Solaris, HP-UX, en nog veel meer hebben (in elk geval standaard) geen bash maar wel de bourne shell, juist voor shell scripts.

Daarom is het juist handig als je een shell script compatible maakt met meer dan alleen Linux.

[Reactie gewijzigd door GekkePrutser op 26 juli 2024 18:02]

[goarilla]

Daarom is het juist handig als je een shell script compatible maakt met meer dan alleen Linux.

Ik streef altijd naar POSIX compatibiliteit. Maar dat verwachten van alle maintainers van een moderne Linux distro zou ik niet doen.

[Thystan]

Is dit geen goede fix dan?

Edit: Bourne ipv Bourne Again Shell gebruiken

[Reactie gewijzigd door Thystan op 26 juli 2024 18:02]

[GekkePrutser]

Ja, maar het probleem is wel dat sommige script bash-specifieke dingen (bashisms) gebruiken, zoals goarilla hierboven al zei. Dus het is in veel gevallen geen afdoende oplossing.

[elmuerte]

Alleen als je environment al bevuild is.
system() aanroepen via mod_php, mod_perl, mod_python heeft geen negatieve neveneffecten omdat er niet automatisch user input als environment variabelen geregistreerd worden. als je PHP/Perl/Python script niet via de specifieke apache module lopen maar via mod_cgi heb je wel het probleem.
De manier waarop CGI werkt maakt het een probleem samen met deze Bash "feature". (i.e. HTTP request headers worden als environment variabelen geregistreerd).

[CAPSLOCK2000]

Een simpele oplossing is natuurlijk door gewoon geen bash in CGI scripts te gebruiken op je webserver. Daar zijn veel betere script talen voor zoals Perl, PHP, Python en Ruby.

Als je bash niet blootstelt aan remote access zoals bij CGI scripts op je webserver, dan is de bug vele malen minder erg. Immers iedere shell heeft zijn eigen set environment variables en je kunt niet de environment variabelen van een andere users veranderen.

Je onderschat het probleem. Als je in je Perl programma 'exec' of 'system' gebruikt dan ben je als nog de pineut. Perl (of iets anders) gebruiken is dus niet genoeg. Je moet zeker weten dat er nergens externe commando's aangeroepen worden direct of indirect Bash gebruiken.

Daarnaast zijn er ook nog systemen die een klein shell-script gebruiken als ze CGI-scripts geschreven in een andere taal aanroepen.

[Verwijderd]

Perl/Python/php/random zijn het probleem niet. Hoe je het wet of keert, het probleem zit primair in bash.

Hoe een popen/exec/backtick commando ook geinterpreteerd wordt, als er een callback naar de shell plaats vindt dan zal het primair via de default shell gaan.

Het probleem zit niet in taal x/y/z of omgeving native/java/mono, het zit in bash.

Het is leuk dat een toepassing van de shell in CGI invloed heeft, maar serieus; welke weldoende python/perl/*whatever* developer laat zijn omgeving in CGI draaien of vertrouwt op een onbekende omgeving?

[Reactie gewijzigd door Verwijderd op 26 juli 2024 18:02]

[CAPSLOCK2000]

Perl/Python/php/random zijn het probleem niet. Hoe je het wet of keert, het probleem zit primair in bash.

Dat ben ik helemaal met je eens. Wat ik probeer duidelijk te maken is dat bash op veel meer plekken gebruikt wordt dan wordt gedacht. Ik heb hier een paar keer gelezen dat als je Perl/P* gebruikt je dus veilig bent. Dat is helaas niet waar. Ook als je applicatie (voornamelijk) in P* is geschreven dan kan het nog zijn dat er onderwater ergens bash gebruikt wordt. Dat maakt deze bug zo vervelend.
Als je de applicatie helemaal zelf hebt geschreven dan kun je misschien zeggen dat die applicatie veilig is, maar de meesten draaien code die ze niet zelf hebben geschreven en waarvan ze dus niet weten of er links of rechts niet iets via de shell gedaan wordt.

Het is leuk dat een toepassing van de shell in CGI invloed heeft, maar serieus; welke weldoende python/perl/*whatever* developer laat zijn omgeving in CGI draaien of vertrouwt op een onbekende omgeving?

Ten eerste kiest de beheerder waar de code draait, niet noodzakelijk de developer. Ten tweede heeft CGI allerlei voordelen boven embedded code waardoor het veel gebruikt wordt. Ten derde leven we niet in een ideale wereld maar worden de meeste applicaties gehost door mensen die niet echt weten waar ze mee bezig zijn.

[Reactie gewijzigd door CAPSLOCK2000 op 26 juli 2024 18:02]

[Verwijderd]

Ten eerste kiest de beheerder waar de code draait, niet noodzakelijk de developer. Ten tweede heeft CGI allerlei voordelen boven embedded code waardoor het veel gebruikt wordt. Ten derde leven we niet in een ideale wereld maar worden de meeste applicaties gehost door mensen die niet echt weten waar ze mee bezig zijn.

@1) Absoluut. Zodra je in een omgeving raakt waar jij niet de initiele keuzes hebt gemaakt, heb je te maken met tech-debt (om het even positief te benoemen).

@2) Persoonlijk ben ik (gelukkig?) nog niet met die situaties in aanraking geweest. Mocht je ervaring hebben waar CGI serieus voordelen bood over
/mod_(p*?)/ dan zou ik (via een reactie of DM) daar graag meer over horen.(NB: ik heb enkel CGI ervaring met Apache. Ik heb nog nooit CGI onder IIS hoeven ondersteunen.)

@3) Lang geleden (onderhand bijna 15 jaar) had ik eens een aantal scripts via CGI draaien en in 1 van die scripts (hsx.cgi) bleek een gat in te zitten waar ik niet van wist. Wat mij toen gered heeft was dat de crackers dachten dat ze met een x86 systeem i.p.v. Sparc te maken hadden. In de week waar dat gebeurde heb ik een heleboel geleerd. Ik weet nog steeds niet of het geluk (x86 vs sparc) of vaardigheid was (log en filesystem forensics) waardoor de betreffende crackers opgepakt zijn.

Wat ik met @3 probeer te zeggen is; zelfs mensen die over het algemeen weten waar ze mee bezig zijn, hebben niet altijd de tijd om alles grondig na te pluizen. Echter, ik snap je punt volledig.

edit:

Ik had je graag een +1 gegeven

[Reactie gewijzigd door Verwijderd op 26 juli 2024 18:02]

[CAPSLOCK2000]

@2)
Bij mod_p* draait de code onder de user van webserver. Als je meedere sites op dezelfde machine host wil je dat misschien niet. Als je cgi gebruikt kun je iedere site z'n eigen UID geven. Dat is erg fijn als je veel websites host van mensen die niks van internetsecurity weten. Dat is voor mij de belangrijkste reden.

Een nadeel van mod_p is dat ieder proces van de webserver een volledige copy van mod_p* bevat, of je die nu gebruikt of niet. Als je een drukke webserver hebt die ook nog verschillende talen ondersteunt tikt dat flink door.

In theorie kun je ook nog je applicatie-code op andere machines draaien dan je webserver maar dat heb ik zelf nooit gebruikt.

Een klein voordeeltje is dat webserver en applicatie onafhankelijk van elkaar herstart kunnen worden. Je kan ook nog verschillende PHP (of wat dan ook) configuratiefiles gebruiken voor verschillende sites.

[Reactie gewijzigd door CAPSLOCK2000 op 26 juli 2024 18:02]

[Verwijderd]

Een aantal mod_p's (i.i.g. mod_perl) hanteren copy_on_write, wat (in een notedop) betekent dat pages in memory alleen gekopieerd worden in specifieke gevallen.

Voor de rest van je reactie; dank Ik was het UID vergeten.

[cowbalt]

ik ga in een groot deel van je verhaal mee maar, maar PHP betere script taal? Ik meen dat we het hier voornamelijk over webserver beveiliging hebben, en dan adviseer je PHP.....

sorry voor de offtopic

[Silmarunya]

Men wil snel zijn - enkele uren na het bekend worden van het probleem was de eerste patch er al. Snel en grondig zijn moeilijk te combineren.

Maar merk wel op dat na patch 1 het lek als fors moeilijker te misbruiken was en dat het na patch 2 nog wat moeilijker is geworden. Zo'n snelle maar onvolledige oplossing is vanuit veiligheidsoogpunt te verkiezen boven de tijd nemen voor een perfecte oplossing en ondertussen het lek dagen tot weken volledig openlaten.

[OverSoft]

Omdat het probleem inherrent aan de werking van bash is. Bash moet environment variables parsen om veel scripts te laten werken.

Hierdoor is het niet op te lossen zonder aanpassing van de scripts die bash gebruiken (en dat zijn er heel heel veel)

[Blokker_1999]

De problemen die geraporteerd zijn geweest zijn wel degelijk verholpen en bash is daardoor niet zo eenvoudig meer te misbruiken. Wat men nu aanhaald is vermoedelijk inherent aan bash en kan men dus niet oplossen zonder de werkingsprincipe van het systeem aan te passen waardoor heel veel software niet meer zou werken.

Het is alsof dat functionaliteit van explorer in windows morgen voor een kwetsbaarheid zou zorgen. MS kan dat patchen, maar daardoor zouden de meeste van je programmas niet meer werken. Wat ga je dan doen?

[Verwijderd]

Hoe komt het dat we na twee fixen nogsteets dit probleem niet de wereld uit geholpen kunnen krijgen ?

Wel dat is voor een goed deel uitgelegd in het artikel!

[MegaTronics]

Waarschijnlijk omdat het probleem dieper ligt dan het in eerste instantie leek.

[P1nGu1n]

Dat is juist waar dit hele artikel over gaat?

[Gamebuster]

Ik zie het probleem niet echt, hoe zou een kwaadwillend iemand uberhaupt "cat" overschrijven naar iets anders zonder directe commandline toegang tot de server? Of mis ik iets?

[Reactie gewijzigd door Gamebuster op 26 juli 2024 18:02]

[curry684]

Ja je mist iets. Met name alle genoemde routers en andere hardware met 'embedded webservers' voeren veel code uit via Common Gateway Interface, oftewel CGI-scripts. In deze omgevingen, maar ook bijvoorbeeld als je PHP draait via CGI ipv de gangbaardere mod-php5 van Apache, worden veel servervariabelen doorgegeven via de environment variabelen.

Specifiek in het geval van PHP-CGI komt bijvoorbeeld de 'User Agent' van de browser, welke triviaal is te wijzigen cq. vervalsen, via environment variables binnen, en kun je dus op die manier code injecten in het gelanceerde proces, onder de security van Apache (of, bij bepaalde configuraties, een specifieke user).

Mag wel hopen dat ook de makers van bijv. PHP en andere gangbare software die nog wel eens op CGI draait aan hun kant ook patches aanbrengen om misbruik te voorkomen, bijv. suspicious user agent strings rejecten, om zo de attack surface als geheel te verkleinen op het net.

[Reactie gewijzigd door curry684 op 26 juli 2024 18:02]

[Gamebuster]

Aah natuurlijk, alle headers worden gezet in environment variablen bij CGI

[MadEgg]

Maar dat was de oorspronkelijke bug. De bug die in dit artikel besproken wordt is veel lastiger te misbruiken, hoe krijg je via CGI ooit cat gealiast?

[Verwijderd]

Twee commando's via && of zelfs maar 1 commando met een embedded script.

[Reactie gewijzigd door Verwijderd op 26 juli 2024 18:02]

[CAPSLOCK2000]

'cat' wordt niet op disk overschreven maar er wordt een alias met de naam 'cat' gemaakt in het geheugen van het kwetsbare proces.

[Gamebuster]

Die had ik door

[Titan_Fox]

Ik zou het dan zo ontwerpen dat je voor Bash root-toegang nodig hebt alvorens het automatisch environment-variabelen verwerkt. Gewoon dat je eerst een prompt "enter password" krijgt of zo.

[sfranken]

Los het dan ala vi/vim op. Je maakt/packaged een nieuwe versie van BASH met deze fixes (even versimpeld), die installeer je als 'bashim' ofzo en je maakt een symlink van /bin/bash naar /bin/bashim met als optie iets als '--compatibile' ofzo, dat bashim zich zoveel mogelijk gedraagt als BASH.

[mkools24]

RedHat heeft wat regels gepost voor mod_security om de exploit tegen te gaan. Ze zijn hier te vinden:

http://www.ehackingnews.com/2014/09/shellshock-bash-bug.html

Ik gebruik zelf geen cgi scripts maar ik heb ze toch maar toegepast omdat m'n server toch bash draait en er nog geen update is (FreeBSD).

[himlims_]

env X="() { :;} ; echo busted" /bin/sh -c "echo stuff"

zou volgens the register voldoende moeten zijn om te controleren of jouw systeem kwetsbaar is

[mkools24]

Yep hij Is ook kwetsbaar maar ik draai niks waardoor die code remote Is uit te voeren.

[kokx]

Zeg dat niet te snel. De DHCP client dhclient is al kwetsbaar voor deze bug. En die wordt op erg veel systemen gebruikt.

[Reactie gewijzigd door kokx op 26 juli 2024 18:02]

[mkools24]

Ja maar dat gaat je remote niet lukken en daar gaat het vooral om. Maar daarom heb ik ook de mod_security rules toegepast, just to make sure.

[Thystan]

Is het niet mogelijk om daar gewoon Bourne voor te gebruiken?

[sfranken]

Mooie uiteenzetting van argumenten die je hier tegenover zet. Echt een wereldse reactie waar we wat aan hebben..

[Verwijderd]

Een "--compatibile" [spelling] gaat anderen absoluut helpen om hun interpreted interpolated shell leak te verhelpen.

Los van dat een "--compatibile" argument in vrijwel alle gevallen niet bestaat; je bashim suggestie geeft mensen een schijngevoel dat het probleem is opgelost.

Daarnaast, zal je vast al wel door hebben dat je "--compatible" faux-pas geen oplossing is.. Dat je reactie een +2 kreeg wekt bij mij het idee dat mensen modereren op de toon van een bericht i.p.v. dat er gemodereerd wordt op eigenlijke inhoudelijke kennis.

En om iets op een
"Hoi, dit is BASIC, een voorbeeld programma:
10 print "Hallo"
20 goto 10
" niveau uit te leggen gaat me op t.net echt veel te ver.

[sfranken]

1) Ik heb nergens gezegd dat het om een uiteindelijke fix gaat, alleen een hotfix (indien mogelijk)
2) No shit dat het geen echte oplossing is, zie punt 1

Maar goed, er zijn e.a. patches al voor uitgekomen en men is ervan bewust, dat is ook wat waard.

En je hoeft iets niet simpel uit te leggen, maar om nou zó kort door de bocht te gaan is de andere uiterste..

[Blokker_1999]

Dat lost nu eens 0;0 op aangezien er vandaag heel veel software is die er op vertrouwd dat bash werkt zoals het werkt. Ofwel vind men een oplossing voor de huidige problemen, ofwel blijven we nog lang met een risico zitten.

[cappie]

Zojuist die test gedaan, maar hier werkt het prima.. ik krijg die echo niet in beeld.. niet iedereen loopt dus risico..

[Reactie gewijzigd door cappie op 26 juli 2024 18:02]

[Jack Flushell]

Je hebt het artikel niet of slecht gelezen. Je kan het op meerdere manieren gebruiken / misbruiken. Die ene test is er 1 van en die werkt nu niet meer. Maar er is meer...

[Reactie gewijzigd door Jack Flushell op 26 juli 2024 18:02]

[cappie]

Ik heb uiteraard verder gelezen dan m'n neus lang was en meerdere vulnerability tests proberen te doen.. inmiddels heb ik kunnen concluderen dat al mijn systemen (inclusief router/NAS) gepatched zijn..

Heb jij nog een test die er door komt dan?

[Jack Flushell]

Nee die is er (denk ik) nog niet. Maar het artikel gaat erover dat er iets mis is _in de basis_. Het is denkbaar dat het nog op andere manieren misbruikt kan worden:

Volgens beveiligingsonderzoeker David Wheeler is de patch van donderdagnacht te waarderen, maar ligt het onderliggende probleem dieper.

[z1rconium]

Als je echt een wereldwijd disaster wilt, dan zou je jouw suggestie inderdaad moeten implementeren. Ik vrees dat de wereldwijde schade dan een factor 1.000.000 hoger ligt dan nu (onderschat).

ontopic:
elk beschikbare linux commando word nu natuurlijk getest en 1 voor 1 komen ze naar buiten, gister was de suggestie van dhcp, nu cat, er zijn er nog een hoop te gaan. vi wellicht ?

[Reactie gewijzigd door z1rconium op 26 juli 2024 18:02]

[CAPSLOCK2000]

elk beschikbare linux commando word nu natuurlijk getest en 1 voor 1 komen ze naar buiten, gister was de suggestie van dhcp, nu cat, er zijn er nog een hoop te gaan. vi wellicht ?

Nee, het probleem zit niet in de commando's. Er wordt een bash-alias aangemaakt met de naam van een bestaand commando. Eerlijk gezegd snap ik nog niet helemaal wat er nu weer aan de hand is maar ik weet wel zeker het het probleem in bash zelf zit, niet in die andere commando's.

[M@rijn]

Al is niet iedereen het daar over eens; t kan ook aan de implementatie van de software die gebruik maakt van BASH liggen?

https://news.ycombinator.com/item?id=8376376

[dajero]

Uit het artikel waarover in jouw link wordt gesproken:

And in the meantime, the undocumented (and under-published)
feature of bash is forgotten.

Het is maar net waar je de grens tussen bug en ongedocumenteerde functionaliteit legt.

[[Yellow]]

Daarom heb ik tijdelijk maar even alle CGI modules uitgezet...
Weet iemand overigens of het op te lossen is door apache onder een user te draaien die Dash als shell gebruikt?

[Mijzelf]

Maakt niet uit. Als je systeem kwetsbaar is, dan zit er ergens een bash script in de executie keten, en die specificeerd zijn eigen shell:

#!/bin/bash

Overigens heb ik op mijn eigen server een paar scripts aangepast om dash te gebruiken ipv bash, maar toen werkten ze niet meer. De dialekten van beide script talen lijken dus niet genoeg op elkaar.

[[Yellow]]

Ik ben bekend met basishm en is vaak niet eens zo heel lastig om het om te zetten.

Maar on-topic: door Apache onder een Dash shell te laten draaien zal de mod_cgi.so toch een Dash script spawnen? Aangezien die niet vatbaar is zou je op deze manier het hele probleem toch kunnen omzeilen?

[cyberstalker]

Niet per se. Wat nou als je PHP-script weer een ander proces start. Een aantal methodes (zoals bijvoorbeeld shell_exec) draaien het gegeven commando in een shell. Volgens mij zijn de environment-variables waarmee PHP gestart is ook weer beschikbaar in deze shell.

Het wordt natuurlijk wel een stuk minder waarschijnlijk dat het mis kan gaan.

[WhatsappHack]

En daar hebben ze disable_functions voor uitgevonden natuurlijk

[Mijzelf]

Apache onder Dash draaien? Bij mij zit er geen shell onder apache. Als een tekstbestand zonder expliciete SheBang wordt uitgevoerd, wordt $SHELL gebruikt. Maar deze is overgeerft uit /etc/init.d/httpd, welke op mijn Debian system /bin/sh gebruikt, wat dash is.

Ik betwijfel of de shell uit /etc/passwd ooit wordt gelezen, behalve bij de initieele login.

[goarilla]

Als je wijd inzetbare shell scripts wil schrijven houd je dan aan die subset (POSIX) die ze allemaal "zouden moeten" ondersteunen (http://pubs.opengroup.org/onlinepubs/9699919799/).
Schrijf wrappers om de verschillen tussen systeem utilities in de Unixes op te vangen (gpart vs fdisk, pw vs usermod, ...). Je kan natuurlijk ook gewoon overgaan op perl en python die toch overal redelijk "gelijk" zijn in vergelijking.

[Reactie gewijzigd door goarilla op 26 juli 2024 18:02]

[Juup]

Waarschijnlijk is het alleen maar nodig om CGI Bash scripts tijdelijk uit te zetten of om te schrijven naar een andere taal (bv. Perl).

[RoestVrijStaal]

Weet iemand overigens of het op te lossen is door apache onder een user te draaien die Dash als shell gebruikt?

In theorie moet het kunnen, want zowel bash als dash als andere *nix-shells zijn POSIX-compatibel.

In de praktijk is het dezelfde situatie als webbrowsers. Niet iedere shell is 100% compatibel of houdt er een eigen interpretatie op na.

Daarnaast heeft bash uitbreidingen die andere shells niet hebben en vice versa.

Zoals IE6 vroeger en Webkit/Chrome nu, is bash de facto Dè standaard geworden.

[Verwijderd]

Het probleem ligt niet alleen bij Bash. Er is ook bewustwording nodig bij web server admins en applicatiebeheerders, dat je op basis van de classificatie van scripts de juiste rechten geeft. Niet alle scripts hebben de noodzaak om 'execute' rechten te krijgen.

[OverSoft]

En niet zomaar naar environment variables laten schrijven. Dat lijkt me een veel groter probleem namelijk.

[Alex3]

En variabelen zijn toch niet bedoeld om uit te voeren? Kan dat niet voorkomen worden?

[OverSoft]

Als je in Bash (of welke andere shell) dan ook dit soort haakjes gebruikt: `commando`, dan wordt de output van dat commando in de variable geschreven. Dat is simpelweg een feature die ook door veel verschillende scripts gebruikt wordt, ook met environment variables.

Wat eigenlijk echt de boosdoener is, is dat het blijkbaar mogelijk is om environment variables te schrijven vanaf de buitenwereld. Dat is trouwens iets wat echt nieuw voor me is, en me ook echt verbaasd. Ik gebruik eigenlijk alleen apache in combinatie met mod_php en mod_perl en daar kan je vanaf buitenaf helemaal niet bij de envvars komen.

Dat ze dit nu "gefixed" hebben binnen bash is eigenlijk gewoon een work-around voor andere programma's die naar envvars schrijven zonder te checken wat hier in staat.

[BCC]

Jawel, kijk maar eens bij php info bij en env VARs. Een groot gedeelte van de request headers worden bijvoorbeeld via de enviroment vanuit apache aan PHP doorgegeven, en daar zit hem precies het probleem.

[OverSoft]

Dat is simpelweg niet waar. Dat is alleen zo als je PHP als CGI app draait, en dat gebeurd al zeker 8 jaar niet meer standaard.
Als je PHP via mod_php draait, dan is dat echt niet meer zo.

[SWINX]

Tenzij je dit zelf weer in je php.ini hebt ingesteld om de $_ENV te vullen.
Standaard zal dat idd niet zo zijn.

[Reactie gewijzigd door SWINX op 26 juli 2024 18:02]

[BCC]

Ok, dat is nieuw voor mij. Mod_ruby bijvoorbeeld is wel vulnerable om deze reden http://blog.phusion.nl/20...-6271-bash-vulnerability/

[deadinspace]

Wat eigenlijk echt de boosdoener is, is dat het blijkbaar mogelijk is om environment variables te schrijven vanaf de buitenwereld. Dat is trouwens iets wat echt nieuw voor me is, en me ook echt verbaasd. Ik gebruik eigenlijk alleen apache in combinatie met mod_php en mod_perl en daar kan je vanaf buitenaf helemaal niet bij de envvars komen.

Dat is bijzonder gebruikelijk, bijvoorbeeld voor CGI en FastCGI (en daarmee wat, de helft van het internet?). Dan staan bijvoorbeeld de URI, de hostname en de headers in environment variabelen (met goed-gedefinieerde namen, niet zomaar willekeurige variabelen).

Het probleem is eerder dat bash (de inhoud van) environment variabelen gaat uitvoeren. En dan niet eens environment variabelen met specifieke namen, nee, ALLE environment variabelen.

Dat ze dit nu "gefixed" hebben binnen bash is eigenlijk gewoon een work-around voor andere programma's die naar envvars schrijven zonder te checken wat hier in staat.

Nee, bash moet geen envvars uitvoeren

[dajero]

Als je in Bash (of welke andere shell) dan ook dit soort haakjes gebruikt: `commando`, dan wordt de output van dat commando in de variable geschreven. Dat is simpelweg een feature.

Je haalt hier twee dingen door elkaar. Code tussen backticks (`) wordt uitgevoerd, en vervangen door de uitvoer, waarna die uitvoer weer toegekend kan worden aan een variabele, of verder bewerkt.

Deze (goed gedocumenteerde) functionaliteit staat los van de shellshock bug.

[Reactie gewijzigd door dajero op 26 juli 2024 18:02]

[Verwijderd]

Het spijt me enorm, maar ik moet dit vragen: hoe ben je tot mod_perl gekomen zonder ooit een CGI script te hebben gedraaid?

[Verwijderd]

Dat is iets wat je niet eens WIL voorkomen.

Een variabele kan in meerdere talen een komplete ORM bevatten welke via eval wordt geinstianteerd (verre van ideaal, maar het komt voor) of een developer baseert zijn script op "bekend" gedrag van zijn linux distro (even achterwege laten dat een andere distro kompleet anders is qua shell of Sys-V implementatie).

TL;DR: Zolang 'eval', 'compile', 'remote executions' toegestaan zijn in welke taal dan ook zullen dit soort lekken voor blijven komen. UIteindelijk ligt de verantwoordelijkheid bij de "defensive" developer.

[Blokker_1999]

Het lijkt me dat als je iets door bash wilt laten uitvoeren, dat je dat toch echt uitvoerbaar moet maken. Wel is het inderdaad zo dat user rechten zeer belangrijk zijn en dat je dus voorzichtiger moet zijn.

Maar stel dat je op deze manier code kan uitvoeren via bijv. CGI/PHP, ..., dan zou je dus wel degelijk bijvoorbeeld een cat kunnen doen van een configuratiebestand van een website en zo de SQL login data gaan uitlezen om die dan weer verder te gaan misbruiken want je kan nu eenmaal niet zeggen dat je webserver niet mag raken aan de config files van je website of dat je webserver geen verbinding mag opzetten met je databaseserver ...

[Mijzelf]

Niet alle scripts hebben de noodzaak om 'execute' rechten te krijgen.

Daarmee ondergraaf je de hele functie van een script. Wat doet deze verder nog dan gestructureerd externe executables uitvoeren?

[sfranken]

Een scripttaal zoals PHP heeft geen execute rechten nodig, alleen lees rechten door httpd/apache2/www-data sinds Apache + mod_php de scripts uitvoert. Dat is niet overal zo maar in 99% van de gevallen (die ik meemaak) wel.

[Verwijderd]

Je wilt dat een script alleen dat gene uit moet voeren wat het mag uitvoeren en niet meer. En je moet natuurlijk de juiste 'ownership' meegeven. Maar vanuit eigen ervaring doe je er juist verstandig aan om niet alle scripts een 'execute' recht te geven omdat je ziet dat een script vaak genoeg meer kan dan eigenlijk niet de bedoeling is.

[Erulezz]

Ok dit is vervelend.. En wat is nu de beste manier om je hiertegen te wapenen? Alles is up2date, inclusief de laatste yum patches.

[Mijzelf]

Ik vraag me af of het mogelijk is om bash te vervangen door een soort 'pre-parser' die de environment variabelen analyseert en eventueel aanpast, voordat hij de oorspronkelijke bash aanroept.

[blorf]

Niet zo'n gek idee volgens mij. bwv test zou je de bash binary kunnen renamen en vervangen met een C-progje dat checkt of het om een CGI-call naar een bash-script gaat en zo ja de hele CLI-string inclusief alle parameters filtert op variabele-toewijzingen die de kwalijke constructie bevatten plus een waarschuwing geven voor een "intrusion attempt". Als er niets aan de hand is kun je via system() oid gewoon de shell aanroepen met de originele parameters.

[merlijn85]

Dat is grofweg wat er nu gedaan wordt met de patches die dit op moeten lossen. In principe maken ze alleen maar de compiler van bash-code sterker, zodat "out of order tokens" een compile error opleveren (zie hiervoor bijvoorbeeld de error meldingen die je krijgt wanneer je de bekende vulnerability test doet op een gepatched systeem).

Wat jij nu voorsteld kan heel goed, maar is eigenlijk overbodig en lost niets extras op. Het geeft jou als sysadmin meer mogelijkheden om zelf filters hiervoor aan te maken - maar dat kost je wel een hoop performance en je hebt flinke kans op false positives.

Voor de grap even een klein voorbeeldje hoe je zou doen wat jij nu voorsteld (untested):

mv /bin/bash /usr/local/bin/
cat <<EOF > /bin/bash
#!/usr/bin/perl

foreach (sort keys %ENV) {
if ($_ eq 'EVIL_ENV') {
delete($ENV{$_});
}
}
exec("/usr/local/bin/bash @ARGV");
EOF
chmod +x /bin/bash

[Reactie gewijzigd door merlijn85 op 26 juli 2024 18:02]

[Ventieldopje]

Simpelweg een andere shell gebruiken dan Bash, bijvoorbeeld Dash of ZSH wat met een beetje geluk zonder problemen zal gaan als je niet al te rare dingen uithaalt in je scripts. Maar het is best een rigoreuze stap om te doen waar je veel mee moet testen of dingen nog goed werken.

[swtimmer]

Wat natuurlijk erg vervelend blijft is dat voor veel netwerk apparaten haast nooit geen firmware patches uitkomen. Waar ik nu tijdelijk woon is praktisch alles van het niveau sweex/tp-link waar na uitbrengen van het apparaat nooit geen nieuwe firmware is uitgebracht. Als er dus ook maar iets van ssl of bash inzit heb je dus zolang je geen nieuw device koopt een "lek" netwerk.

[Mijzelf]

Dat valt wel mee. Voor SSL is er een tijdslot van 2 jaar (voorjaar 2012 tot voorjaar 2014) waarin de meest current versie vatbaar was. De meeste routers bevatten oudere meuk. Verder is heartbleed alleen een probleem als ssl gebruikt wordt. (Duh!). Voor een router zou dat alleen een https webinterface zijn, lijkt me. En die zet je toch niet naar buiten open?

Verder draait geen enkele consumenten router/AP bash. Veel te groot, terwijl busybox ash bijna hetzelfde kan tegen veel minder (flash) kosten.

Wat natuurlijk niet wegneemt dat er een nog onbekend probleem met busybox zou kunnen zijn. Dàt zou enorme impact hebben. Alle embedded Linux systemen gebruiken busybox.

[swtimmer]

Ik doel er meer op dat wat voor bugs er ook gevonden gaan worden deze naar alle waarschijnlijkheid nooit gepatch gaan worden in consumenten hardware. Wat dus wel daadwerkelijk een gevaar zou kunnen opleveren. Eerst was het SSL, nu is het bash, wat is next?

[CH4OS]

Dat valt wel mee. Voor SSL is er een tijdslot van 2 jaar (voorjaar 2012 tot voorjaar 2014) waarin de meest current versie vatbaar was. De meeste routers bevatten oudere meuk. Verder is heartbleed alleen een probleem als ssl gebruikt wordt. (Duh!). Voor een router zou dat alleen een https webinterface zijn, lijkt me. En die zet je toch niet naar buiten open?

En waarom zou je de webinterface van je router via ssl willen aanbieden als je het toch enkel bereikbaar wil hebben op lokaal netwerk niveau? Dat zou dan betekenen dat je je eigen netwerk niet vertrouwd.

[Reactie gewijzigd door CH4OS op 26 juli 2024 18:02]

[TheMak]

Deze derde bug lijkt mij eerder een feature. Een feature dat er voor zorgt dat bash wellicht niet meer veilig binnen CGI scripts gebruikt kan worden. Het is te flexibel, te krachtig. Je denkt dat je een script gemaakt heb dat A doet. Een buitenstaander kan er voor zorgen dat het B doet. Misschien dat het deels op te lossen is met een command-line optie dat er voor zorgt dat er geen functies in vars doorgegeven kunnen worden. SQL kan je ook niet zonder voorzorgmaatregelen tegen SQL-injecties op het internet zetten. Dus misschien zijn voor Bash scripts dergelijke maatregelen ook nodig, of overstappen op een shell. Een shell die op dit punt minder "flexibel" is.