Apple stelt fix voor FaceTime-bug in groepsbellen uit tot volgende week

Apple heeft het beveiligingsprobleem in groepsbellen via FaceTime verholpen, maar brengt de software-update hiervoor niet deze week uit, zoals aanvankelijk gemeld, maar volgende week. Het bedrijf biedt verontschuldigingen aan voor het probleem.

De fix is doorgevoerd voor de servers, meldt Apple aan MacRumors, en volgende week schakelt een software-update groepsbellen via FaceTime weer in. Het bedrijf verontschuldigt zich bij klanten en meldt het geduld voor de periode van verhelpen te waarderen.

Dinsdag besloot Apple de functie voor groepsbellen van FaceTime uit te schakelen, nadat een beveiligingsprobleem aan het licht kwam. Door tijdens het laten overgaan van een privégesprek simpelweg een groepsgesprek te maken door het eigen telefoonnummer toe te voegen, kon een kwaadwillende audio afluisteren en video zien, zonder dat de ontvanger het gesprek hoeft op te nemen of te weigeren.

De bug werd gevonden door een veertienjarige jongen en Apple negeerde de meldingen van zijn moeder. Apple bedankt de familie voor het aandragen van de kwetsbaarheid. Het bedrijf belooft zijn procedures voor het ontvangen en escaleren van beveiligingsmeldingen te verbeteren 'om te zorgen dat deze de juiste personen zo snel mogelijk bereiken'.

Still uit de video van KOLD News 13

Door Olaf van Miltenburg

Nieuwscoördinator

01-02-2019 • 15:56

45 Linkedin

Reacties (45)

45
33
14
0
0
9
Wijzig sortering
Het bedrijf belooft zijn procedures voor het ontvangen en escaleren van beveiligingsmeldingen te verbeteren 'om te zorgen dat deze de juiste personen zo snel mogelijk bereiken'.
Volgens mij is dat wel eens vaker beloofd, maar is het dus niet gelukt waardoor ze er nu weer mee bezig moeten :)
Mooi dat ze er de tijd voor nemen. Tuurlijk is t allemaal “damage control”, maar vaak pakt Apple dit soort dingen dan wel weer goed op en worden procedures ook daadwerkelijk opnieuw bekeken bij ze
Gezien de lijst van CVEs moeten ze nog best leren: https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=apple
(Microsoft heeft er iets meer en Linux scoort niet veel beter). Security is moeilijk en staat haaks op wat mensen willen (eenvoudig en niet omslachtig, snel etc.). Ga er maar vanuit dat er nog vele security bugs volgen.
Leuk dat je kijkt naar aantallen, maar daarmee weten we natuurlijk niets over hoe ernstig ze zijn of hoe lang het gemiddeld duurt om ze op te lossen. Toch ook belangrijke factoren imho. Want wat heb je liever? 100 kleine kwetsbaarheden die telkens binnen 1 dag zijn opgelost, of 1 zeer ernstige die maanden blijft openstaan?
Ik reageerde voornamelijk op de "worden procedures ook daadwerkelijk opnieuw bekeken bij ze". Ik heb alleen ooit (in een heel grijs verleden) het security offensief van MS meegekregen waarbij alle ontwikkelaars verplicht een week op security training moesten. Ik zie echter nergens dat het beter is geworden (niet bij MS en niet bij Apple). En een security bug is een security bug. Doel van leren is dat je geen fouten meer maakt. Niet dat je ze sneller verhelpt (althans, dat zou wel de insteek moeten zijn). CVE zijn alleen security zaken en of het nu een root exploit is of de foto's van je ex lekken naar het internet maakt niet uit: er gebeurde iets zonder dat jij er toestemming voor gaf. Dat is een security lek en dat mag niet. Dus de lijst van CVEs lijkt me een heel zinnig criterium om te toetsen of een organisatie leert van haar fouten.
Sowieso is zoiets twijfelachtig als criterium. Ik zou bijna willen stellen dat meer beter is, omdat dat een teken van transparantie is; maar goed, daar zit ook een keerzijde aan natuurlijk.
Cve's hebben niets met transparantie van doen. Het tegenovergestelde zelfs: bugs die je zelf vind en oplost maak je geen cve voor aan.
Kijk, dus eigenlijk ben je het met mij eens. Want als er dus heel veel bugs gefixt zijn, maar die hebben ze 'interne bug' behandeld, dan zegt het aantal Cve's dus niks als criterium.
Nee, je zou het zelfs kunnen kantelen: marktaandeel Apple is lager en net zoveel cve's: dus buggier. Maar ik blijf erbij dat cve s een graadmeter zijn voor hoe goed je je zaken op orde hebt. Analyse als de oplostijd kun je er ook uithalen. Als die terugloopt kun je nog iets zeggen over het lerend vermogen van een organisatie.
Van de lijst die je geeft zijn er van de eerste 10 sowieso al 7 opgelost in recente releases. Men neemt in deze lijst dus ook history mee van de afgelopen 2 decennia. Beetje gekleurd beeld dan.
Dat is de essentie: leert een organsatie? M.a.w. worden het aantal fouten per tijdseenheid minder. Het resultaat lijkt bedroevend.
Deze cve kwetsbaarheden komen vaak uit software van derden. Open source libs die gebruikt zijn (openSSL bijvoorbeeld). Daar kun je als organisatie dan ook niet zoveel van lere anders dan dat je goed omgaat met de reports.
De assigning authority is per onderdeel gegeven. Voor OpenSSL is dit niet Apple. De data is wel bruikbaar, maar je kunt het niet 1-op-1 vinden door te zoeken naar je meest/minst favoriete leverancier.
Kennelijk wel, want je eerste hit geeft een vuln terug in ZenMate 1.5.4 van ZenGuard. Daar kan Apple niets aan doen anders dan ZenGuard op zijn donder geven.

