Zoom for Mac-oppdateringer får root-feil – oppdater nå! PlatoBlockchain Data Intelligence. Vertikalt søk. Ai.

Zoom for Mac-oppdateringer får root-feil – oppdater nå!

Tidsstempel: 15. august 2022 12:26

by
Paul Ducklin

På den velkjente DEF CON sikkerhetstjenesten i Las Vegas, Nevada, forrige uke, Mac cybersecurity researcher Patrick Wardle avslørt en "get-root" forhøyelse av privilegiet (EoP)-feil i Zoom for Mac:

I tweeten, som fulgte foredraget hans [2022-08-12], bemerket Wardle:

For øyeblikket er det ingen lapp [:FRIED-EGG EYES DEPICTING ALARM EMOJI:] [:EDVARD MUNCH SCRREAM EMOJI:]

Zoom jobbet umiddelbart med en oppdatering for feilen, som ble annonsert dagen etter Zoom sikkerhetsbulletin ZSB-22018, får en gratulasjon svar fra Wardle i prosessen:

Mahalos til @Zoom for den (utrolig) raske løsningen! [:BEGGE HENDER HEKKET I FEIRING OG VRIKKET OM EMOJI:] [:PALMER DRESSET SAMMEN I TEGN PÅ ÅNDELIG VILJE EMOJI:]

Null-dagers avsløring

Gitt den tilsynelatende hastigheten og lettheten som Zoom var i stand til å sende ut en oppdatering for feilen, kalt CVE-2022-28756, du lurer sikkert på hvorfor Wardle ikke fortalte Zoom om feilen på forhånd, og satte dagen for sin tale som fristen for å avsløre detaljene.

Det ville gitt Zoom tid til å sende ut oppdateringen til sine mange Mac-brukere (eller i det minste å gjøre den tilgjengelig for de som tror på lapp tidlig/lapp ofte), og eliminerer dermed gapet mellom Wardle som forklarer verden hvordan man misbruker feilen, og oppdateringen av feilen.

Faktisk ser det ut til at Wardle gjorde sitt beste for å advare Zoom om denne feilen, pluss en haug med sammenkoblede feil i Zooms autooppdateringsprosess for noen måneder siden.

Wardle forklarer tidslinjen for avsløring av feil i lysbilder fra hans DEF CON-tale, og viser en strøm av Zoom-oppdateringer relatert til feilene han oppdaget.

Et dobbeltkantet sverd

Feilene som Wardle diskuterte var generelt knyttet til Zooms automatiske oppdateringsmekanisme, en del av ethvert programvareøkosystem som er litt av et tveegget sverd – et kraftigere våpen enn et vanlig sverd, men tilsvarende vanskeligere å håndtere trygt.

Automatisk oppdatering er en må-ha-komponent i enhver moderne klientapplikasjon, gitt at den gjør kritiske patcher enklere og raskere å distribuere, og dermed hjelper brukere å lukke cybersikkerhetshull på en pålitelig måte.

Men automatisk oppdatering fører med seg et hav av risikoer, ikke minst fordi selve oppdateringsverktøyet typisk trenger systemtilgang på rotnivå.

Det er fordi oppdateringsprogrammets jobb er å overskrive applikasjonsprogramvaren (noe som en vanlig bruker ikke skal gjøre), og kanskje å starte privilegerte operativsystemkommandoer for å gjøre konfigurasjon eller andre systemnivåendringer.

Med andre ord, hvis utviklerne ikke er forsiktige, kan selve verktøyet som hjelper dem med å holde den underliggende appen deres oppdatert og sikrere bli et strandhode som angripere kan undergrave sikkerheten ved å lure oppdateringsprogrammet til å kjøre uautoriserte kommandoer med systemprivilegier .

Spesielt må autooppdateringsprogrammer passe på å verifisere autentisitet av oppdateringspakkene de laster ned, for å hindre at angripere bare mater en falsk oppdateringspakke, komplett med ekstra skadelig programvare.

