Zoom lost kritiek beveiligingslek in updatetool van macOS-app op

Zoom heeft een kritieke kwetsbaarheid in zijn updatetool voor macOS opgelost. De kwetsbaarheid maakte het mogelijk om rootrechten te verkrijgen op een systeem. Onderzoeker Patrick Wardle ontdekte de kwetsbaarheid en presenteerde deze op DEF CON.

Zoom heeft de kwetsbaarheid opgelost in versie 5.11.5, zo blijkt uit een securitybulletin van het bedrijf. De kwetsbaarheid werd aangeduid als CVE-2022-28756 en had een cvss-ernstigheidsscore van 8,8 uit 10. Via de kwetsbaarheid was het mogelijk om als lokale gebruiker toegang te krijgen tot de rootdirectory van een systeem. Het lek zat alleen in de macOS-versie van Zoom.

Beveiligingsonderzoeker Patrick Wardle presenteerde de kwetsbaarheid tijdens hackerevent DEF CON in Las Vegas. Wardle toonde onder meer twee kwetsbaarheden in de Zoom-updater voor macOS, die de onderzoeker eind vorig jaar meldde bij Zoom en inmiddels zijn opgelost. De beveiligingsonderzoeker presenteerde tijdens DEF CON echter een derde kwetsbaarheid, die nog niet gepatcht was.

De onderzoeker ontdekte dat er een moment tijdens het updateproces was waarop een Zoom-update al was geverifieerd, maar nog niet werd geïnstalleerd. Tijdens dat moment was het mogelijk om eigen code te injecteren. Bovendien wist de onderzoeker de updatetool van Zoom zo te misleiden dat het de huidige versie van de app opnieuw installeert, zodat het updateproces op ieder moment gestart kon worden. Gebruikers konden die kwetsbaarheden inzetten om roottoegang tot een systeem te verkrijgen. Deze kwetsbaarheid is nu dus ook opgelost door Zoom.

Reacties (38)

[fapkonijntje]

Dit klinkt als een probleem van Zoom, maar als een updater root toegang kan krijgen is er toch op het OS niveau iets goed fout?

[P1nGu1n]

Nee het probleem zat in Zoom, de details kan je vinden in de slides van de presentatie op Defcon: https://speakerdeck.com/patrickwardle/youre-muted-rooted

TL;DR:

• Wanneer je zoom installeert of de-installeert, zijn root rechten nodig
• Updates kunnen zonder root-rechten worden geïnstalleerd, want de daemon draait als root
• Het pad waar een Zoom update wordt weggeschreven is schrijfbaar zonder root-rechten
• Van updates wordt gecontroleerd of deze zijn uitgegeven (ondertekend) door Zoom, dus willekeurige binaries hier plaatsen is niet mogelijk
• De onderzoekers plaatsten een oude en onveilige Zoom update in het auto-update pad, zodat de auto-updater deze installeert, en ze hierin vervolgens kwetsbaarheden kunnen misbruiken
• Deze kwetsbare versie bevat een bug in package validatie, waardoor malafide binaries kunnen worden uitgevoerd die niet door Zoom gesigneerd zijn
• Door met de kwetsbare versie nogmaals een "auto-update" uit te voeren, wordt de malafiede package gestart en zijn rootrechten verkregen
• Zoom heeft het probleem gepatcht door rechten op het updatepad te beperken, zodat je hier geen schrijfrechten meer hebt

[Reactie gewijzigd door P1nGu1n op 24 juli 2024 08:54]

[Bor]

Oprechte vraag; Waarom heeft een app als Zoom root rechten nodig? Een daemon onder root privileges laten draaien is sowieso geen best practice.

[P1nGu1n]

Oprechte vraag; Waarom heeft een app als Zoom root rechten nodig?

Om een applicatie voor alle users te installeren zijn admin rechten nodig (dat is niet hetzelfde als root).

Als je zoom alleen voor de huidige user wil installeren, is dat ook niet nodig:
https://support.zoom.us/h...fe-45af-8d56-e8239f2a86cf

[Reactie gewijzigd door P1nGu1n op 24 juli 2024 08:54]

[fapkonijntje]

Dus als ik Zoom installeer als single user onder macOS is deze vulnerability voor mij niet van toepassing?

In dat geval vind ik dat dat noemen een aanvulling zou zijn voor dit artikel.

[Bor]

Zo te zien wel. De update daemon draait ook dan.

