Google maakt veiligheidslek macOS bekend voordat er een patch is

Googles Project Zero heeft een ernstig lek in de XNU-kernel van macOS aangetroffen en de details erover bekendgemaakt voordat Apple een patch gereed heeft. Google lichtte Apple in november vorig jaar in over het lek.

Google Project Zero hanteert standaard een periode van negentig dagen na de melding over kwetsbaarheden aan een ontwikkelaar, daarna gaat het bedrijf over tot publicatie. Apple werkt wel aan een fix, maar wanneer deze verschijnt, is niet bekend.

De kwetsbaarheid betreft het copy-on-write-, of cow-gedrag van XNU. "Het is belangrijk dat gekopieerd geheugen beschermd wordt tegen latere modificaties door het bronproces", schrijven de onderzoekers van Google Project Zero. Bij Apples implementatie bleek dat niet op orde.

"Dit betekent dat als een aanvaller een on-disk-bestand kan muteren zonder het virtueelbeheersysteem te informeren, dit een beveiligingsprobleem is", aldus Project Zero. Bij macOS speelt dit bij het mounten van filesystemimages: veranderingen aan het bestandssysteem worden niet doorgegeven aan het gemounte bestandssysteem, wat te misbruiken is. De onderzoekers hebben een proof-of-concept vrijgegeven.

Reacties (137)

[bbob]

Het is niet de eerste keer dat google dit doet. Ze bepalen zelf dat 90 dagen een door hun gestelde termijn is, voldoe je niet hup alles openbaar met eventueel alle gevolgen van dien.

[gday]

Als je een veiligheidslek vindt moet je er vanuit gaan dat jij niet de eerste bent die ermee bekend is. Dat betekent dat er druk moet zijn om dat lek te dichten voordat kwaadwillenden er schade mee aanrichten. Als je zegt: “Sja, we hebben een lek gevonden maar zie maar of en wanneer je ‘m dicht!” dan schiet dat niet echt op.

[batjes]

Alleen heb je als buitenstaander zoals Google totaal gaan kijk op de interne werking van in dit geval Apple.

Voor hetzelfde geld is het een serieus probleem dat ze niet 1, 2, 3 kunnen fixen, zonder dat er van alles stuk gaat. En met een beetje pech ben je al langer dan 3 maanden bezig met testen.

Google flikt dit vaker bij concurrentie, terwijl ze duidelijk hebben laten weten prima coulant te kunnen wezen naar anderen waarbij ze exploits vinden. Maar elke keer als het een grotere concurrent is, dan is die coulance nergens te bekennen. Tenzij het richting Google zelf is, ook dan hebben ze ineens ook schijt aan die 90 dagen.

Het is gewoon niet aan Google om die 90 dagen af te dwingen, vooral omdat ze hier zelf ook al meerdere keren in gebreke zijn gebleken.

Wat richt eventueel meer schade aan, miljoenen gebruikers met een bricked systeem of Google die voordat fixes uitgebracht zijn, de exploit publiekelijk maakt. Hoe ernstig het lek ook is, het is niet aan Google. Tenzij Apple zwaar in gebreke blijkt

[Ed Vertijsment]

Meh, als het een of ander IoT dingetje was schreeuwden we van de daken dat 90 te dagen te lang is. Komt Apple langs dan mag het opeens weer niet. Apple had net zo goed ff de telefoon kunnen pakken en naar Google bellen om het e.e.a. te overleggen om niet te publiceren, hoewel uit de bugtracker is op te maken dat er contact met Apple is geweest betwijfel ik of Apple het echt heel belangrijk vind aan gezien de quote:

"Apple are intending to resolve this issue in a future release".

Voor mij klinkt dat als marketing praat maar goed, ik kan niet bij Apple in de keuken kijken. In ieder geval vermoed ik dat Apple:

- Dit issue meer prioriteit had kunnen geven.
- Contact met Google kunnen aanhalen om publicatie te voorkomen.

Het feit dat Google vendors achter de vodden aanzit om security issues te fixen en daar een meetbare, en mijn inziens acceptabele grens aan hangt kan ik alleen maar toejuichen.

[CivLord]

Meh, als het een of ander IoT dingetje was schreeuwden we van de daken dat 90 te dagen te lang is.

In één of ander IoT dingetje zijn problemen ook iets makkelijker op te lossen dan in het geheugenmanagement van een compleet OS.

[Ed Vertijsment]

Dat is nogal een aanname, macbook patchen gaat misschien wel een stuk makkelijker dan beperkte IoT devices met embedded software die niet zomaar update. Bovendien weet je niet hoe complex het IoT ding is.

Alles wat aan het internet hangt moet te updaten zijn, of het nou je koelkast, je telefoon, je toilet, je tv of je laptop is.

[NanoSector]

Wat @CivLord wil zeggen is dat het maken van een oplossing waarschijnlijk makkelijker is bij een IoT apparaat dan bij een complex OS als macOS. Dat het updaten van een Macbook makkelijker is dan een IoT apparaat is irrelevant.

[Ed Vertijsment]

Mijn punt is dat dat niet irrelevant is. Alleen code in productie telt, alles wat niet uitegrold wordt telt niet. Dus zul je ook de efforts om te deployen mee moeten tellen.

[likewise]

Je device (IoT of Mac) heeft ofwel een update mechanisme of niet. De effort zit hem met name in hoe ingrijpend de bug fix is in de code base.

[Little Charlie]

Maar juist dan had Apple ff contact op kunnen nemen met Google en zeggen;

Joh, niet om het een of ander, maar is best ingewikkeld probleem, en we zijn hard bezig het op te lossen, maar we hebben nog wat meer tijd nodig. Zou je het nog ff buiten de pers willen houden totdat we de update uit kunnen rollen?

De marktetingblaat van Apple geeft niet echt het idee dat ze er hard aan werken, maar dat ze het wel zien wanneer ze er klaar mee zijn. En als ze wel met Google gebeld hadden, en Google toch door had gezet, hadden ze dat wel laten weten, want dan komt Google over als lomp en rigide, en had veel goodwill opgeleverd, iets wat ze momenteel toch wel kunnen gebruiken.

[Pyramiden]

Ik neem aan dat je vanuit interne bronnen hebt vernomen dat Apple geen contact heeft opgenomen? Aangezien het scenario waarin Apple wel contact op heeft genomen maar Google simpelweg de middelvinger geeft blijkbaar uitgesloten is?

[Little Charlie]

Normaliter krijgen mensen met zo'n opmerking van mij de vraag of ze wel begrijpend lezen hebben gehad, maar jij leest gewoon niet:

"En als ze wel met Google gebeld hadden, en Google toch door had gezet, hadden ze dat wel laten weten, want dan komt Google over als lomp en rigide, en had veel goodwill opgeleverd, iets wat ze momenteel toch wel kunnen gebruiken." Het staat er letterlijk.

Apple kan alle sympathie-punten die ze kunnen krijgen tegenwoordig gebruiken na de rare fratsen die ze uitgehaald hebben.

[djwice]

"we're working together" - Apple & Google. Zie bugtracker.

[Ed Vertijsment]

Lees nogmaals en zie de bugtracker...

[laptopleon]

Staat er marketing van Apple in de bugtracker? Ik kon het even niet vinden.

Er staat überhaupt geen woord van Apple hierover online tot nu toe, dat is wat @SoloH bedoelt.

[Ed Vertijsment]

Het gaat dus om quote van een Hawkes die bij Google werkt.

quote: http://[e-mail]

We've been in contact with Apple regarding this issue, and at this point no fix is available. Apple are intending to resolve this issue in a future release, and we're working together to assess the options for a patch. We'll update this issue tracker entry once we have more details.

Hieruit valt een beeld op te maken van hoe "kritiek" Apple hiermee omgaat.

- "no fix is available"
- "Intending"
- "future release"

Geven alle drie een aardige hint dat dit nu niet bepaald allerhoogst op de pro lijst bij Apple staat. Tuurlijk een aanname maar ik heb geen ander pers statement van Apple zelf gezien dus hier moeten het even mee doen.

In zo'n geval snap ik heel goed de keuze om publiek te gaan.

[SoloH]

Knap hoe je dat uit een regel tekst van Google kan opmaken. Er staat dus precies wat de status is.... future release. Geen marketing van Apple in een quote van Google. Zou wel erg slechte marketing zijn, om door je concurrent te laten zeggen dat ze het probleem nog niet gefikst hebben. Zou meer marketing voor de Google zijn, toch?
Het gaat me niet om hoe Google er mee omgaat, alleen om dit soort onnozele reacties die alles wat Apple zeggen als marketing afdoen, maar Google die doet natuurlijk niet aan marketing.
En future release, kan dus prima next release zijn, he.... hoeft niet, maar kan wel.

