Hertzbleed utnyttjar turbofrekvenser för att komma åt information

Permalänk
Melding Plague

Hertzbleed utnyttjar turbofrekvenser för att komma åt information

En ny kategori av säkerhetshål avtäcks, där dynamiska klockfrekvenser och tid för beräkningar är de två huvudingredienserna.

Läs hela artikeln här

Visa signatur

Observera att samma trivselregler gäller i kommentarstrådarna som i övriga forumet och att brott mot dessa kan leda till avstängning. Kontakta redaktionen om du vill uppmärksamma fel i artikeln eller framföra andra synpunkter.

Permalänk
Medlem

Varje gång jag läser sånt här tänker jag att det är någon, någonstans som producerat rapporten med huvudsyftet att få anslag för sin forskning, och att det de aldrig skriver är att det krävs något extremt osannolikt hypotetiskt scenario -- typ att en cyberbrottsling installerat en fysisk antenn i ditt datorchassi, för att "sårbarheten" överhuvudtaget ska existera.

Permalänk
Konsolpleb 🕹
Skrivet av Sveklockarn:

Varje gång jag läser sånt här tänker jag att det är någon, någonstans som producerat rapporten med huvudsyftet att få anslag för sin forskning, och att det de aldrig skriver är att det krävs något extremt osannolikt hypotetiskt scenario -- typ att en cyberbrottsling installerat en fysisk antenn i ditt datorchassi, för att "sårbarheten" överhuvudtaget ska existera.

Jo vissa sådana här exploits kräver ju att man probe:ar saker direkt på systemkretsen. Då börjar det känns lite: sure om du är Elon Musk och din dator är stulen kanske det här är ett problem. För samtliga andra är det 100% ett ickeproblem.

Visa signatur

240p är livet

Permalänk
Medlem

Lösning: skaffa en Celeron som inte har turbo.

Eller så borde det vara vara att stänga av turbo och sätta att den ska ligga konstant på en nivå tex en Alla kärnor OC med C step avstängt. Men tror inte vanligt folk behöver oroa sig.

Visa signatur

Asus B650 TUF, Ryzen 7600X, 32GB 6000mhz DDR5, Corsair RM1000X, Powercolor 6900XT Red Devil Ultimate, 360mm Corsair AIO, MSI Velox 100P Airflow. Kingston KC3000 M.2.

Permalänk
Konsolpleb 🕹
Skrivet av dagas:

Lösning: skaffa en Celeron som inte har turbo.

Eller så borde det vara vara att stänga av turbo och sätta att den ska ligga konstant på en nivå tex en Alla kärnor OC med C step avstängt. Men tror inte vanligt folk behöver oroa sig.

Jo precis en av lösningarna som föreslogs där är just att stänga av turbo.

Visa signatur

240p är livet

Permalänk
Medlem
Skrivet av UndaC:

Jo precis en av lösningarna som föreslogs där är just att stänga av turbo.

Kanske läge att återinföra en fysisk turboknappen för de gånger man hanterar känslig data?

Permalänk
Medlem

Känns väldigt hypotetiskt då ett OS som Windows eller Linux alltid har en massa olika processer igång i bakgrunden som hela tiden varierar med någon tiondels procent i last så man kan inte mäta exakt hur länge en viss operation tar i isolation. Processer kan också hoppa mellan kärnor, det kan ske cache misses o.s.v. Lägg till det t.ex. att fläktar varvar upp olika snabbt på olika system, olika exemplar av samma CPU kan ha marginellt olika boost-beteende, och att t.o.m. rumstemperaturen påverkar boostfrekvensen (har "förlorat" 25 MHz nu jämfört med i vintras). Alla vet ju att man måste köra benchmarks flera gånger i följd för att få ett pålitligt medelvärde eftersom en enskild körning kan variera i prestanda med några procent.

Visa signatur