[:murb:]

Volgens mij wil Zoom graag op root niveau dingen regelen zodat gebruikers minder "last" hebben van beveiligingen van macOS. Standaard heeft een app geen toegang tot je camera, of b.v. het besturen en opnemen van je desktop (twee losse autorisaties), daar moet je dan weer handmatig toegang toe geven etc en soms de applicatie voor de eerste keer een keer voor herstarten. Juist om de root-toegang zelf altijd Zoom als desktop app gemeden, want verder is het echt nergens voor nodig, een vergelijkbare dienst zoals Google Meet werkt gewoon goed vanuit een browser.

Het is voor een installer op macOS mogelijk om root rechten te vragen (soort sudo), maar misschien moet Apple de applicaties meer in een keurslijf drukken en eisen dat een applicatie die root rechten wil dit veel specifieker aanvragen.

[Reactie gewijzigd door :murb: op 24 juli 2024 08:54]

[NanoSector]

Iedereen lijkt deze vraag te hebben zonder concreet antwoord, het lijkt erop dat de app zelf geen features heeft waar root voor nodig is, maar het alleen root gebruikt voor het updaten van zichzelf ongeacht welke gebruiker is ingelogd (want niet iedere gebruiker hoeft in de admin groep te zitten aka schrijfrechten te hebben tot de /Applications map).

Dit is een van de slechtste implementaties van een auto-updater die ik ooit op macOS gezien heb; handel het dan op zijn minst af met een user launch agent/daemon...

[fapkonijntje]

Ja en ik vind dat dus erg kort door de bocht. Ik snap je reactie verder ook niet, je herhaalt gewoon het nieuwsbericht maar gaat niet in of het een OS of Zoom probleem is. Als Zoom gewoon vieze dingen doet op macOS, dan is het een Zoom probleem, maar als apps nou eenmaal iets als root moeten doen op een mac omdat ze anders niet werken, is het een OS probleem. Ik ben op benieuwd naar de oorzaak en of het een zwakte in de applicatie of het OS is.

Dan kun je opnieuw herhalen hoe het gat te misbruiken is, maar dat beantwoord de vraag niet.

Wanneer je zoom installeert of de-installeert, zijn root rechten nodig

Daar gaat 't al fout wat mij betreft. Waar zijn die voor nodig en is dat iets dat vanuit het OS komt of vanuit Zoom?

[P1nGu1n]

Ik snap je reactie verder ook niet, je herhaalt gewoon het nieuwsbericht maar gaat niet in of het een OS of Zoom probleem is.
[...]
Dan kun je opnieuw herhalen hoe het gat te misbruiken is, maar dat beantwoord de vraag niet.

offtopic:
Een erg vervelende toon van je tegen iemand die je probeert je helpen, maar goed, ik zal er toch maar op antwoorden... En duidelijker kan ik het niet voor je maken, dan kan je beter naar nu.nl gaan.

Het is een drieledig probleem in de Zoom applicatie:

1. Zoom had het auto-update pad world-readable gemaakt, waardoor iedereen erheen kan schrijven
2. Zoom staat downgrades toe in de auto-updater
3. Oude zoom versies bevatten kwetsbaarheden (een fout in package validatie)

[Reactie gewijzigd door P1nGu1n op 24 juli 2024 08:54]

[fapkonijntje]

Het is een drieledig probleem in de Zoom applicatie:

1. Zoom had het auto-update pad world-readable gemaakt, waardoor iedereen erheen kan schrijven
2. Zoom staat downgrades toe in de auto-updater
3. Oude zoom versies bevatten kwetsbaarheden

Nog steeds beantwoord dit de vraag dus niet hè. Je omschrijft hier gewoon wat we al weten en je valt weer in herhaling, dan wel met andere woorden, maar de inhoud is hetzelfde. Dat Zoom een iets in het auto-update pad niet goed doet, dat is bekend, maar wáárom Zoom dat doet en of dat door het OS moet of omdat Zoom iets raars doet weten we dus nog steeds niet. Ik kan mij namelijk best voorstellen dat auto-updaten ook moet kunnen zonder gelijk root rechten te geven aan de applicatie die auto-update doet.

Punt 2 en 3 zie ik niet als relevant. Downgraden en upgraden is hetzelfde trucje en punt 3 is een heel ander ouder en losstaand probleem.