Nog eentje verder is een kwetsbaarheid in libraw waar ook ubuntu vatbaar voor is (14,16 en 18 LTS versies en afgeleiden).

Dus nee, niet alles is direct gelieerd aan.
Apple is daar zeker in gegroeid de afgelopen jaren.

Al vinden veel mensen deze dingen vanzelfsprekend. Dat zijn ze namelijk niet.
Er zijn veel fabriekanten, van elektronica waaronder IOT. Die dit niet doen.
Ik zie niet helemaal in waarom het mooi is dat ze de tijd nemen. Is dat niet een indicatie dat er fundamenteel iets mis is?
Hoeft niet. Ze kunnen ook extra tijd nemen om de fix goed te testen op potentiele andere bugs of onvoorziene bijwerkingen, waardoor andere applicaties wellicht problemen zouden kunnen krijgen.

Beter dat dan er een rush-job van maken en dan blijkt dat er weer andere problemen optreden elders. Het risico is nu immers via een workaround al ingeperkt, dus de nood is ook iets minder hoog om er een rush-job van te maken.
Dat het verstandig is dat ze de tijd nemen staat buiten kijf, mij ging het om de kwalificatie "mooi" die ik niet begrijp.
Helaas is worden er genoeg "fixes" uitgebracht om het maar probleem maar snel te verhelpen, zonder een goede of uitgebreide test mee uit te voeren met meerdere problemen als gevolg. Daarom was mijn woordkeuze "mooi" omdat ik blij ben/het goed vind dat ze er dan langer mee bezig zijn, om vervolgens ook een daadwerkelijk goede fix uit te brengen.
Implicerende dat ze dat ook aan het doen zijn.

Dat kan je nooit weten tenzij jij een van de devs bent.

[Reactie gewijzigd door PlowKing op 1 februari 2019 16:31]

100% niet, maar heb in het verleden voor Apple gewerkt en daar werden in die tijd zulke dingen altijd wel goed opgepakt en herbeken. Of dat het ook daadwerkelijk veranderd is een 2e..
De reden dat ze het uitstellen heeft ook te maken met de exploits die zijn uitgekomen voor de laatste ios versies.

Ze willen dit ook goed patchen, ivm jailbreaks
Dat heeft niets met het tegenwerken van Jailbreaks te maken. Jailbreaks zijn mogelijk omdat er (beveiligings-)fouten in de software zit. Deze fouten kun je "misbruiken" om een Jailbreak toe te passen, want het is eigenlijk gewoon "hacken", maar het kan dus ook door kwaadwillende en andere instanties worden uitgebuit; en dat is dan weer niet te bedoeling. Je kunt beargumenteren dat je meer vrijheden wilt binnen iOS d.m.v een Jailbreak, maar dat wil je liefst ook zonder potentieel onveilig besturingssysteem.
De Security Exploit binnen FaceTime is al uitgeschakeld door deze functie tijdelijk te blokkeren. Je loopt dus geen gevaar nu.

