Google onthult ongepatchte lekken in Mac OS X
Na verschillende lekken in Windows te hebben onthuld waar op dat moment nog geen beveiligingsupdates waren heeft Google hetzelfde nu gedaan bij Mac OS X. In totaal gaat het om drie kwetsbaarheden waardoor een aanvaller commando's als een 'system daemon' kan uitvoeren, via 'kernel code execution' rootrechten kan krijgen of via een Bluetooth-apparaat geheugencorruptie kan veroorzaken.
Eén van de kwetsbaarheden is alleen getest op Mac OS X 10.9.5, terwijl een ander alleen op Yosemite is bevestigd. De lekken zijn ontdekt door het "Project Zero Team" van Google, dat speciaal naar kwetsbaarheden in veelgebruikte software zoekt. Zodra er een lek wordt gevonden krijgt de betreffende leverancier 90 dagen de tijd om met een update te komen, anders worden de details van de kwetsbaarheid automatisch openbaar gemaakt. Dit tot grote onvrede van Microsoft, dat Google opriep om beter samen te werken. Apple heeft nog niet op de onthulde lekken gereageerd.
Reacties (20)
23-01-2015, 11:38 door
[Account Verwijderd]
[Verwijderd]
23-01-2015, 11:42 door
[Account Verwijderd]
[Verwijderd]
Google voelt zich machtig zeg!
Laat de leveranciers in ieder geval op dit gebied veel beter samenwerken, want het internet is van iedereen. Iedereen heeft belang bij een veilig internet, dus waarom zouden lekken perse openbaar gemaakt moeten worden?
Als andere organisaties dit soort lekken fulltime bij Google of Android op gaan sporen en openbaar maken, ben ik benieuwd wat Google's reactie zou zijn.
Laat de leveranciers in ieder geval op dit gebied veel beter samenwerken, want het internet is van iedereen. Iedereen heeft belang bij een veilig internet, dus waarom zouden lekken perse openbaar gemaakt moeten worden?
Als andere organisaties dit soort lekken fulltime bij Google of Android op gaan sporen en openbaar maken, ben ik benieuwd wat Google's reactie zou zijn.
Door Krakatau: Waarom corrigeren die leveranciers hun software niet gewoon tijdig? Ze krijgen er nota bene 90 dagen de tijd voor! Dan kunnen ze wel met de vinger wijzen naar Google, die de kwetsbaarheid automatisch openbaar maakt maar 90 dagen is natuurlijk ook ruim de tijd voor (black hat) hackers om zo'n kwetsbaarheid te vinden (onafhankelijk van Google). En dan zijn ze nog veel verder van huis (want black hat hackers doen niet aan die 90 dagen).
1. 90 dagen lijkt lang, maar dat is het niet. Ze moeten oplossing verzinnen, impementeren, testen op alles wat mogelijk is
2. Wanneer MS binnen die 90 dagen meldt, dat is in de update actie na 92 dagen wordt gefixed, komt het bericht ook naar buiten. Kwaadwillenden hebben dan 2 dagen om het te gebruiken (en meer aangezien er genoeg mensen zijn die niet meteen updaten).
23-01-2015, 15:43 door
dutchfish
Two big thumbs up for Google! Hier maken ze bij mij punten mee.
Gewoon, de zweep erover, en zorgen dat je tijdig security issues fixed.
quote: "no room for lazy admins"
Gewoon, de zweep erover, en zorgen dat je tijdig security issues fixed.
quote: "no room for lazy admins"
Het gaat Google echt niet om een beter of veiligere internet omgeving, vergeet dat maar.
Opsporen fouten prima, belonen van gevonden fouten ook ok.
De impact/risoco analyse hoort bij voorkeur een onafhankelijke partij te doen inclusief de eventuele publicatie.
Nu is het veel meer concullegaatje pesten waarbij de gebruikers met "collaterable damage" getroffen kunnen worden.
Opsporen fouten prima, belonen van gevonden fouten ook ok.
De impact/risoco analyse hoort bij voorkeur een onafhankelijke partij te doen inclusief de eventuele publicatie.
Nu is het veel meer concullegaatje pesten waarbij de gebruikers met "collaterable damage" getroffen kunnen worden.
PaloAltoNetworks HQ CISO en Security afdeling willen niet eens weten van vulnerabilities, ze sturen je gewoon weg met een PR tekst als je iets full details gratis en voor nix wil melden, en maanden later blijkt er ook niets aan gedaan te zijn ook al is 't maar 10min werk om te fix'n.
't is langzaam een flinke stapel met serieuze issues.
En dat voor een security bedrijf :(
't is langzaam een flinke stapel met serieuze issues.
En dat voor een security bedrijf :(
Bug fixes die meer dan 90 dagen kosten om te herzien? Kom op zeg, ze hoeven geen nieuw product te maken, alleen wat code te herzien die slechts een (heel klein) deel van het totaal aan code is. Tis gewoon zielig als je het niet in 90 dagen voor elkaar krijgt. Maand voorbereiding (wat is het lek en wie kan en gaat de boel om programmeren?). Maandje programmeren en laatste maand testen en (eventueel) bijstellen.
23-01-2015, 17:19 door
[Account Verwijderd]
[Verwijderd]
23-01-2015, 21:56 door
[Account Verwijderd]
[Verwijderd]
23-01-2015, 21:57 door
[Account Verwijderd]
-
Bijgewerkt: 23-01-2015, 21:57
[Verwijderd]
23-01-2015, 21:59 door
[Account Verwijderd]
[Verwijderd]
Door Krakatau:
Dat ding is niet van Google maar van Adobe en Adobe zal de problemen moeten oplossen waarop Google het ding kan bundelen met hun software. Ze zijn hierin dus afhankelijk van Adobe.
Door U-7:
Door dutchfish: Two big thumbs up for Google! Hier maken ze bij mij punten mee.
Gewoon, de zweep erover, en zorgen dat je tijdig security issues fixed.
quote: "no room for lazy admins"
Hier 4 duimen naar beneden. Google heeft nog steeds niet de brakke embedded Flash-player geüpdatet.Gewoon, de zweep erover, en zorgen dat je tijdig security issues fixed.
quote: "no room for lazy admins"
Dat ding is niet van Google maar van Adobe en Adobe zal de problemen moeten oplossen waarop Google het ding kan bundelen met hun software. Ze zijn hierin dus afhankelijk van Adobe.
Dan miet je geen brakke software in je superieure browser bundelen....
En hier nog een vette duim naar beneden. Dat Google maar hand in eigen boezem steekt i.p.v. de tekortkomingen van anderen etaleren. Psa!!... Google heeft dus een héél grote berg boter op het hoofd met nog steeds ondersteuning van SSLv3 uit het oeka.. oeka.. Neanderthalertijdperk!
24-01-2015, 14:06 door
[Account Verwijderd]
[Verwijderd]
24-01-2015, 22:24 door
[Account Verwijderd]
-
Bijgewerkt: 24-01-2015, 22:28
[Verwijderd]
24-01-2015, 23:41 door
Joep Lunaar
Door Anoniem:
1. 90 dagen lijkt lang, maar dat is het niet. Ze moeten oplossing verzinnen, impementeren, testen op alles wat mogelijk is
2. Wanneer MS binnen die 90 dagen meldt, dat is in de update actie na 92 dagen wordt gefixed, komt het bericht ook naar buiten. Kwaadwillenden hebben dan 2 dagen om het te gebruiken (en meer aangezien er genoeg mensen zijn die niet meteen updaten).
Door Krakatau: Waarom corrigeren die leveranciers hun software niet gewoon tijdig? Ze krijgen er nota bene 90 dagen de tijd voor! Dan kunnen ze wel met de vinger wijzen naar Google, die de kwetsbaarheid automatisch openbaar maakt maar 90 dagen is natuurlijk ook ruim de tijd voor (black hat) hackers om zo'n kwetsbaarheid te vinden (onafhankelijk van Google). En dan zijn ze nog veel verder van huis (want black hat hackers doen niet aan die 90 dagen).
1. 90 dagen lijkt lang, maar dat is het niet. Ze moeten oplossing verzinnen, impementeren, testen op alles wat mogelijk is
2. Wanneer MS binnen die 90 dagen meldt, dat is in de update actie na 92 dagen wordt gefixed, komt het bericht ook naar buiten. Kwaadwillenden hebben dan 2 dagen om het te gebruiken (en meer aangezien er genoeg mensen zijn die niet meteen updaten).
De fout, de aanroep van een virtual function van een object op adres 0x0, is ernstig, en vermoedelijk niet al te moeilijk te repareren. Wat code in de trant van "if (obj == 0x0) panic();" ergens op een gepaste plek in de call stack zal wel voldoen.
Lastiger is mogelijk dat de kext niet door Apple, maar door een derde partij ...
24-01-2015, 23:53 door
Joep Lunaar
Een kleine test leert overigens dat het PoC op OS X Lion (10.7) niets uithaalt.
1) Google en onthullen van ongepatchte lekken
Opmerkelijk,
Google is na Apple zelf zo ongeveer de grootste Apple hardware gebruiker.
http://www.ft.com/cms/s/2/d2f3f04e-6ccf-11df-91c8-00144feab49a.html
https://www.usenix.org/conference/lisa13/managing-macs-google-scale
Met het openbaren van deze lekken schieten ze ook in de eigen voet.
Daar geloof ik echter niets van, Google heeft een team dat ook eigen applicaties voor de Mac ontwikkelt.
"Macintosh Operations Team"
https://plus.google.com/113021614344742332063
Ik maak me sterk dat ze niet ook al (voor zichzelf intern) een oplossing hebben bedacht voor deze lekken.
Het één sluit het ander niet uit, kom dan ook maar op met publieke security hints Google ;)
2) Opmerkingen wat betreft de geconstateerde lekken
Waarom Apple ze nog niet verholpen heeft is gissen.
Misschien hebben andere zaken meer prioriteit? *
Wat is de dreigingsfactor eigenlijk van deze lekken?
(Meldingen bekeken met een 'dummie'bril)
* Issue 136: OS X IOKit kernel memory corruption due to bad bzero in IOBluetoothDevice
Voor connectie met bluetooth apparaten moet je toestemming geven (dat hoeft bij voorkeur niet automatisch, dat moest je toch al nooit willen).
Een kwaadaardig apparaat zal dan met behulp van social engineering toegepast moeten worden.
Wat zou kunnen is dat iemand stiekem het wireless toetsenbordje (of muis) van je mac omwisselt. Als je zo'n klein batterij slurpend toetsenboard onding hebt tenminste.
Zet maar een mooie zichtbare handtekening op je bluetooth apparaten ;)
* Issue 130: OS X "networkd" "effective_audit_token" XPC type confusion sandbox escape (with exploit)
Tja, Yosemite en continue netwerkconnecties (Oh my! Wat een hoop "d"'s!
'Overuren' voor je Firewall, zelfs als je privacy settings in acht hebt genomen!).
Ik kom er niet precies achter wat "networkd" zoal zou kunnen wilen en in welke concrete gevallen.
Bij normaal gebruik onder Yosemite zie ik geen connectie attempts van "networkd" terug.
Het "networkd" proces is er onder OS X sinds Lion 10.7, gekeken naar firewall meldingen onder 10.7 heb ik ook daar geen specifieke "networkd" activiteit waargenomen.
Dat zou dan ook kunnen betekenen dat wanneer het niet in je/een firewall ge-whitelisted is, wat vooralsnog niet direct de werking van OS X in de weg lijkt te zitten, deze aanvals aanpak niet zou werken?
Vond deze Poc bug tijdens een zoektochtje ook nog op de Google pagina's
https://code.google.com/p/google-security-research/issues/detail?id=92
* Issue 135: OS X IOKit kernel code execution due to NULL pointer dereference in IntelAccelerator
Er wordt geen (begrijpelijk) gegeven toelichting verder, via welke weg komt dat 'little program' dan je Mac binnen?
Meer specifiek :
@ Joep
(de enige die serieus lijkt te hebben gekeken naar de essentie van het artikel, namelijk de gemelde en niet gepatchte Mac OS X lekken. En daarnaast vermoedelijk één van de heel weinige reageerders hier die ook kennis heeft van of met OS X zelf werkt.)
Zou je voor de geïnteresseerde dummie(s) kunnen / willen uitleggen wat de kwetsbaarheid behelst.
Of anders gezegd, wat je hebt geprobeerd via welke weg (een Mac met dit lek van buitenaf getest? Via de browser?).
Aardig in ieder geval om te zien dat het voor Lion 10.7 niet lijkt de werken, daar gaan sowieso geen updates meer voor uitkomen.
* Apple's Should Be Super Security Priority Above All !
Thunderstrike 31c3
https://trmm.net/Thunderstrike_31c3[/u]
Opmerkelijk,
Google is na Apple zelf zo ongeveer de grootste Apple hardware gebruiker.
http://www.ft.com/cms/s/2/d2f3f04e-6ccf-11df-91c8-00144feab49a.html
https://www.usenix.org/conference/lisa13/managing-macs-google-scale
Met het openbaren van deze lekken schieten ze ook in de eigen voet.
Daar geloof ik echter niets van, Google heeft een team dat ook eigen applicaties voor de Mac ontwikkelt.
"Macintosh Operations Team"
https://plus.google.com/113021614344742332063
Ik maak me sterk dat ze niet ook al (voor zichzelf intern) een oplossing hebben bedacht voor deze lekken.
Het één sluit het ander niet uit, kom dan ook maar op met publieke security hints Google ;)
2) Opmerkingen wat betreft de geconstateerde lekken
Waarom Apple ze nog niet verholpen heeft is gissen.
Misschien hebben andere zaken meer prioriteit? *
Wat is de dreigingsfactor eigenlijk van deze lekken?
(Meldingen bekeken met een 'dummie'bril)
* Issue 136: OS X IOKit kernel memory corruption due to bad bzero in IOBluetoothDevice
Voor connectie met bluetooth apparaten moet je toestemming geven (dat hoeft bij voorkeur niet automatisch, dat moest je toch al nooit willen).
Een kwaadaardig apparaat zal dan met behulp van social engineering toegepast moeten worden.
Wat zou kunnen is dat iemand stiekem het wireless toetsenbordje (of muis) van je mac omwisselt. Als je zo'n klein batterij slurpend toetsenboard onding hebt tenminste.
Zet maar een mooie zichtbare handtekening op je bluetooth apparaten ;)
* Issue 130: OS X "networkd" "effective_audit_token" XPC type confusion sandbox escape (with exploit)
networkd is the system daemon which implements the com.apple.networkd XPC service. It's unsandboxed but runs as its own user. com.apple.networkd is reachable from many sandboxes including the Safari WebProcess and ntpd (plus all those which allow system-network.)
networkd parses quite complicated XPC messages and there are many cases where xpc_dictionary_get_value and xpc_array_get_value are used without subsequent checking of the type of the returned value.
networkd parses quite complicated XPC messages and there are many cases where xpc_dictionary_get_value and xpc_array_get_value are used without subsequent checking of the type of the returned value.
Tja, Yosemite en continue netwerkconnecties (Oh my! Wat een hoop "d"'s!
'Overuren' voor je Firewall, zelfs als je privacy settings in acht hebt genomen!).
Ik kom er niet precies achter wat "networkd" zoal zou kunnen wilen en in welke concrete gevallen.
Bij normaal gebruik onder Yosemite zie ik geen connectie attempts van "networkd" terug.
Het "networkd" proces is er onder OS X sinds Lion 10.7, gekeken naar firewall meldingen onder 10.7 heb ik ook daar geen specifieke "networkd" activiteit waargenomen.
Dat zou dan ook kunnen betekenen dat wanneer het niet in je/een firewall ge-whitelisted is, wat vooralsnog niet direct de werking van OS X in de weg lijkt te zitten, deze aanvals aanpak niet zou werken?
Vond deze Poc bug tijdens een zoektochtje ook nog op de Google pagina's
https://code.google.com/p/google-security-research/issues/detail?id=92
* Issue 135: OS X IOKit kernel code execution due to NULL pointer dereference in IntelAccelerator
I wrote a little program to run over every IOKit IOService userclient type from 1 to 100 and just call IOConnectMapMemory for all the memory type values from 1 to 1000.
Er wordt geen (begrijpelijk) gegeven toelichting verder, via welke weg komt dat 'little program' dan je Mac binnen?
Meer specifiek :
@ Joep
(de enige die serieus lijkt te hebben gekeken naar de essentie van het artikel, namelijk de gemelde en niet gepatchte Mac OS X lekken. En daarnaast vermoedelijk één van de heel weinige reageerders hier die ook kennis heeft van of met OS X zelf werkt.)
Zou je voor de geïnteresseerde dummie(s) kunnen / willen uitleggen wat de kwetsbaarheid behelst.
Of anders gezegd, wat je hebt geprobeerd via welke weg (een Mac met dit lek van buitenaf getest? Via de browser?).
Aardig in ieder geval om te zien dat het voor Lion 10.7 niet lijkt de werken, daar gaan sowieso geen updates meer voor uitkomen.
* Apple's Should Be Super Security Priority Above All !
Thunderstrike 31c3
https://trmm.net/Thunderstrike_31c3[/u]
Reageren
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.