De må også vedlikeholde integritet av oppdateringsfilene som de til slutt bruker, slik at en lokal angriper ikke snikende kan endre den "verifiserte sikre" oppdateringspakken som nettopp er lastet ned i den korte perioden mellom den ble hentet og aktivert.

Omgå autentisitetssjekken

Som Wardle forklarer i sin papir, var en av feilene han oppdaget og avslørte en feil i det første trinnet som er oppført ovenfor, da Zooms automatiske oppdatering forsøkte å bekrefte ektheten til oppdateringspakken den nettopp hadde lastet ned.

I stedet for å bruke de offisielle macOS API-ene for å validere den digitale signaturen til nedlastingen direkte, bestemte Zoom-utviklere seg for å utføre autentiseringen indirekte ved å kjøre macOS-verktøyet pkgutil --check-signature i bakgrunnen og undersøker resultatet.

Her er et eksempel på pkgutil output, ved å bruke en gammel versjon av Zoom.pkg programvarepakke:

$ pkgutil --check-signature Zoom.pkg Pakke "Zoom.pkg": Status: signert av et utviklersertifikat utstedt av Apple for distribusjon Signert med et pålitelig tidsstempel på: 2022-06-27 01:26:22 +0000 Certificate Chain : 1. Utvikler-ID Installer: Zoom Video Communications, Inc. (BJ4HAAB9B3) Utløper: 2027-02-01 22:12:15 +0000 SHA256 Fingeravtrykk: 6D 70 1A 84 F0 5A D4 C1 C1 C3 E01 AE 2F FB 1F 2C A9 5 6 A80 48 4 FF B76 F60 5 BB 0C ------------------------------------------ -------------------------------------- 57. Developer ID Certification Authority utløper: 8-2-2027 02:01:22 +12 SHA15 Fingeravtrykk: 0000A FC 256D 7 A9 01F 6 A2 DE 03 2 96 37D 93A FE 6 4 68D 09D E0 2D 1 F8 03C 2 CF B9 -------- B88 BA 0 -------------------------------------------------- -------------- 1. Apple Root CA Utløper: 63-58-7 3:2035:02 +09 SHA21 Fingeravtrykk: B40 B36 0000 256E CB C0 FF 1 73 0 7C 45 F05 14 2E 49E DA 1B CA ED 29E 5C 6 C6 BE 7 B2 A68 5 91 F5 1

Dessverre, som Wardle oppdaget da han dekompilerte Zooms signaturverifiseringskode, behandlet ikke Zoom-oppdateringen pkgutil data på samme måte som menneskelige observatører ville gjort.

Vi ville sjekke utdataene ved å følge den nyttige visuelle sekvensen i utdataene.

Først vil vi først se etter ønsket status, f.eks signed by a developer certificate issued by Apple for distribution.

Så finner vi underoverskriften Certificate Chain:.

Til slutt ville vi krysssjekke at kjeden besto av disse tre underskriverne, i riktig rekkefølge:

  1. Zoom Video Communications, Inc. 2. Developer ID Certification Authority 3. Apple Root CA

Utrolig nok bekreftet Zooms kode ganske enkelt at hver av de tre strengene ovenfor (ikke engang sjekket for Zooms egen unike ID BJ4HAAB9B3) dukket opp et sted i utgangen fra pkgutil.

Så, å lage en pakke med et absurd-men-gyldig navn som f.eks Zoom Video Communications, Inc. Developer ID Certification Authority Apple Root CA.pkg ville lure pakkeverifikatoren til å finne "identitetsstrengene" den lette etter.

Det fullstendige pakkenavnet gjentas i pkgutil utdataoverskrift på den første linjen, der Zooms ulykkelige "verifikator" ville matche alle tre tekststrengene i feil del av utdataene.

Dermed kan "sikkerhets"-sjekken trivielt omgås.

En delvis reparasjon

Wardle sier at Zoom til slutt fikset denne feilen, mer enn syv måneder etter at han rapporterte den, i tide for DEF CON ...

…men etter å ha brukt lappen, la han merke til at det fortsatt var et gapende hull i oppdateringsprosessen.