Ryzen 7 3800X, Asus Prime X370 Pro, 32 GB LPX 3600, Gainward RTX 3060 Ti Ghost, 7 TB SSD + 4 TB HDD

Permalänk
Medlem
Skrivet av Pepsin:

Känns väldigt hypotetiskt då ett OS som Windows eller Linux alltid har en massa olika processer igång i bakgrunden som hela tiden varierar med någon tiondels procent i last så man kan inte mäta exakt hur länge en viss operation tar i isolation. Processer kan också hoppa mellan kärnor, det kan ske cache misses o.s.v. Lägg till det t.ex. att fläktar varvar upp olika snabbt på olika system, olika exemplar av samma CPU kan ha marginellt olika boost-beteende, och att t.o.m. rumstemperaturen påverkar boostfrekvensen (har "förlorat" 25 MHz nu jämfört med i vintras). Alla vet ju att man måste köra benchmarks flera gånger i följd för att få ett pålitligt medelvärde eftersom en enskild körning kan variera i prestanda med några procent.

Säg inte det, just det här med att kryptografiska implementationer behöver göra arbetet på konstant tid för att inte läcka information är ju etablerat sedan gammalt, det är inte något som bara avfärdas trots att koden i regel körs i den typ av "brusiga" miljö du beskriver.
Detta är ju i princip ett specialfall där även en korrekt implementation, som sett till antalet klockcykler som förbrukas gör arbetet på konstant tid, till följd av hårdvarans turbobeteende ändå tar varierande tid att göra jobbet, och detta dessutom på ett sätt där den varierande tiden beror på indatan.

Trivialt att utnyttja på försöka försöket varje gång? Säkerligen inte.
Omöjligt att utnyttja i verkligheten? Förmodligen inte.

Visa signatur

Desktop: Ryzen 5800X3D || MSI X570S Edge Max Wifi || Sapphire Pulse RX 7900 XTX || Gskill Trident Z 3600 64GB || Kingston KC3000 2TB || Samsung 970 EVO Plus 2TB || Samsung 960 Pro 1TB || Fractal Torrent || Asus PG42UQ 4K OLED
Proxmox server: Ryzen 5900X || Asrock Rack X570D4I-2T || Kingston 64GB ECC || WD Red SN700 1TB || Blandning av WD Red / Seagate Ironwolf för lagring || Fractal Node 304

Permalänk
Skrivet av Sveklockarn:

krävs något extremt osannolikt hypotetiskt scenario

Känner samma.
Tänker alltid att det är överspelat och kräver att helt osannolika situationer krävs för gemene datorburen att bli drabbade.

Visa signatur

CPU i9-9900K GPU ASUS RTX 2080 TI Strix OC MB ASUS STRIX Z390-E RAM Corsair VENGEANCE RGB 32GB DDR4 3200MHz Case Fractal Design Define C PSU EVGA G3 850W Cooling Noctua D15
Monitor MSI Optix MAG342CQR SSD Samsung 970 EVO 500GB 860 EVO 500GB 860 QVO 2TB + QVO 4TB PLEX Server 2x HC560 20TB+WD RED 2x10TB+12TB

Permalänk
Medlem
Visa signatur

Processor: Motorola 68000 | Klockfrekvens: 7,09 Mhz (PAL) | Minne: 256 kB ROM / 512 kB RAM | Bussbredd: 24 bit | Joystick: Tac2 | Operativsystem: Amiga OS 1.3

Permalänk
Inaktiv

Vilket dravel. "Få ut krypterad information". Läser ni själva vad ni skriver?

Känns som den tekniska kompetensnivån på SweC redaktörerna har sjunkit avsevärt senaste åren.

Permalänk
Datavetare

Är detta ett problem för gemene man? Kanske inte!

Men det verkar tyvärr värre än de flesta tidigare CPU-buggar av ett par orsaker

1. Det finns (än så länge) ingen vettig väg runt problemet mer än att stänga av turbo-funktionen, vilket för dagens x86 CPUer är illa på desktop och katastrof för bärbara

