1)
Google en onthullen van ongepatchte lekkenOpmerkelijk,
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-scaleMet 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/113021614344742332063Ik 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 lekkenWaarom 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 IOBluetoothDeviceVoor 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.
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 IntelAcceleratorI 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]