En metode til, at indsætte et rootkit på CPU'ens cache er blevet opdaget!
Læs hele nyheden her: http://hwt.dk/newsdetails.aspx...
Læs hele nyheden her: http://hwt.dk/newsdetails.aspx...
#1
😲 .. fuck hvor sygt man har fundet ud af det 😲
#3
Fuck hvor stygt, men egentlig også nice 😀 Det er sku da fedt nok det er blevet således at man har kunne bryde og indsætte ny microcode på en processor... den med typen er jo egentlig lige gyldigt, for det er jo forskellige microcoder til hver stykke HW, men de laves garanteret omtrendt ens 🤣
Nu er det ikke microcoden det angreb ændrer, men det benytter en given fejl i denne til, at kunne skrive ind i cachen udenom antivirus og andre systemlag :) Og at man kan det er i sig selv en ekstrem fejl, hvis du læser på wikipediasiden, om microcoden :)
For nylig kom der en virus ud, der ændrer din BIOS, så du ikke kan flashe den med en anden BIOS og fjerne den, samtidigt med at den deaktivere safe mode i Windows så du ikke kan gå ind og fjerne den og yderligere deaktiverede den samtlige kendte antivirusprogrammer, malwarefjernere, mv. og ændrede hosts-filen så man ikke kunne gå ind på nogen antivirusproducentsider. Afgjort heller ikke særligt fedt :|
For nylig kom der en virus ud, der ændrer din BIOS, så du ikke kan flashe den med en anden BIOS og fjerne den, samtidigt med at den deaktivere safe mode i Windows så du ikke kan gå ind og fjerne den og yderligere deaktiverede den samtlige kendte antivirusprogrammer, malwarefjernere, mv. og ændrede hosts-filen så man ikke kunne gå ind på nogen antivirusproducentsider. Afgjort heller ikke særligt fedt :|
#5
Hvis et program har har mulighed for at køre kode på de niveau, så var det sku nok nemmere bruge traditionelle metoder.
Hvorfor sparke 12 døre ind, hvis pengeskabet står efter dør nummer 2? 😉
Hvorfor sparke 12 døre ind, hvis pengeskabet står efter dør nummer 2? 😉
#6
Synd for dem der kunne finde på at købe intel ^^
#7
#4 Det som jeg synes er nice er det kan lade sig gøre, og at det viser Intel også laver bommerter på det niveau, selvom de burde være foruden😉
#8
Jeg går ud fra at softwaren som kan inficere CPU'en bruger micro instructions i sidste ende og det er derfor at en opdatering af micro instructions ville sætte en stopper for det?
Men micro instructions er jo blot et instruktionssæt der hjælper med at udføre de opgaver CPU'en bliver bedt om af kode på et højere niveau. Er det ikke nærmere i et af software niveauerne under "virussen" der bør laves et sikkerhedstjek?
For de her insrtuktionssæt bliver jo offentliggjort så software udviklere kan benytte sig af dem og desværre også folk med ikke så gode hensigter.
Så vidt jeg ved kan micro instructions kun lave simple beregninger og tjekke 2 tal i forhold til hinanden og yderligere så vidt min lille hjerne kan forstå det, så er det ikke nok til et sikkerhedstjek, men det kan også bare være min hjerne skulle udvides med lidt mere viden. 😀
Men micro instructions er jo blot et instruktionssæt der hjælper med at udføre de opgaver CPU'en bliver bedt om af kode på et højere niveau. Er det ikke nærmere i et af software niveauerne under "virussen" der bør laves et sikkerhedstjek?
For de her insrtuktionssæt bliver jo offentliggjort så software udviklere kan benytte sig af dem og desværre også folk med ikke så gode hensigter.
Så vidt jeg ved kan micro instructions kun lave simple beregninger og tjekke 2 tal i forhold til hinanden og yderligere så vidt min lille hjerne kan forstå det, så er det ikke nok til et sikkerhedstjek, men det kan også bare være min hjerne skulle udvides med lidt mere viden. 😀
Det vi snakker om, er at microcoden bare SLET IKKE skal tillade, at der skrives direkte ind ring 0 (i det har tilfælde så direkte til cachen), da dette udfra designbasen er "forbidden". Det skal slet ikke kunne lalde sig gøre, at skrive til MTR på den måde det er muligt her :)
#10
#9 - Skal lige forstå noget rigtigt her.... Er "virussen" skrevet i micro instructions?
Hvis det er sådan er det jo som du siger micro architectur'en der skal sørge for at der ikke tillades adgang til cachen for uvedkomne.
Jeg havde dog troet at det var gjort, blot på hardware niveau.
Hvis det er sådan er det jo som du siger micro architectur'en der skal sørge for at der ikke tillades adgang til cachen for uvedkomne.
Jeg havde dog troet at det var gjort, blot på hardware niveau.
#11
Jamen så er det da godt jeg køre vista... Jeg vil væde med at linux ville være lige så usikker som windows hvis der var lige så mange der brugte det.
Sikkerheden er der kun fordi at der ikke er så mange der bruger det og derfor ikke så mange der gider at lave skadelig kode til linux.
Sikkerheden er der kun fordi at der ikke er så mange der bruger det og derfor ikke så mange der gider at lave skadelig kode til linux.
#12
Hvad? Har jeg kigget forkert på kalenderen, det er da ikke d. 1 april i dag?
#13
#10 Kan ikke gøres, hvis kernen ikke tillader skriving via hul i microcoden til ring 0 layer. Dette attack er ikke skrevet til ring 0, men sådan så at det kan køre kode, der så kommer ind på layer 0 - og i dette tilfælde via cachen... Tidligere meget gamle tilfælde af sådanne lignende attacks/virus var lavet så de skrev sig ind, i DMI pool data på HDD'en, eller til chain loading via boot loader og derfor blev loadet ved OS loading ved boot.
Chernobyl virus har jeg selv haft i 1997. Og den virkede ved, at den skrev sig ind i filer og derpå enten den flashede din BIOS til en BIOS med ingenting i, eller overskrev harddisken med rene 0'er :| "It uses methods of jumping from processor ring 3 to 0 to hook system calls." "The payload, which is considered extremely dangerous, first involves the virus overwriting the first megabyte (1024KB) of the hard drive with zeroes, beginning at sector 0. This deletes the contents of the partition table, and may cause the machine to hang.
The second payload tries to write to the Flash BIOS. Due to what may be an unintended feature of this code, BIOSes that can be successfully written to by the virus have critical boot-time code replaced with junk."
Se det er en virus, der vil noget, ikke? Som 10.000-vis af mennesker sikkert vil sige, så må Chen Ing Hau fra Taiwan der skrev virussen, enten brænde i helvede, eller henrettes tidligt om morgenen ;)
Se link:
http://en.wikipedia.org/wiki/C...
Jeg var så "heldig" at den dag Chernobyl virussen udløste, da tændte jeg lige præcis, ikke for min PC :| Jeg fandt den først 3 måneder efter, da jeg fik et opdateret antivirusprogram fra en ven (det var før internettet nåede almindelige mennesker). Den er nok en af de mest onde vira jeg nogensinde har set :| Derfor vil jeg opfordre til, at alle læser historien på wikipedia, så de ved, hvad en virus virkelig kan gøre af stor skade.
Det er IKKE som du skriver microarchitecturen, da denne er på level 0 (hardware level, hardcoded), men på kernel ring 0, altså afvikles af hardwaren, men på ring 0 via den microcode der er i CPU'en. Microcoden kan du sammenligne med en slags BIOS for en CPU eller processor. Og der findes indtil flere CPU'er der kan programmeres via microcoden til, at kunne hvad end du beder dem om (som Transmeta's Crusoe CPU), eller til at rette på hardware fused fejl i CPU'en, som på Pentium 90, der havde et regneproblem under beregning af integer regnestykker, hvor den regnede direkte forkert, hvis disse overskred visse rammer Der var FPU-delen af CPU'en ramt af hardwarefel i dens design (floating point unit), hvis man badd den dividere tal. Og da ikke mange benyttede software der brugte denne funktion, vidste de ikke de var ramt af hardwarefejl.
"Many software packages, including many that do use floating-point numbers, don't actually use a computer's FPU. These packages don't show the error. Also, only certain numbers (whose binary representation show specific bit patterns) divide incorrectly. Consequently many users may never encounter the division error. The most famous example and the worst well-known case is 4195835/3145727, discovered by Tim Coe of Vitesse Semiconductors. The correct value is 1.33382 to 6 sig. figs, while the flawed Pentium's floating-point unit computed 1.33374 to 6 sig figs, a relative error of 0.006%. One can easily test a Pentium using Microsoft's Windows and this example: Use the Windows calculator in scientific mode to divide Coe's numbers and compare to the numbers above."
Se linket hér:
http://www.willamette.edu/~mja...
#11 Dette kan som jeg skrev også lade sig gøre på Windows, men der vil det være mere "besværligt, at skrive koden til dette, da bypass via kernel til MTR-registrene er mere kompleks.
Det er altså IKKE hardwaren der fejler, men den microcode der ligger i CPU'en der gør, at den kan bedes lave noget der er programmeringsmæssigt "ulovligt".
Chernobyl virus har jeg selv haft i 1997. Og den virkede ved, at den skrev sig ind i filer og derpå enten den flashede din BIOS til en BIOS med ingenting i, eller overskrev harddisken med rene 0'er :| "It uses methods of jumping from processor ring 3 to 0 to hook system calls." "The payload, which is considered extremely dangerous, first involves the virus overwriting the first megabyte (1024KB) of the hard drive with zeroes, beginning at sector 0. This deletes the contents of the partition table, and may cause the machine to hang.
The second payload tries to write to the Flash BIOS. Due to what may be an unintended feature of this code, BIOSes that can be successfully written to by the virus have critical boot-time code replaced with junk."
Se det er en virus, der vil noget, ikke? Som 10.000-vis af mennesker sikkert vil sige, så må Chen Ing Hau fra Taiwan der skrev virussen, enten brænde i helvede, eller henrettes tidligt om morgenen ;)
Se link:
http://en.wikipedia.org/wiki/C...
Jeg var så "heldig" at den dag Chernobyl virussen udløste, da tændte jeg lige præcis, ikke for min PC :| Jeg fandt den først 3 måneder efter, da jeg fik et opdateret antivirusprogram fra en ven (det var før internettet nåede almindelige mennesker). Den er nok en af de mest onde vira jeg nogensinde har set :| Derfor vil jeg opfordre til, at alle læser historien på wikipedia, så de ved, hvad en virus virkelig kan gøre af stor skade.
Det er IKKE som du skriver microarchitecturen, da denne er på level 0 (hardware level, hardcoded), men på kernel ring 0, altså afvikles af hardwaren, men på ring 0 via den microcode der er i CPU'en. Microcoden kan du sammenligne med en slags BIOS for en CPU eller processor. Og der findes indtil flere CPU'er der kan programmeres via microcoden til, at kunne hvad end du beder dem om (som Transmeta's Crusoe CPU), eller til at rette på hardware fused fejl i CPU'en, som på Pentium 90, der havde et regneproblem under beregning af integer regnestykker, hvor den regnede direkte forkert, hvis disse overskred visse rammer Der var FPU-delen af CPU'en ramt af hardwarefel i dens design (floating point unit), hvis man badd den dividere tal. Og da ikke mange benyttede software der brugte denne funktion, vidste de ikke de var ramt af hardwarefejl.
"Many software packages, including many that do use floating-point numbers, don't actually use a computer's FPU. These packages don't show the error. Also, only certain numbers (whose binary representation show specific bit patterns) divide incorrectly. Consequently many users may never encounter the division error. The most famous example and the worst well-known case is 4195835/3145727, discovered by Tim Coe of Vitesse Semiconductors. The correct value is 1.33382 to 6 sig. figs, while the flawed Pentium's floating-point unit computed 1.33374 to 6 sig figs, a relative error of 0.006%. One can easily test a Pentium using Microsoft's Windows and this example: Use the Windows calculator in scientific mode to divide Coe's numbers and compare to the numbers above."
Se linket hér:
http://www.willamette.edu/~mja...
#11 Dette kan som jeg skrev også lade sig gøre på Windows, men der vil det være mere "besværligt, at skrive koden til dette, da bypass via kernel til MTR-registrene er mere kompleks.
Det er altså IKKE hardwaren der fejler, men den microcode der ligger i CPU'en der gør, at den kan bedes lave noget der er programmeringsmæssigt "ulovligt".
#14
#13 - Det må du undskylde, jeg roder rundt i begreberne.
Jeg mente selvfølgelig at det burde være micro instructions sættet der burde lukke af for adgangen.
Det giver jo selvfølgelig god mening at du har adgang til stort set alle processer og procedure i CPU'en med micro instructions. Jeg forstår bare ikke hvordan man via micro instructions skulle kunne sortere i hvilket kode der godt må få adgang og hvilket der ikke må.
Man kan vel lave et sæt instruktioner til procedure i cachen, men er det nok?
Jeg mente selvfølgelig at det burde være micro instructions sættet der burde lukke af for adgangen.
Det giver jo selvfølgelig god mening at du har adgang til stort set alle processer og procedure i CPU'en med micro instructions. Jeg forstår bare ikke hvordan man via micro instructions skulle kunne sortere i hvilket kode der godt må få adgang og hvilket der ikke må.
Man kan vel lave et sæt instruktioner til procedure i cachen, men er det nok?
#15
Problemet er, at hullet i kernen og microcoden gør, at man i disse specifikke tilfælde kan få lov, at skrive direkte til MTR-registrene i CPU'en - og det er netop meningen, at man ikke på nogen måde skal kunne gøre dette. Det er alene kernen der har lov til via HAL at skrive og læse til cachen. Og det bør ikke kunne lade sig gøre - microcode eller operativsystem - at kunne udføre denne operation, rent teknisk på softwareplan, som applikation. Dette er en kombineret sikkerhedskompromittering - men som nævnt vil den også kunne lade sig udføre på Windows, Solaris, BeOS, BSD, eller hvad end OS du ønsker, om den udføres på den rigtige måde. Nogle steder vil dette givet bevirke, at man ænderer på kernens codebase, men det er ligeledes alene ladesiggørligt, fordi microcoden har et flaw, der tillader denne direkte skrivning/læsning.
Citat fra wikipedia:
"The microcode is normally written by the CPU engineer during the design phase. It is generally not meant to be visible or changeable by a normal programmer, nor even an assembly programmer. Unlike machine code which often retains backwards compatibility, microcode only runs on the exact CPU model for which it's designed. Microcode can be used to let one microarchitecture emulate another, usually more powerful, architecture."
Læs mere her, om baggrunden:
http://en.wikipedia.org/wiki/M...
Og du skal da ikke undskylde for noget Hessi - vi sidder her jo alle, for at lære nyt og mere hele tiden og ingen kan på guddommelig vís vide, eller forstå alt :) Normalt har jeg min gode ven der er low-level assembly programmør til, at forklare mig disse ting, da han programmerer diverse CPU'er og procesmaskiner i industrien :)
Og når jeg skriver, at det givet måske kan lade sig gøre på AMD og andre producenters CPU'er, så er det fordi de jo stort set alle licensierer teknologi til hinanden. AMD var først med en 64-bit arkitektur der kunne bruges mainstream og derfor købte Intel licens til x86-64 instruktionssættet, ligesom AMD har købt licens til, at bruge MMX. MMX2 og SSE. Intels egen måde, at lave 64-bit arkitektur er IA-64 der bruges i Itanium, som AMD netop IKKE har købt (eller fået lov at købe) licens til, at bruge :)
Citat fra wikipedia:
"The microcode is normally written by the CPU engineer during the design phase. It is generally not meant to be visible or changeable by a normal programmer, nor even an assembly programmer. Unlike machine code which often retains backwards compatibility, microcode only runs on the exact CPU model for which it's designed. Microcode can be used to let one microarchitecture emulate another, usually more powerful, architecture."
Læs mere her, om baggrunden:
http://en.wikipedia.org/wiki/M...
Og du skal da ikke undskylde for noget Hessi - vi sidder her jo alle, for at lære nyt og mere hele tiden og ingen kan på guddommelig vís vide, eller forstå alt :) Normalt har jeg min gode ven der er low-level assembly programmør til, at forklare mig disse ting, da han programmerer diverse CPU'er og procesmaskiner i industrien :)
Og når jeg skriver, at det givet måske kan lade sig gøre på AMD og andre producenters CPU'er, så er det fordi de jo stort set alle licensierer teknologi til hinanden. AMD var først med en 64-bit arkitektur der kunne bruges mainstream og derfor købte Intel licens til x86-64 instruktionssættet, ligesom AMD har købt licens til, at bruge MMX. MMX2 og SSE. Intels egen måde, at lave 64-bit arkitektur er IA-64 der bruges i Itanium, som AMD netop IKKE har købt (eller fået lov at købe) licens til, at bruge :)
#17
#15 - Er microcode ikke det samme som micro instructions?
Fordi jeg sidder bare og tænker at micro instructions bliver offentliggjort sådan at udviklere kan udvikle software dertil.
Og micro instructions er dem der styre hardwaren, altså hvilke bit skal flyttes hvor til og hvordan det skal bearbejdes, dermed også registrene. Det er selvfølgelig prædifineret hvordan det skal gøres og hvad der må gøres. Så må hullet vel være i den predifinition, altså den kan omgåes.
Jeg forstår bare ikke hvordan de kan få adgang, for det burde jo som sagt kun være muligt med de prædifinerede micro instructions/microcode, og disse har jo precedure sådan at der ikke bliver lavet noget forkert eller noget de ikke vil have der bliver gjort.
Undskyldningen var også ment som, undskyld forvirringen.
Fordi jeg sidder bare og tænker at micro instructions bliver offentliggjort sådan at udviklere kan udvikle software dertil.
Og micro instructions er dem der styre hardwaren, altså hvilke bit skal flyttes hvor til og hvordan det skal bearbejdes, dermed også registrene. Det er selvfølgelig prædifineret hvordan det skal gøres og hvad der må gøres. Så må hullet vel være i den predifinition, altså den kan omgåes.
Jeg forstår bare ikke hvordan de kan få adgang, for det burde jo som sagt kun være muligt med de prædifinerede micro instructions/microcode, og disse har jo precedure sådan at der ikke bliver lavet noget forkert eller noget de ikke vil have der bliver gjort.
Undskyldningen var også ment som, undskyld forvirringen.
#18
#17 Jeg fatter altstå heller ikke hvordan det kan lade sig gøre :)
#16 ups tastefejl kl. sent. Er rettet :)
#16 ups tastefejl kl. sent. Er rettet :)