2. När det kommer till spectre-buggarna och dess variant, även fast "proof-of-concept" exemplen krävde "root" access var det ofta hopplöst att få dem att fungera med mindre än att man handoptimerade varje fall specifikt för exakt timing hos sitt eget system, räckte inte inte ens att ha samma CPU-modell som man testat (bl.a. p.g.a turbo-funktioner som påverkas av kylning etc). Proof-of-concept för denna (som fortfarande kräver att man är "root") verkar tyvärr fungera rätt bra "out-of-the-box", något jag bara sett hos TakeAWay tidigare (som på det stora hela inte var så farlig ändå, den läckte bara meta-data, inte data i sig)

Kommentar kring detta

"Processorer från andra tillverkare, exempelvis ARM-baserade alternativ, väntas också vara påverkade, förutsatt att de har dynamiska klockfrekvenser."

Rimligen är det helt sant, värt att påpeka här är ändå att Apple faktiskt inte har dynamiska frekvenser på det sätt som denna sårbarhet kräver d.v.s. CPU-frekvensen kan ändras baserad på hur lastad kretsen är. Apple CPUer kan ändra CPU-frekvens men till skillnad från nästan alla andra har de konstant frekvens oavsett antalet lastade kärnor, det gäller både M1-serien och A-serien som används i mobiler. Tar man t.ex. M1 kör den på 3,2 GHz ("stora" kärnorna) / 2,0 GHz ("små" kärnorna) oavsett om en eller alla kärnor är aktiva.

Visa signatur

Care About Your Craft: Why spend your life developing software unless you care about doing it well? - The Pragmatic Programmer

Permalänk
Hedersmedlem
Skrivet av Sveklockarn:

Varje gång jag läser sånt här tänker jag att det är någon, någonstans som producerat rapporten med huvudsyftet att få anslag för sin forskning, och att det de aldrig skriver är att det krävs något extremt osannolikt hypotetiskt scenario -- typ att en cyberbrottsling installerat en fysisk antenn i ditt datorchassi, för att "sårbarheten" överhuvudtaget ska existera.

Detta är ju dock inte fallet här. Det möjligt att utveckla attacker som använder denna teknik som funkar över Internet, givet rätt omständigheter.

Inga antenner krävs, vet inte var du fått detta från.

Permalänk
Hedersmedlem
Skrivet av anon334363:

Vilket dravel. "Få ut krypterad information". Läser ni själva vad ni skriver?

Känns som den tekniska kompetensnivån på SweC redaktörerna har sjunkit avsevärt senaste åren.

Vad exakt är det du menar inte stämmer?

Permalänk
Medlem

Finns det några tester för hur mycket prestanda man förlorat med alla dessa "fixar" genom åren för säkerhetshål och dylikt? Sitter på en intel 9600k

Permalänk
Medlem
Skrivet av Sveklockarn:

Varje gång jag läser sånt här tänker jag att det är någon, någonstans som producerat rapporten med huvudsyftet att få anslag för sin forskning, och att det de aldrig skriver är att det krävs något extremt osannolikt hypotetiskt scenario -- typ att en cyberbrottsling installerat en fysisk antenn i ditt datorchassi, för att "sårbarheten" överhuvudtaget ska existera.

Jag tänker inte så men. Ber om ursäkt i förhand. Det var ganska klart att de som klagade på att stekt potatis var så farligt ville ha mera anslag. Bara för att något är mer cancerframkallande än det innan innebär inte att man ska sluta äta stekt potatis.

Jag har inte läst PDF filen och tror jag inte kommer förstå den. Men jag vet hur det var med vissa system mellan vissa system och timeouts. De jag jobbade med fick inte ha mer än fem min fel på klockorna men vid transaktioner var det klart mindre,

