Sikkerhedsforsker advarer: Forvent ondsindet Spectre-malware inden for et år

Kan moderne multicore CPU'er mon hjælpe. Hvis man isolerer en CPU kerne til usikre elementer, så burde muren mellem forskellige tasks blive bedre.

Men det kommer selvfølgelig med en cost.

Apple styrer hele processen både med hardware og software, således at alle chips, hukommelse, drivere med videre. F.eks. har Apple to features specifikt til Apple;

Apple har ikke designet de centrale dele af CPU'en. Det er stadigvæk en ARM processor og dermed har den de samme problemer omkring caching og speculative execution som andre ARM processorer. Det man kan håbe er at ARM har lært af misæren og fikset evt. problemer.

Kigger vi på harddisken så benytter Apple algoritmen AES-XTS til datakryptering.

Nu citerer du vist Apples marketing materiale. Du mangler bare at skrive at krypteringen er magisk. AES er en standard algoritme. XTS er en standardmetode for brug at krypteringsalgoritmer. Det store problemer med kryptering er ikke algoritmer ... problemet er hvor man gemmer krypteringsnøglerne. Og med mindre du render rundt og husker en 256-bit krypteringsnøgle i hovedet og taster den ind hver gang computeren starter så er krypteringsnøglerne den store svaghed ved systemet.

Og til opbevaring af nøgler, passwords mv. benyttes en hjælpeprocessor kaldet T2 Secure Enclave.

Den magiske T2 Secure Enclave er vist den rigtige betegnelse. Lignende foranstaltninger findes på Intel og AMD platforme. Problemet omkring Apples setup er at der er meget lidt dokumentation. I praksis betyder det: stol på Apple ... ikke nogen god ide når der er folk på nettet der fortæller at sikkerheden i T2 er brudt. Nøglerne til harddisk kryptering gemmes i øvrigt i T2.

Jeg tror vi skal være enige om at være uenige – for jeg tror forsat ikke på at du bare kan anvende Spectre og Meltdown – sådan bare uden videre med Apple M1 chip.

Jeg er faktisk enig med dig i at der er en stor sandsynlighed for at M1 og de omkringliggende chips er fikset. Vi ved det bare ikke for Apple fortæller os ikke noget. Og indtil nu er det eneste du er kommet med tro og håb på Apple's kompetencer uden den mindste argumentation. Det er ikke særligt ingeniøragtigt.

En mere interessant angrebsflade er nok cloud-servere ... bruge en browser som adgang til at hærge og kræve løsepenge, er nok lidt for svært i forhold til udbyttet.

Hvis du skal bruge egne cloudservere så betaler du for CPU forbrug. Der er også ret stor sandsynlighed for at de andre ting der kører på serveren ikke er specielt interessante. Den kombination er måske det der redder cloud. Mht. browser hacking, så betaler brugeren selv for det ekstra strømforbrug hackeren bruger. Og hackeren kan inficere maskinen og stjæle netbank koder, crypto-currency wallets, etc. Der skal ikke meget til før det giver overskud.

Fejlen er svjv ikke "arkitektur specifik" men "koncept specifik

Apple styrer hele processen både med hardware og software, således at alle chips, hukommelse, drivere med videre. F.eks. har Apple to features specifikt til Apple;

Kigger vi på harddisken så benytter Apple algoritmen AES-XTS til datakryptering.

Og til opbevaring af nøgler, passwords mv. benyttes en hjælpeprocessor kaldet T2 Secure Enclave.

Jeg tror vi skal være enige om at være uenige – for jeg tror forsat ikke på at du bare kan anvende Spectre og Meltdown – sådan bare uden videre med Apple M1 chip.

Og ja, det vil med tiden blive hacket ligesom alt muligt andet.