Dat de update later komt door de jailbreak community zodat die daadwerkelijke Security Exploit opgelost kan worden is alleen maar een (goeie) aanname van @Gladiator5
Daar is een oplossing voor. Namelijk het jailbreaken toe te staan. Dus zonder exploits.
Bijvoorbeeld om goed te testen? Alles direct uitrollen is niet altijd een goed idee. Volgens mij zijn er vrij recent nog wel software updates (van verschillende software) geweest die problemen gaven.
Tsja. Bij concurrenten kun je een jaar na aankoop al naar enige vorm van support fluiten, dus dan is een paar dagen best vlot.
Nadat ze echter een melding van een vrouw, inclusief video een tijd genegeerd hadden.
De vrouw vroeg eerst om geld voordat ze het filmpje stuurde he. Pas toen anderen er al mee kwamen stuurde ze pas een video :+
Heb je daar een bron van?
U vraagt, wij draaien.
The emails emphasized the bug’s significance, calling it “a huge issue” that Thompson had personally verified. Without revealing the necessary steps to exploit the bug in that email — she had questions regarding Apple’s bug bounty program and wondered if her son might receive a monetary reward for discovering it — Thompson asked Apple to get in touch immediately so that a fix could be quickly developed.
https://www.google.nl/amp...-bug-warned-eavesdropping

[Reactie gewijzigd door Thomas18GT op 2 februari 2019 10:46]

Nee, elk fatsoenlijk bedrijf legt dit bij als de sodemieter bij een RED-team neer en laat dat team de severity van deze finding beoordelen.Gelet op het gemak, complexiteit en impact van deze bug kan het niet anders dan dat hier een hoge CVSS score uitrolt. Op basis van deze score kan (in dit geval) Apple hun eigen procedures volgen...

Op dit item kan niet meer gereageerd worden.

Tweakers maakt gebruik van cookies

Tweakers plaatst functionele en analytische cookies voor het functioneren van de website en het verbeteren van de website-ervaring. Deze cookies zijn noodzakelijk. Om op Tweakers relevantere advertenties te tonen en om ingesloten content van derden te tonen (bijvoorbeeld video's), vragen we je toestemming. Via ingesloten content kunnen derde partijen diensten leveren en verbeteren, bezoekersstatistieken bijhouden, gepersonaliseerde content tonen, gerichte advertenties tonen en gebruikersprofielen opbouwen. Hiervoor worden apparaatgegevens, IP-adres, geolocatie en surfgedrag vastgelegd.

Meer informatie vind je in ons cookiebeleid.

Sluiten

Toestemming beheren

Hieronder kun je per doeleinde of partij toestemming geven of intrekken. Meer informatie vind je in ons cookiebeleid.

Functioneel en analytisch

Deze cookies zijn noodzakelijk voor het functioneren van de website en het verbeteren van de website-ervaring. Klik op het informatie-icoon voor meer informatie. Meer details

janee

    Relevantere advertenties

    Dit beperkt het aantal keer dat dezelfde advertentie getoond wordt (frequency capping) en maakt het mogelijk om binnen Tweakers contextuele advertenties te tonen op basis van pagina's die je hebt bezocht. Meer details

    Tweakers genereert een willekeurige unieke code als identifier. Deze data wordt niet gedeeld met adverteerders of andere derde partijen en je kunt niet buiten Tweakers gevolgd worden. Indien je bent ingelogd, wordt deze identifier gekoppeld aan je account. Indien je niet bent ingelogd, wordt deze identifier gekoppeld aan je sessie die maximaal 4 maanden actief blijft. Je kunt deze toestemming te allen tijde intrekken.

    Ingesloten content van derden

    Deze cookies kunnen door derde partijen geplaatst worden via ingesloten content. Klik op het informatie-icoon voor meer informatie over de verwerkingsdoeleinden. Meer details

    janee