Rent spontant efter läst nyheten här att det är tidsspannet som är det hela. Då det är en osäker tidsrymd så är det +- något och om man lyckas ändra på datat då så går det igenom som godkänt. Tanken är att man inte ska hinna ändra något inom den tidsrymden.
Men ja. Vissa har ju otur. Som killen (inte jag) som lyckaded logga in på en dold kanal på undernet IRC då en netsplitt hånde och vart admin. Förta in.

Hur mycket snabbare hade inte våra system vart om vi hade kunnat lita på DMZ och Molnet samt intern. (vi litar inte på våra användare av princip)
Slippa skriva program för att kolla på annat en felskrivningar osv istället för att skydda systemen.
Hur mycket går inte åt till filtrering som skulle vart onödig om inte folk hela tiden skulle vara lite som de är?

Visa signatur

CPU: 5900x. Mem:64GB@3200 16-17-17-34-1T. (ImDIsk)
GPU: 1080 Ti@ca 6-7%OC. Sound: SB-Z -> toslink (DTS)-> old JVC. MB Realtek to Z-2300 for VOIP.

Permalänk
Skrivet av anon334363:

Vilket dravel. "Få ut krypterad information". Läser ni själva vad ni skriver?

Känns som den tekniska kompetensnivån på SweC redaktörerna har sjunkit avsevärt senaste åren.

Varför skulle ett infekterat system inte kunna läcka krypterad information?
Är du infekterad så kan den ju läsa din data innan den blir krypterad / efter den avkrypteras, du får gärna förklara varför det skulle vara så problemematiskt..

Enligt mig samma logik som säga, mitt hus är låst, det går inte komma in, säg det till inbrottstjuvarna, dom kan ju lyssna för all del..

Den tekniska kompetensnivån enligt mig är helt intakt då ett infekterat system mycket väl kan läcka information trots kryptering..

En annan fråga är ju dock givetvis VEM som lyckas dra sig på ett skadoprogram som lyckas med detta, men för vara ärlig.. inte mycket förvånar mig idag.. verkar som Ingrid 79 år har mer logik på datoranvändandet än Anders 17 år idag, verkar tyvärr gå på fel håll då alla verkar tro allt är riskfritt på internet...
Däremot om Ingrid blir uppringd och någon ber om känslig information, då är det tvärt om..

Permalänk
Medlem
Skrivet av Panterria:

Varför skulle ett infekterat system inte kunna läcka krypterad information?
Är du infekterad så kan den ju läsa din data innan den blir krypterad / efter den avkrypteras, du får gärna förklara varför det skulle vara så problemematiskt..

Enligt mig samma logik som säga, mitt hus är låst, det går inte komma in, säg det till inbrottstjuvarna, dom kan ju lyssna för all del..

Den tekniska kompetensnivån enligt mig är helt intakt då ett infekterat system mycket väl kan läcka information trots kryptering..

En annan fråga är ju dock givetvis VEM som lyckas dra sig på ett skadoprogram som lyckas med detta, men för vara ärlig.. inte mycket förvånar mig idag.. verkar som Ingrid 79 år har mer logik på datoranvändandet än Anders 17 år idag, verkar tyvärr gå på fel håll då alla verkar tro allt är riskfritt på internet...
Däremot om Ingrid blir uppringd och någon ber om känslig information, då är det tvärt om..

Om vi kollar på kopieringsskyddat Denuvo så om jag inte har fel så var en av dess storhet att du inte kan debuga skiten.
Den skickar in kod i CPUn som sedan exekveras mer än en gång mellan CPU och L? Cash. Så blir lite svårt att debugga utan att virtualisera hela skiten. Om man nu vill titta på det.