Mijn vraag was dan ook, zit de oorzaak van het probleem (en dus de oorzaak van waarom Zoom deze rechten heeft) bij Zoom of macOS?

[Reactie gewijzigd door fapkonijntje op 24 juli 2024 08:54]

[aikebah]

De oorzaak van het probleem is het niet veilig omgaan met de toegekende root-rechten door de auto-installer (en dus Zoom). Root-rechten zijn nu eenmaal nodig bij het system-wide (en dus niet single-user) installeren van software pakketten.

[dieAndereGozer]

Hoe wil je iets installeren zonder root rechten?
Je kan alles wel in userspace houden maar daar zitten ook nadelen aan.

[fapkonijntje]

Hoe wil je iets installeren zonder root rechten?

Je beantwoord in je reactie je eigen vraag;

Je kan alles wel in userspace houden maar daar zitten ook nadelen aan.

Wat zijn die nadelen dan voor een applicatie als Zoom?

[dieAndereGozer]

Het is wel zo makkelijk een daemon te hebben voor zoom. Dan hoef je niet door hoepels te springen om zoom te autostarten of bepaalde functies aan te roepen van het systeem.
Ik weet ook niet hoe je bij macOS bepaalde system overwrites m.b.t. fullscreen en notifications, of microfoon en camera precies doet.

Verder, waarom niet een programma installeren op een plek waar het hoort? Maar ja, met externe installatie files werken voelt een beetje knudde, gewoon in de package manager rammen(als macos dat heeft) of gewoon de daemon het vanuit een root only folder dingen laten installeren.

[NanoSector]

Alle dingen die je noemt hebben geen root rechten nodig op macOS. Een applicatie kan zich bij macOS registreren als autostart en komt dan in je Login Items terecht; in uitzonderlijke gevallen kan je een launch agent of launch daemon installeren die start wanneer de user inlogt. De privacy opties die je noemt zijn allemaal beschikbaar voor rootless apps.

Het is ontzettend kwalijk dat Zoom een daemon installeert die altijd als root draait. Zelfs Apple's systeem services als WindowServer en zelfs userspace drivers draaien als een aparte, unprivileged, user waar mogelijk om zo de mogelijkheid voor een root privilege escalatie te verminderen. Dit is niet alleen een ding op macOS, maar ook op Linux en vziw zelfs Windows.

Ik zit niet in de security branch maar als ik dit zou moeten oplossen zou ik Zoom tijdens het starten naar updates laten zoeken en via tijdelijke privilege escalatie de update vervolgens installeren. Of nog beter; ervoor zorgen dat Zoom geen root permissie nodig heeft om geïnstalleerd te worden, zoals bijvoorbeeld Microsoft Teams, die is gewoon drag & drop op macOS.

macOS Ventura geeft je een melding wanneer een app een achtergrondproces (launch agent / launch daemon in launchd wereld) installeert; met dit soort praktijken juich ik dit heel erg toe.

Ook even uit je oude post, over userspace gesproken:

Je kan alles wel in userspace houden maar daar zitten ook nadelen aan.

Userspace is in simpele termen alles wat niet in de kernel draait, dus je haalt hier een begrip door elkaar. Wanneer een applicatie als Zoom een kernel extensie zou gaan installeren zouden bij mij in ieder geval alle alarmbellen af gaan. Zoom heeft niets te zoeken in de kernel; alles is beschikbaar via userspace APIs middels Apple's frameworks.

Het is wel zo makkelijk een daemon te hebben voor zoom.

Nee, een auto-update daemon is volledig overbodig. Frameworks als Sparkle bestaan die (in de meeste gevallen) zonder root rechten de applicatie kunnen vervangen. Een applicatie wordt in macOS in de /Applications map geïnstalleerd, en deze is standaard schrijfbaar door mensen in de `admin` groep, dus de administrator(s) van de Mac. LaunchServices pakt dan automatisch de applicatie mee in dingen als "Open with" en dergelijke. Dit beantwoordt ook meteen je vraag "hoe installeer je iets zonder root rechten".

Een daemon is een achtergrondproces; continu een proces actief hebben voor het draaien van updates is in geen enkele normale situatie nodig.

Maar ja, met externe installatie files werken voelt een beetje knudde, gewoon in de package manager rammen(als macos dat heeft)