Problemet opstår primært fordi man tager kode fra tilfældige internet sites og eksekverer lokalt. Basalt set er browseren turing complete og brugeren kører kode han intet kender til på denne turing maskine. Spectre eller ej ... det er i praksis at bede om problemer.</p>
<p>Mere grundlæggende er problemet manglende "defence in depth". To processer der kører på en CPU er kun adskilt af en papir tynd beskyttelsesmekanisme (MMU'en, m.m.). Spectre viser at MMU'ens beskyttelse ikke ydede 100% beskyttelse og så falder det hele sammen. Det havde det ikke gjort hvis man havde haft et eller to ekstra lag af beskyttelse.

At bruge en browser som adgang til at hærge og kræve løsepenge, er nok lidt for svært i forhold til udbyttet. Men jeg er ikke inden for "branchen".

Fejlen er svjv ikke "arkitektur specifik" men "koncept specifik", jeg mener at have læst at mindst en version af ARM er ramt af en af de sårbarheder.

Jo ... men man kan fikse meget hvis man erkender at det er et samarbejde mellem OS og CPU. Hvis man fx. slet ikke mappede anden memory end den processen havde adgang til så var en del af problemet væk. Så skulle OS'et skifte memory mapping hver gang man ramte kernen ... måske kunne man så have to mapping roots (en for user space og en for kernen). Måske kunne kernen markere visse pages som "non cacheable". Måske kunne man skille datacachen i to: en stor userspace cache og en lille kernelcache.

Listen er alenlang med muligheder som ikke behøver koste så meget på performance og hvor Apple har det nemmere end Intel/AMD fordi Apple ingen historik har omkring M1 og i øvrigt plejer at være ret nonchalante omkring bagud kompatibilitet. Intel/AMD/Microsoft har lovet folk at deres 30 år gamle kode stadigvæk kører fint (og det er jeg glad for). Apple not so much.

er baseret på ARM arkitektur og ikke på Intels. Så Apple M1 er formentlig fri for denne fejl (i øjeblikket).

Det handler netop ikke om arkitektur, men om at hente data ud af hukommelsen, så alle CPU'er med cache prefetching er udsat.

At udvikle en ny processor som formentlig koster milliarder USD uden at skelne til af eksisterende hacks og herunder eksisterende processorer.... er noget jeg ikke tror at Apple begiver sig ud i.

Jeg har arbejdet i 20+ år for virksomheder for virksomheder med op til 250.000 ansatte og i hvert eneste projektmøde bliver trusler imod projektet (indre og ydre) gennemgået.

Jeg finder det helt usandsynligt at projektet ikke betragter eksisterende hacks eller eksisterende processorer som en trussel.

Du er bare nødt til at tro mig når jeg siger, at de mennesker som bevilliger X milliarder USD – de har rundsave på albuer, skulder, hofte, knæ, fødder, hænder og hovedet. Og de slår til øjeblikkeligt hvis ikke du kan levere varen.

Jeg ville nødig sidde som ansvarlig projektleder på et milliarddyrt processorprojekt, hvor en skoleknægt siger at ”Kejseren ikke har noget tøj på” for man kan bare udlæse hukommelsen.

Selvfølgelig er der lavet ekstra sikkerhed hvor man f.eks. opdeler hukommelse i almindelig hukommelse og særlig beskyttet hukommelse, kryptering, certifikater og lignende indbygget i direkte i hardwaren.

Jeg siger ikke at det er superavanceret eller at det ikke kan hackes – men hardwaren i motherboardet skal jo ændres alligevel, for at få den nye processor til at fungerer.

Eller måske træde et skridt tilbage, og "genopfinde" browseren til det den oprindelig var tiltænkt, nemlig rendering af HTML - og skal der så endelig eksekveres Javascript må det ikke kunne ske cross-site.

Ja ... men det er vist en større opgave. Men i øvrigt har muligheden for at køre JavaScript været afgørende for at rykke brugerinterfaces til rent browserbaserede løsninger. Uden turing maskinen risikerer man at låse sig fast i det UI paradigme der var førende da man låste standarden. Jeg ville nødig tilbage til 1993 da jeg først kørte Mozilla eller til det paradigme som Java definerede omkring år 2000.

Det handler netop ikke om arkitektur, men om at hente data ud af hukommelsen, så alle CPU'er med cache prefetching er udsat.

Ja, men ikke alt spekulative execution+prefetching er problematisk. Det er kun når man krydser security boundaries at der bliver problemer. Det kunne godt udnyttes bedre i moderne operativsystemer. Problemet har selvfølgeligt været at Intel, AMD m.fl. har sagt: Stol på os - MMU'en håndterer beskyttelsen.

er baseret på ARM arkitektur og ikke på Intels. Så Apple M1 er formentlig fri for denne fejl (i øjeblikket).

Det handler netop ikke om arkitektur, men om at hente data ud af hukommelsen, så alle CPU'er med cache prefetching er udsat.

Hvis det var tilfældet, så ville Apple helt klart slå på tromme for det

Faldt tilfældigvis over en artikel, hvor de skriver at M1 også er åben for angreb: https://www.zdnet.com/article/google-this-spectre-proof-of-concept-shows-how-dangerous-these-attacks-can-be/

Den "simple" måde at beskytte mod browser baserede angreb er at flytte browseren ud af brugerens computer.

Apple's M1

Dermed ikke sagt at der ikke findes andre sikkerhedshuller, men mon ikke der går lidt tid før de bliver fundet og udnyttet?

Ganske enkelt fordi hackere først skal lærer den arkitektur og de sikkerhedsmekanismer som Apple har fået indbygget.

Og Apple lancerer jo sig selv som et firma som tager sikkerhed alvorligt - så mon ikke det har været et krav at kendte sikkerhedshuller blev lukket?

Dernæst er der jo "økonomien i hacket". Hvis det er en meget lille andel af alle processorer på markedet, så er det begrænset med økonomien i at sælge/udvikle hacks.

KIgger man på Zerodium så er det endnu ikke kommet op som "efterspørgsel".

Og kigger man på priserne hos Zerodium, så bør man huske at efterspørgsel er den primære prisdriver og ikke hvor svært eller sikkert et produkt er.

...om nye CPU'er som f.eks. Apple's M1 har fået fjernet hullet.

Hvis det var tilfældet, så ville Apple helt klart slå på tromme for det - men det vil være også betyde at deres CPU vil være langsommere - så det vil ikke være et godt salgsargument - for hele problemet ligger i et modstridende krav om at være så sikker og samtidig så hurtig som muligt - hvilket (indtil videre) bl.a. kun kan løses ved at "læse forud" og derved opstår problemet, da denne læsning fra hukommelsen kan afsløre ting.

Problemet opstår primært fordi man tager kode fra tilfældige internet sites og eksekverer lokalt. Basalt set er browseren turing complete og brugeren kører kode han intet kender til på denne turing maskine. Spectre eller ej ... det er i praksis at bede om problemer.

Mere grundlæggende er problemet manglende "defence in depth". To processer der kører på en CPU er kun adskilt af en papir tynd beskyttelsesmekanisme (MMU'en, m.m.). Spectre viser at MMU'ens beskyttelse ikke ydede 100% beskyttelse og så falder det hele sammen. Det havde det ikke gjort hvis man havde haft et eller to ekstra lag af beskyttelse.

Den "simple" måde at beskytte mod browser baserede angreb er at flytte browseren ud af brugerens computer. Såfremt man havde servere i DMZ der stod for eksekveringen af kode i browseren og at browseren kommunikerede med brugerens computer gennem en RDP lignende protocol (en protocol der ikke er turing complete), så ville angrebet have begrænset effekt. Der findes produkter der kan netop dette.

Der er selvfølgeligt andre situation hvor man ønsker "privacy" mellem processer på brugerens computer. Til disse findes mere elelr mindre perfekte løsninger men hvis man til at starte med blot holder fremmed kode ude så har man en rigtig god start.

Cloud computing er en helt anden sag. Der synes beskyttelsen primært at ligge i at der sandsynligvis ikke er noget vigtigt der er værd at spilde CPU ressoucer på på samme cloud-CPU som malwaren kører på ... uha!

...om nye CPU'er som f.eks. Apple's M1 har fået fjernet hullet.