Detta innebär att man kan om jag förstått det rätt mer eller mindre leka med tiden. Klockan som ska avgöra om det är korrekt eller inte korrekt information som läggs till eller läses av.
Om du har fysisk tillgång till datorn är den din. (root) Branvägskurs då vi skämtade om det på början av 2000.
När data ska byta register så måste ett byte ske och var är då minsta gemensamma nämnare?
RAM? VRAM? L1? L2 L3 L4 L? 3DCashe. OS??? Det där var inte så OSI korrekt men jag tror ni förstår. Det där lär inte vara lätt. Men borde i teroin gå om någon har typ VNC eller RemoteDectop installerat med "Hitta hem" på. Så man kommer åt datorn efter varje omstart och kan gå via brandväggarna.

Visa signatur

CPU: 5900x. Mem:64GB@3200 16-17-17-34-1T. (ImDIsk)
GPU: 1080 Ti@ca 6-7%OC. Sound: SB-Z -> toslink (DTS)-> old JVC. MB Realtek to Z-2300 for VOIP.

Permalänk
Datavetare

Läst en hel del kommentarer kring detta problem. Känns som de flesta är överens om att även detta säkerhetshål är otroligt svårt att utnyttja på något relevant sätt utanför hårt kontrollerad labb-miljö. Så är nog inget man behöver vara nervös för att kommer kunna användas av virus/malware.

Den potentiellt relevanta attackvektorn är om man får sin dator stulen, med fysisk access till systemet finns eventuellt en möjlighet att detta gör det möjligt att komma förbi krypteringsskydd som t.ex. BitLocker. Även det är spekulation i nuläget, men verkar teoretiskt möjligt.

Det som oftast glöms bort i de här diskussionerna är att även om dessa sårbar kan utnyttjas lever de inte i en isolerad bubbla. Så länge som det finns långt enklare sätt att bryta sig in i systemen (buggar i OS och annan programvara), vilket så här långt definitivt varit fallet, kommer dessa CPU-sårbarhetet i praktiken vara rätt akademiska.

Skrivet av Tauri85:

Finns det några tester för hur mycket prestanda man förlorat med alla dessa "fixar" genom åren för säkerhetshål och dylikt? Sitter på en intel 9600k

Finns en del. Problemet är väl att man sedan de flesta av dessa tester gjordes har jobbat hårt på minska prestandapåverkan från patcharna med tiden, så lite svårt att veta hur de tester som gjordes när respektive sårbarhet var aktuellt visar en rättvis bild av dagens tillstånd.

Andra problemet är att vissa fixar inte kan backas då de gjorts i HW, d.v.s. finns inte längre något enkelt sätt att jämföra mot prestanda utan fix.

Positiva är väl ändå att fixarna för de tidigare hålen typiskt haft liten eller ingen påverkan på beräknings-tunga problem, det är främst I/O-intensiva laster som påverkats. I/O på klientmaskiner är ändå nästan alltid helt begränsade av I/O-enheten, få sitter på 100 Gbit/s Ethernet, supersnabba diskar samt arbetslaster som faktiskt påverkas om peak I/O-prestanda minskar.

Just Hertzbleed är ju extra illa då eventuell fix för den faktiskt har en relevant påverkan på beräkningstunga problem, inklusive saker relevanta för klientmaskiner som t.ex. spelprestanda. Bästa lösningen just nu, givet de praktiska möjligheterna att utnyttja denna sårbarhet, är nog struts-taktiken...

Visa signatur

Care About Your Craft: Why spend your life developing software unless you care about doing it well? - The Pragmatic Programmer

Permalänk
Medlem

Skydda åtkomsten till burkarna så är det fine. Dvs se till att de som potentiellt kan utnyttja sårbarheten inte kommer åt hårdvaran (vilket de inte heller ska). Annars så får man stänga av turbofunktionen men det känns som en "dum" lösning.

Visa signatur

Skärm Samsung 32" C32JG50 144Hz | CPU Ryzen 5 2600X | GPU AMD Vega 64 vattenkyld | Moderkort Asus Rog Strix B350-F Gaming | Minne 16 GB Corsair CL15 Vengeance | HDD 1 TB NVMe Samsung 970 Evo | Chassi Lian Li O11 Dynamic Svart