De meeste installers op macOS zijn disk images die, wanneer je die opent, de applicatie bevatten om in je /Applications map te gooien. Soms met een plaatje en een shortcut erbij om dit duidelijk te maken. Applicaties die meer componenten moeten installeren worden wel eens als een .pkg geleverd die via Installer.app geopend worden; in dat geval vraagt Installer indien nodig tijdens de installatie voor extra rechten en heeft de applicatie dit zelf niet meer nodig.
De meeste applicaties die op deze manier worden geïnstalleerd downloaden een nieuw installatiebestand en hebben dan "even" root rechten nodig om te updaten. Zie bijvoorbeeld VMware Fusion.

gewoon de daemon het vanuit een root only folder dingen laten installeren.

Beetje de TLDR van mijn post: Ze moeten hetgeen wat root nodig heeft gewoon weghalen uit de app, dan kun je dit soort problemen ook niet krijgen.

[dieAndereGozer]

Ik weet dat ze geen root rechten nodig hebben, maar mijn applicatie files in een folder hebben waar alleen een root user bij kan, is wel zo handig. Dan weet ik tenminste dat er niet zomaar gerommeld kan worden met mijn applicaties met alle gevolgen van dien. Dat is het nadeel van dingen in userspace hebben staan.

De meeste installers op macOS zijn disk images die, wanneer je die opent, de applicatie bevatten om in je /Applications map te gooien.

Ugh wat een moeite, lijkt windows wel.

[NanoSector]

Dan weet ik tenminste dat er niet zomaar gerommeld kan worden met mijn applicaties met alle gevolgen van dien.

Daar heb je Gatekeeper en code signing voor; als je bundel een digitale signatuur heeft wordt die nagekeken door macOS wanneer de app opstart. Klopt dit niet meer dan wordt je app geblokkeerd. Heb je geen Root voor nodig.

Zelfs in kernelspace is dit een probleem en kan het zelfs veel groter uitpakken. Draai je iets in de kernel dan heeft het zelfs meer rechten dan root. Maar ik denk nogmaals niet dat jij kernelspace/userspace bedoelt; een map die alleen door root toegankelijk is bestaat nog steeds in userspace, maar heeft simpelweg andere permissies.

Als je het op zo’n manier wil oplossen kan je veel beter een aparte updater-user maken en daarmee uitvoeren. Dan kan je die gebruiker de eigenaar van de applicatie bundel maken en de groep waar de normale gebruikers in zitten kan dan lees/uitvoer rechten krijgen. Dan kan je de bundel wel aanpassen met die update user maar kan die user niks anders overnemen op je systeem.

Maar dat is nog steeds ontzettend omslachtig en Zoom heeft hier grotere problemen dan alleen waar ze hun update bestand plaatsen.

Edit:

Ugh wat een moeite, lijkt windows wel

Je hebt homebrew waarmee je GUI apps via pakketbeheer kan installeren.

[Reactie gewijzigd door NanoSector op 24 juli 2024 08:54]

[dieAndereGozer]

Daar heb je Gatekeeper en code signing voor; als je bundel een digitale signatuur heeft wordt die nagekeken door macOS wanneer de app opstart.

Een goede leugenaar zegt niet dat hij liegt.

Je hebt homebrew waarmee je GUI apps via pakketbeheer kan installeren.

Dus er is geen standaard oplossing? Pfft, wat een moeite, ik dacht dat het een betere gebruiksvriendelijkheid had, dat macos.

[Superstoned]

Een goede leugenaar zegt niet dat hij liegt.

Dus? Met een signature kun je niet klooien dus te kunt als derde partij hier niets mee. Het is een mooie oplossing die ook op Linux steeds populairder worst, zie flatpack enzo. Zelf blijf ik bij zypper maar het werkt allemaal wel aardig op Mac OS moet ik zeggen. Het is minder chaos dan op Windows. Second best? ;-)

[Keypunchie]

Op MacOS mag je buiten de appstore apps installeren.

Die kunnen alle rechten vragen die ze willen en als je als gebruiker die verleent, dan ben je het bokje.

Tenzij je naar de situatie zoals op iOS wil waar je alleen maar via de App Store kunt installeren, is er weinig aan te doen.

De meeste app-makers doen het puur uit gemakzucht of luiheid, maar daar kan een OS je niet tegen beschermen… dat kan immers ook niet raden waarvoor de root-rechten nodig zijn.

Dit is niet anders dan op Windows of Linux. De app vraagt rechten, de gebruiker verleent ze (bij installatie) en daarmee heb je een potentiële kwetsbaarheid.

