Zephyrnet-logo

Google Pixel-telefoons hadden een ernstige bug voor het lekken van gegevens - dit is wat u moet doen!

Datum:

Zelfs als u er nog nooit een hebt gebruikt, weet u waarschijnlijk wat een videorecorder is (of was).

Kort voor videorecorder, was het hoe we thuis video's opnamen en terugkeken in de tijd dat digitale video opgeslagen op harde schijven het absurd dure voorrecht was van grote bedrijven, meestal tv-zenders.

De cassettes waren kleine plastic bakjes met twee spoelen en een lange strook magnetische opnametape - een beetje zoals een ouderwetse harde schijf, maar met het magnetische oppervlak gerangschikt in een lange strook van...

... nou ja, van plastic tape, 12.7 mm breed (dat is precies 1/2 ") en ongeveer 100 meter lang voor elk uur opnemen.

(Tapes werden verkocht met identifiers zoals E-120, wat betekent PAL- of SECAM-opname, zoals gebruikt in het grootste deel van de wereld, 120 minuten lang, of T-180, voor drie uur opnemen in NTSC-indeling, de tv-standaard die wordt gebruikt in Noord-Amerika en Japan).

In een VHS-standaard videorecordercassette.
Afbeelding dankzij Toby Hudson on Wikimedia voor CC BY-SA 2.5 AU.

Overgebleven gegevens onthuld aan het einde

Weinig tv-programma's waren precies zo lang als een band, dus als je een programma opnam, had je meestal nog een stukje band over aan het einde van de spoel, dat leeg zou zijn.

Als je bijvoorbeeld een programma van 45 minuten terugkijkt dat is opgenomen op een E-60-band, krijg je 15 minuten video-fuzz (algemeen bekend als 'statisch') als je de band laat lopen als de show is afgelopen, totdat de videorecorder detecteerde het einde van de spoel en spoelde de cassette gewillig terug voor de volgende keer.

Tenzij jij (of de vriend die je de tape had geleend) hem natuurlijk eerder had gebruikt en iets langer dan 45 minuten had opgenomen...

...in dat geval zou je uiteindelijk kijken naar het laatste deel van wat er nog over was van de tijd ervoor, en wanneer dat eindigde, wat er daarvoor was opgenomen, of de tijd daarvoor, enzovoort.

Je krijgt het beeld.

De cut-over was nooit erg schoon, omdat de videorecorder het videosignaal meestal uit het oog verloor toen de eerste opname eindigde, en een mengelmoes van schuine lijnen, gedeeltelijke frames die op het scherm rondsprongen, wazige kleurovergangen afspeelde , en een rare, onleesbare mix van verschillende audio-soundtracks.

In ieder geval voor een tijdje.

Doorgaans zou de videorecorder zichzelf echter 'opnieuw afstemmen' op de overgebleven gegevens van de vorige opname, opnieuw synchroniseren met de oude videostream en zou de verknipte, onbegrijpelijke onzin op het scherm verdwijnen.

Je zou in het staartje van een onbekend tv-programma worden gegooid, een vakantie-opname bekijken of een ander soort homevideo bekijken, waarvan de meeste (maar niet alle!) Verloren waren gegaan toen het opnieuw werd opgenomen.

In werkelijkheid zou je bijna altijd wat onverwachte en misschien ongewenste eerdere inhoud aan het einde achterlaten, tenzij je eerst de hele band wist voordat je eroverheen opnam.

De "aCropalypse"-bug

Welnu, een Britse cyberbeveiligingsonderzoeker genaamd David Buchanan heeft zojuist een dit artikel over zo'n bug...

…in de tool voor het bewerken van afbeeldingen op de Pixel-telefoons van Google.

De gewraakte software staat blijkbaar bekend als Markup, en je kunt er foto's of screenshots mee maken die al op je telefoon staan, en ze bijsnijden of anderszins bewerken om ongewenste details te verwijderen voordat je ze naar je vrienden stuurt of ze uploadt naar online services.

U kunt bijvoorbeeld iemand uit de foto knippen om te voldoen aan zijn verzoek om zijn of haar gezicht niet te delen, of om een ​​gebruikersnaam of account-ID te blokkeren in een softwarescreenshot, of om iemands huisnummer onleesbaar te maken om niet weg te geven hun adres.

Zoals u zich kunt voorstellen, is het resulterende afbeeldingsbestand, vooral wanneer u een afbeelding bijsnijdt om de grootte te verkleinen, vaak kleiner dan het bestand dat u vervangt.

Markering zou klaarblijkelijk kleinere afbeeldingen verwerken door de nieuwe afbeelding over de oude heen te schrijven (zoals je vader of je grootvader de voetbalwedstrijd van deze week opneemt over de wedstrijd op de videorecorder van vorige week), en vervolgens het afbeeldingsbestand in te korten naar zijn nieuwe, kortere maat.

De oude gegevens – het staartstuk van de voetbalwedstrijd van vorige week, in onze videorecorder-analogie – zouden achterblijven op het opslagapparaat, maar zouden geen deel meer uitmaken van het digitale bestand met het nieuwe beeld.

Met andere woorden, wanneer u het nieuwe bestand opende, zou u niet het VCR-probleem hebben dat er overgebleven beeldinhoud in zit, omdat het besturingssysteem wist dat het op het juiste punt moest stoppen met lezen (of kopiëren).

De overgebleven gegevens konden dus niet per ongeluk worden gelekt als je het nieuwe bestand naar iemand anders stuurde of naar een clouddienst uploadde.

Een aanvaller heeft normaal gesproken fysieke toegang tot je telefoon nodig, moet weten hoe hij deze kan ontgrendelen en root-privileges kan krijgen, en moet een forensisch beeld op laag niveau kunnen maken van de ongebruikte gegevens om eerder verwijderde dingen te herstellen.

Behalve de fout.

Afkappen of niet afkappen?

Zoals Buchanan ontdekte, de Java-programmeerfunctie die Markup gebruikte "open het bestaande bestand in afkapmodus" (wat betekent dat ongebruikte gegevens die overblijven nadat u klaar bent met herschrijven, aan het einde van het bestand worden afgehakt)...

...is blijkbaar ongeveer twee jaar geleden gewijzigd in "openen in herschrijfmodus zonder afkappen wanneer voltooid".

Met andere woorden, als je het oude bestand zou openen en slechts één enkele byte aan het begin zou schrijven voordat je het sluit, zou het nieuwe bestand niet één byte lang zijn en de rest zou zijn weggelaten, zoals je zou verwachten, maar zou het oude bestand zijn, in zijn geheel, waarbij alleen de eerste byte is gewijzigd.

De rest zou intact zijn – helemaal niet wat de bedoeling was!

Zoals Buchanan ontdekte, hoewel de overgebleven gegevens van de vorige versie van de afbeelding onvolledig waren en met rust zouden worden gelaten als het bestand zou worden geopend met een gewone afbeeldingsviewer (die zoveel zou lezen als nodig is en de extra dingen op de einde)…

… je zou toch die overgebleven afbeeldingsgegevens kunnen extraheren en er vaak iets zinnigs uit kunnen halen, ook al zou je kunnen eindigen met een stroom gecomprimeerde gegevens die halverwege een gecomprimeerd blok is begonnen.

Net als bij die videorecorders, waarbij de videorecorder mogelijk niet onmiddellijk kan synchroniseren met de overgebleven opname, is een speciaal geschreven programma voor het decomprimeren van PNG-bestanden misschien niet in staat om de eerste paar stukjes van de overgebleven gegevens te begrijpen, maar kan het vaak reconstrueren blokken van de vorige afbeelding die later volgden.

Net als die videorecorders, waar het overgebleven deel op zichzelf misschien niet veel waard is, kon je nooit helemaal zeker weten wat er was achtergebleven, en iemand die in je bestanden graaft, kan soms geluk hebben met de brokken die ze hebben weten te reconstrueren.

Dat betekent dat ze beeldfragmenten van het einde van de vorige versie kunnen ontdekken dat was precies wat u van plan was te verwijderen.

Losjes gezegd, hoe meer je het originele bestand had bijgesneden en verkleind, hoe meer overgebleven gegevens er achter zouden blijven en hoe groter de kans dat een deel ervan precies was wat je niet wilde delen.

Wat te doen?

  • Nu patchen. Google heeft blijkbaar het Markup-programma gepatcht in de beveiligingsupdate van Android van maart 2023. U kunt deze bugfix volgen met de identifier CVE-2023-20136.
  • Bekijk afbeeldingen die je al hebt gedeeld opnieuw. Afbeeldingen die je al hebt bijgesneden en gedeeld, zijn te laat om te corrigeren. Maar u kunt overwegen ze toch te verwijderen of ze te vervangen door opnieuw bewerkte afbeeldingen die zijn gemaakt met de gepatchte versie van Markup.
  • Overweeg om beveiligingskritieke afbeeldingen conservatief op uw laptop te bewerken. Bestandsindelingen zoals PNG kunnen ook opmerkingen en zogenaamde metadata bevatten (bijvoorbeeld locatie-informatie of cameradetails) die u nooit wilde delen, laat staan ​​dat u onbedoeld overgebleven pixels van vroeger zou behouden.

Hulpprogramma's voor beeldmanipulatie via de opdrachtregel, zoals ImageMagick or AfbeeldingenMagick, en open-sourcetools zoals GNU-beeldmanipulatieprogramma, kunt u bewerkte afbeeldingen converteren naar indelingen waarbij u de inhoud nauwkeurig beheert.

Ruwe RGB-bestanden bevatten bijvoorbeeld alleen de kleurwaarden van elke pixel in de afbeelding, zonder kopteksten, metagegevens of commentaarvelden. of andere externe informatie of pixels.

RGB-bestanden kunnen enorm zijn, omdat er geen compressie is om ruimte te besparen, maar dat betekent dat u geen beeldkwaliteit verliest bij de conversie, ook al verliest u alle gegevens die niet direct deel uitmaken van de afbeelding waarin u bent geïnteresseerd in.

Dus het transcoderen van een afbeelding naar RGB-indeling en vervolgens terug naar bijvoorbeeld PNG, is een manier om ervoor te zorgen dat u een totaal nieuw bestand maakt dat niets "weet" over waar of hoe de originele afbeelding is gemaakt, of welke nu verwijderde gegevens het had eerder kunnen bevatten.


spot_img

Laatste intelligentie

spot_img