Permalänk
Medlem
Skrivet av Yoshman:

Kommentar kring detta

"Processorer från andra tillverkare, exempelvis ARM-baserade alternativ, väntas också vara påverkade, förutsatt att de har dynamiska klockfrekvenser."

Rimligen är det helt sant, värt att påpeka här är ändå att Apple faktiskt inte har dynamiska frekvenser på det sätt som denna sårbarhet kräver d.v.s. CPU-frekvensen kan ändras baserad på hur lastad kretsen är. Apple CPUer kan ändra CPU-frekvens men till skillnad från nästan alla andra har de konstant frekvens oavsett antalet lastade kärnor, det gäller både M1-serien och A-serien som används i mobiler. Tar man t.ex. M1 kör den på 3,2 GHz ("stora" kärnorna) / 2,0 GHz ("små" kärnorna) oavsett om en eller alla kärnor är aktiva.

Vet inte om jag missförstår dig här, men svagheten här är inte att klockfrekvensen ändras om man har fler eller färre kärnor aktiva - svagheten är att effektförbrukningen på en kärna ändras av vilken data den arbetar med. Enkelt uttryckt - om det är många binära ettor i den övre delen av ett tal, drar det mer ström än om det är många nollor. Eftersom högre effektförbrukning leder till att klockfrekvensen går ner, kan man genom att mäta tiden detektera vilka tal algoritmen jobbar med. Forskarna har sedan konstruerat ett fall där algoritmen jobbar med talet 0 om en viss bit är samma som den föregående, och använder sedan en mätning av den förbrukade tiden till att detektera om detta inträffar.

För att denna metod skall fungera på något annat än Intels chip, krävs det att de har samma typer av optimeringar, där man spar ström om många av de övre bitarna i ett tal är 0. Det är inte alls säkert att Apples chip har det. Det är inte omöjligt, men långt ifrån givet.

Slutligen: attacken i det här fallet tog 36 timmar i det bästa fallet, och en attack mot en liknande men inte identisk setup tog 89 timmar, eller nästan 4 dagar. Även om den säkert går att optimera, bör det också gå att göra den svårare genom att uppdatera algoritmer. Om det skiljer en faktor 2.5 mellan två liknande implementationer, finns det en del att hämta här. Man bör också kunna bygga system som försöker detektera hacker-försök som pågår i flera dagar.

Eh. Detta är inte Spectre. Detta är en teoretisk attack, som möjligen kan bli en byggsten i något värre, men det är ingen kris än.

Visa signatur

5900X | 6700XT

Permalänk
Medlem
Skrivet av martak:

Skydda åtkomsten till burkarna så är det fine. Dvs se till att de som potentiellt kan utnyttja sårbarheten inte kommer åt hårdvaran (vilket de inte heller ska). Annars så får man stänga av turbofunktionen men det känns som en "dum" lösning.

Rapporten visar på ett exempel där angreppet genomfördes över Internet, så nej, det räcker inte. Som jag skrev ovan är jag inte speciellt orolig, men just detta var inget bra argument.

Visa signatur

5900X | 6700XT

Permalänk
Datavetare
Skrivet av mpat:

Vet inte om jag missförstår dig här, men svagheten här är inte att klockfrekvensen ändras om man har fler eller färre kärnor aktiva - svagheten är att effektförbrukningen på en kärna ändras av vilken data den arbetar med. Enkelt uttryckt - om det är många binära ettor i den övre delen av ett tal, drar det mer ström än om det är många nollor. Eftersom högre effektförbrukning leder till att klockfrekvensen går ner, kan man genom att mäta tiden detektera vilka tal algoritmen jobbar med. Forskarna har sedan konstruerat ett fall där algoritmen jobbar med talet 0 om en viss bit är samma som den föregående, och använder sedan en mätning av den förbrukade tiden till att detektera om detta inträffar.

