Reacties (25)
:strip_exif()/u/72391/Pinky_and_the_Brain_-_Brain.gif?f=community){kind=small}
Op T.net mocht het allemaal wel wat beter uitgelegd worden.
De kern van de zaak is dat de system()-call waarmee je een process opstart 2 stappen doet:
1) fork() start een child-process op, een identieke clone van het huidige programma.
2) exec() voert het programma uit wat je wil opstarten. Mààr, hier zit het speciale dan. Er wordt niet zomaar exec() gedaan van je programma, het uitgevoerde commando is '/bin/sh -c "<jouw echte commando hier>"'. Doordat elk child processen standaard de environment variabelen overerven van het parent (bij de fork()) wil het zeggen dat elk proces wat system() uitvoert en waar op 1 of andere manier opzettelijk of via een exploit een gebruiker invloed heeft op wat er in de environment variabelen zit is vulnerable.
Voorbeelden zijn CGI scripts, waar mogelijk URL variabelen in de environment geplaatst kunnen worden, of een DHCP client waar DHCP parameters in de environment gezet worden.
Hoe erg is zo'n vulnerable shell? Dat hangt af van de configuratie. DHCP clients durven gemakkelijk als root draaien, terwijl een administrator die CGI scripts als root draait een schop voor z'n kont verdient. Wanneer standaard practices zoals het gebruik van users/groups met beperkte rechten goed ingesteld zijn, dan kan de schade enigzins beperkt zijn. Als je een goed geconfigureerde SELinux erbovenop draaien hebt, kan de schade mogelijk nog verder beperkt worden. Ook veel embedded apparatuur zoals NASen, routers en andere gebruiken busybox, dewelke dit probleem niet heeft.
En wat met de claim dat het ding na 2 patches nog altijd vulnerable is? Wat overblijft is een standaard feature van de shell, dewelke je kan misbruiken. Hierbij moet gekozen worden tussen backwards compatibility of security. De realiteit zal echter waarschijnlijk zijn dat er een 3de oplossing zal komen met een aanvaardbare trade-off. Welke dat zal zijn moeten we nog even afwachten.
Als je even kijkt naar https://lwn.net/Articles/613640/ dan zie je dat Fedora heel veel packages gefixed heeft bovenop de fix voor bash. Eigenlijk komt het tot op zeker hoogte daarop neer. De parent is verantwoordelijk voor de environment (tenzij een andere exploit daar iets mee doet), het is dan ook die parent die moet zorgen dat er geen troep in zit.
De kern van de zaak is dat de system()-call waarmee je een process opstart 2 stappen doet:
1) fork() start een child-process op, een identieke clone van het huidige programma.
2) exec() voert het programma uit wat je wil opstarten. Mààr, hier zit het speciale dan. Er wordt niet zomaar exec() gedaan van je programma, het uitgevoerde commando is '/bin/sh -c "<jouw echte commando hier>"'. Doordat elk child processen standaard de environment variabelen overerven van het parent (bij de fork()) wil het zeggen dat elk proces wat system() uitvoert en waar op 1 of andere manier opzettelijk of via een exploit een gebruiker invloed heeft op wat er in de environment variabelen zit is vulnerable.
Voorbeelden zijn CGI scripts, waar mogelijk URL variabelen in de environment geplaatst kunnen worden, of een DHCP client waar DHCP parameters in de environment gezet worden.
Hoe erg is zo'n vulnerable shell? Dat hangt af van de configuratie. DHCP clients durven gemakkelijk als root draaien, terwijl een administrator die CGI scripts als root draait een schop voor z'n kont verdient. Wanneer standaard practices zoals het gebruik van users/groups met beperkte rechten goed ingesteld zijn, dan kan de schade enigzins beperkt zijn. Als je een goed geconfigureerde SELinux erbovenop draaien hebt, kan de schade mogelijk nog verder beperkt worden. Ook veel embedded apparatuur zoals NASen, routers en andere gebruiken busybox, dewelke dit probleem niet heeft.
En wat met de claim dat het ding na 2 patches nog altijd vulnerable is? Wat overblijft is een standaard feature van de shell, dewelke je kan misbruiken. Hierbij moet gekozen worden tussen backwards compatibility of security. De realiteit zal echter waarschijnlijk zijn dat er een 3de oplossing zal komen met een aanvaardbare trade-off. Welke dat zal zijn moeten we nog even afwachten.
Als je even kijkt naar https://lwn.net/Articles/613640/ dan zie je dat Fedora heel veel packages gefixed heeft bovenop de fix voor bash. Eigenlijk komt het tot op zeker hoogte daarop neer. De parent is verantwoordelijk voor de environment (tenzij een andere exploit daar iets mee doet), het is dan ook die parent die moet zorgen dat er geen troep in zit.
[Reactie gewijzigd door H!GHGuY op 23 juli 2024 06:28]
:strip_exif()/u/119419/candc-60px.gif?f=community){kind=small}
Ik heb wat testjes gedaan in onze testomgeving en ik ben echt verbaasd hoe makkelijk het is te exploiten en hoe ernstig de inbreuk is.
Met 1 regel heb je elk gewenst shellcommando gerund, met een regel of 5 heb je een remote shell.
Wat mij betreft kan er niet genoeg ophef over komen. Die bashes moeten zo snel mogelijk geupdate worden!
Met 1 regel heb je elk gewenst shellcommando gerund, met een regel of 5 heb je een remote shell.
Wat mij betreft kan er niet genoeg ophef over komen. Die bashes moeten zo snel mogelijk geupdate worden!
Ja bash maakt het wel heel makkelijk met zijn socket redirection, klein stukje uit de man page:Met 1 regel heb je elk gewenst shellcommando gerund, met een regel of 5 heb je een remote shell.
.Bash handles several filenames specially when they are used in redirections, as described in the following table:
/dev/fd/fd
If fd is a valid integer, file descriptor fd is duplicated.
/dev/stdin
File descriptor 0 is duplicated.
/dev/stdout
File descriptor 1 is duplicated.
/dev/stderr
File descriptor 2 is duplicated.
/dev/tcp/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 TCP connection to the corresponding socket.
/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.
Ik vind deze uitleg wel interessant: http://paste.lisp.org/display/143864
[Reactie gewijzigd door nieternie op 23 juli 2024 06:28]
:strip_icc():strip_exif()/u/162143/crop5b6d888e9cc79_cropped.jpeg?f=community){kind=small}
Als je je server een beetje geconfigureerd hebt dan heeft de gebruiker die de website draait (eigenaar van de scripts) helemaal geen toegang tot een shell.
Daar gaat het niet om. Het probleem is dat apache bash gebruikt als 'tussenstap' om CGI scripts te draaien. Dus de exploit zit niet in de scripts zelf maar in het mechanisme waarmee ze gestart worden. Wat er in het cgi script zelf staat is totaal niet van belang.
De user die die scripts start (meestal 'apache' of 'httpd') heeft wel toegang anders kan die ook geen CGI scripts starten.
De user die die scripts start (meestal 'apache' of 'httpd') heeft wel toegang anders kan die ook geen CGI scripts starten.
Lees http://www.troyhunt.com/2...u-need-to-know-about.html anders eens.
Ik heb eigenlijk nog nergens iets gezien of gehoord hierover, behalve nu in deze poll.
Dus wat betreft vragen naar overdreven ophef, ik had zelf zoiets van 'welke ophef'. Dat lijkt ook overeen te komen met het hoge aantal 'geen idee' stemmers.
Dus wat betreft vragen naar overdreven ophef, ik had zelf zoiets van 'welke ophef'. Dat lijkt ook overeen te komen met het hoge aantal 'geen idee' stemmers.
:strip_icc():strip_exif()/u/78725/train-icon3.jpg?f=community){kind=small}
Er zijn op T.net toch echt al meerdere nieuwspost over geweest de laatste dagen:
nieuws: Bash-kwetsbaarheid laat aanvaller code uitvoeren op Linux en OS X
nieuws: Patch voor Bash-beveiligingsprobleem blijkt onvoldoende
nieuws: Tweede Bash-fix laat gaten over
En hoewel de eenvoudigste exploits ondertussen verdwenen zijn, blijkt bash dus kwetsbaar te zijn vanuit het ontwerp ervan, en dat kan men niet zomaar patchen zonder ontelbare systemen niet meer te laten werken.
nieuws: Bash-kwetsbaarheid laat aanvaller code uitvoeren op Linux en OS X
nieuws: Patch voor Bash-beveiligingsprobleem blijkt onvoldoende
nieuws: Tweede Bash-fix laat gaten over
En hoewel de eenvoudigste exploits ondertussen verdwenen zijn, blijkt bash dus kwetsbaar te zijn vanuit het ontwerp ervan, en dat kan men niet zomaar patchen zonder ontelbare systemen niet meer te laten werken.
/u/29147/crop685ebf24d1183_cropped.png?f=community){kind=small}
Behalve een melding van m'n VPS boer en een artikel op t.net, had ik er ook nog niet veel over gehoord.
Hier dus ook; anders nl. Welke ophef?
Kan er ook door komen dat ik het na 1 melding wel weet, en daarna automatisch alle opvolgende teksten erover skip.
Hier dus ook; anders nl. Welke ophef?
Kan er ook door komen dat ik het na 1 melding wel weet, en daarna automatisch alle opvolgende teksten erover skip.
[Reactie gewijzigd door Engineer op 23 juli 2024 06:28]
:strip_icc():strip_exif()/u/28792/thing.jpg?f=community){kind=small}
Het is me nog steeds niet duidelijk hoe groot het gevaar is als je geen benaderbare CGI scripts op je server hebt staan. Bovendien moeten die CGI scripts ook nog eens bash openen. Het probleem zou concreter worden als er een populaire library vulnerable is, voor welke taal dan ook.
Op dit moment is het allemaal erg theoretisch, dat was bij Heartbleed heel anders. Daar was bijna elke server vatbaar. Dus in die zin is de vergelijking met Heartbleed overdreven, en misschien de aandacht ook (hoewel dat op tweakers.net wel meevalt).
Voor de zekerheid heb ik wel security updates gedraaid op mijn servers.
Op dit moment is het allemaal erg theoretisch, dat was bij Heartbleed heel anders. Daar was bijna elke server vatbaar. Dus in die zin is de vergelijking met Heartbleed overdreven, en misschien de aandacht ook (hoewel dat op tweakers.net wel meevalt).
Voor de zekerheid heb ik wel security updates gedraaid op mijn servers.
[Reactie gewijzigd door Blaise op 23 juli 2024 06:28]
Dat is dus een beetje het punt; op het moment dat je iets op bash krijgt met een normale procedure voegt deze vuln niet echt wat toe.
Stel dat je bash intern in een script gebruikt en input in principe nooit bij bash moet komen, maar dat nu dus wel kan, dan is het wel een probleem. Komt dus een beetje neer op goed geprogrammeerde scripts vs. slecht geprogrammeerde scripts. Probleem is ook dat veel shellscripters er van uit gaan dat de shell problemen wel opvangt, maar dat is dus een vrij slappe assumptie die alleen maar tot dit soort exploiteerbare vulnerabilities leidt.
Op het moment is het voornamelijk op het moment dat er als root user een service een shell script uitvoer om iets externs te verwerken een probleem. Bijvoorbeeld bij veel DHCP client systemen, WPA, CGI, enz. Systemen die op de achtergrond draaien, voornamelijk voor desktop systemen en niet echt voor servers.
Stel dat je bash intern in een script gebruikt en input in principe nooit bij bash moet komen, maar dat nu dus wel kan, dan is het wel een probleem. Komt dus een beetje neer op goed geprogrammeerde scripts vs. slecht geprogrammeerde scripts. Probleem is ook dat veel shellscripters er van uit gaan dat de shell problemen wel opvangt, maar dat is dus een vrij slappe assumptie die alleen maar tot dit soort exploiteerbare vulnerabilities leidt.
Op het moment is het voornamelijk op het moment dat er als root user een service een shell script uitvoer om iets externs te verwerken een probleem. Bijvoorbeeld bij veel DHCP client systemen, WPA, CGI, enz. Systemen die op de achtergrond draaien, voornamelijk voor desktop systemen en niet echt voor servers.
:strip_exif()/u/31303/HMC2.gif?f=community){kind=small}
Alleen voor Linux?
Maar daar draaien heel veel systemen op? NAS, webcams, routers, ga zo maar door.
Hier moet ik echt meer onderzoek naar doen...Totaal gemist in al het nieuws.
Shame on me...
Maar daar draaien heel veel systemen op? NAS, webcams, routers, ga zo maar door.
Hier moet ik echt meer onderzoek naar doen...Totaal gemist in al het nieuws.
Shame on me...
[Reactie gewijzigd door HMC op 23 juli 2024 06:28]
Synology heeft net een update uitgebracht, even inloggen op je NAS.
Als het in de 'normale' media terecht komt wordt er teveel aandacht aan gegeven 😁
/u/37590/koffie.PNG?f=community){kind=small}
Zolang er onderbouwd en constructief aandacht aan besteed wordt kan het wat mij betreft niet overdreven zijn. Bewustzijn van beveiligingsrisico's is altijd goed.
"OMG LINUX EN MAC ZIJN ONVEILIG!!ZOMG" hoeft dan weer niet zo nodig.
"OMG LINUX EN MAC ZIJN ONVEILIG!!ZOMG" hoeft dan weer niet zo nodig.
tsja....misschien sust dat de discussie over veiligheid van de OS'en een beetje...
Op dit item kan niet meer gereageerd worden.