Denne uge i sikkerhed: GTA, Apple og Android, og usikker opstart

Da vi første gang så tweets om et sikkerhedsproblem i Grand Theft Auto V, lød det lidt som en trold. “Tryk på ‘alt og f4’ for at låse op for en snydetilstand”, eller hackeren, der hævder at være i stand til at slette din karakter. [Tez2]’s advarende tweet at du ikke skal spille GTA Online uden en firewall, lyder som en anden af ​​disse online urban legender. Men denne virker faktisk lovlig. NIST er selv med på det sjove og tildeler CVE-2023-24059 til udnyttelsen.

Når du spiller et onlinespil, sender andre brugere en “deltagelsesanmodning” for at deltage i den aktive session. Disse pakker kan indeholde misdannede data, som er blevet observeret at crashe spilklienten eksternt. Det menes, men ikke offentligt bekræftet, at det også er en Remote Code Execution (RCE) sårbarhed. Det virker sandsynligt, at dette aspekt vil blive tilføjet til nogle af de forskellige snydepaneler, der allerede er meget brugt til dette 10 år gamle spil. Så nu, i stedet for bare at give din egen karakter uendelig ammunition og sundhed, kan du påføre andre spillere noget kaos, muligvis op til at ødelægge deres karakterfiler og få dem forbudt.

Men hvorfor stoppe der? Hvis vi har kodeudførelse inde i spillet, hvad forhindrer en anden spiller i at starte et rigtigt angreb? Et videospil er ikke i sandkasse som en browser, og der er intet, der forhindrer et diskviskerangreb eller endda en orm i at kompromittere en flok spillere. Det værste er, at det er et gammelt spil, og selvom der er en stor spillerbase, er det ikke garanteret, at det bliver løst. Der er mindst ét ​​projekt, der sigter mod at være en firewall for at forhindre problemet.

XNU’s 19 og 20 år gamle Bugs

[Adam Doupé] ser ud til at have en evne til at finde gamle fejl i Apples kode, og denne gang er det et par rigtig gamle fejl i Apples kerne, XNU. Den første er et problem i dlil.c, netværksgrænsefladebehandleren. Dette problem er en type casting fejl, hvor en int er castet til en uint_16. Hvis denne cast løber over, bliver værdien et stort negativt tal, og den efterfølgende dataskrivning løber under bufferen og skriver uden for grænserne. Metoden til at udløse denne er en smule vanskelig, da den kræver oprettelse af 65536 netværksgrænseflader.

Der er to tilgange til at udløse denne tilstand. Den første er den enkleste, et lille script, der kører som root, der kalder ifconfig gentagne gange for at skabe grænseflader. Selvom det kunne være interessant som en del af en udnyttelseskæde, er den mere interessante idé at lave en ondsindet USB-dongle, der præsenterer sig selv som flere netværksgrænseflader. Resten af ​​indlægget er [Adam]’s forsøg på at vende underløbet til en udnyttelse. Han klarede det ikke helt, men det ser ud til, at det er muligt.

Den anden fejl er endnu ældre, en 20 år gammel fejl i XNU’er ndrv.c, den rå socket-handler. Det er et edge-tilfælde, hvor en sammenkædet liste med to medlemmer bliver forkert gået, et af listemedlemmerne er frigivet, men det overordnede element indeholder stadig en pegepind til den nu frigjorte hukommelse. Begge fejl er nu blevet rettet i de seneste iOS- og macOS-udgivelser.

Android (ARM) også

Android er ikke en, der skal udelades, med en stor opskrivning fra [Man Yue Mo] fra Github Security Lab, om et problem i Arm Mali GPU’en, der blev leveret som en del af Pixel 6-enheder. Med stor ironi får vi at vide, hvordan det ene ikke-Google-element i telefonen helt fra Google førte til udnyttelse af kernel-rum inde fra en app. Specifikt er det driveren til den GPU, og hvordan den håndterer JIT-hukommelse, som er hukommelsessegmenter, der styres af kernen og tilgås af brugerområdet og direkte af GPU’en. Og som du måske forventer, kan det forårsage problemer at have tre forskellige komponenter, der får adgang til hukommelsen på én gang.

I dette tilfælde er problemet, hvordan fraflytning håndteres. Disse bidder af hukommelse bliver behandlet og kan derefter returneres til den gratis butik. En ydelsesoptimering af driveren er at holde hukommelsesbuffere “varme”, faktisk ikke bede kernen om at frigøre dem, og springe allokeringsprocessen over, når den næste anmodning er nødvendig. Problemet er, at hukommelsen i denne limbo-tilstand betragtes som “evicerbar”, og kernen kan frigøre disse områder uden at gøre det gennem GPU-driveren. Dette efterlader systemet i en mærkelig tilstand, hvor GPU-driveren og brugerområdet stadig har gyldige pointere til en hukommelsesplacering, men kernen har markeret den som fri. Det virkelig sjove begynder, når den frigjorte hukommelsesplacering gøres krav på af en angrebsproces, og et falsk JIT-objekt sættes i stedet. Ved en eller anden smart hukommelsesmanipulation kan dette udnyttes til at producere en brugerrumskortlægning af kernekode, som derefter kan læses og skrives. Og det enkleste trin derfra er bare at ændre userspace-applikationen, så den kører som root.

