Shellshock bewees je ongelijk
Ummm... Nee.
Volgens mij moet je nog een keertje de papers en uitleg over Shellshock bekijken.
Als ik zo je 2 reacties nog eens lees, lijk je te denken dat Shellshock enkel gebruikt kon worden als er toegang was tot een proces dat als root draaide, of dat het enkel dan een groot gevaar vormde.
Niets is minder waar, ook bij diensten die netjes under-privileged draaiden kon (kan als je niet gepatched bent
) bizar veel gevaar opleveren.
Ik stel voor dat je jezelf overnieuw inleest in wat nou werkelijk het probleem is met Shellshock.
Processen die als root draaien zijn verre van het enige risico factor.
Maar ook de defaults zijn vaak slecht. MySQL in combinatie met Apache draait bijvoorbeeld standaard NIET afgeschermd om maar wat te noemen. Het komt dus wel degelijk heel vaak voor en is verre van onzin.
Met alle respect: ik weet niet op welke manier jij je servers installeert, maar mySQL start standaard als de mySQL user en niet als root. En Apache als de http user of als nobody; ook niet als root, en bij een goede configuratie werk je bij Apache vervolgens nog met suexec ook; en voor processen als PHP zorg je dat ze niet buiten hun basedir kunnen komen (en gebruik je ook weer een vorm van phpSuExec, plus 't liefst een aantal extra beveiligingsmaatregelen).
Apache die standaard als root zou draaien is werkelijk de grootste onzin die er is, and I mean no offense.
Ze draaien niet sandboxed nee, dwz dat ze niet in een geheel eigen environment draaien. Maar dat wilde ik ook helemaal niet suggeren... Als je m'n post goed had gelezen dan zie je ook dat ik zelfs uit zit te leggen in wat voor een scenario dat bijvoorbeeld *wel* zou kunnen: maar hoe je daar vervolgens vrij weinig mee opschiet omdat de diensten alsnog met elkaar moeten kunnen communiceren om een effectieve stack te hebben, waarbij een compromise bij de een dus tot gevolg kan hebben dat ook informatie/data van de ander opgehaald kan worden: of je zelfs je weg verder (omhoog) kan vinden.
(En dat komt niet door teveel privileges, maar omdat ze elkaar gewoon moeten kunnen benaderen om hun werk te kunnen doen. Simple as that.)
Webservices die als root draaien komen standaard absoluut *niet* heel vaak voor.
Je spreekt jezelf namelijk verderop tegen:
Nee, sorry, je hebt of niet goed gelezen of me gewoon niet goed begrepen met wat ik probeerde duidelijk te maken.
En dat is het probleem. Een process kan dan toch opeens allerlei andere data van andere processen bereiken zelfs als het aan apart user-process is. Juist omdat het moeilijk is draait men vaak op hogere privileges dannodig. Lekker makkelijk. Niet bij een grote UNIX mainframe server, maar wel bij de kleine *nix PC/rack die de webserver moet draaien. Zeker als bedrijven
1.) Dat is geen probleem, want dat proces *moet* data van een ander proces kunnen bereiken, anders werkt het niet. Zonder dat dat kan, kunnen de diensten niet met elkaar communiceren. Dan krijg je dus dat je PHP proces bijvoorbeeld geen verbinding meer kan leggen met je mySQL server. Of dat je Apache niet meer kan lezen van je NFS share en uit pure wanhoop maar een 404 of 500 tevoorschijn tovert. Dan kan je net zo goed de stekker uit de server trekken; dan weet je zeker dat je veilig bent en heb je ongeveer evenveel nuttige diensten draaien...
2.) "Juist omdat het moeilijker is draait men vaak op hogere privileges dan nodig".
Ik blijf erbij: Neen.
Ik ben benieuwd... Op deze manier blijven we heen en weer gaan; wat zij jou bronnen dat dit soort diensten standaard hele hoge privileges (volgens jou zelfs als root!) hebben en/of dat heel veel mensen ze in hele hoge privileges laten draaien? Zeker op webservers (bij bedrijven)? Ik herken het beeld echt *totaal* niet.
Misschien 10 jaar geleden, maar tegenwoordig echt niet meer.
En *juist* bij bedrijven is men steeds meer gaan focussen op security. (niet altijd met succes, maar het gros wel.)
Niet lullig bedoeld, maar volgens mij leef je nog ergens in het verleden waar dit nog veel voorkwam omdat toch (bijna) niemand een computer had, of enkel voor tekstverwerken
, en dit soort apparatuur puur werd ingezet voor bijv bedrijf-bedrijf communicatie of applicatie servers voor bijvoorbeeld het controleren van gegevens in een databank bij de gemeente, om maar wat te noemen. Maar op de webservers van tegenwoordig, zoals de genen die het gros van de websites op de interwebz serveren? Nah uh... Geen denken aan dat die vitale webservices als root draaien, misschien hier en daar een uitzondering: maar dan heb je 't wel gehad.
Zoals ik al zei: de meeste software *weigert* zelfs als root te draaien.
Men kan bijvoorbeeld bepaalde devcie drivers benaderen, of men kan bijvoorbeeld het intranet op. Dat is laatste hoe men vaak bedrijfsnetwerken infiltreert. Je hackt een process, dat vervolgens niet afgeschermd is en een socket kan openen naar het interne netwerk.
Ah, maar dat is toch echt weer een heel ander verhaal.
Ik vind dat trouwens meer de schuld van een achterlijke netwerk engineer dan van de server beheerder, maar goed.
Dat kon je goed zien bij KPN... De servers konden nog zo veilig zijn, maar op netwerk niveau kon men gewoon vanaf public interfaces ook bij het interne netwerk komen... En dan op dusdanige manier dat de sjaak die toegang kreeg (vanuit een datacenter van KPN, trouwens) zelfs toegang had tot routers die 112 afhandelden.
Dat heeft vrij weinig te maken met een Apache servertje in een sandbox flikkeren, want als die netwerk connectiviteit heeft en het netwerk staat het toe: waarom zou ie dan niet, als het process 't opgedragen wordt, daar verbinding mee maken...? Apache weet niet dat dat fout is, dat moet *of* in de firewall op de server goed geregeld worden of, en dat is nog beter, gewoon netjes in het netwerk goed ingesteld worden.
Ik zie ook niet in hoe dat voorkomen kan worden met een sandbox, even serieus.
Je kan 't wel leuk gaan sandboxen, maar als het proces in de sandbox netwerk connectiviteit nodig heeft en het is vervolgens mogelijk om met het intranet te verbinden: dan heeft dat helemaal niets te maken met teveel rechten voor dat process of dat het niet in een sandbox staat (immers staat het *wel* in een sandbox): nee, dat is gewoon een brakke netwerk configuratie en/of je hebt je sandbox gewoon niet goed ingericht. (Of je firewall (acl) regels sporen niet.)
Een sandbox is niet het heilige middel dat alles direct oplost; ook daar kan je de configuratie gewoon op een manier in orde brengen dat er alsnog heel hard om gejankt kan worden.
Elk proces is onderhevig aan goede configuratie van het bovenliggende systeem/netwerk; als je sandbox dingen mag doen die je niet wil dat het zou mogen doen: dan is je configuratie gewoon slecht; niets meer, niets minder...
Vandaar dat ik bj mijn stelling blijf, dat "De Les" is dat je procesen moet afschermen en een zo laag mogelijk privilege moet geven. Liefst een sandbox, maar als dat niet gaat echt zoveel mogelijk afgeschermd. En daar is helaas nog steeds veel te veel bij te winnen.
Nou, ja... Dat is een les die het overgrote deel van de mensen, althans: in een enigszins redelijke positie (en zelfs na een jaartje MBO niveau 3 systeembeheer...) wel weten. En te hoge privileges is niet per definitie waar de GHOST kwetsbaarheid haar bestaansrecht aan te danken heeft... Shellshock ook niet.
De stelling dat te veel privileges het probleem is bij die hacks en dat daardoor de grote problemen mogelijk zijn wijs ik echt van de hand.
Vandaar dat ik bij m'n stelling blijf dat de meeste mensen prima weten (nogmaals: mensen in een enigszins redelijkse positie, Sjaak die thuis z'n DLNA servertje op een Ubuntu bak heeft gegooid en de "Do not run me as root! Use --force to override." negeerd boeit heel weinig.) dat ze processen niet als root moeten draaien, en de meeste notabele processen _weigeren_ dat ook gewoon of geven grove waarschuwingen en een echt gevecht voordat ze 't wel doen: zoals het hoort.
Er is maar heel weinig nog aan te winnen op dat gebied, en nogmaals: dan nog. Een sandbox is niet de heilige graal, en underprivileged users gebruiken biedt ook helemaal niet per definitie een werkelijke oplossing om lekken, data theft en misbruik van grove kwetsbaarheden te voorkomen.
Zoveel mogelijk afschermen is een heel goed iets, de meeste mensen weten dat (sure, er zijn vast een paar incompetente sjaakies die het niet kunnen); maar je moet niet doorslaan: zeker niet als het geen werkelijk nut heeft. ... Op geld verdienen aan de tijd die je eraan verspild na misschien.
Trouwens, ik geloof graag dat embedded systemen daar best kwetsbaarder voor kunnen zijn hoor; of het (veel) vaker doen. En *daar* zal misschien nog best wat te winnen zijn. (Zoals het voorkomen van het draaien van bitcoin miners op je smartkoelkast!
)
Maar ik heb het puur over webservices in m'n posts.
[Reactie gewijzigd door WhatsappHack op 29 januari 2015 04:45]
Beheer en beveiliging
Geniaal.
) 
Beheer en beveiliging
.
Gelukkig snel gefixt.