lek...
Iemand die hier meer over weet of kan uitleggen wat er aan de hand is?
Zijn VPS'en ook kwetsbaar voor dit lek?
http://www.nutech.nl/internet/3887350/os-x-en-linux-ondanks-update-nog-kwetsbaar-bash-bug.html
Verder zou ik zeggen dat een VPS júist kwetsbaar is, zeker als je self-managed hosting hebt, waarbij je dus zelf verantwoordelijk bent voor het installeren van updates.
De bug in kwestie maakt het mogelijk om in sommige gevallen commando's door te geven aan de shell, terwijl dat eigenlijk niet zou moeten kunnen. Met een beetje fantasie kun je denk ik zelf wel bedenken wat voor mogelijkheden dat biedt.
Gezien het tijdstip heb ik weinig zin om uit te zoeken in hoeverre het lek ook daadwerkelijk misbruikt kan worden. Maar voor de zekerheid stel ik mijn slaapmomentje nog een half uurtje uit om onze servers in het publieke subnet van een update'je te voorzien (lang leve IVT met zijn key-broadcast).
Voor CentOS is het een simpele:
Verder ligt de tweede patch al klaar, die op dezelfde wijze uit te voeren is.
Gewijzigd op 26/09/2014 09:27:52 door - Ariën -
Maar als ie Linux draait toch wel?
>> Maar voor de zekerheid stel ik mijn slaapmomentje nog een half uurtje uit om onze servers in het publieke subnet van een update'je te voorzien (lang leve IVT met zijn key-broadcast).
Nou, is dit topic toch nog ergens goed voor :)
>> yum update bash
Kun je zo'n update commando altijd uitvoeren? Ook als er geen update is? Is het echt zo simpel? Dat valt dan nog mee... en voer je dat dan als root uit? Ik moet mijn vps nog bestellen, maar ik ben wel benieuwd of de hoster nu al z'n images heeft aangepast naar aanleiding van dit lek...
Toevoeging op 26/09/2014 11:39:12:
P.S.
Zouden we hier eigenlijk niet een "officieel" topic moeten hebben waarop je een lek kunt melden? Lijkt me wel erg nuttig eigenlijk...
Gewijzigd op 26/09/2014 11:37:26 door Ozzie PHP
Als er geen update klaarstaat, dan meldt hij dat ook netjes.
Ah oke... thanks Aar!
Jep, voor het genereren van slaaptekort...
Toevoeging op 26/09/2014 12:15:34:
> Er worden nu al een hoop attacks op .cgi-scripts gedaan via gewijzigde useragents.
Ik heb ze inderdaad al zien langskomen...
:)
Lijkt mij toch wel een beetje logisch, maar ik kan het verkeerd hebben.
Een beetje wel... maar veel dingen regel je (in mijn geval) via een panel. En dan heb je met de commandline niet zoveel te maken. Maar er zijn ook genoeg mensen die alles via de commandline doen...
Webhosting bieden VPS'sen in twee gradaties aan:
Managed en Non-Managed
Bij de eerste zal je geen root-access hebben en zal de webhoster zelf updates doorvoeren volgens overeenkomst. En bij de tweede ben je zelf helemaal verantwoordelijk. het spreekt voor zich dat de Managed duurder is.
Als je de VPS zelf beheert, dan moet je heel goed op de hoogte blijven van security-leaks en patches. Het supportforum van het control-panel die je gebruikt, evenals de Engelse Webhostingtalk zijn beide al goede kanalen.
Thanks Aar... ik zou best graag hier op phphulp een soort "beveiligings" (sticky)topic willen hebben, waarin alle veiligheidslekken worden vermeld. Als je dan een lek tegenkomt, zou je die erop kunnen plaatsen, liefst ook met een oplossing erbij. Dan krijg je uiteindelijk een mooi chronologisch overzicht. Wellicht iets voor jullie om als moderators/team te bespreken?
Alle veiligheidslekken? Dat zijn er jaarlijks tienduizenden.
Lijkt me sterk... ik bedoel dus algemene veiligheidslekken die betrekking hebben op een server/OS/PHP... ofwel... de lekken waar wij voor moeten oppassen.
CVE's (Common Vulnerabilities and Exposures) staat op 64.260.
Ik begrijp wel wat je bedoelt: een checklist zou handig zijn. Maar dan nog is dat te groot en vooral te onoverzichtelijk (met allerlei opeenvolgende versies) voor één sticky topic.
Dat is een overdrachtelijk bedoeld rond getal, maar dat komt aardig in de richting. De telling van Ik begrijp wel wat je bedoelt: een checklist zou handig zijn. Maar dan nog is dat te groot en vooral te onoverzichtelijk (met allerlei opeenvolgende versies) voor één sticky topic.
24-09-2014: TYPE SERVER, OS CentOS, shell-lek, [link naar meer info]
26-09-2014: TYPE PHP, FUNCTIE preg_match, injectiegevoelig, [link naar meer info]
Ken je het Open Web Application Security Project (OWASP)?
Die hebben onder andere een PHP Security Cheat Sheet.
Gewijzigd op 26/09/2014 14:46:06 door - Ariën -
We hebben hier onze handen al vol aan onvoldoende gecontroleerde $_POST's.
@Aar... dat zou inderdaad ook nog een goed idee zijn. Alleen vind ik dan wel dat deze topics niet onder het kopje "FORUM BERICHTEN" (linksboven) moeten komen, want dan raken ze te snel uit het zicht. Maar bijv. onder een apart kopje "BEVEILIGING" (net zoals bij "REACTIES", "PHP SCRIPTS" en "PHP TUTORIALS").
Gewijzigd op 26/09/2014 14:47:13 door Ozzie PHP
Ozzie PHP op 26/09/2014 14:34:54:
Hiermee ben je dan eigenlijk reactief en ad-hoc bezig. Met zo'n werkwijze is je server-software binnen een jaar totaal verouderd. Het is zinvol om bijvoorbeeld maandelijks een update/upgrade uit te voeren waarbij onder andere al je libs/kernel e.d. worden bijgehouden waarna je aansluitend alleen nog maar reactief hoeft te reageren op nieuws zoals dit over bash. In alle gevallen is het handig om veel te leren op commandline level omdat je daar veel directer en sneller kan ingrijpen dan via paneeltjes. Ik vind zelf bijvoorbeeld phpadmin zo'n beetje de allergrootste ergernis die er is.Misschien heb je gelijk, maar het lijkt me wel handig dat je als programmeur af en toe even kunt checken of je niet iets gemist hebt. Het zou ook een heel simpel overzicht kunnen zijn, zoiets als:
24-09-2014: TYPE SERVER, OS CentOS, shell-lek, [link naar meer info]
26-09-2014: TYPE PHP, FUNCTIE preg_match, injectiegevoelig, [link naar meer info]
24-09-2014: TYPE SERVER, OS CentOS, shell-lek, [link naar meer info]
26-09-2014: TYPE PHP, FUNCTIE preg_match, injectiegevoelig, [link naar meer info]