[Reactie gewijzigd door SoloH op 23 juli 2024 01:52]

[breinonline]

Dat is jouw interpretatie van de tekst. Ik lees in hetzelfde stuk:

and we're working together to assess the options for a patch

Dat klinkt mij meer in de oren alsof Apple constructief mét Google kijkt maar het tegen valt hoe makkelijk het op te lossen is.

[laptopleon]

Ik heb geen medelijden met Apple als ze hier zelf voor kiezen. Wel bij de feiten blijven graag. Er staat geen woord van Apple zelf bij dus welke 'marketingblaat' hebben we het over?

Er komen nogal eens persberichten langs met claims die achteraf nogal opgeblazen blijken. Vorige week nog iets met onveilig dit en dat waarvoor je fysiek bij de computer moest zijn én ingelogd als administrator. Weinig indrukwekkend dat je dan onveilige grappen uit kunt halen. Ik vraag me dan ook oprecht af hoe realistisch het probleem dit keer is.

& @Little Charlie

De marktetingblaat van Apple geeft niet echt het idee dat ze er hard aan werken, maar dat ze het wel zien wanneer ze er klaar mee zijn. En als ze wel met Google gebeld hadden, en Google toch door had gezet, hadden ze dat wel laten weten, want dan komt Google over als lomp en rigide, en had veel goodwill opgeleverd, iets wat ze momenteel toch wel kunnen gebruiken.

Blijkbaar is dus wel contact geweest (zie hierboven reactie van Ed).

[Little Charlie]

Maar Apple doet weer zijn normale actie; totaal niks richting de eindgebruiker, en totaal geen gevoel van urgentie bij hun oplossingen.

Blijft toch een machtig mooie marketing afdeling, dat mensen dit soort gedrag wel goed praten van een firma, maar van een andere compleet zouden verketteren.

[laptopleon]

Maar Apple doet weer zijn normale actie; totaal niks richting de eindgebruiker, en totaal geen gevoel van urgentie bij hun oplossingen.

Paar maanden terug was er een bug waarbij je iemand belde via FaceTime (en dan moest je nog jezelf toevoegen aan een groepgesprek), waarvan je dan al het geluid kon horen voordat hij opnam, terwijl het toestel overging.

Niet het soort hacks waarmee je geschiedenis schrijft, zullen we maar zeggen, maar toch, daar zit niemand op te wachten. Dezelfde dag werd FaceTime nog tijdelijk uitgezet, tot het probleem gefixt was. Week later kwamen ze met een update die dit fixte.

Dus wat is de 'normale reactie'? Dit keer doen ze dat niet, wat je zou kunnen opvatten als dat ze het risico van deze hack minder groot vinden. Proportionele reactie. Je moet nog steeds een programma zien te draaien als aanvaller. Je moet dus eerst die malware zien te installeren. Tja met alle respect dan ben je dus al 'binnen'. Dan kun je al zoveel doen dat dit niet zo heel veel meer toevoegt.

[Little Charlie]

Normale reactie:

- niks (accu's)
- je doet het fout (antenne)
- ontwerpkeuze / materiaalkeuze (ipad/iphone boemerangs)
- Je Hebt Het Maar Leuk Te Vinden (U2)
- Je bent te dik in een te kleine broek (breuken in behuizing)

Oftewel, de schuld bij anderen leggen.

En alleen als het aan de grote klok gehangen wordt, wordt er actie ondernomen.

[likewise]

Hieruit valt een beeld op te maken van hoe "kritiek" Apple hiermee omgaat.

- "no fix is available"
- "Intending"
- "future release"
Geven alle drie een aardige hint dat dit nu niet bepaald allerhoogst op de pro lijst bij Apple staat.

Ik ben het niet met je eens, hieruit valt alleen op te maken dat:
- ze nog geen fix hebben (is meestal zo voor bugs, zeker als ze nog niet bekend zijn)
- er een intentie is om het te fixen
- dat dit in de toekomst gebeurt (duh..., zie eerste item)

bovendien dat ze samenwerken.

Je kunt hier helemaals niks uit afleiden. Zelfs al zou het probleem top priority hebben, dan nog wil dat niet zeggen dat er binnen 3 maanden een afdoende fix is.

Denk eens even aan Spectre en Meltdown -- idem.

[Little Charlie]

Wie denk je dat die antwoorden voorkauwt?

Dat is geen verhaal wat de techneuten uit willen brengen; die willen problemen zsm opgelost hebben.

[Little Charlie]

https://bugs.chromium.org.../issues/detail?id=1726#c2

[batjes]

Huh wat. Wie is 'we'?

Deze discussie is vaker voorgekomen hier op Tweakers over Google die andermans exploits blood legt voordat een bedrijf een fix klaar heeft.

90 dagen is een twijfelachtig limiet. Sommige exploits kunnen nogal wat code aanpassingen vereisen om gefixt te worden en nogmaals. 3 maanden kan te kort zijn om fatsoenlijk te testen. Laat staan fixes uitbrengen.

-De issue zou meer prio kunnen krijgen, maar dat is niet aan Google om dat besluit te maken.
-Contact met Google kan weinig soelaas bieden, in het verleden heeft MS in dezelfde situatie gezeten terwijl ze duidelijk naar Google hadden gecommuniceerd dat het probleem lastig was op te lossen en ze meer tijd nodig hadden.
Google heeft toen alsnog vet bot na 90 dagen het publiek lopen informeren.

Google zit achter die vodden aan i.v.m. marketing, niet om de good guy uit te hangen.

[SoloH]

Een marketing praat van wie? Het is namelijk een quote van Google die je aanhaalt. En er staat toch dat ze contact hebben gehad, maar toch gaan ze over op release.

[davince72]

Ik ben het met je eens dat 90 dagen best voldoende is en indien dat niet het geval is je contact moet opnemen, mits je daar gelijk vanaf het begin van op de hoogte wordt gebracht.

Echter je haalt zelf de bugtracker aan, maar het enige dat ik daar uit kan halen is:
- 30 november 2018 de bug is geregistreerd bij bugs.chromium.org (google dus)
- 28 februari 2019 (slechts 4 dagen geleden) is er contact opgenomen met Apple en beschrijft een google medewerker zijn interpretatie van wat er gezegd is... Dat is natuurlijk geen "quote" van Apple.

Nergens zie ik of lees ik dat Apple al sinds het begin (30 nov.) op de hoogte is. Dus wellicht worden zijn nu overvallen. In dat laatste geval moet ik mijn mening bijstellen en dan is het niet handig/fraai van Google.

[gday]

Google flikt dit vaker bij concurrentie, terwijl ze duidelijk hebben laten weten prima coulant te kunnen wezen naar anderen waarbij ze exploits vinden. Maar elke keer als het een grotere concurrent is, dan is die coulance nergens te bekennen. Tenzij het richting Google zelf is, ook dan hebben ze ineens ook schijt aan die 90 dagen.

Dat is gewoon niet waar.

Zo is Google bijvoorbeeld in 2016, na overleg, wel degelijk coulant geweest bij een vulnerability in macOS en iOS en heeft Apple meer tijd gegeven om dit op te lossen. Zie hier de gedocumenteerde disclosure timeline:
https://bugs.chromium.org...o/issues/detail?id=837#c3

Hou je alsjeblieft bij de feiten.

[Reactie gewijzigd door gday op 23 juli 2024 01:52]

[batjes]

Ah oke, feiten. Google is dus wel coulant

https://www.techzine.nl/n...microsoft.html?redirect=1

Google heeft afgelopen weekend een lek bekend gemaakt in Windows 10, ondanks dat Microsoft meermaals heeft geprobeerd om dat te voorkomen. Googles Project Zero heeft op 19 januari de bug aan Microsoft bekend gemaakt. Microsoft heeft op zijn beurt drie weken later laten weten dat ze het rapport goed hebben ontvangen. Van zodra Project Zero de bug doorstuurt, start er een 90-dagen deadline voordat Google het veiligheidslek publiek maakt.

Helaas kon Microsoft de patch niet tijdig verwerken in de Patch Tuesday van april, volgens ITProPortal omwille van een “onverwachte coderelatie”. Het vroeg voor een extra twee weken eerder deze maand, maar kreeg die niet van Google.

Daarna wilde Microsoft de code updaten in de nieuwe Redstone 4-update (Spring Creators Update), maar omdat ze daarrond nog geen lanceringsdatum hebben, heeft Google opnieuw geweigerd om medewerking te verlenen vorige week.

Nu heeft Apple de patch nog niet klaar, wel aangegeven dat hij de volgende release/patch mee komt. Weer super coulant dit.

[gday]

Ho, ik heb nergens gezegd dat Google altijd coulant is. Maar jij zei dat Google nooit coulant is en dat is gewoon niet waar.

[Reactie gewijzigd door gday op 23 juli 2024 01:52]

[batjes]

Ik heb ook niet gezegd dat Google nooit coulant is. Maar dat ze dit niet zijn als ze grote concurrentie op de hak kunnen nemen.

[gday]

Excuus. Ik bedoelde dat je zei dat Google nooit coulant is richting concurrenten. En dat is dus gewoon niet waar.

[Jorick]

Heb je er al eens bij stilgestaan dat Google niet alleen een concurrent maar ook klant van Apple is? Bij Google werken veel werknemers met een Macbook dus het is ook in het belang van Google dat Apple snel met een oplossing komt. Het is niet raar dat Google in de rol van klant bij de fabrikant afdwingt binnen negentig dagen met een oplossing te komen.

Dat Google na negentig dagen over gaat op publicatie is overigens niet van gisteren dus Apple had daar prima op kunnen anticiperen. Het blijft (wederom) opvallend stil vanuit Cupertino, ze hadden op zijn minst duidelijk kunnen communiceren waarom ze nog geen oplossing voor dit lek hebben en wanneer die dan wel te verwachten valt.

[batjes]

Dan zou Google een lijn moeten trekken en zelf ook niet compleet schijt hebben aan die 90 dagen als het Google uitkomt. Want ze houden zichzelf er al niet eens aan.

Ik zie ook wel eens voorbij komen dat Google best coulant is bij kleine partijen.

Maar ook Intel gaven ze met de ernstigste zet exploits in lange tijd ook dik een half jaar voor publicatie. En dat lekte, Google zou rustig een jaar wachten.

Maar Google laat de coulance vallen als het op Apple of Microsoft aankomt?

Volgens mij is dit geen zuivere koffie.

[TheVivaldi]

En wat weerhield Apple ervan om Google te bellen en te zeggen "bedankt voor het vinden van dit lek, we hebben er ontwikkelaars op gezet om het te gaan dichten"? Nu hebben ze alleen gezegd "we hebben de intentie het ooit op te lossen", nee dat is lekker duidelijk, zeg... Als het nu om een klein bugje ging, soit, maar dit is een serieus veiligheidslek, dan hadden ze best wat duidelijker tegen Google kunnen zijn dat ze het serieus namen en kunnen vragen of ze misschien die deadline niet zo strak hadden willen hanteren als ze hun goede wil hadden getoond.

[Reactie gewijzigd door TheVivaldi op 23 juli 2024 01:52]

[Thystan]

Als Apple binnen 14 dagen het lek zou dichten zou Google het ook niet publiceren.

[Vexxon]

Het grappige is dat Google die regels alleen hanteert wanneer het om bugs gaat in andermans software, maar niet als het om bv Android gaat:

Drake had eerder al te kennen gegeven dat hij de exploit vrij zou geven. Dat moest gebeuren op de Black Hat-conferentie. Toen werd echter besloten tot uitstel, om Google meer tijd te geven om de kwetsbaarheid te repareren. De internetgigant bracht eerder al een patch naar buiten, maar een beveiligingsbedrijf wees erop dat deze niet voldoende bescherming bood tegen de Stagefright-bug. In hoeverre er momenteel misbruik wordt gemaakt van de Stagefright-bug is niet bekend.

bron

[raro007]

Een week kregen ze en geen 90 dagen...

[Foamy]

Een week uitstel bedoel je. De eerste melding naar Google was op dat moment al 4 maanden oud.. Stagefright is in april 2015 voor het eerst gemeld aan Google. De patch die ze hier twee dagen later voor uitbrachten was niet afdoende. Wat er toe heeft geleid dat eind juli 2015 de bug alsnog publiekelijk bekend werd gemaakt.

[CH4OS]

Security heeft (eindelijk) veel meer prioriteit gekregen in vier jaar tijd. Dus zo raar vind ik het niet.

[Maurits van Baerle]

Klopt, er zijn dan ook mensen die vermoeden dat dit programma eigenlijk een manier is om de concurrentie in een kwaad daglicht te stellen.

[Thystan]

Zie mijn reactie hier boven ^

[bbob]

Alles heeft met het type lek te maken, de ene is urgenter dan de ander. Als voor de ene fysiek toegang tot een pc nodig is zal dat minder urgent zijn dan een ander waar het via een bestand of internet kan.

Daarnaast kan men had aan de oplossing gewerkt hebben maar soms zorgt een patch weer voor andere problemen die je dan moet oplossen.

Wat ik wil aangeven is dat je dit soort zaken van geval tot geval moet bekijken. Het ene zal urgent zijn de ander minder urgent.

[theduke1989]

en hier gaat het dus om een ''ernstige lek'' zoals in de tekst staat.

Dus tja en om dan meteen naar buiten te reopen Nadat je het gevonden hebt, heb je juist een grotere breach impact dan de 90 dagen misschien waabij niemand of weinig mensnen er van kunnen profiteren.

[Mundatin]

Hier met ik het volledig mee eens. Google heeft in dit geval Apple genoeg tijd gegeven dit lek te dichten, acht Apple het niet belangrijk genoeg. Dan maar eens zien op het moment dat het gepubliceerd wordt kijken hoe belangrijk Apple het dan nog acht.

[cavey]

90 dagen is anders een vrij normale grace periode. Al kan elke organisatie een eigen termijn hanteren. Zo zijn er genoeg organisaties die een bug procedure hebben, en hebben gepubliceerd, waarbij ze zelf aangeven wat de grace periode kan zijn. Heb er nu al een paar gevonden die varieren: 45 dagen, 60 dagen, en dan is google weer aan de ruime kant met 90 dagen.

Dit is dan weer een onderszoeks instantie die aangeeft dat ze na 45 dagen al een disclosure doen na initieel contact:
https://ics-cert.us-cert....ability-Disclosure-Policy

Dus ja, het is niet in steen geschreven wat de grace periode is. 90 dagen is eigenlijk voor 0-days al heel erg ruim.

[Cergorach]

Ze bepalen zelf dat 90 dagen een door hun gestelde termijn is, voldoe je niet hup alles openbaar met eventueel alle gevolgen van dien.

Daar moeten vast regels aan gesteld worden en als ze consequent 90 dagen aanhouden ongeacht wie of wat het issue is kan ik dat alleen maar aanprijzen. En vanuit de organisatie gezien kan je niet van buiten een organisatie bepalen of ze er hard aan werken of dat het ergens in een hoekje ligt bij de te fixen partij, ipv. onderbuikgevoel hebben ze regels aan zichzelf gesteld en daar houden ze zichzelf aan.

En in dit geval is het niet fijn voor de MacOS gebruikers, maar als ze het niet op deze manier doen heb je straks weer van die lekken waar men jaren en soms wel eens decennia niets mee doet.

[Kevinp]

Als er prioriteit is moet het wel HEEL complex zijn wanneer een reproduceerbaar lek niet binnen een paar dagen op te lossen is. Als het prioriteit krijgt.

Na 3 maanden lukt dat sowieso (bij prioriteit). Dat ze het openbaar maken is wat mij betreft niet zo erg. Want wie zegt dat google uberhaupt de eerste was. Als ik crimineel zou zijn zou ik het sowieso voor mezelf houden of verkopen.

[CivLord]

Wanneer het probleem op zichzelf staat, mag dat inderdaad geen probleem zijn. Wanneer het probleem in het geheugenmanagent van een OS zit en een wijziging daarvan mogelijk problemen op kan leveren in andere onderdelen van het OS, kan een 'simpele' fix een cascade aan problemen opleveren. Een goede fix, met eventuele aanpassingen in andere onderdelen van het OS en tests kan aardig wat tijd in beslag nemen, zelfs wanneer het topprioriteit heeft.

Of Google de eerste was die dit lek heeft ontdekt weet niemand. Maar dat iedereen die belangstelling heeft nu weet dat er een nog ongepatcht lek is en er zelfs een proof-of-concept is vrijgegeven om ze op weg te helpen is 100% zeker.

[BLACKfm]

Prima toch? Misschien dat ze dan een beetje haast gaan maken bij de software afdeling. Hoe lastig kan het zijn om even 'al je recources' te zetten op het fixen van die fout? Dat mag geen 3 maanden duren.

[SuperDre]

Mag hopen dat het een sarcastische opmerking was. 3 maanden is in feite heel kort, voor sommige bugs hoeft dat geen probleem te zijn, maar als het dieper zit kun je vaak niet even zomaar aanpassingen maken. Zeker bij OSsen als MacOS en Windows zul je heel goed moeten uitzoeken wat de gevolgen zijn als je de aanpassing maakt. Dan komt er ook nog het testen van de fix bij.
Dus simpel zeggen dat 3 maanden genoeg is, is wel heel erg kort door de bocht en een gebrek aan visie.

[SuperDre]

Ja, juist het is precies een zaak van 'allemaal mitsen en maren'. Je kunt dus nooit precies zeggen of 3 maanden genoeg is. Misschien IS het een kwestie van een '1' in een '0' veranderen, maar je zult toch wel moeten weten wat de gevolgen dan kunnen zijn, zeker bij API's waarbij de werking dus eigenlijk is zoals beschreven, maar dus niet zo goed is nagedacht over de API zelf.
En ja prioriteiten stellen kan een probleem zijn, wat JIJ een hoge prioriteit vindt kan iemand anders geen prioriteit vinden, ook met dit soort bugs. Naast dat je gelijk hebt, sommige developers zijn nu eenmaal ergens mee bezig en kunnen dan niet zomaar van dat project gehaald worden, en niet elke developer is geschikt om bepaalde bugs op te lossen.

[harrald]

Het is niet dat je met 10 keer meer programmeurs het probleem 10 keer sneller oplost. Zo zou je met 9 vrouwen in 1 maand een baby ter wereld kunnen brengen

[BLACKfm]

Een vergelijking die weer als een tang op een varken slaat... Ik gooi er even een paar tegen-vergelijkingen in.

- Een straat is met 10 stratenmakers een stuk sneller klaar dan met 1 persoon (je kunt allemaal een stukje doen)
- De muur verven gaat een stuk sneller met 10 man, dan in je 1tje (je kunt allemaal een stukje doen)
- Je kunt met 12 man in een eigen auto alle boodschappen voor het jaar in 1x halen, ipv 12x zelf op en neer te rijden (je kunt allemaal een maand boodschappen kwijt in je auto).

Mij is altijd geleerd "2 weten meer dan 1", en uit mijn eigen praktijk blijkt ook dat het een stuk sneller gaat als je met een team werkt (in specifieke gevallen, niet elke situatie - zoals een kind produceren - leent zich daar voor) dan dat je alleen gaat zitten stoeien.

Oftewel, als je met een paar man (ik neem aan dat er bij apple wel iets meer dan 10 mensen werken voor het MacOS) even over deze kwestie heen buigt is de oplossing een stuk sneller gevonden dan iemand die in zijn/haar eentje de boel even moet gaan oplossen. En wie weet is deze fout als stopklusje weggezet omdat het geen prioriteit heeft.

Ik kan niet inschatten of dit een groot of klein probleem is en hoe groot het risico is dat het uitgebuit kan worden. Maar het feit dat er aandacht aan wordt besteed (mogelijk alleen maar vanuit de media om maar te kunnen zeggen 'zie je wel, Apple heeft ook zijn zwakke punten') maakt het blijkbaar een relatief groot probleem. Het kan natuurlijk ook vanwege de temperaturen al vroeg komkommer-tijd zijn dat elk wissewasje wordt gemeld, maar daar ga ik bij t.net maar even niet van uit.

Hoe dan ook, het bericht suggereert dat de wereld vergaat omdat google een lek openbaart die nog niet gefixed is. Als dit een groot probleem voor Apple is dan hadden ze er wat meer tijd aan moeten spenderen.

[WhatsappHack]

Echter is too many tim cooks in the kitchen ook een reëel probleem bij softwareontwikkeling.

[Stoelpoot]

> Een straat is met 10 stratenmakers een stuk sneller klaar dan met 1 persoon (je kunt allemaal een stukje doen)

Klopt, maar 1 steen leggen met 2 stratenmakers duurt langer dan 1 stratenmaker die dat doet. 2 stenen ook nog. Pas wanneer je een groot aantal stenen moet leggen kunnen meerdere stratenmakers werken zonder met elkaar rekening te hoeven houden. Een bug is vaak iets wat met maar een klein aantal "stenen" in een programma te maken heeft. Om dan met 10 programmeurs het werk te verdelen is vaak niet mogelijk zodra de onderzoeksfase voorbij is.

> De muur verven gaat een stuk sneller met 10 man, dan in je 1tje (je kunt allemaal een stukje doen)

Hierbij ook: Dit gaat enkel op als elke schilder voldoende ruimte heeft om z'n eigen stuk te schilderen. Een muur van 3m schilderen met 10 man geeft geen snelheidswinst, de schilders zullen elkaar juist in de weg lopen.

> Je kunt met 12 man in een eigen auto alle boodschappen voor het jaar in 1x halen, ipv 12x zelf op en neer te rijden (je kunt allemaal een maand boodschappen kwijt in je auto).

Maar met 7 man kan je niet sneller boodschappen voor elke dag halen. 1 maand is in dit geval een dusdanig ruime tijdseenheid dat elke deelnemer een eigen lijstje af kan werken met minimale overlap. 1 dag niet, omdat je voor de meeste boodschappen zal moeten communiceren of een ander datzelfde item al heeft. Als de persoon voor maandag al toiletpapier heeft, hoeft dat dinsdag niet gehaald te worden.

De voorbeelden hierover komen heel sterk overeen met hoe samenwerken in programmeren gaat. Met 2 man krijg je een taak langzamer af dan met 1 man, omdat je je an elkaar moet aanpassen binnen de ontwikkeling. Maar 4 taken kunnen door 2 man wel sneller worden opgelost, omdat beiden 2 losstaande taken kunnen oppakken. Blindelings resources tegen een probleem aan gooien betekent niet per definitie dat het probleem sneller wordt opgelost. De verhouding moet kloppen.

[GeenBergTeHoog]

Je zou best parallel meerdere mensen op hun eigen branch kunnen laten werken en kijken wie het eerst met een goede workaround (of zelfs de fix) komt; een security issue is daar mogelijk/waarschijnlijk wel belangrijk genoeg voor. Of een paar mobs laten programmeren naar de oplossing.

[Verwijderd]

Prima toch? Misschien dat ze dan een beetje haast gaan maken bij de software afdeling. Hoe lastig kan het zijn om even 'al je recources' te zetten op het fixen van die fout? Dat mag geen 3 maanden duren.

Jij hebt overduidelijk nog nooit in je leven aan een groot software product gewerkt. Een complexe bug fixen en die testen, in tien dagen, is in veel gevallen gewoon absoluut onmogelijk. Voor veel software problemen helpt het inzetten van meer mensen gewoon niet. Je kan niet 100 man aan een subroutine laten werken.

[ApexAlpha]

Terecht, anders laten ontwikkelaren het te lang liggen. Google publiceert het nu, maar je weet niet hoeveel anderen dit al gevonden hebben en hoelang ze dit al gebruiken.

In ieder geval goed dat ze de lijn ook bij Apple durven hanteren en niet alleen bij kleinere bedrijfjes.

[bbob]

Er zijn genoeg voorbeelden van fouten die al 20 jaar in een systeem zitten en bij toeval gevonden zijn.

Het zal altijd een discussie zijn, wordt de bug al actief gebruikt of niet. Als die kans klein is maakt een paar weken extra niet uit. Als het echt groot probleem is, is meer actie nodig.
De vraag is ook hoe eenvoudig is het op te lossen en zorgt de oplossing zoals vaker voorkomt niet voor een ander probleem.

Ik denk dat je dit van geval tot geval moet bekijken, compliciteit, type bug enz. Pas dan kun je zeggen ik ga openbaar maken en laat dan misbruik door iedereen toe. Het is een gevaarlijk spelletje.

[The Zep Man]

Ik denk dat je dit van geval tot geval moet bekijken, compliciteit, type bug enz. Pas dan kun je zeggen ik ga openbaar maken en laat dan misbruik door iedereen toe. Het is een gevaarlijk spelletje.

Dat het niet publiekelijk bekend is, is niet gelijk aan dat het niet misbruikt wordt. Als het beveiligingsprobleem publiek bekend is en er is nog geen oplossing, dan stelt het iedereen in staat om risicoanalyses te maken en te kijken naar workarounds. Zie bijvoorbeeld EternalBlue, een kwetsbaarheid die al lang door de NSA werd misbruikt voordat het publiekelijk bekend werd.

90 dagen is een redelijke periode. Als het na 90 dagen niet is op te lossen, dan is het beter dat het publiekelijk bekend is. Immers zijn systemen dan al (introductie kwetsbaarheid) + 90 dagen kwetsbaar, en dat is lang genoeg om te kijken naar alternatieve oplossingen/mitigaties in plaats van enkel te wachten op een officiële oplossing.

[Reactie gewijzigd door The Zep Man op 23 juli 2024 01:52]

[Wittev1]

Het is inderdaad niet de eerste keer, maar er zijn ook situaties waarin Google wel langer heeft gewacht.

Dit komt dan waarschijnlijk vooral door de onderlinge communicatie. "Patch is onderweg en releasen we op datum x". Als dit in de buurt ligt van de 90 dagen dan zijn ze echt niet de beroerdste. Zodra de patch er is wordt er een direct een publicatie tegenaan gegooid.

[EvilWhiteDragon]

Toch een aantal keer gezien dat Google een bug in Windows gevonden had, waarbij het daar wel moeilijk over deed. Zo had de patch klaar voor een aankomende "Patch Tuesday" een paar dagen tot een week later, maar vond Google het toch nodig om strikt die 90 dagen aan te houden. Dat is m.i. niet netjes en brengt juist meer mensen in gevaar dan wanneer er een paar dagen gewacht wordt.

[Sandwalker]

Google is een commercieel bedrijf. Ze doen dit onderzoek om twee redenen: Leren en markteting.
Daar kun je van alles van vinden, maar in 90 dagen na melding moet een professioneel bedrif in staat zijn om in de eigen software een containment te bouwen. Als ze net iets voor de patch zijn, levert dat veel meer reuring op dan net erna. En ze houden zich wel netjes aan die negentig dagen termijn, die men vanaf de start communiceerde, waarmee ze hun marketing een dienst bewijzen en iedereen laten weten dat zij de druk op de ketel houden. Zeker richting de softwarereuzen zoals in dit geval Apple is dat ook nodig.

[Rob Coops]

Heel erg goed van Goolge zouden er meer moeten doen.
Google weet ook wel dat haar mensen niet beter zijn dan de rest van de wereld en dat als zij dit lek kunnen vinden andere dat zeker ook kunnen. Google geeft een bedrijf 90 dagen de tijd. Dat is relatief lang te noemen er zijn meer dan voldoende mensen die liever 30 dagen zouden zien dan 90 dagen. Maar ondanks dat zijn er bedrijven die claimen dat veiligheid en privacy belangrijk zijn die dan meer dan 90 dagen nodig hebben om een lek te dichten. Dat is onzin, als dit de juiste prioriteit had gehad en security echt zo belangrijk was geweest had zo'n lek gedicht kunnen worden in ene paar weken zeker een paar maanden. Maar na 3 maanden is er nog steeds geen patch dat betekend niets anders dan een verkeerde prioriteit stelling bij Apple. Google heeft al vaker aangetoond dat het dan simpel weg de fout openbaar maakt omdat het zeer waarschijnlijk is dat andere de fout inmiddels ook gevonden hebben en op deze manier het bedrijf in kwestie (in dit geval Apple) de bug wel moet fiksen omdat er nu zeer snel een exploit op de markt zal komen die hier misbruik van maakt.

Is dat verkeerd van Google? Nee, niet echt ze hebben van af het begin duidelijk gemaakt dat hun doel is om bugs te vinden en opgelost te krijgen in systemen die zij zelf ook veel gebruiken. 90 dagen is een zeer redelijke termijn (eerder te lang dan te kort) voor een bedrijf om een bug op te lossen. Omdat ook Google medewerkers massaal Apple systemen gebruiken is het niet meer dan normaal dat zij graag zien dat het OS zo veilig mogelijk is. En dus op deze manier proberen om Apple te dwingen lekken te dichten.

Ik kan dit alleen maar toejuichen het is alleen erg jammer dat er zo weinig bedrijven zijn die dit soort teams hebben. Er zijn genoeg grote bedrijven die flink geld uitgeven aan IT oplossingen die vaak ook willen draaien op een klant systeem waar niemand ooit naar de veiligheid van zulke systemen kijkt. En dat zijn alleen de eigen systemen al, als men zo als Google vrijwel oneindig veel geld te besteden heeft dan is ook het onderzoeken van bijvoorbeeld de besturingssystemen waar men dagelijks mee werkt zeker niet een slecht idee.

[Skywalker27]

Dit is nog netjes in ISEC zien we deze tijd rap kleiner worden, nu is eigenlijk 30 dagen al normaal, het zou me niet verbazen als we in de toekomst richting de tien dagen gaan.

[ICT Consultant]

Het is niet de eerste keer dat google dit doet. Ze bepalen zelf dat 90 dagen een door hun gestelde termijn is, voldoe je niet hup alles openbaar met eventueel alle gevolgen van dien.

Meestal sta ik aan de kant van Apple, maar hier geef ik Google toch gelijk. De regels zijn duidelijk en simpel en voor iedereen gelijk. Elke bug wordt netjes bij de juiste softwaremaker gemeld, en na 90 dagen worden er wat gegevens betreffende het lek gepubliceerd.

Apple had 90 dagen om het lek te zoeken, te fixen en een software update uit te rollen. Als Apple dat niet doet, vindt men het waarschijnlijk niet belangrijk genoeg.

Is het een grote bedreiging? Volgens mij niet. Er is een bug, er is een PoC om dit gat te misbruiken, maar ook ongepatcht hoef je je vast geen zorgen te maken. Toch een minpuntje voor Apple.

[Vlizzjeffrey]

Goed dat ze dat doen.

[quintox]

Het valt me op, maar het kan slechts mijn perceptie zijn, dat Apple altijd slordig/traag omgaat met breaches. In het verleden werd Apple geprezen vanwege het "kan niet geïnfecteerd worden door virussen", maar dat is natuurlijk onzin en heeft dat ze soms lui gemaakt?

Als je het vergelijkt met Microsoft, waar ze natuurlijk een rijke historie hebben van verschillende breaches/kwetsbaarheden zijn ze wél in staat om op korte termijn een hotfix uit te rollen. Vaak slechts enkele dagen na initiële reports. Waarom moet dit bij Apple maanden duren? Is de complexiteit dusdanig hoog of heeft het gewoon geen prioriteit?

90 dagen zou meer dan voldoende moeten zijn om tijdig met een oplossing te komen.. lijkt me een gevalletje wanbeleid i.p.v. technische onkunde.

[Reactie gewijzigd door quintox op 23 juli 2024 01:52]

[World Citizen]

Stats

https://bugs.chromium.org...roduct%20Finder%20Summary

Het lijkt allemaal wel mee te vallen dus.

(krijg ik nou een 0 omdat de link slecht is, of omdat mijn eigen mening slecht is?)

[Reactie gewijzigd door World Citizen op 23 juli 2024 01:52]

[quintox]

Waar doel je op? Het totale aantal bugs dat gerapporteerd en/of gefixed zijn? Of de time to fix?
Dat ze er minder hebben mag niet betekenen dat ze er 3 maanden (of langer) voor nodig mogen hebben om het te fixen. Dit is namelijk niet de 1e keer.

Eerder:
"Unfortunately, the researchers said that most of the latest bugs were in Apple’s WebKit codebase for somewhere between six months and a year before being addressed, though they (and their predecessors) might have survived longer if Google hadn’t reported them."

Zeker gezien het prijskaartje en de schouderklopjes die Apple zichzelf geeft wanneer het aankomt op security/privacy verwacht je simpelweg meer van Apple. Echter zijn het overige fabrikanten die doorgaans door het slijk gaan terwijl ze daar niet alleen sneller problemen fixen maar ze ook nog zélf publiceren ( zonder hulp van Google ). Shame on you Apple.

[Reactie gewijzigd door quintox op 23 juli 2024 01:52]

[World Citizen]

Ik wil niet zo zeer zeggen dat het goed of slecht is, er staan er gewoon niet zo veel open voor Apple, en er staan er een hoop uit september afgevinkt.

Er word dus wel degelijk iets gedaan.

Als er verder zo weinig open staat, en deze berichten niet wekelijks op T.net komen, lijkt het me dat we wat verder moeten kijken dan simpel zeggen dat Apple slecht is (ik wil ook niet zeggen dat ze goed zijn.. het boeit me niet)

De quote van "Unfortunately, the researchers said that most of the latest bugs were in Apple’s WebKit codebase for somewhere between six months and a year before being addressed,"

Is opmerkzaam, ik zou inderdaad ook eens vragen hoe dat zit. Maar die info staat er niet bij. Dat is hetzelfde als dat je zegt dat BMW's snel stuk gaan omdat je er een langs de snelweg zag staan.

Wat is de context van die claim? Waren het echt gevaarlijke bugs, zijn het kleine dingen die wel fout zijn maar niet zoveel impact hebben? Puur de opmerking die je quote stelt mij net zo veel vraagtekens bij de schrijver ervan dan bij Apple.

Ik wil niet zeggen dat Apple hier goed bezig is, maar wat ik wel wil zeggen is dat wij daar vooral geen uitspraak over kunnen doen.

@quintox geeft aan dat hem iets opvalt ... maar wat is daar de context van? Leest hij 1 site of alle bugreports? Hierop geef ik hem enkel een link waarop hij wellicht zijn gevoel kan staven. Anders zitten we allemaal slap te lullen...

[quintox]

Bron van mijn quote:
https://venturebeat.com/2...fari-security-advisories/

Met researchers doelen ze overigens op Project Zero medewerkers, niet een of andere "the verge" blogger

[World Citizen]

Als ik die bron lees dan zijn ze zelf al redelijk gematigd. Blijkbaar waren er een aantal bugs fixed binnen de tijd, en zijn er wat van webkit die dat niet zijn. Een reden daarvoor neigt naar speculatie in dat artikel.

Maar goed er word aangehaald dat ze "stiekem fixen" en beter hadden kunnen vertellen of iets in die richting?

Ik weet het niet, maar als ik die pagina van Google erbij pak en jouw artikel dan zou ik me niet echt zorgen maken als Apple gebruiker om dit bericht. Het gaat eigenlijk wel goed en normaal gesproken fixen ze alles wel binnen 3 maanden. Wellicht publiceren ze een fix niet en kun je ze dat kwalijk nemen, maar voorlopig word er een hoop gefixed.

[Vlizzjeffrey]

3 maanden valt niet mee

[BikkelZ]

Als je het vergelijkt met Microsoft, waar ze natuurlijk een rijke historie hebben van verschillende breaches/kwetsbaarheden zijn ze wél in staat om op korte termijn een hotfix uit te rollen. Vaak slechts enkele dagen na initiële reports.

Microsoft software heeft niet de reputatie veilig te zijn maar gezien het enorme oppervlak aan legacy-cruft in Windows en het lage aantal problemen is het echt een enorm veilig systeem. Apache was eerst veiliger maar naderhand werd IIS veel veiliger. Weinig mensen weten dat en denken dat Apache veiliger is. Onder de motorkap zit Windows vaak beter in elkaar maar het probleem met Windows zit hem de UX en hoe alles uiteindelijk met elkaar samenwerkt. Maar macOS kies ik niet vanwege de veiligheid.

Waarom moet dit bij Apple maanden duren? Is de complexiteit dusdanig hoog of heeft het gewoon geen prioriteit?

Een bug oplossen in je file system is één ding. Een bug oplossen zonder compatibiliteit te breken met alles wat er op leunt is een ander verhaal. Drie maanden kan erg kort zijn als de enige oplossing een herstructurering van je bestaande software vereist.

[Reactie gewijzigd door BikkelZ op 23 juli 2024 01:52]

[quintox]

In het geval van Windows snap ik dat nog wel, maar juist in Apple's situatie zou dat toch eenvoudiger moeten zijn? Immers, de totale hoeveelheid variaties in hardware/drivers/configuraties is enorm beperkt. Hierdoor zou je (in theorie) toch veel makkelijker een work-around moeten kunnen hotfixen?

Unit testing lijkt me voor Apple een heel stuk eenvoudiger/sneller dan voor Microsoft of Google

[Reactie gewijzigd door quintox op 23 juli 2024 01:52]

[BikkelZ]

In het geval van Windows snap ik dat nog wel, maar juist in Apple's situatie zou dat toch eenvoudiger moeten zijn? Immers, de totale hoeveelheid variaties in hardware/driversconfiguraties is enorm beperkt. Hierdoor zou je (in theorie) toch veel makkelijker een work-around moeten kunnen hotfixen?

Het gaat ook niet om de hardware maar om de software, een zeer groot deel van de software benadert de schijven. Als ze een fix uitrollen waardoor Adobe CS en alle third-party back-up software stuk gaat plus nog wat ongedefinieerd gedrag in een aantal Terminal-tools dan hebben ze ook een enorm probleem.

Unit testing lijkt me voor Apple een heel stuk eenvoudiger/sneller dan voor Microsoft of Google

Het is zeker makkelijker niet alleen in verband met de hardware configuraties (die niet zo erg van toepassing zijn bij dit probleem waarschijnlijk) maar ook omdat Apple altijd strikt de oude meuk er uit gooit terwijl Microsoft compatibiliteit blijft bieden voor spul uit de jaren '80.

Ik ben enorm onder de indruk van de manier waarop Microsoft zijn zaakjes op orde heeft gezien alle legacy cruft. Wat Windows mist is een coherentie visie maar het is echt een enorme prestatie.

Waarom Android, als veruit het nieuwste OS en simpeler van opzet dan macOS laat staan Windows in álle opzichten zelfs na tien jaar nog een zootje is vind ik een grof schandaal. Windows update zat al in Windows 95 en had patches voor álle computers met Windows op de zelfde dag. Dat is echt méér dan 20 jaar geleden.

[Reactie gewijzigd door BikkelZ op 23 juli 2024 01:52]

[quintox]

Dat ligt toch niet zozeer aan Android? Dat fabrikanten er hun eigen schil overeen gooien en updates blokkeren doordat ze hun eigen bloatware niet of traag updaten kun je moeilijk Android verwijten.

Iets wat Google immers probeert op te lossen met Android 9 door strengere eisen te stellen aan third-party fabrikanten zodat updates niet geblokkeerd worden.

"Als ze een fix uitrollen waardoor Adobe CS en alle third-party back-up software stuk gaat plus nog wat ongedefinieerd gedrag in een aantal Terminal-tools dan hebben ze ook een enorm probleem."
Dat klopt, maar het grote voordeel waarom ik hardware aanhaal: Ze moeten allemaal dezelfde hardware én drivers gebruiken ( bijv. de USB drivers en transfer protocollen ). De functie die wordt aangeroepen door software kun je toch isoleren met een extra laag? Oversimplified natuurlijk, maar juist omdat ze geen gigantische hoeveelheid legacy code ondersteunen is het sneller gefixed én getest.

[BikkelZ]

Dat ligt toch niet zozeer aan Android?

De schillen blokkeren de updates niet. Je kunt in Windows ook talloze dingen customized en geen enkele aanpassing blokkeert Windows Updates. Het is een bewuste ontwerpfout in Android om dat aan fabrikanten én providers over te laten.

Iets wat Google immers probeert op te lossen met Android 9 door strengere eisen te stellen aan third-party fabrikanten zodat updates niet geblokkeerd worden.

We zijn inmiddels tien jaar verder en het wordt maar héél langzaam beter. Als het een Microsoft-product was geweest dan waren ze allang echt he-le-maal tot op de grond afgefakkeld. Windows Phone zat véél beter in elkaar. Waarschijnlijk zelfs beter dan iOS, het draaide in ieder geval als een tierelier op zwakkere hardware.

Dat klopt, maar het grote voordeel waarom ik hardware aanhaal: Ze moeten allemaal dezelfde hardware én drivers gebruiken ( bijv. de USB drivers en transfer protocollen ). De functie die wordt aangeroepen door software kun je toch isoleren met een extra laag? Oversimplified natuurlijk, maar juist omdat ze geen gigantische hoeveelheid legacy code ondersteunen is het sneller gefixed én getest.

Precies, macOS zit simpeler in elkaar dan Windows en zou daardoor makkelijker te onderhouden moeten zijn. Maar de software die op macOS draait moet ook blijven werken via de zelfde API's zonder dat er ineens allerlei edge cases opduiken anders hebben ze echt een probleem. En die software is héél divers en ook die software hangt weer van hacks aan elkaar. Met name Adobe.

[Reactie gewijzigd door BikkelZ op 23 juli 2024 01:52]

[quintox]

"De schillen blokkeren de updates niet. Je kunt in Windows ook talloze dingen customized en geen enkele aanpassing blokkeert Windows Updates. Het is een bewuste ontwerpfout in Android om dat aan fabrikanten én providers over te laten."

Nouja, aan één kant is het een design flaw, maar aan de andere kant is het natuurlijk het effect van open source software. Iedereen kan ( en doet ook ) zijn eigen tailormade variant bouwen. Iets wat Apple en Microsoft natuurlijk nooit zullen toestaan. Zoiets kun je dan ook niet vergelijken met "het customizen van windows", aangezien de fabrikant van bijv. een laptop enkel drivers levert, maar niks met het OS doet.

Dit is een design flaw, maar ook de de kracht van Android geweest wanneer het op marktaandeel en featuresets aankwam. De snelheid waarmee (nieuwe) features op toestellen kwamen was iets wat iOS simpelweg niet bij kon benen. Je kreeg weliswaar een wildgroei van ROMS, bloatware en slecht updatebeleid, maar hierdoor is Android wél gegroeid tot wat het is op de dag van vandaag.

Daarnaast had je tot aan Windows8 ook geen automatische major version updates, naar mijn weten deed alleen Apple dit. In dat opzicht doet Android (en fabrikanten/providers) het niet veel anders.. Criticals/security patches kunnen ze al enige tijd (ongeacht schil) doordrukken.

[Reactie gewijzigd door quintox op 23 juli 2024 01:52]

[gjmi]

Niemand met verstand van zaken heeft ooit gezegt dat software van Apple niet vatbaar is voor virussen, ook Apple zelf niet. Want dat is onzin.
De kans is veel kleiner omdat
- Unix-afgeleiden (zoals macOS) minder vatbaar zijn/waren dan Windows varianten.
- de userbase vele malen kleiner is.

Dus je moet meer moeite doen om minder computers te kunnen infecteren. Het is dan veel interessanter om een virus voor Windows maken.

En de opmerking dat ze dat lui heeft gemaakt is ook maar uit de lucht gegrepen.
Betekend dat Microsoft dan nog luier is?

Of je snel een bugfix kunt uitrollen is afhankelijk van de bug, sommige zijn makkelijk op re lossen, andere niet. Ook Windows heeft bigs gehad die niet binnen een paar maanden opgelost waren.
En als Windows zoveel bugs heeft die binnen een paar dagen op te lossen zijn, waarom hebben ze die dan überhaupt niet meteen gevonden. Kan het zijn dat Apple beter zijn best doet, en daarom alleen moeilijke te vinden/te repareren bugs overblijven?


Ik kan ook software maken met veel bugs die ik dan binnen een dag oplos en dan zeggen: kijk eens hoe goed ik ben in oplossen van bugs! Of ik maak meteen zo goed mogelijke software, waar mogelijk een paar bugs in zitten die blijkbaar niet zo makkelijk te vinden zijn...
Wat vind je dat beter?

[quintox]

Dat snap ik, en wellicht iedere Tweaker ook wel, maar dat is wel de redenatie/opvatting onder de leken. Windows staat voor virussen, Mac is virus vrij ( hoe belachelijk dit ook is ). Ik haalde ook al aan dat dat onzin is dus je hele betoog/technische uitleg was niet nodig geweest

Anyways, wie meer of minder bugs in de code heeft zitten maakt even niet uit, het heeft met de ernst van en de mentaliteit te maken. Waar elke andere fabrikant zijn fout erkent, producten terughaalt, zelf het lek publiceert of snel met een fix komt, is Apple van een ander kaliber: Ze ontkennen dat er een probleem is, vegen het onder het tapijt, reageren niet of komen extreem laat met een fix ( zowel in hun software als hardware! )

Bij iPhones flikken ze dit ook. Ze ontkennen dat er een probleem is ( o.a. Bendgate ), passen ondertussen het productieproces na maanden aan en vervolgens worden de early adopters weggeschreven als een "handjevol" zeikende mensen die overdrijven.

"Apple finally acknowledges iPhone ‘Touch Disease’ problem by denying responsibility"
https://thenextweb.com/ap...y-denying-responsibility/

"Apple denies its acknowledgement that iPad Pros are prone to bending, says they're perfect"
https://www.techspot.com/...prone-bending-theyre.html

Nee, ik zat inderdaad verkeerd. Ze zijn niet lui, dit is company policy.

[Reactie gewijzigd door quintox op 23 juli 2024 01:52]

[DeFeCt]

Wat betreft dat "ook Apple zelf niet"... https://www.youtube.com/watch?v=eF7habaTvAY

[gjmi]

Dit is gewoon een stukje slimme marketing.
Ook in dat filmpje zegt Apple niet dat Apple geen virussen heeft.

Ze zeggen alleen dat er 114.000 bekende virussen voor PC zijn.
Voor PC’s niet voor de Mac.

Ze zeggen dus alleen dat de Mac niet die 114.000 bekende virussen heeft.

Als ik me goed herinner waren er op dat moment een aantal dat je op 1 hand kon tellen, en die konden zich niet via internet verspreiden

[Verwijderd]

De vatbaarheid voor malware van een OS heeft natuurlijk niets te maken met de hoeveelheid gebruikers he? Alleen de kans dat iemand die malware gaat maken is kleiner.

[gjmi]

Je wilt dat een virus zoveel mogelijk gebruikers bereikt. Dus als een OS weinig gebruikers heeft, is het niet interessant om een virus te maken.

De vatbaarheid staat daar inderdaad los van

[Reactie gewijzigd door gjmi op 23 juli 2024 01:52]

[Werelds]

Apple is ook traag met dit soort dingen, vergeleken met hun concurrenten.

Zij doen niet of nauwelijks aan hotfixes. Het moet al bijzonder ernstig zijn willen ze dit soort fixes niet pas vrijgeven met hun volgende point release van macOS of iOS (dus 2-3 maanden na de laatste release). Het heeft niet zo zeer met complexiteit te maken, dat is gewoon hun beleid.

[z1rconium]

Oh ?

1, 2

[Niet Henk]

Eh... Dat zijn wel heel ander soort lekken.

1 is een lek in de device guard, wat van toepassing is op Windows 10 S en zeer weinig gebruikers kent, en fysieke toegang tot het systeem vereist. Dan kan je met die fysieke toegang enkel de extra laag beveiliging die Windows 10 S heeft t.o.v. normale Windows omzeilen. In de Windows RT tijd heb ik nog dankbaar gebruik gemaakt van een dergelijk lek om zelf applicaties op mijn Surface RT te kunnen draaien buiten de store.

2 is een lek dat het uitlezen van geheugen toestaat zonder hier rechten toe te hebben, maar dan moet je wel eerst code kunnen uitvoeren op de machine. Je kan dus enkel als je reeds instaat bent om code uit te voeren op de machine, iets zeggen over wat er gaande is op die machine. Niet goed, het kan o.a. door malware gebruikt worden om wachtwoorden uit te lezen, maar dan moet je wel eerst niet-gedetecteerde malware op je PC hebben die code kan uitvoeren. En dan ben je al ver van huis.

Dit huidige lek in MacOS is een vrij ernstige, het maakt het aanpassen van bestanden mogelijk zonder dat OS/Antivirus daar weet van heeft en zonder dat je er rechten toe hebt. Dat zorgt dat een virus makkelijk detectie kan omzeilen, en kan worden gebruikt voor allerlei nare toepassingen: nauwelijks detecteerbare ransomware bijvoorbeeld, die tevens bij bestanden kan waar je stricte rechten op gezet hebt.

[z1rconium]

Als je het vergelijkt met Microsoft, waar ze natuurlijk een rijke historie hebben van verschillende breaches/kwetsbaarheden zijn ze wél in staat om op korte termijn een hotfix uit te rollen.

Daar ging het om.

[Niet Henk]

Oh, sorry, dit moest een reactie op de reactie van z1rconium zijn.

[quintox]

In die berichten staat duidelijk dat Microsoft er bovenop zat en aangaf bezig te zijn met een patch. In de 2e post hadden ze zelfs al een patch uitgebracht, maar deze had niet alles gefixed.

De ernst van de kwetsbaarheid speelt daarbij ook een rol lijkt me, gezien de 1e "niet bijzonder ernstig is" aldus de onderzoeker. Overigens niet geheel vergelijkbaar als je een tienvoud van kwetsbaarheden moet oplossen in tegenstelling tot Apple. Apple heeft er véél minder, maar als ze er een hebben is deze meestal vrij ernstig en duurt het een eeuwigheid voordat ze het oplossen. Dan is MacOS ook nog eens een gesloten systeem met een beperkt aantal hardware/driver configuraties.. zou het e.e.a. alleen maar makkelijker moeten maken.

[quintox]

Kleine bias, wellicht.. ik heb inderdaad geen hoge pet op van het beleid dat Apple voert. Ik haal Microsoft aan omdat het vrijwel de enige (desktop) OS concurrent is, maar ik had net zo goed Google Android erbij kunnen halen en dezelfde vergelijkingen kunnen maken.

Liever dat ze huilen dan het negeren of zelfs ontkennen... het is erg zat dat "Apple gerelateerd issue maar genoeg traction krijgt in de media dan fixen ze het bijzonder snel." normaal is en blijkbaar geaccepteerd wordt.

"Unfortunately, the researchers said that most of the latest bugs were in Apple’s WebKit codebase for somewhere between six months and a year before being addressed, though they (and their predecessors) might have survived longer if Google hadn’t reported them."
https://venturebeat.com/2...fari-security-advisories/

[z1rconium]

Tja de vraag is hoe hoog de nood nu eigenlijk is bij dit issue ?

Er staat severity high, maar in de PoC lijkt het hier te gaan om FAT filesystems, dat is niet standaard op MacOs. Images kunnen uiteraard wel gemaakt worden met een FAT filesysteem.

Hoe word je dan gehacked ?

Iemand stuurt je een img/dmg of download hem of een kwaadwillende regelt het via een USB stick oid en dan moet je 'm nog mounten om hem te kunnen exploiten. Het vereist nogal wat actie.

Don't get me wrong, alle bedrijven die laken om actie te nemen word ik niet vrolijk van, Google zelf net zo. Zeker als ze op de hoogte zijn.

[quintox]

Nouja, de infiltratie van Stuxnet binnen Iraanse nucleare installaties verliep ook via USB drives

[zanza006]

Bij Microsoft was er eens een bug in server 2003r2, ik denk met active directory of smb. Deze is nooit opgelost geweest omdat het te ingrijpend was en het EOL bijna inzicht was.

[quintox]

Lijkt me niet dat MacOS EOL in zicht is Jouw voorbeeld was dus eenvoudig te "patchen" door simpelweg te updaten naar een nieuwe versie.

[Shark.Bait]

Een server eenvouding updaten is nooit simpel.

[quintox]

Ik zeg niet dat het simpel is, maar het product loopt tegen EOL aan dus het is geen excuus om het niet te doen. Ik bedoel.. kijk naar Windows 7, mainstream support is in 2015 gestopt, maar EOL is pas in 2020. Als je dan nog steeds niet geupdate hebt? Dan kun je toch niet eisen dat ze nog patches moeten uitrollen?

[Firecrash]

Ik vind het altijd moeilijk om dit soort artikelen te snappen vanuit zo'n kort stukje tekst hoe erg moet je je Mac hiervoor openstellen voor vreemde voordat dit werkt?

[iAR]

Je krijgt -1, maar ik begrijp het ook niet goed.
Vaak zijn er ook beveiligingskwesties die ernstig klinken maar vervolgens moet je wel fysiek toegang hebben tot het device, dan is het risico al een stuk kleiner.

[GertMenkel]

Voordat dit werkt moet je een programma van een onbekende bron draaien. Dus zolang je alleen applicaties uit de app store haalt (ervan uitgaande dat Apple daadwerkelijk kwaadwillende software pakt als deze wordt geupload naar de app store) zul je hier weinig last van hebben.

Het is echter een exploit die in een keten van exploits meer narigheid kan veroorzaken. Zo kan vanuit een andere Safari-exploit deze exploit weer worden gebruikt om een virus permanent in het systeem te nestelen.

[Cergorach]

Well... Er is een linkje in het artikel die precies uitlegt hoe het werkt, maar erg technisch van aard. Ik vermoed dat als je op basis van het Tweakers.net artikel geen goede gok kan maken van de impact, het technische artikel ook niet gaat helpen.

Vergeet niet dat niet direct een gebruikte aanval is, zie het als een gat in de muur, maar men weet nog niet precies welk stuk gereedschap je ervoor gebruikt om het te maken. Er is dus nog geen malware/trojan die er in het wild gebruik van maakt (althans nog niet ontdekt).

[Keypunchie]

Ben het helemaal met je eens en dan weet ik nog best wel wat van dit soort zaken.

Zoals ik het begrijp: als er geheugen naar disk wordt geschreven, dan is het mogelijk om dat geschreven geheugen te manipuleren zonder cow te triggeren, en wordt mogelijk later de gemanipuleerde file weer terug in geheugen geladen en uitgevoerd (whatever it is).

Dus in theorie betekent dat, dat je onder de rechten van de user die de geheugeninstructie van disk haalt, de instructie kan worden uitgevoerd.

Maar ik begrijp het maar half, moet ik eerlijk toegeven.

Al met al is dat een serieus beveiligingsgat, maar niet eentje om nu als mac-gebruiker van in paniek te raken. Het grootste risico is niet dat je gehackt wordt via het internet, maar dit is voor systeembeheerders die lokale gebruikers willen afschermen van bepaalde zaken wel iets om rekening mee te houden.

[Reactie gewijzigd door Keypunchie op 23 juli 2024 01:52]

[t link]

tja 3 maanden zou meer dan genoeg moeten zijn om een beveiligingslek op te lossen...

[locke960]

Zou je denken, maar dat hangt toch echt van de complexiteit van het probleem af. Spectre en Meltdown hebben veel langer geduurd, en je kunt zelfs zeggen dat ze nog steeds niet echt opgelost zijn.

Ook heeft Google bij Spectre en Meltdown veel langer dan 90 dagen gewacht voor ze het probleem geopenbaard hebben. Blijkbaar is het dus mogelijk om uitstel te krijgen, als het probleem maar ernstig genoeg is en Google er van overtuigt is dat je er echt aan werkt.

[t link]

spectre en meltdown zijn hardware exploits dat is van een heel ander kaliber dan een OS exploit. de hardware exploits zijn deels te patchen via software in dat geval gelukkig.

[Cergorach]

tja 3 maanden zou meer dan genoeg moeten zijn om een beveiligingslek op te lossen...

Dat is natuurlijk kort door de bocht, is het een beveiligingsprobleem wat met een paar simpele wijzigingen op te lossen is of moet het hele OS van de groundup opnieuw? Waarschijnlijk zal het er ergens tussenin zitten, maar de vraag is waar het dichter bij zit...

@t link Ze hebben een team dat werkt aan het OS, dat breid je niet even adhoc uit. Das het nadeel van closed source software, je heb niet meteen een berg goed personeel beschikbaar dat even aan je OS gaat sleutelen. Het zou wat anders zijn geweest als het in een applicatie was van Apple wat draaide op het OS, er zijn een hoop externe MacOS applicatie ontwikkelaars. Maar zelfs dan haal je niet even een team binnen in een paar weken.

[Reactie gewijzigd door Cergorach op 23 juli 2024 01:52]

[t link]

Zelfs al was het een beveiligingsprobleem waarbij ze het halve OS moeten herschrijven, ze hebben de mankracht en het geld dat te doen. dirtycow was vergelijkbaar en door grotendeels vrijwillgers opgelost in ongeveer een jaar.

[tom.cx]

Dat is lekker eenvoudig om te zeggen. Je weet toch niet hoe complex dit lek is?

[t link]

niet heel complex. het gaat hier simpelweg erom dat er niet word gechecked of de juiste privileges aanwezig zijn, niet meer niet minder.

[slijkie]

Met het budget en de interne & externe mankracht van Apple zou dit gewoon ‘inprincipe’ moeten lukken.

[zonoskar]

Heeft niks met budget of mankracht te maken. Ik werk in een bedrijf waar 800 software ontwikkelaars werken en het duurt zeker 3 tot 6 maanden voordat een enkele regelcode wijzigen bij de klant is. Het kan sneller, maar alleen als de klant er echt, echt, ECHT om staat te springen. Dan kan het in 2 maanden.

[GnrlSchnavy]

Ik hoop en ga er van uit dat dit een overdrijving is. Verder neem ik aan dat apple echt, echt, ECHT staat te springen om dit op te lossen. Dus dan kan het, in jouw woorden, in 2 maanden

[zonoskar]

Helaas het is echt. Een patch maken kan in 2 weken. Maar dan lever je naar een service pack. Dat service pack wordt vervolgens alpha, beta en dan pas customer. Elke stap duurt een maand qua testing. Dus 2 weken + 2 a 2.5 maanden testen in alpha/beta state. En dan heb je een makkelijke patch. Ik kan me voorstellen dat een security patch niet makkelijk is en dat het ontwikkelen daarvan geen 2 weken kost, maar (veel) meer. Het zal niet simpel even een NULL pointer check zijn die toegevoegd moet worden.

[-Dream]

Project Zero heeft een policy van 90 dagen tot publicatie om developers te pushen de bugs snel te fixen. Als je zo'n policy hebt moet je je daar ook aan houden, anders heeft hij weinig zin.

[JelleDJs]

Daar houden ze zich toch ook aan?

[0vestel0]

COW in XNU. XNU is een hybride van Mach3 en BSD welke ook onderdeel van IOS is.
Is IOS ook vatbaar? En zit dit alleen in XNU of ook in de opensources waarop de XNU is gebaseerd?

[Verwijderd]

Zoals ik het lees ben je alleen kwetsbaar als je software installeert die misbruik maakt van dit lek. De les blijft dus wat die al jaren is: installeer alleen software uit betrouwbare bron.

[jvelite]

Dergelijke exploits kunnen ook via andere methoden binnenkomen. Denk aan browser exploits, etc.

[Verwijderd]

“Dergelijke” misschien wel maar “deze” niet. Althans niet zoals ik de oorspronkelijke Google pagina lees.

[quintox]

EDIT:
Deze post kwam als losse reactie i.p.v. genest in een draadje na een (ongelukkige) pagina refresh

[Reactie gewijzigd door quintox op 23 juli 2024 01:52]

[Thystan]

Ik weet liever wanneer ik mijn systemen beter in de gaten moet houden als een lek nog moet worden gedicht.

[drakiesoft]

Wat ik mij altijd afvraag wat het belang is van google bij het doen van dit soort onderzoeken. .