[Reactie gewijzigd door Keypunchie op 24 juli 2024 08:54]

[Ferruginous Hwk]

Ja, het update-bestand wordt in de root 'home-folder' weggeschreven maar de kwetsbaarheid is er nog steeds.

Dit omdat het bestand (omdat het proces zelf ook root-rechten heeft) nog steeds hernoemd kan worden naar het certificaat-naam zij het een korte periode tussen het uitpakken en het uitvoeren van de Zoom-update.

Hoop dat het een keer de norm wordt dat applicaties geen updater daemon (met hoge rechten) hebben draaien. Want Google Chrome doet dit nagenoeg hetzelfde.

Blijft een trade-off tussen automatisch gepatchte software en dit soort beveiligingszwakheden.

[aikebah]

Dit omdat het bestand (omdat het proces zelf ook root-rechten heeft) nog steeds hernoemd kan worden naar het certificaat-naam zij het een korte periode tussen het uitpakken en het uitvoeren van de Zoom-update.

Nope...

wat je kunt (kon) doen (TOCTTOU) is de certificaat-gevalideerde file overschrijven met iets geheel anders (je eigen blob die whatever evils doet) voordat ie door de updater gebruikt wordt om de feitelijke update uit te voeren. De filenaam had er niets meer mee van doen na de eerdere al beschikbare patches.

[Koen Hendriks]

Bij de installatie wordt eenmalig om het wachtwoord van de user gevraagd voor deze rechten. Het probleem was dat de updater op de achtergrond met deze verhoogde rechten bleef draaien.

Zie ook nieuws: Beveiligingsonderzoeker vindt kritieke kwetsbaarheden in Zoom voor macOS

[Reactie gewijzigd door Koen Hendriks op 24 juli 2024 08:54]

[fapkonijntje]

Ik blijf dat toch ook een zwakte in macOS vinden. Dit soort apps zouden ook qua installatie geen rechten moeten krijgen. Hooguit dat je de installatie goedkeurt met je credentials, maar niet dat er daadwerkelijk rechten aan verleend worden. Zeker voor iets sufs als Zoom.

[PrimusIP]

Zoom is buiten de AppStore. En gelukkig staat macOS nog steeds een hele boel toe itt IOS. Zou best storend zijn als Apple zou besluiten met macOS Root rechten niet meer te geven zijn. Volgens mij ook helemaal niet vreemd voor een besturingssysteem. Het is dan vervolgens wel zaak dat de developer er zorgvuldig mee omgaat en dat je als gebruiker van het OS je er bewust van bent dat en wanneer je Root access geeft.

[fapkonijntje]

Ja, maar ook hier, betekent het dus wel dat de Zoom updater root rechten heeft en de bug is nu dat deze root rechten kan overhevelen door een foute configuratie, maar ik snap niet helemaal waarom een applicatie root rechten moet behouden om zichzelf bij te werken.

[Superstoned]

Dat is precies het probleem, en niet de eerste keer. Zoom niet installeren en alleen via de browser gebruiken is de oplossing.

[Yzord]

Een update heeft admin rechten nodig om in de Library folder te mogen schrijven en daar zal het hem wel inzitten.

[kodak]

De applicaties krijgen niet zomaar rechten, iemand moet dat bij de eerste installatie eerst goedkeuren.
Wardle toont dit ook in de presentatie.
Als die rechten eenmaal zijn gegeven gaat het voor het updaten mis, omdat er kennelijk te veel vertrouwen is in een goede werking met die rechten.

Als je zoom op macos wil installeren dan gaat dat kennelijk buiten de app store om en moet je bepaalde rechten toekennen zonder dat duidelijk is waar precies voor.

Dus dat zoom lekken heeft en hoort op te lossen is duidelijk, maar dat een beheerder moeite gaat doen om buiten de app store om te installeren en het root rechten te erkennen zonder te weten wat het dan doet is ook geen behoorlijk beheer.

[Eitot]

Zoom installeert een zogenaamd “privileged helper tool” (de bovengenoemde Zoom-updater). Dit zijn hulpprogramma’s die het mogelijk maken om handelingen met root-rechten uit te voeren, zonder dat de hoofd-app zelf root-rechten nodig heeft. De communicatie tussen deze twee programma’s verloopt via XPC (inter-process communication); de hoofd-app heeft geen directe controle over het hulpprogramma en kan alleen “aanvragen” sturen, afhankelijk van het interface (api) dat het hulpprogramma ter beschikking stelt. Als dit goed en veilig is ontwikkeld is er niets aan de hand. Deze manier van doen is gewoon mogelijk op macOS en een keuze van de ontwikkelaar.