Oppdatereren prøvde å gjøre det rette:

  • 1. Flytt den nedlastede pakken til katalogen som eies av root, og dermed teoretisk sett forbudt for enhver vanlig bruker.
  • 2. Bekreft den kryptografiske signaturen til den nedlastede pakken, ved hjelp av offisielle APIer, ikke via en tekst-matchende bodge mot pkgutil utgang.
  • 3. Avarkiver den nedlastede pakkefilen, for å verifisere versjonsnummeret, for å forhindre nedgraderingsangrep.
  • 4. Installer den nedlastede pakkefilen, ved å bruke rotrettighetene til den automatiske oppdateringsprosessen.

Dessverre, selv om katalogen som ble brukt til å lagre oppdateringspakken var eid av root, i et forsøk på å holde den trygg fra nysgjerrige brukere som prøver å undergrave oppdateringsfilen mens den ble brukt...

…den nylig nedlastede pakkefilen ble "verdensskrivbar" på sin nye plassering (en bivirkning av å ha blitt lastet ned av en vanlig konto, ikke av root).

Dette ga lokale angripere et smutthull for å endre oppdateringspakken etter dens digitale signatur hadde blitt validert (trinn 2), uten å påvirke versjonssjekkdetaljer (trinn 3), men like før installasjonsprogrammet tok kontroll over pakkefilen for å behandle den med root-privilegier (trinn 4).

Denne typen feil er kjent som en løp tilstand, fordi angriperne må tidsbestille ferdigheten slik at de kommer hjem rett før installasjonsprogrammet starter, og de skal derfor snike de ondsinnede endringene inn rett foran det.

Du vil også høre denne typen sårbarhet referert til med det eksotisk-klingende akronymet TOCTOU, kort for tid-av-sjekk-til-tidspunkt-for-bruk, et navn som er en klar påminnelse om at hvis du sjekker fakta for langt i forveien, kan de være utdaterte når du stoler på dem.

TOCTOU-problemet er hvorfor bilutleiefirmaer i Storbritannia ikke lenger bare ber om å få se førerkortet ditt, som kunne ha blitt utstedt for opptil 10 år siden, og kunne ha blitt suspendert eller kansellert av en rekke årsaker siden den gang, mest sannsynlig fordi av usikker eller ulovlig kjøring fra din side. Sammen med den fysiske lisensen din må du også presentere en engangs alfanumerisk "bevis for nylig gyldighet"-kode, utstedt i løpet av de siste 21 dagene, for å redusere det potensielle TOCTOU-gapet fra 10 år til bare tre uker.

Reparasjonen er nå inne

I følge Wardle har Zoom nå forhindret denne feilen ved å endre tilgangsrettighetene til oppdateringspakkefilen som er kopiert i trinn 1 ovenfor.

Filen som brukes til signaturkontroll, versjonsvalidering og den endelige installasjonen på rotnivå, er nå begrenset til kun tilgang til root-kontoen til enhver tid.

Dette fjerner rasebetingelsen, fordi en uprivilegert angriper ikke kan endre filen mellom slutten av trinn 2 (bekreftelse vellykket) og starten på trinn 4 (installasjonen begynner).

For å endre pakkefilen for å lure systemet til å gi deg root-tilgang, må du allerede ha root-tilgang, så du trenger ikke en EoP-feil av denne typen i utgangspunktet.

TOCTOU-problemet gjelder ikke fordi sjekken i trinn 2 forblir gyldig til bruken av filen begynner, og etterlater ingen mulighet for at sjekken blir ugyldig.

Hva gjør jeg?

Hvis du bruker Zoom på en Mac, åpner du appen og går deretter til i menylinjen zoom.us > Check for Updates...

Hvis en oppdatering er tilgjengelig, vil den nye versjonen vises, og du kan klikke [Install] for å bruke lappene:

Zoom for Mac-oppdateringer får root-feil – oppdater nå! PlatoBlockchain Data Intelligence. Vertikalt søk. Ai.

Versjonen du ønsker er 5.11.5 (9788) eller senere.

Tidstempel:

Mer fra Naken sikkerhet