För att denna metod skall fungera på något annat än Intels chip, krävs det att de har samma typer av optimeringar, där man spar ström om många av de övre bitarna i ett tal är 0. Det är inte alls säkert att Apples chip har det. Det är inte omöjligt, men långt ifrån givet.

Slutligen: attacken i det här fallet tog 36 timmar i det bästa fallet, och en attack mot en liknande men inte identisk setup tog 89 timmar, eller nästan 4 dagar. Även om den säkert går att optimera, bör det också gå att göra den svårare genom att uppdatera algoritmer. Om det skiljer en faktor 2.5 mellan två liknande implementationer, finns det en del att hämta här. Man bör också kunna bygga system som försöker detektera hacker-försök som pågår i flera dagar.

Eh. Detta är inte Spectre. Detta är en teoretisk attack, som möjligen kan bli en byggsten i något värre, men det är ingen kris än.

Så förstod även jag det, d.v.s. ett krav är att CPU-frekvensen på något sätt har ett beroende av strömförbrukning. I det läget blir bl.a. Apples CPUer opåverkade då de inte har ett sådant beroende mellan last och frekvens. Det är samma frekvens vare sig man kör skalär-addition, vektor-operationer, etc, det på en eller alla kärnor.

Om det är så att man kan omöjliggöra denna attack genom att fixera frekvensen och om attacken faktiskt är praktisk användbar känns ju den rimligast fixen framåt att utföra den här typen av operationer på en hjälpkrets. När kryptering är involverad befinner man sig rätt sällan i den mest prestandakritiska delen, så högre latens (vilket tyvärr lär bli effekten av att lägga operationen på en extern krets) är ett litet problem.

Fast både Intel och AMD verkar tycka att sårbarheten är allt för opraktisk att utnyttja utanför labbmiljö för att det ska en vara värt att fixa problemet. Gissar att de har något på fötterna kring detta, men är absolut inte 100 %-ig garanti....

Visa signatur

Care About Your Craft: Why spend your life developing software unless you care about doing it well? - The Pragmatic Programmer

Permalänk
Medlem

Så om man kör allcore OC med satt frekvens så är det inte något problem? Vissa överklockare är immuna?

Visa signatur

Hur många datorer är för många?

Permalänk
Hedersmedlem
Skrivet av kelthar:

Så om man kör allcore OC med satt frekvens så är det inte något problem? Vissa överklockare är immuna?

Spännande om en praktisk mitigering faktiskt *ökar* prestanda den här gången.

Permalänk
Medlem
Skrivet av Yoshman:

Så förstod även jag det, d.v.s. ett krav är att CPU-frekvensen på något sätt har ett beroende av strömförbrukning. I det läget blir bl.a. Apples CPUer opåverkade då de inte har ett sådant beroende mellan last och frekvens. Det är samma frekvens vare sig man kör skalär-addition, vektor-operationer, etc, det på en eller alla kärnor.

Ah, OK, då fattar jag.

Citat:

Om det är så att man kan omöjliggöra denna attack genom att fixera frekvensen och om attacken faktiskt är praktisk användbar känns ju den rimligast fixen framåt att utföra den här typen av operationer på en hjälpkrets. När kryptering är involverad befinner man sig rätt sällan i den mest prestandakritiska delen, så högre latens (vilket tyvärr lär bli effekten av att lägga operationen på en extern krets) är ett litet problem.

Det där med en separat krets slog mig också. Den behöver inte ens vara så speciellt separat, bara den har en fixerad klockfrekvens så länge den är aktiv. Tillverkarna lägger ju transistorer på allehanda grejer som sällan används, medan kryptering körs av alla varenda dag.

Visa signatur

5900X | 6700XT

Permalänk
Medlem
Skrivet av Yoshman:

utnyttja denna sårbarhet, är nog struts-taktiken...

Förstår inte, det regnar ute.

Visa signatur

