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.

Is dat een nieuwe marketing techniek van Google?

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).

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"

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.

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 :(

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.

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!

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 ...

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]