Skyldes kæmpe sikkerhedshul Intel-chipfejl? "Nej, I skal bare læse manualen"
Bør chipproducenten Intel have røde ører? Eller burde softwarefirmaerne, der skriver programmer til Intels CPU'er, bare sætte sig ned og læse den forbandede manual til processorerne?
Det er spørgsmålet her en uge efter historien om et sikkerhedshul i styresystemer og virtualiseringsløsninger, som i første omgang så ud til at kunne give hackere fuld kontrol med Intel-baserede servere, næsten uanset hvilket styresystem der kører på dem.
Advarslen blev blandt andet brølet ud fra hustagene af den amerikanske it-varslingstjeneste US-CERT, men blev siden nedtonet, efterhånden som flere firmaer meldte hus forbi eller kunne fremvise sikkerhedsopdateringer til kunderne.
Tjenesten havde firmaer som Microsoft, virtualiseringsfirmaet Citrix og serverstyresystemet FreeBSD med på listen over sårbare styresystemer eller hypervisorer, der angiveligt skyldtes en usikker instruktion i 64-bit CPU'er fra Intel, men ikke fra konkurrenten AMD.
Sårbarheden kunne i værste fald udnyttes til at springe fra den virtuelle maskine og videre til at få systemadgang på værtsmaskinen.
Siden har blandt andet Citrix annonceret patches til flere af selskabets virtualiseringsprodukter, og det samme har Microsoft gjort til selskabets 64-bit Windows-udgaver, dog fraregnet Windows 8 og Windows Server 2012, der ikke er ramt. Microsoft har også understreget, at selskabets virtualiseringsplatform, Hyper-V, ikke er påvirket af sårbarheden.
Men skyldes problemet så sjusk fra softwareleverandørernes side? Eller er der tale om en fejl i Intels CPU'er, som programmører dermed uforvarende kommer til føre med over i deres software?
Spørger man Version2-blogger og FreeBSD-udvikler Poul-Henning Kamp, er Intel ganske enkelt sluppet for let i den konkrete sag.
Intel burde holde sig til forbilledet
Sårbarheden udspringer af instruktionen med navnet SYSRET fra AMD's 64-bit processorarkitektur x86-64, som Intel for år tilbage kort fortalt fik lov at implementere i sine egne processorer mod til gengæld at bytte nogle instruktioner den anden vej.
Ifølge kritikerne er problemet, at Intels fejlhåndtering til SYSRET-instruktionen er implementeret med en lille, men afgørende nuance i forhold til AMD's version. Og det er her, det kan ende galt.
»Instruktionerne er defineret af AMD, og derfor er AMD's implementeringer per definition referencen for alle spørgsmål, som AMD's dokumentation ikke måtte afklare,« skriver Poul-Henning Kamp i en e-mail til Version2.
»Hvis Intels CPU'er opfører sig anderledes end AMD's, er de ikke 100 procent kompatible, og så er det egentlig ligegyldigt, hvad de måtte skrive i deres dokumentation (til arkitekturen, red.),« forklarer han.
Nogenlunde samme konklusion når man frem til hos folkene bag open source-virtualiseringsprojektet Xen, der også var blandt de sårbare softwareprodukter:
»Instruktionen blev defineret af AMD som en del af x86-64-arkitekturen, og Intels version er tydeligvis lavet til at være kompatibel med AMD's version,« lyder det i et længere blogindlæg om sagen fra Xen.
»Hvis størstedelen af styresystemerne derude uafhængigt af hinanden ikke har håndteret det ordentligt, er det ikke svært at konkludere, at Intel har begået en fejl i designet af specifikationen.«
Intel har i en kort udtalelse til internationale medier henvist til sin egen udviklermanual til 64-bit-processorerne og peget på de to sider, der dokumenterer SYSRET-instruktionen.
Intel: Ikke en fejl i vores produkt
Da Version2 fanger en af Intels specialister på telefonen, er holdningen stadig den, at Intel er uden skyld i sagen.
»Vi kommenterer normalt ikke på ting, der ikke har noget med vores egne produkter at gøre,« indleder Technology Specialist hos Intel i Norden Jan Östling, da Version2 spørger ham om Intels rolle i sagen.
Den amerikanske sikkerhedstjeneste US-CERT kalder SYSRETs opførsel på Intel-processorer for 'unsafe'. Er Intel enig i den udlægning?
»Jeg er ikke enig i brugen af ordet unsafe. Der er tale om softwareimplementeringer, som ikke tager højde for adfærden af vores teknologier i deres kode,« siger Jan Östling til Version2.
Men problemet gør sig jo ikke gældende for jeres konkurrent AMD. Siger det ikke noget om, at SYSRET's adfærd på jeres platform er uhensigtsmæssig?
»Jeg kan kun sige, at vi har en specifikation til vores produkt, og så er der nogen leverandører, som har skrevet software, der ikke tager højde for det. Dokumentationen har været tilgængelig fra dag ét, og den viser tydeligt, hvordan instruktionen fungerer,« siger Jan Östling til Version2.
»Man kan godt få den tanke, at mange softwareleverandører ikke har læst manualen igennem,« tilføjer han.
Hvorfor har Intel oprindeligt valgt at implementere SYSRET på en anden måde end AMD?
»Den information ligger jeg ikke inde med,« siger Jan Östling.
»Men vi anbefaler alle vores kunder at have en tæt dialog med softwareleverandørerne, når det handler om at holde softwaren opdateret og følge best practices på sikkerhedsområdet,« siger han.
Konsulenthus: Intel har sit på det tørre
Hos det danske konsulenthus Platon Infrastructure bakker teknologidirektør Michael Frandsen op om Intels udlægning af sagen.
»Jeg synes ikke, at man kan klandre Intel for det her. Uanset hvad er der tale om kode, der gør noget med CPU'en, som ikke er meningen. Intel siger selv i dokumentationen, at hvis man vil bruge instruktionen på en anden måde end beskrevet, så skal man gøre CPU'en opmærksom på det. Ellers får det konsekvenser,« siger Michael Frandsen til Version2.
Virtualiseringsfirmaet VMware var blandt den lille gruppe selskaber, der stod angivet som upåvirkede af sårbarheden på den oprindelige liste fra US-CERT.
Forklaringen er enkel:
»Vi benytter ikke den funktionalitet i Intels CPU'er, og derfor er vi ikke ramt. Derudover har vi ingen kommentarer,« siger VMwares tekniske chef i Norden, Robin Prudholm, til Version2.
Kommentarer (18)
Forskellen er jo ret subtil (læste om det i Xen-bloggen), men den måde det er implementeret på hos Intel er stærkt uhensigtsmæssig uanset om man har læst manualen eller ej; den tvinger dig til at lave et ekstra tjek hver gang, fordi opførslen ellers er grundlæggende usikker.
Det kan godt være deres dokumentation er i tråd med opførslen, men i så fald er opførslen bare dårligt design.
-
7 -
0
Hvis processoren skal være bagud kompatibel, så må kræves, at eksisterende operativsystemer kan køre med processoren, uden at nye indstruktioner, giver anledning til sikkerhedsrisici. Ellers, bør processoren direkte sælges med advarsel imod, at køre på ældre operativsystemer.
En ny indstruktion, bør ikke give mulighed for, at et program kan skifte til systemtilstand, og overlade denne tilstand til brugeren.
Normalt bør et skift til systemtilstand, kun kunne ske, ved at operativsystemet samtidigt overtager, og det skal ske på en måde, så der ikke er risiko, uanset at det kører på et gammelt operativsystem, hvis denne er implementeret korrekt.
Hvis den nye indstruktion, kan medføre et sikkerhedshul på eksisterende operativsystemer, så lyder det som en forkert implementering fra Intel. Processoren, er i så fald, ikke fuldt bagud kompatibel, og bør forsynes med advarsel om at den indeholdere et sikkerhedshul der kan give hackere fri adgang, hvis den bruges på et ældre operativsystem - eller, måske rettere, et ikke intel godkendt operativsystem.
Naturligvis, kan man ikke bare skrive dokumentere sig ud af problemet, ved at nævne det, i en teknisk manual. Et sikkerhedsproblem indført på grund af nye indstruktioner, er så alvorligt, at det skal stå på en advarsel sammen med CPU'en, og der skal beskrives, hvordan brugeren kan sikre sig, at der ikke er en risiko. Her vil sandsynligvis være nødvendigt, at direkte beskrive hvilke operativsystemer, som CPU'en er sikker sammen med, da at alle nye operativsystemer, ikke nødvendigvis får lukket hullet, selvom de er fuldt opdateret.
-
0
-
0
Findes et detaljeret kodeeksempel på, hvordan fejlen introduceres i praksis?
-
0
-
1
Hvis den nye indstruktion, kan medføre et sikkerhedshul på eksisterende operativsystemer, så lyder det som en forkert implementering fra Intel. Processoren, er i så fald, ikke fuldt bagud kompatibel
Det er der trods alt ikke tale om; instruktionen er ny og er en del af "Intel 64" som er Intels 64bit extension. Den er næsten, men altså ikke helt, kompatibel med Amd64, som er AMDs ditto.
Man må erkende at der er små forskelle på Amd64 og Intel 64. Det her er så en af de mere subtile, hvor Intels implementation er ret dårlig, men der har vist hele tiden været forskelle man skulle tage højde for.
-
0
-
1
AMD har ikke udviklet et 64 bit isa. Det er intels x86 instruktionssæt som AMD har UDVIDET til 64 bit. Derfor kan AMD ikke lovligt tage ejerskab over x64. Intel kalder det derfor intel64 for at understrege ejerskabet. Det har været til stede i alle Intel pentium 4 CPU'er siden Nocona modellen fra 2004, men har ikke været enabled i alle modeller, hvilket ledte visse til at tro, det ikke eksisterede på Intel siden. Dvs. AMD og Intel introducerede samme x64 næsten samtidigt. Intel havde to alternative 64 bit instruktionssæt ud over x64, men Microsoft valgte sidstnævnte og det tog Intel til efterretning.
se f.eks.:http://en.wikipedia.org/wiki/Xeon
-
1
-
19
AMD har ikke udviklet et 64 bit isa. Det er intels x86 instruktionssæt som AMD har UDVIDET til 64 bit.
Enten er du igang med bevidst historieforfalskning, eller også har du drukket for meget Intel-sodavand.
Intel havde travlt med at proppe Itanic ned i halsen på alle og enhver, selvom den performede lort i forhold til f.eks de tilsvarende Power, Precision og Alpha chips.
Spurgt igen og igen om der kom en '64bit x86' var Intels svar et rungende & kategorisk NEJ.
Så smed AMD "Hammer" på markedet, med et instruktionsæt de havde defineret og trods alt hvad Intel kunne og gjorde, flokkedes brugerne til en 64bit arkitektur der bla. havde den fordel at man vidste hvordan man skrev compilere til den.
En af de ting Intel gjorde, var at læne sig meget kraftigt op ad Microsoft for at undgå at der kom en 64-bit windows, men Microsoft følte servermarkedet kigge lidt for interesseret på 64-bit UNIX og begyndte fodslæbende at lave 64 bit Windows.
Det fik Intel til at overgive sig og efter hårdnakket at have benægtet alt i gennem længere tid, blev de taget med bukserne nede og en AMD64 compatibel mode i en af deres x86 chips, ca. 6 måneder før de havde tænkt sig at annoncere noget om det.
Intel klonede AMDs instruktionssæt men de gør alt hvad de kan for at undgå at det bliver sagt i så klare ord.
SYSRET fejlen er helt klart en inkompatibilitet og derfor er det en fejl i Intels cpuer, uanset om de har skrevet i manualen hvorledes de dummede sig.
-
30
-
3
Det fik Intel til at overgive sig og efter hårdnakket at have benægtet alt i gennem længere tid, blev de taget med bukserne nede og en AMD64 compatibel mode i en af deres x86 chips, ca. 6 måneder før de havde tænkt sig at annoncere noget om det. Intel klonede AMDs instruktionssæt men de gør alt hvad de kan for at undgå at det bliver sagt i så klare ord.
Der er faktisk en række mindre forskelle[1], så det ikke engang en ren klon, selv uden SYSRET-problematikken. Det skal jo nødig være for nemt :p.
[1] http://en.wikipedia.org/wiki/X86-64#Differences_between_AMD64_and_Intel_64
-
0
-
1
Nej, Poul-Henning Kamp, det er DIG der historieforfalsker. Jeg har intet med Intel at gøre. Selv Linus Torvalds er enig i min fremlægning af begivenhederne. SPØRG HAM. Læs på din lektie inden du fremsætter injurierende beskyldninger der er ubeviselige.
Punkt 1. Intel har ALDRIG sagt der ikke ville komme nogen x64 CPU. Fremlæg venligst bevis for din påstand.
Punkt 2. Intel sagde de stod 100% bag Itanium, for at folk ikke skulle flygte fra den. Det har intet med punkt 1 at gøre.
Punkt 3 Ifølge Intel havde de arbejdet med 64 bit X86 i FEM ÅR før de sendte Prescott/Nocona på markedet. Modbevis venligst dette.
-
2
-
13
Ad. 1 & 2: Intel sagde meget klart at der ikke kom nogen anden 64 bit platform end Itanic fra deres hånd og de flippede helt ud da Sun kastede sig over AMD's "Sledgehammer" osv. Det er veldokumenteret, der er ingen grund til at opfinde nyt spin om det, når vi har alt Intels orginale spin i f.eks The Registers arkiver.
Ad 3: Ja, det er næsten rigtigt men det er nu kun fire år:
Sledgehammer blev annonceret i august 2000.
Rygterne om at Intels Yamhill ville have AMD64 instruktioner begyndte at sprede sig i 2002
I August 2004 begyndte samples af Nocona Xeon med 64 bit instruktioner at dukke op.
-
13
-
2
Aha, Poul-Henning, jeg læste faktisk The Register den gang. Hvem sagde at der ikke kom nogen 64 bit platform end Itanium? Citater tak. Det var kun Intels chef for Server divisionen med ansvar for Itanium, der ikke ville be- eller afkræfte 64 bit x86, men sagde man var 100% bag Itanium. Selvfølgeligt ville han sige det. Noget AMD udnyttede i propaganda til den påstand du gør dig til djævlens advokat for.
Der er ingen grund til at bruge The Registers gætterier fra før 2004. Brug hellere konkrete informationer EFTER intels fulde forklaring angående forløbet fra efter 2004.
Iøvrigt bekræfter du mig og modsiger dig selv ved at nævne, at Intel havde teknologien parat FØR AMD shippede deres første Athlon 64 i 2003. Der har aldrig været en periode, hvor AMD har kunnet udkonkurrere Itanium med x64. Om noget har Intel selv udkonkurreret Itanium. Dette kan ikke undre nogen da Itanium er HP's baby, som "nogen" hos Intel kunne lide - andre ikke.
Hele sagen har blot været en gang politisk studehandel bag lukkede døre som i virkeligheden blot afslører én ting. Nemlig at Microsoft har udnyttet konkurrencen mellem AMD og Intel til at styre showet efter deres eget hoved.
Så jeg tilgiver dig Poul-Henning. Jeg ved, hvem der har hjernevasket dig og hvorfor.
-
2
-
17
Tomas:
Hvis du har skyggen af bevis for at Intel arbejdede på en anden 64bit platform end Itanic inden August 2000 skal du være velkommen til at komme frem med dem.
Det er dig der påstår existensen af noget sådant og derfor dig der har bevisbyrden.
I alle andre tilfælde er den her diskssion ovre for mit vedkommende.
-
15
-
3
@Tomas Kjersgaard
Punkt 1. Intel har ALDRIG sagt der ikke ville komme nogen x64 CPU. Fremlæg venligst bevis for din påstand.
Nej, det har de måske ikke sagt - men de har sagt at 64-bit var for servere - ikke for mainstream. Skal jeg finde de 10 første citater til dig?
Intel sagde de stod 100% bag Itanium ... dermed afviser man på serversiden indirekte AMD64 - og så kan man vel godt konkludere at de rent faktisk generelt afviste AMD64 - eller?
Jeg har ikke forstået hvad du kom med i denne tråd, der rent faktisk var on-topic og ikke blot et hovedløst forsvar af et firma, som du har et fan-forhold til.
-
11
-
0
PS:
Punkt 1. Intel har ALDRIG sagt der ikke ville komme nogen x64 CPU. Fremlæg venligst bevis for din påstand.
Det kunne ellers godt lyde sådan her:
http://www.theinquirer.net/inquirer/news/1008689/intel-wont-produce-amd-...
-
7
-
0
@Tomas Kjersgaard - hvis du ikke vil ligne en amatør, er det åndsvagt at himle op og kræve dokumentation, der modbeviser dine påstande. Hvis du faktisk har ret, er det meget mere ræson i at fremlægge dokumentation der enten bakker dine egne påstande op eller modsiger det du anfægter.
Skingre postulater som nedenstående, får dig bare til at ligne en forurettet teenager.
Nej, Poul-Henning Kamp, det er DIG der historieforfalsker. Jeg har intet med Intel at gøre. Selv Linus Torvalds er enig i min fremlægning af begivenhederne. SPØRG HAM.
-
5
-
0
...hvis de indrømmede at de har lavet en noget så gebommerlig fejl, i stedet for at prøve at bortforklare sig. Fanboys kan sige hvad de vil, men PHK siger det nydeligt med Helt enig det er simpelthen for dumt at tage trap'en i den (halve) context.
Ikke at AMD er perfekt, de har haft en stribe hyggelige cpu og chipsæt bugs - men hypervisor breakout? Ups, Intel, ups.
-
6
-
0
specifikt kan det være nok så stor en "designfejl", men det vil i mine øjne ikke være ansvarspådragende når de har dokumenteret forholdet, og det kan slet ikke ansvarsfritage software-udviklerne. Jeg har selv AMD cpu og radeon, og min næste cpu vil også være AMD. Så jeg er ikke Intel fan.
-
0
-
4
specifikt kan det være nok så stor en "designfejl", men det vil i mine øjne ikke være ansvarspådragende når de har dokumenteret forholdet, og det kan slet ikke
Problemet er blot, at når man vælger, at implementere et instruktiossæt, så skal det også implementeres. Hvis man vælger, at lave afvigelser fra referenceimplementeringen, så er det ikke længere det instruktionssæt, som man påstår, at have implementeret.
Du kan heller ikke påstå, at have lavet et PCI-kort hvis det ikke passer i et PCI-reference-bundkort, uanset hvad du vælger at skrive i dokumentationen.
Implementerer du en standard, så implementerer du hele standarden. Det er alt eller intet. Hvis du ikke implementerer hele standarden, så må du ikke give udtryk for, at du har implementeret hele standarden, uanset hvad du skriver i din dokumentation.
-
5
-
0
Tilføj kommentar
