Mozilla har annonsert fullføringen av en uavhengig revisjon av klientprogramvare for tilkobling til Mozilla VPN-tjenesten. Tilsynet inkluderte en analyse av en frittstående klientapplikasjon skrevet ved hjelp av Qt-biblioteket og tilgjengelig for Linux, macOS, Windows, Android og iOS. Mozilla VPN drives av mer enn 400 servere til den svenske VPN-leverandøren Mullvad, lokalisert i mer enn 30 land. Tilkobling til VPN-tjenesten gjøres ved hjelp av WireGuard-protokollen.
Tilsynet ble utført av Cure53, som på et tidspunkt reviderte NTPsec-, SecureDrop-, Cryptocat-, F-Droid- og Dovecot-prosjektene. Tilsynet dekket verifisering av kildekoder og inkluderte tester for å identifisere mulige sårbarheter (spørsmål knyttet til kryptografi ble ikke vurdert). Under tilsynet ble det identifisert 16 sikkerhetsproblemer, hvorav 8 var anbefalinger, 5 ble tillagt lavt farenivå, to ble tillagt middels og en ble tillagt høy faregrad.
Imidlertid ble bare ett problem med middels alvorlighetsgrad klassifisert som en sårbarhet, siden det var det eneste som kunne utnyttes. Dette problemet resulterte i lekkasje av VPN-bruksinformasjon i den fangede portaldeteksjonskoden på grunn av ukrypterte direkte HTTP-forespørsler sendt utenfor VPN-tunnelen, og avslører brukerens primære IP-adresse hvis angriperen kunne kontrollere transittrafikken. Problemet løses ved å deaktivere fangeportaldeteksjonsmodus i innstillingene.
Det andre problemet med middels alvorlighetsgrad er assosiert med mangelen på riktig rengjøring av ikke-numeriske verdier i portnummeret, som tillater lekkasje av OAuth-autentiseringsparametere ved å erstatte portnummeret med en streng som "[e-postbeskyttet]", som vil føre til installasjon av taggen[e-postbeskyttet]/?code=..." alt=""> får tilgang til example.com i stedet for 127.0.0.1.
Det tredje problemet, flagget som farlig, lar enhver lokal applikasjon uten autentisering få tilgang til en VPN-klient via en WebSocket bundet til localhost. Som et eksempel er det vist hvordan, med en aktiv VPN-klient, ethvert nettsted kan organisere opprettelsen og sendingen av et skjermbilde ved å generere screen_capture-hendelsen. Problemet er ikke klassifisert som en sårbarhet, siden WebSocket kun ble brukt i interne testbygg og bruken av denne kommunikasjonskanalen kun var planlagt i fremtiden for å organisere interaksjon med et nettlesertillegg.
Kilde: opennet.ru