Apple dicht ernstig Bash-lek in Mac OS X
Apple heeft vannacht een update uitgebracht voor het ernstige Bash-lek in Mac OS X. Via de kwetsbaarheid die vorige week werd ontdekt zou een aanvaller volgens Apple in bepaalde gevallen op afstand willekeurige shell commando's kunnen uitvoeren.
Bash is een Unix-shell waarmee er opdrachten aan het systeem kunnen worden gegeven. Het wordt voor allerlei toepassingen gebruikt en veel programma's draaien het in de achtergrond. Het is in op Unix-gebaseerde systemen aanwezig, waaronder Linux en Mac OS X. Apple liet vorige week al weten dat Mac OS X-gebruikers standaard geen risico lopen. Alleen als er bepaalde services werden gedraaid zou een aanvaller het lek kunnen misbruiken.
Na het eerste Bash-lek bleken er in het programma nog meerdere problemen aanwezig te zijn, die elk een apart CVE-nummer kregen toegekend. In totaal zijn er vijf CVE-nummers uitgedeeld, te weten CVE-2014-6277, CVE-2014-6278, CVE-2014-7169, CVE-2014-7186 en CVE-2014-7187. De update van Apple verhelpt CVE-2014-6271 en CVE-2014-7169.
Apple merkt op dat de update ook de in CVE-2014-7169 gesuggereerde verandering bevat die de parser-staat reset. Daarnaast voegt de update ook een extra maatregel toe die het onbedoeld doorsturen van headers naar Bash moet voorkomen. De update is beschikbaar voor OS X Lion 10.7.5, OS X Lion Server 10.7.5, OS X Mountain Lion 10.8.5 en OS X Mavericks v10.9.5.
Zoals je ziet, vergelijk je appels met peren. Hetgeen je suggereert is niet juist. Linux systemen zijn vatbaar voor het Bash-lek, terwijl maar een heel klein deel van de Apple systemen vatbaar is. Met andere woorden deze bug heeft een veel lagere prioriteit op OS X.
Zoals je ziet, vergelijk je appels met peren. Hetgeen je suggereert is niet juist. Linux systemen zijn vatbaar voor het Bash-lek, terwijl maar een heel klein deel van de Apple systemen vatbaar is. Met andere woorden deze bug heeft een veel lagere prioriteit op OS X.
Als jij goed leest heeft hij wel gelijk: Zoals je ziet, Apple is trager in het oplossen van bekende bugs.
Hij zegt alleen dat Apple trager is, en vergelijkt dus niks.
Dus Apple zal dingen langer willen testen voordat ze iets uitgeven.
Overigens kun je net zo goed schadeclaims verwachten wegens het uitstellen van fixes voor bekende securitybugs trouwens, dus dat lijkt me op zichzelf niet zo'n heel goed excuus.
Linux-op een typisch desktopsysteem is voor zover ik het overzie dus evenmin kwetsbaar als OS/X op een typisch desktopsysteem. OS/X op een webserver is even kwetsbaar als Linux op een vergelijkbare webserver. Ik lees de "safe by default"-reactie van Apple die je citeert dan ook vooral als een indicatie dat Apple zich als leverancier van desktopsystemen opstelt en vergeet dat ze OS/X ook als server-OS op de markt zetten. Dat is nalatig.
En dan vind jij 5 dagen wachttijd voor een patch te lang?
Erop ingaan is zinloos, reageerder betreft één van de vaste OS-Trollen op security.nl en andere fora
Binnen 2 minuten gepost op security.nl en webwereld
Zoals je ziet, Apple is trager in het oplossen van bekende bugs. Zeg maar de windows in unix-land ;)
De bug zit er inderdaad erg lang in, wat uiteraard geen goede zaak is.
Mijn punt is dat wanneer de bug bekend is, dat je daar zo snel mogelijk actie moet ondernemen. Het is beter om de bug 3 keer in kleine stappen op te lossen, dan in 1 keer en langer moeten wachten.
Tenslotte zijn security-updates een van de belangrijkste maatregelen voor een veilig besturingssysteem.
Alsof jij op één forum actief bent? Blijkbaar jij ook niet. Je durft/wil niet eens je eigen nickname te gebruiken op dit forum..
Wat is er mis met mijn eigen stelling? OSX is nou eenmaal van Apple en is trager met updates dan bij Debian distros het geval is. Fact, het is niet eens een mening.
Het misbruik van het bash-lek vereist, in alle scenario's die ik beschreven heb gezien, dat er een webserver of andere service aan de buitenwereld wordt blootgesteld die onder water bash gebruikt om taken uit te voeren, en daarbij invoer van buiten als environmentvariabelen aan bash doorgeeft. Dat kan bij technologieën voor dynamische websites voorkomen, het kan bij bepaalde manieren om GIT-repositiories remote ter beschikking te stellen voorkomen, dat soort dingen. Ik heb zeker geen ervaring met alle Linux-distributies, maar dit is voor zover mijn ervaring reikt niet het soort dingen dat default actief is bij een desktopinstlallatie, en bij een server-installatie pas als je het installeert en configureert. Gewone SSH-toegang (remote shell) levert geen extra risico op omdat daarmee toch al toegang tot een interactieve shell wordt gegeven, daar heb je het bash-lek niet nodig om commando's uit te kunnen voeren.
Dan heb je denk ik de proof-of-concept exploits met DHCP even gemist; als dhcp-client kun je ook kwetsbaar zijn. Gebruik zelf geen OSX dus ik weet niet of die client het ook is, maar niet alles gebeurt services die de machine zelf aanbiedt.
Deze posting is gelocked. Reageren is niet meer mogelijk.
Junior DevOps Engineer
Certified Secure is op zoek naar een Junior DevOps Engineer. Deze functie is een stuk interessanter dan de term doet vermoeden! Om jou als potentiële nieuwe collega meteen te laten zien wat we doen hebben we speciaal voor jou een selectie gemaakt van een aantal leuke security challenges. Are you ready for a challenge?
Cybersecurity Trainer / Streamer
Toe aan een nieuwe nieuwe job waarmee je het verschil maakt? In de Certified Secure trainingen laat je deelnemers zien hoe actuele kwetsbaarheden structureel verholpen worden. Ook werk je actief mee aan de ontwikkeling van onze gamified security challenges. Bij het maken van challenges kom je telkens nieuwe technieken tegen, van Flutter tot GraphQL, van Elastic Search tot Kubernetes.