CPU: 5900x. Mem:64GB@3200 16-17-17-34-1T. (ImDIsk)
GPU: 1080 Ti@ca 6-7%OC. Sound: SB-Z -> toslink (DTS)-> old JVC. MB Realtek to Z-2300 for VOIP.

Permalänk
Medlem
Skrivet av mpat:

Rapporten visar på ett exempel där angreppet genomfördes över Internet, så nej, det räcker inte. Som jag skrev ovan är jag inte speciellt orolig, men just detta var inget bra argument.

Haha, ja men det betyder väl inte att den är skyddad ;D

Det handlar om att se till att obehöriga INTE kommer åt dina grejer. Om de kommer åt grejerna, även om du tycker att (äh, det är nog fine), så är det inte fine ur ett säkerhetsperspektiv då nya hot och sårbarheter dyker upp kontinuerligt.

En vettig lösning i det här fallet är att se till att du har dina burkar skyddade från extern åtkomst utan vettig autentisering.

Tex, två faktors auth till din VPN som sedan kopplar upp sig mot burken som i sin tur kräver två faktor för själva anslutningen.

Visa signatur

Skärm Samsung 32" C32JG50 144Hz | CPU Ryzen 5 2600X | GPU AMD Vega 64 vattenkyld | Moderkort Asus Rog Strix B350-F Gaming | Minne 16 GB Corsair CL15 Vengeance | HDD 1 TB NVMe Samsung 970 Evo | Chassi Lian Li O11 Dynamic Svart

Permalänk
Medlem

Så... vad för information kan man få ut? Frågar åt en kompis

Permalänk
Skrivet av hACmAn:

Om vi kollar på kopieringsskyddat Denuvo så om jag inte har fel så var en av dess storhet att du inte kan debuga skiten.
Den skickar in kod i CPUn som sedan exekveras mer än en gång mellan CPU och L? Cash. Så blir lite svårt att debugga utan att virtualisera hela skiten. Om man nu vill titta på det.

Detta innebär att man kan om jag förstått det rätt mer eller mindre leka med tiden. Klockan som ska avgöra om det är korrekt eller inte korrekt information som läggs till eller läses av.
Om du har fysisk tillgång till datorn är den din. (root) Branvägskurs då vi skämtade om det på början av 2000.
När data ska byta register så måste ett byte ske och var är då minsta gemensamma nämnare?
RAM? VRAM? L1? L2 L3 L4 L? 3DCashe. OS??? Det där var inte så OSI korrekt men jag tror ni förstår. Det där lär inte vara lätt. Men borde i teroin gå om någon har typ VNC eller RemoteDectop installerat med "Hitta hem" på. Så man kommer åt datorn efter varje omstart och kan gå via brandväggarna.

Fast jag köper inte det 100 faktiskt.. OM (notera att jag menar inte att jag tror någon faktiskt drar på sig detta.. jag menar bara rent vad som skulle vara möjligt OM man får in skiten i systemet...) Så har ju "bakdörren" redan åtkomst till systemet.. dom kan ju skicka fil/en/erna precis hur dom vill?, Jag menar, om man är en som krypterar datan, så avkrypterar ju systemet (os:et) datan, hade du skickat en fil via mail / social media så får ju inte mottagarsidan en oläsbar fil, eller hur? Det är ju om man krypterar hela systemet då, antar det finns andra alternativ med kryptering per fil / mapp (katalog) då kan det ju givetvis se annorlunda ut, om det helt enkelt krävs lösenord för öppna specifik plats (mapp) eller fil på systemet, men en krypterad disk på OS nivå så är ju systemet för all del krypterat men ingen förfrågan om avkryptera för skicka datan vidare existerar? (Är la mer för skydda datan vid stöld av datorn i sig typ) Jag har faktiskt aldrig behövt kryptera något då jag inte har behovet av göra det.. men om OS:et skulle be mig avkryptera med "nyckel" vartenda fil systemet vill ha åtkomst till skulle jag nog vara 90 miljarder år gammal för ens starta upp mspaint..