Det er et smart fund, men det, der virkelig skiller sig ud, er problemet med at få det rettet. Dette blev rapporteret til Android-ingeniører i juli 2022, og et par uger senere blev rapporten lukket som et “Vil ikke løse”-problem. Der er en legitim pointe her, at det ikke er Android-koden, der indeholder problemet, og dette skulle rettes i ARM-driveren. ARM udsendte en opdatering, der løste problemet mindre end tre måneder senere, i august 2022. En koordineret offentliggørelse var planlagt med ARM til november, men det ser ud til, at Android-ingeniørerne fuldstændig droppede fejlen og ventede til januar-opdateringen for endelig at sende patch til Android-brugere. Og da den endelig kom, blev den sporet som en helt anden fejl, hvilket betyder, at den oprindelige rapport blev lukket og glemt. Det er lidt nedslående at se Google vise sådan en flippet holdning til en sårbarhed af denne sværhedsgrad på deres eget produkt.

KSMBD igen

Det begynder at ligne en dårlig idé at placere Server Message Block Daemon-driveren i Linux-kernen, da vi har endnu et heltalsunderløb før godkendelse, der fører til lammelsesangreb. Forskere ved Sysdig fandt fejlen denne gang ved at forske baseret på den tidligere ZDI-22-1690, som var en mere seriøs RCE i det samme kernemodul. Denne er en smule anderledes end andre heltalsunderløb, vi har set på. Heltals omsluttende natur sparer i stedet denne sårbarhed fra at være en mere alvorlig.

Det virkelige problem er, at under SMB-godkendelse indeholder datastrukturen fra fjernbrugeren et par længdeværdier, som bruges til at parse de indgående godkendelsesdata. Det er indlysende, at disse værdier ikke implicit er tillid til, og der udføres en god fejlkontrol for at forhindre et trivielt bufferoverløb. Den sag, der vælter os, er hvornår nt_len er mindre end CIFS_ENCPWD_SIZE, og den resulterende værdi er negativ. Når dette negative heltal castes til usigneret size_t i en memcpy() kaldes, er det negative heltal “udpakket” til en næsten max-værdi size_t. Hukommelseskopieringsfunktionen vil forsøge instruktionen, men dette er en temmelig ukontrolleret operation, og når til sidst utilgængelig hukommelse og panikerer kernen. Indtil videre ser der ikke ud til at være en måde at forvandle denne særlige fejl til en ægte RCE. Og desuden, efter disse mange år, ved alle sikkert ikke at udsætte en SMB-tjeneste for upålidelige brugere, ikke?

Usikker boot

Selvom Secure Boot ikke helt har vist sig at være den dystopiske pc-lock-in, som nogle af os frygtede, er det stadig indimellem en smerte at håndtere, mens man forsøger at reparere noget på en ødelagt maskine. Har du brug for en brugerdefineret boot-disk til at køre et værktøj? Jep, tid til at deaktivere sikker opstart. Men der er et par tilfælde, hvor det er nyttigt, som at forhindre opstarts-malware i at få et tåhold i et krypteret system. Der er måske noget at sige for en kendt mængde som sikker boot.

Derfor er det lidt mærkeligt at finde ud af, at MSI besluttede at kompromittere det en masse på deres desktop bundkort i en firmwareopdatering, der blev skubbet ud i januar sidste år. Og bemærk, at MSI ikke deaktiverede sikker opstart. Kontroller firmwareindstillingerne, eller kør mokutil --sb-state, og disse maskiner vil med glæde informere dig om, at Secure Boot stadig var aktiveret. Men en obskur firmwareindstilling, “Image Execution Policy” er indstillet til “Always Execute” – så sikker opstart ville stadig tjekke signaturen på opstartsstakken og derefter starte den, uanset hvad der blev fundet. Jeg vil bare citere opdageren, [Dawid Potocki]’s konklusion: “Stol ikke på, at uanset hvilke sikkerhedsfunktioner, du har aktiveret, virker, TEST DEM!”

QT’s RCE Sårbarhed Insekt

QT-pakken har et problem, hvor Javascript indlejret i QML (Qt Modeling Language)-kode kunne udløse et af to hukommelseshåndteringsproblemer og opnå RCE. Der er en smule uenighed mellem Cisco Talos og QT, om hvorvidt dette er en simpel fejl eller sikkerhedssårbarhed. QML-kode er eksplicit beregnet til at være brugergrænsefladekode til applikationer og bør aldrig udføre kode, der ikke er tillid til. Faktisk ville sikkerhedssårbarheden ifølge QT være enhver “applikation, der sender upålidelige input til QtQml”.