Het probleem hier is enerzijds dat er een kwetsbaarheid in het hulpprogramma zat die het mogelijk maakte om de root-rechten van het hulpprogramma te misbruiken. Hier had Zoom de zaken dus niet goed op orde, met een kwetsbaarheid als gevolg. Het probleem is echter anderzijds dat ik mij ook de vraag stel, waarom een app als Zoom deze root-rechten nodig heeft. Als ik het Zoom.pkg-bestand bekijk is de Zoom-app een vrijstaande app, die je gewoon door slepen en neerzetten kunt installeren en verwijderen. Het bijwerken van zulke apps kan bijvoorbeeld met het populaire Sparkle-library, waarbij gewoon naar een admin-wachtwoord wordt gevraagd als dat nodig is.

Ik vind echter wel een groot gemis op macOS dat er behalve de Mac App Store geen officiële mogelijkheid is om apps (veilig) bij te werken.

[GekkePrutser]

Elke "PKG" (net zoiets als MSI op Windows) installer op macOS draait als root. Daarom moet je ook je wachtwoord invoeren als je die installeert. Simpelere programma's kunnen zonder installer gewoon in de Applicaties folder worden gegooid maar ook daar heb je root voor nodig. Logisch, want die folder is voor elke gebruiker leesbaar.

Nou heeft Zoom hier een eigen updater in elkaar gedraaid en omzeilt Apple's mechanisme. En dat zal ongetwijfeld wel weer vol met fouten zitten. Ze hebben een paar jaar geleden zelfs een complete rootkit op Macs geinstalleerd, die ze weigerden te verwijderen tot Apple een macOS update pushte die het voor ze deed

Dit bedrijf heeft wat mij betreft aangetoond alleen maar te geven om hun features en niet om de beveiliging van de systemen van hun klanten. Bij ons op het werk is hun software dan ook nog steeds verboden. Als iemand een Zoom call met een klant of leverancier moet doen dan mag het alleen via de webversie.

Ik snap ook niet waarom je nog Zoom zou gebruiken tegenwoordig. Jitsi en BigBlueButton tonen aan dat het gewoon gratis en in een browser zonder installatie perfect werkt.

[Reactie gewijzigd door GekkePrutser op 24 juli 2024 08:54]

[jmvdkolk]

Iedere applicatie kan root toegang krijgen als die dat vraagt en de gebruiker zegt ja. Dus een updater en een installer kunnen dat ook. Wat kan het OS hier tegen doen?

[Nimja]

Zoom lost kritieke kwetsbaarheid op die al heel lang geleden is ge-report en pas opgelost wordt als het in het nieuws komt.

nieuws: Beveiligingsonderzoeker vindt kritieke kwetsbaarheden in Zoom voor macOS

Het was EIND 2021 al doorgegeven aan Zoom....

[Erik1337]

Dit klopt niet, zoek de CVEs maar op en de tijd van publicatie.

Eind 2021 is een kwetsbaarheid bekend gemaakt en heeft Zoom geprobeerd dat op te lossen. De kwetsbaarheid bleek LATER alsnog via een andere route te bestaan. Daar heeft de onderzoeker, Patrick Wardle, recent over geschreven en is dat vandaag blijkbaar vanuit Zoom opgelost.

[kodak]

Alleen de eerste twee problemen waren in december 2021 bij zoom bekend gemaakt. De oplossingen kwamen in april en juli uit. Dat was voor deze publicatie. Het nu opgeloste probleem noemt Wardle nieuw en dat hij deze vond na verschijnen van de oplossingen.

Wat er kennelijk niet staat is wanneer Wardle deze nieuwe ontdekking aan zoom bekend heeft gemaakt en of er afspraken zijn over oplossen en publiceren. Zoom heeft een responsible disclosure, normaal maak je daar afspraken in over ongeveer gelijktijdig publiceren en updates uitgeven.

[GertMenkel]

Nee, dat was dus een andere kritieke kwetsbaarheid in het Zoom-updateproces.

Securitytip: negeer de dark patterns, open Zoom in je browser als je echt Zoom nodig hebt, dan kunnen ze niet van die onzin op je computer uithalen.