Architectuurfout in oudere x86-cpu's Intel maakt rootkit mogelijk - update

Een ontwerpfout in x86-cpu's van Intel van enkele jaren oud maakt het mogelijk om vanuit een proces met administratieve gebruikersrechten vergaande toegang te krijgen tot een systeem. Dat maakt rootkits mogelijk die nooit kunnen worden gedetecteerd. Nieuwere cpu's zijn niet getroffen.

De ontwerpfout maakt het mogelijk om vanuit een proces met administratieve rechten door te breken tot system management mode, de diepste laag waarin x86-cpu's kunnen opereren. Dat maakte beveiligingsonderzoeker Christopher Domas bekend op de Black Hat-beveiligingsconferentie in Las Vegas. Intel heeft het probleem opgelost in Core i-cpu's sinds 2011 (Sandy Bridge en later) en Atom-cpu's sinds 2013. "Intel was het iets eerder op het spoor dan ik", aldus Domas, die echter benadrukt dat nog steeds 'honderden miljoenen' apparaten kwetsbaar zijn. Mogelijk zijn ook cpu's van AMD kwetsbaar, maar dat heeft Domas niet onderzocht.

Normaal kan het besturingssysteem niet bij smm, omdat die modus een eigen deel van het geheugen gebruikt dat niet door het besturingssysteem te beschrijven is. Door een ongerelateerde feature die Intel twintig jaar geleden toevoegde vanwege compatibiliteit met oudere systemen, kan vanuit het besturingssysteem toch toegang worden verkregen tot dit zogenoemde smram.

System management mode is oorspronkelijk ingebouwd voor energiebeheer, maar heeft inmiddels tal van functionaliteit aan boord. Zo is de trusted platform module, waar encryptiesleutels in kunnen worden opgeslagen, in smm ondergebracht. Het besturingssysteem kan niet zien wat er op het niveau van smm gebeurt, en ook voor eventuele hypervisors is dat onzichtbaar, wat smm een perfecte plek maakt om er malware in onder te brengen. Ook secure boot wordt door smm geregeld.

Tijdens zijn presentatie toonde Domas hoe hij dankzij de ontwerpfout - die geen bug is, benadrukt de onderzoeker - root kon krijgen op een Linux-systeem, maar de fout werkt ook op andere besturingssystemen, omdat het om een fysieke ontwerpfout in de processor gaat. Een aanvaller zou verder een rootkit kunnen installeren die onzichtbaar is voor het besturingssysteem en aanwezig blijft als een besturingssysteem opnieuw wordt geïnstalleerd. In theorie zou een aanvaller zelfs een kwetsbare laptop in brand kunnen laten vliegen, omdat smm over het energiebeheer gaat, stelt Domas.

Voor een geslaagde aanval zou een aanvaller wel eerst code moeten kunnen uitvoeren op een systeem. Dat kan bijvoorbeeld door een gebruiker ertoe te verleiden om een programma uit te voeren, maar ook kunnen kwetsbaarheden in programma's worden misbruikt. Vooral als gebruikers beveiligingsupdates vergeten te installeren, is dat een realistisch probleem. Ook moet de gebruiker rootrechten kunnen verkrijgen; daarvoor zal een andere exploit moeten worden gebruikt.

De fout bevindt zich in code die ooit is gebouwd voor de advanced programmable interrupt controller, een deel van een x86-cpu dat inmiddels niet meer wordt gebouwd. De apic besloeg een deel van het geheugen dat op eerdere cpu's voor andere doeleinden werd gebruikt. Om problemen met oudere cpu's te voorkomen, werd een feature ingebouwd om apic naar een ander adres in het geheugen te verplaatsen.

Hoewel de apic inmiddels geen zelfstandig onderdeel meer is van een x86-cpu, is de legacycode van Intel nog steeds aanwezig, en kan die code worden gebruikt om eigen instructies in te laden in system management mode. Dat kan met slechts acht instructies, benadrukt Domas.

"De enige manier om het probleem volledig op te lossen, is het uitbrengen van een nieuwe cpu", aldus Domas; firmware-updates zijn volgens hem mosterd na de maaltijd, omdat een gebruiker dan al geïnfecteerd kan zijn. Inmiddels heeft Intel al een nieuwe versie uitgebracht. Volgens Domas is het de tweede kwetsbaarheid die in x86-cpu's zelf is gevonden. "Maar ik denk dat er nog meer problemen zijn", stelt hij. De x86-architectuur bevat namelijk veertig jaar aan legacy en is ontzettend ingewikkeld.

Update, 03:18: In dit artikel stond aanvankelijk dat een proces met normale rechten de fout kan exploiteren. Een proces moet echter administratieve rechten hebben. Het artikel is hierop aangepast.

Reacties (111)

[Rudie_V]

Misschien is dit in detail anders, maar dit is toch al eerder voorbij gekomen?
2008: http://phrack.org/issues/65/7.html
2009: http://theinvisiblethings...memory-via-intel-cpu.html
2009: http://www.networkworld.c...to-be-posted-3-19-09.html
2009: http://olzakonsecurity.co...-pondering-intels-apathy/
2014: http://resources.infoseci...mode-malware-deitybounce/
2015: http://www.slideshare.net...ption-from-sandbox-to-smm
http://lmgtfy.com/?q=cpu+smm+hack

[Tribits]

Dan blijft bij mij vooral de vraag waarom dergelijke exploits niet massaal in het wild voorkomen, wat voor zover mij bekend niet het geval is. Het verkrijgen van 'root' op een terminal server of een Linux box zou bijvoorbeeld een behoorlijke impact hebben en het zou denk ik toch wel bekend zijn als hier gangbare exploits voor bestonden. Zoals ik het zie zijn er twee mogelijke antwoorden op die vraag: de vulnerabilities die tot nu bekend werden zijn niet praktisch bruikbaar en deze wel of deze vulnerability is net als de rest om de een of andere reden niet praktisch inzetbaar. Zonder die informatie is het niet mogelijk te bepalen of we hier te maken hebben met een theoretisch probleem of een potentiele ramp.

[Rudie_V]

Goede vraag. In de update van het artikel staat dat je wel root/admin rechten moet hebben voordat je eventueel van de exploit gebruik kan maken, dus dat is alvast één ding. Maar verder kan ik daar ook geen antwoord op geven.

[cdwave]

In dit geval biedt het toegang tot een deel waar zelfs het OS niet bij kan. Dus al ben je root en kun je je eigen drivers maken en direct hardware aansturen, dan nog zou je niet bij deze regio moeten kunnen komen. De relatie met virussen en trojans is dus maar een heel zwakke, theoretisch zou malware zich via deze weg bijvoorbeeld kunnen verstoppen voor het OS (en daarmee ook voor scanners).

In het wild heb je helemaal niks aan dit soort exploits. Malware probeert doorgaans vanuit een gewoon user process (doorgaans de browser of e-mail client) uit te breken en root privileges te verkrijgen zonder dat de operator dat merkt. Bij die cruciale stap helpen dit soort vulnerabilities niet. Je oude Intel is niet kwetsbaarder geworden voor malware via internet.

Wat wel zou kunnen met deze exploit is een soort extra stage toevoegen waarbij de malware zich via de smm kan verbergen of dieper doordringen in het systeem. Uitbreken uit een VM zou zelfs tot de mogelijkheden behoren.

[Reteip]

@Tribits. Wat ik vooral eng vind is de nuance die je aanbrengt in je eerste zin:
[quote]"wat voor zover mij bekend niet het geval is."[quote]
Dat is exact het probleem met dit type exploit(s).

Ik zou graag een tool zien die kan detecteren of er een rootkit aanwezig is. Maar zoals ik uit het artikel en andere documenatie begrijp is dit niet makkelijk

"Dat maakt rootkits mogelijk die nooit kunnen worden gedetecteerd."

. Ik vrees dat er een hoop (overheids)instanties aardig geinteresseerd zijn in zulke rootkits.

[Titan_Fox]

Zover ik het uit het artikel kan opmaken zijn AMD CPU's helemaal niet getroffen door deze architectuurfout ? Dit is wel even interessant om te weten omdat AMD ook x86-instructiesets heeft die ze onder licentie van Intel mogen gebruiken.

[rickboy333]

Zover ik het uit het artikel kan opmaken zijn AMD CPU's helemaal niet getroffen door deze architectuurfout ? Dit is wel even interessant om te weten omdat AMD ook x86-instructiesets heeft die ze onder licentie van Intel mogen gebruiken.

Ja maar waarschijnlijk zo beperkt mogelijk. Dus ik neem aan dat ze zo min mogelijk legacy codes van de x86 architectuur kunnen gebruiken. Daarnaast probeert AMD zo veel mogelijk ruimte te sparen in hun CPU's om een beetje bij te blijven met Intel. Dus ik geloof niet dat er nog sporen van apic or andere legacy codes nog aanwezig zijn.

Als laatste moet je ook niet vergeten dat AMD een totaal andere chipset heeft qua structuur. En om iets met apic te kunnen doen moet je toch via de Northbridge naar het geheugen toe. Ik weet niet in hoeverre dat uitmaakt maar het is een gok.

[Reactie gewijzigd door rickboy333 op 25 juli 2024 04:54]

[Rudie_V]

AMD CPU's zijn net zo goed backward compatible als de intel CPU's, dus de legacy hardware zal er gewoon in zitten, maar wellicht anders geïmplementeerd.

En of de chipset nou anders is of niet maakt niet uit, ook AMD hardware moet interrupts kunnen afhandelen, want dat is een functie van de x86 ISA, hoewel ook hier hun implementatie anders kan zijn.
Overigens heeft AMD wel ooit een andere interrupt controler architectuur gehad, maar die standaard haalde het niet en sinds de athlons heeft AMD een licentie op de intel APIC.
https://en.wikipedia.org/...pt_Controller#Competition

[casparvl]

Dat vroeg ik me ook af inderdaad. Maar: strict lezend is het inderdaad alleen Intel "Een ontwerpfout in x86-cpu's van Intel..."

[MisterData]

Ik heb de uitgebreide PowerPoint even bekeken, en het lijkt erop dat deze exploit gebruik maakt van een implementatiedetail van een corner case in de architectuur. Het idee is dat een tabel waarmee de APIC (interrupt handler) ingesteld kan worden kan worden verplaatst naar een geheugenadres dat ook door de SMM (system management mode) wordt gebruikt (het zgn. SMRAM). Hierdoor is het mogelijk om enkele bits in dat SMM-geheugen te schrijven, simpelweg door de APIC te programmeren (bij het instellen van de APIC wordt, in tegenstelling tot 'normale' geheugentoegang, de toegangsrechten tot het SMRAM niet goed gecheckt en afgedwongen; de APIC programmeer je met de speciale 'wrmsr' instructie).

Normaliter is er niet echt een goede reden om de APIC te laten overlappen met het SMRAM. Het is goed mogelijk dat het gedrag van de processor onder deze specifieke omstandigheden niet goed gespecificeerd is, of door AMD niet zo geimplementeerd is.

[Reactie gewijzigd door MisterData op 25 juli 2024 04:54]

[batjes]

AMD heeft zijn eigen implementaties en heeft support voor (een aantal) Intel instructies. Maar bouwt het verder allemaal zelf.

[atlaste]

Nou... "een aantal" wekt volgens mij de verkeerde suggestie.

De verschillen zitten vooral in nieuwe instructiesets zoals AVX/AVX2/etc. Voor de oudere instructies (incl de meeste SSE) is er een 100% overlap. Dat zou ook een hoop ellende opleveren als dat niet zo was.

Pre-2011 Sandy Bridge (Nehalem / Westmere dus) ondersteunt x86-64, Intel 64, SSE, SSE2, SSE3, SSSE3, SSE4, SSE4.1, SSE4.2, VT-x en VT-d. Als je dat vergelijkt met AMD Bulldozer, die ondersteunen deze instructies allemaal behalve (uit mijn hoofd) VT-x / VT-d.

Overigens maken de instructies weinig uit in dit geval. De vulnerability zit in de APIC; AMD doet dat anders.

[batjes]

o.a. SSE heeft toch een slechtere performance op AMD dan op Intel, het is zeker niet dezelfde onderliggende code.
Dat het "100%" hetzelfde werkt, wil niet zeggen dat de bulk eronder hetzelfde is. AMD bouwt de meuk gewoon zelf.

[atlaste]

Ja, als het ging om een bug had je daarin gelijk. Dit is een ontwerpfout. Als het een ontwerpfout in de instructieset was (wat het niet is), dan betekent dit dat je door de combinatie van features een exploit kan maken.

Kortom, functionaliteit gaat het hier om, niet hoe ze het hebben geimplementeerd. Ik ben ervan overtuigd dat de transistors anders zitten en de microcode anders in elkaar zit.

[batjes]

Daar heb je zeker een punt, als AMD zich in dit geval gewoon 100% aan het ontwerp van Intel had gehouden dat ze hetzelfde probleem hadden.

Overigens is niet bekend of AMD dit (of een soortgelijk) probleem heeft, omdat ze met deze onderzoeken vrijwel nooit getarget worden.

[ByteBusters]

Intel64? Amd64 zal je waarschijnlijk bedoelen. Een all-in-one itanium/x86-64 is er voor zover ik weet nooit geweest.

[Reactie gewijzigd door ByteBusters op 25 juli 2024 04:54]

[atlaste]

Nee, ik bedoel Intel64. Intel64 is de 64-bit implementatie van de x86-64 instructieset. Voorheen heette dit EM64T en IA32-e.

Zie ook: https://en.wikipedia.org/wiki/X86-64 .

[ByteBusters]

Zal aan mij liggen want dacht dat intel 64 toch altijd stond voor itanium (maar zie dat het IA-64 is). Lijkt er meer op dat ze dit nog snel even hebben aangepast toen iedereen zijn handen daar vanaf trok.
Toch heb ik ook zoiets van, ere wie ere toekomt. Jarenlang was het IA-32 (als in: intel architecture) en nu is het dus AMD64.

[atlaste]

@ByteBusters

Ach "ere"... als je de intel architecture guide hebt gelezen zoals ik weet ik niet of je nog over "eer" zou spreken. Met name sinds AMD64 is de hele x86 instructieset (incl SSE, AVX, etc) een grote klerezooi met de ene hack op de andere eerlijk gezegd. VEX, VOP, XOP... ultimo zijn het allemaal hacks die proberen meer registers en instructies in de bestaande bits te prakken door wat bits hier en daar te "lenen" die toevallig nog niet gebruikt werden (en dat is inmiddels verdomde onhandig).

[ByteBusters]

Toevallig wel eens iets gedaan met assembly (32 bits) dus weet waar je het obver hebt. Sommige zaken zijn handig waarbij het soms toch net weer jammerlijk tekort schiet en weer terug moet naar de oude vertrouwde instructies. Maar met de eer bedoelde ik deze meer naar AMD voor het introduceren van een werkende en werkbare 64-bit implementatie. Volgens mij is het ook nogsteeds de bedoeling om ooit in de volledige 64-bit modus te gaan draaien maar helaas zie je dat er nog maar weinig van komen. De meest mooie 32-bit opcodes zijn nogsteeds bezet door bijvoorbeeld instructies voor rekenen met bcd getallen. Wel, afgezien van (wederom) wat hacks worden die nergens meer voor gebruikt. Ze nemen helaas nog wel ruimte in de decoder, gelukkig in verhouding tot het geheel steeds minder, maar toch. Compatibaliteit heeft nu eenmaal zijn prijs in een cisc processor.

[atlaste]

Volgens mij is het ook nogsteeds de bedoeling om ooit in de volledige 64-bit modus te gaan draaien maar helaas zie je dat er nog maar weinig van komen. De meest mooie 32-bit opcodes zijn nogsteeds bezet door bijvoorbeeld instructies voor rekenen met bcd getallen.

Je bedoelt dat de meeste bits die gebruikt worden gealloceerd zijn door 32-bit instructies?

Hoe dan ook maakt het niets uit. Je moet een REX prefix gebruiken om de extra registers te kunnen duiden; dat laatste is de crux. Door de manier waarop MOD.R/M werkt heb je dan een paar extra bitjes nodig -- en dat resulteert vanzelf in een extra byte. Kortom, die opcode prefix heb je toch wel nodig.

Punt is alleen dat je op deze manier bezig blijft. SSE heeft nog meer registers en AVX nog meer. Die gebruiken daarom een extensie genaamd VEX/XOP om - je raadt het al - 1 resp 2 bitjes toe te voegen aan MOD.R/M. Om de extensie te duiden wordt een byte gebruikt. Mag jij drie keer raden wat er in de toekomst gaat gebeuren, bijvoorbeeld met AVX512...

Een betere oplossing zou zijn om er gewoon vanuit te gaan dat je bijv. max 256 registers hebt per categorie. Als je dat gaat doorrekenen worden je instructies 'in het normale geval' korter. Ik heb voor de grap weleens dit soort dingen getest op een stapeltje binaries... RISC is eigenlijk gewoon handiger. Ik meen ergens een keer te hebben gelezen dat de decoder er ook zoiets van maakt. Helaas lijkt dat er alleen voor de buitenwereld / programmeurs niet in te zitten.

De prijs is decoderen, extra memory fetches, complexiteit voor compiler bouwers, etc.

Maar met de eer bedoelde ik deze meer naar AMD voor het introduceren van een werkende en werkbare 64-bit implementatie.

Ik snap wat je bedoelde.

Bovenstaande trend is in gang gezet bij de introductie van AMD64 met REX. Intel introduceerde oorspronkelijk een hele nieuwe processor modus, waarbij je dergelijke hacks niet nodig hebt (IA64). Helaas heeft AMD gewonnen vanwege de backward compatibility; op langere termijn krijg je deze hacks echter keihard terug in de 'prijs' die je noemt. Kortom, ik vind het vooral kortzichtig.

[ByteBusters]

Je bedoelt dat de meeste bits die gebruikt worden gealloceerd zijn door 32-bit instructies?

Ik bedoelde: In 32-bits modus zijn de meest korte instructies bezet door instructies die eigenlijk niet meer gebruikt worden. Die zijn in de 64-bit instructieset niet overgenomen.

Wat betreft het korter maken door de decoder bedoel je waarschijnlijk micro-ops. Grotere instructies worden inderdaad vaak opgesplitst zodat ze ook nog eens tegelijk door verschillende verwerkingsunits verwerkt kunnen worden.

Goed boek hierover (vond ik zelf althans) is "inside the machine" wat, onder andere, dit mooi illustreerd.

[atlaste]

Ik bedoelde: In 32-bits modus zijn de meest korte instructies bezet door instructies die eigenlijk niet meer gebruikt worden. Die zijn in de 64-bit instructieset niet overgenomen.

False.

Ik heb pasgeleden de x64 instructieset nog helemaal uitgezocht op basis van de laatste Intel Architecture Guides. Er zijn 11 instructies die in 32-bit ondersteund worden en niet een 64-bit variant hebben. Overigens alle 11 met 1-byte notatie. Vrijwel alle instructies hebben een REX (64-bit) counterpart.

Dit is de hele lijst: AAA, AAD, AAM, AAS, BOUND, DAA, DAS, LAHF, POPA, PUSHA, SAHF.

Wat praktisch gezien niet meer gebruikt wordt (maar wel ondersteund) zijn MMX en FPU. In plaats hiervan gebruikt iedereen SSE. FPU is overigens de opcode range D8-DF; MMX is praktisch gezien altijd multi-byte opcodes (0F extensie). Beiden zijn hier buiten beschouwing gelaten.

In totaal kan je dus stellen dat slechts 8+11 = 19 first-level opcodes niet meer valid zijn op x64, wat overigens betekent dat deze gewoon voor andere doeleinden gebruikt mogen worden in 64-bit mode.

Vwb. 'gebruikt worden' in praktische zin: van LLVM is het bekend dat het in principe alle instructies kan genereren (indien de situatie zich hier voor leent uiteraard).

Het enige 'echte' probleem is te weinig bits voor MODR/M met de nieuwe hoeveelheden registers, waardoor je prefixen nodig hebt om dit te kunnen encoderen. http://wiki.osdev.org/X86-64_Instruction_Encoding legt het uit.

[ByteBusters]

Maar dat bedoelde ik juist. Die 19 instructies zijn allemaal single-byte opcodes. De andere instructies zoals add, sub etc.. hebben natuurlijk een 64-bit variant.

Van die 19 instructies hebben de meeste ook nog eens een speciale encoding voor het geval het eerste register (eax/rax) gebruikt wordt of slechts gedeeltelijk (ax). Dus neemt dat ook de ruimte van een single byte opcode in beslag. Op dezelfde wijze als dat voor add, or, etc... gebeurd (in bepaalde gevallen neemt 1 instructie wel 6 single byte opcodes in beslag) (zie hier)

De oude instructies zijn uitgeschakeld en kunnen worden gebruikt om andere, langere instructies te coderen. Zo is er beter rekening gehouden met het uitbreiden van de instructie set, ipv alle extenties veelal te baseren op 0f (general exception).

[atlaste]

Van die 19 instructies hebben de meeste ook nog eens een speciale encoding voor het geval het eerste register (eax/rax) gebruikt wordt of slechts gedeeltelijk (ax).

Mijn punt was juist dat dit niet het geval is. Deze instructies hebben geen EAX/RAX variant (dat laatste vereist een REX) en hebben allemaal 1 byte als opcode. Ze werken op AX/AH/AL.

Ah nu begrijp ik wat je bedoelt. Je bedoelt dat ADC (add with carry) bijv. encodeert naar verschillende varianten voor (delen) van het register. Dat klopt, maar is geen legacy. Het is wel wat ik bedoelde met "niet toekomstvast".

Waarom geen legacy: als je bijv. in je programma een uint16_t gebruikt, zal je compiler dit (afhankelijk situatie blabla) compileren naar een opcode die een 16-bit register (AX/...) gebruikt. Dat is juist handig, dan kan je bijv. een RAX lezen en daarna vervolgens een AX gebruiken als dit goed uitkomt (iets met alignment en access patterns)

Wat onhandig is, is bijv. de encoding van -zeg- VPSLLVQ ymm1, ymm2, ymm3/m256. Zeker als je daarbij ook nog combinaties maakt met modr/m (e.g. ellende zoals [ymm1+ymm2*4 + 8] ). Dat encodeert tot een heleboel bytejes.

[ByteBusters]

[...]
Ah nu begrijp ik wat je bedoelt. Je bedoelt dat ADC (add with carry) bijv. encodeert naar verschillende varianten voor (delen) van het register. Dat klopt, maar is geen legacy. Het is wel wat ik bedoelde met "niet toekomstvast".

Dat deel is geen legacy inderdaad maar wou ermee dat het wel in hetzelfde byte gecodeerd wordt. Het is immers een single-byte instructie, dus iedere variant die in de opcode zit neemt een plaats in de single-byte instructies. De encoding zelf is erg handig maar neemt wel veel ruimte. Daarom is het voor sommige instructies erg efficient te zorgen dat het A (al, eax, rax) register gebruikt wordt (in welk formaat dan ook) en voor een aantal het C register (loop instructies e.d.). Dan krijg je kortere code. Maar dat is peanuts in vergelijking met de nieuwe instructies die behoorlijk wat ruimte in beslag kunnen nemen. Maar goed, met immediate addressing in 64-bit modus is het adres alleen al een 8 byte lange constante.
Leuke link trouwens die ik tegen kwam over x86 oddities.

[atlaste]

Klopt. Volgens mij zijn we het eens.

Nice link trouwens, thanks.

[ByteBusters]

Volgens mij ook

[MrFax]

Juist, alleen op het patent word een licentie genomen, de implementatie word (waarschijnlijk) volledig zelf gedaan.

[Trommelrem]

Zou grappig zijn als eigenaren ineens eligeerbaar zouden zijn voor een nieuwe revisie, net als bij de Pentium floating point bug destijds.

Hoewel de apic inmiddels geen zelfstandig onderdeel meer is van een x86-cpu, is de legacycode van Intel nog steeds aanwezig

Zijn trouwens alle legacy, tot en met de 8086/8088 nog aanwezig? Alleen 8085 code kan volgens mij niet meer worden gedraaid op een moderne CPU.

[Reactie gewijzigd door Trommelrem op 25 juli 2024 04:54]

[mae-t.net]

Nieuw werkwoord, ik eligeer, jij eligeert, hij eligeert, geëligeerd worden, iemand eligeren, geëligeerd zijn, als je iemand goed kunt eligeren is zij compleet eligeerbaar, enz. klinkt best eng of misschien wel spannend. Nu nog een leuke betekenis verzinnen die bij de klank past en dan in het urban dictionary plaatsen.

Waarschijnlijk bedoel je gewoon "in aanmerking komen voor".

8086 code kun je inderdaad gewoon draaien, daar komt de naam x86 voor de architectuur ook vandaan. Het is een subset van de 286 code, die weer een subset is van de 386 code, enzovoort en er is aan die subsets op instructieniveau nooit veel meer gesleuteld (er zijn wel wat timings veranderd en ik meen een paar losse instructies aangepast of vervallen die er echt niet tussenpasten of voor grote problemen zouden zorgen).

8080/8085 code kon je al vanaf de eerste 8086 nooit draaien op x86 processoren, want dat was een compleet andere processorfamilie (periferie-chips grotendeels uitwisselbaar maar instructieset en andere eigenschappen compleet anders). Een Z80, maar ook een V20 of V30 processor konden nog wel code draaien die voor de 8080 geschreven was.

Het leuke van die V20/V30 processoren (fabrikant NEC, typenummers naar ik meen uPD70108 en uPD70116) was dat je er zowel 8080 als 8086 code op kon draaien, maar dat is bij mijn weten ook de enige processorreeks die dat kon. In de praktijk zijn die processoren soms in PC's gebruikt omdat ze een paar procent sneller waren en ook hoger geklokt konden worden, maar de mogelijkheid om 8080-code uit te voeren werd zelden gebruikt.

[Reactie gewijzigd door mae-t.net op 25 juli 2024 04:54]

[Trommelrem]

Grappig dat je over die NEC V20/V30 begint. Mijn eerste PC had een NEC V20 processor. Die was (merkbaar) sneller met berekeningen dan een gelijkgeklokte 8088.

Kun je een voorbeeld noemen van een applicatie die wel op de NEC V20 werkte maar niet op andere PC/XT-compatibles?

Vreemd dat er geen Nederlands woord voor eligeerbaar bestaat. Hetzelfde probleem kom je met het woord ameniteiten tegen. Daar is volgens mij ook geen officieel Nederlands woord voor.

[Reactie gewijzigd door Trommelrem op 25 juli 2024 04:54]

[mae-t.net]

Voorbeeld durf ik zo niet te noemen, zullen niet veel programma's geweest zijn, misschien wat emulatoren of programmeeromgevingen voor CP/M of homecomputers. Ik heb destijds nog overwogen om mijn 8088 te vervangen door een V20, maar voor dat beetje snelheidswinst vond ik het niet lonen, hij was al op 9,54MHz geklokt (was bij aanschaf door mijn vader destijds de snelste van de verouderde modellen, geld voor een gloednieuwe 386 was er niet).

Hoe dan ook: 'to be eligible for' = 'in aanmerking komen voor', dus het bestaat wel. Het alternatief 'recht hebben op' kan soms ook. Blijft leuk om wat met woorden te spelen soms, eligeerbaar klinkt opzich best leuk.

[Reactie gewijzigd door mae-t.net op 25 juli 2024 04:54]

[scsirob]

8085 code kan op geen enkele x86 processor draaien.

Edit: Waarom is dit niet relevant? Rechtstreeks antwoord op de gestelde vraag "Alleen 8085 code kan volgens mij niet meer worden gedraaid op een moderne CPU."

[Reactie gewijzigd door scsirob op 25 juli 2024 04:54]

[--Andre--]

Na aanleiding van dit voorval is volgens mij de microcode geïntroduceerd die softwarematig bijgewerkt kan worden, zodat fouten in de CPU voortaan softwarematig opgelost kunnen worden.

[Fermion]

Draag geen alu hoedje, maar hoezo is dit niet met opzet erin gezet? Een altijd hackbaar systeem, iets waar NSA natuurlijk dol op is. Zo geloof ik ook dat vele verholpen bugs in Windows systemen een manier was om NSA zichzelf toegang tot het systeem te geven.

Edit: Ik zou dat doen als ik de baas van NSA zou zijn, een logische stap voor spionage.

[Reactie gewijzigd door Fermion op 25 juli 2024 04:54]

[Iblies]

Fouten zijn inherent aan elk proces. De kunst is ze te minimaliseren en toch nog een werkend product/dienst neer te zetten. Zo wordt er soms bewust gebruik gemaakt van een mindere kwaliteit stof om de prijs te drukken, worden er diensten uitbesteed met de kennis dat het duurder is omdat je niet meer personeel in dienst wilt nemen, etc, etc


In de ICT blijkt dat nog een graadje erger te zijn. Zo deed iemand de boute uitspraak dat wanneer een ontwikkelaar een huis/gebouw zou bouwen, het na een jaar onbewoonbaar kan worden verklaard omdat het te gevaarlijk is en dat klopt deels ook.
Chips (CPU, gpu, etc) en software blijft maar uitdijen terwijl men nooit afscheid neemt van oude zwakke technieken.
Een prachtig voorbeeld is de ontwikkeling van IOS en Android. Dat begon hartstikke klein, maar neemt vandaag de dag veel ruimte in beslag. Echter blijkt ook dat ze beide niet veilig zijn, waarbij met enige regelmaat exploits naar buiten worden gebracht die meerdere versies beïnvloeden.

[ATS]

Zou grappig zijn als eigenaren ineens eligeerbaar zouden zijn voor een nieuwe revisie, net als bij de Pentium floating point bug destijds.

Dat is wel een erg directe vertaalpoging van het Engelse 'eligible'. Probeer het eens met "in aanmerking komen voor"...

[Reactie gewijzigd door ATS op 25 juli 2024 04:54]

[JAVE]

'In aanmerking komen' dan toch

[ATS]

'In aanmerking komen' dan toch

Ja, irritante auto-"correct" op mobile apparaten soms...

[LaMaZitten]

...ineens eligeerbaar zouden zijn...

Eligible ==> eligeerbaar?!? No..... just no!

[SinergyX]

Wel een behoorlijke omweg, je moet code kunnen uitvoeren (exploit die al vaak geblokkeerd wordt), het 'zou' op Windows ook moeten werken (wat doet UAC hier eigenlijk mee?) en het gaat dan om nog een relatief oude CPU.

In theorie zou een aanvaller zelfs een kwetsbare computer in brand kunnen laten

Wel een erg bizar ver gezochte theorie, of de PC moet bij voorbaat al brandgevaarlijk zijn (en elke vorm van beveiliging is uitgeschakeld).

[Joost]

Wel een behoorlijke omweg, je moet code kunnen uitvoeren (exploit die al vaak geblokkeerd wordt), het 'zou' op Windows ook moeten werken (wat doet UAC hier eigenlijk mee?) en het gaat dan om nog een relatief oude CPU.


[...]

Wel een erg bizar ver gezochte theorie, of de PC moet bij voorbaat al brandgevaarlijk zijn (en elke vorm van beveiliging is uitgeschakeld).

Je hebt dus geen speciale rechten nodig: je hoeft enkel in staat te zijn om naar het geheugen te schrijven. En die 'vorm van beveiliging' is niet van toepassing, de smm ís de beveiliging.

[ilaurensnl]

Normaal gesproken wordt UAC gebruikt om dit op te pikken als je veranderingen in de geheugen wilt maken, heb je administratie rechten nodig.

Tenminste toen ik met c# werkte wel, kan ook een nadeel zijn door de api's die gebruikt wordt om deze geheugen veranderingen te kunnen gebruiken.

[Patriot]

Ieder zinnig programma kan naar het geheugen schrijven. Jij hebt het misschien over het aanspreken van geheugen van iets anders dan het eigen proces, dat is heel iets anders.

[Mijzelf]

Je hebt geen speciale rechten nodig om veranderingen in het geheugen te maken. Tenzij je het recht om code uit te voeren al speciaal vindt. Je kunt geen code uitvoeren zonder het geheugen te veranderen.

[batjes]

Alleen kan ook Windows niet bij dit geheugen.

[Blokker_1999]

UAC komt in actie wanneer je veranderingen aan het systeem wenst aan te brengen. Het kan niet beschermen tegen fouten waar het OS op zich geen enkel vat op heeft.

[Niemand_Anders]

Je moet ook niet zozeer aan een PC denken, maar meer aan laptops. Denk bijvoorbeeld aan de berichten van in brand vlieggende laptop accu's. Die issues zijn grotendeels softwarematig verholpen door aangepast energie beheer naar de accu. Deze exploit zou die 'patch' dus ongedaan kunnen maken..

Maar doorgebrande processors zijn ook niet nieuw. In 2000 hadden wij destijds een aantal supermicro moederborden waarvan de socket was gesmolten. Niet alleen moesten we toen het moederbord vervangen, omdat we ook de processor niet meer uit de gesloten voet kregen moesten we destijds een nieuwe Xeon processors bestellen. Dat was een erg duur grapje.

Ik weet alleen niet of code in de CPU settings uit het BIOS kan overrulen. Zou de exploit mogelijk de thermische beveiligingen in het BIOS kunnen uitschakelen?

[bogy]

normaal kan je met een microcode update hier wel een patch voor installeren zodat de power managment van de cpu niet meer gebruikt wordt (maar bv die van het moeder bord of van de software die je gebruikt) of dat deze functie op write/only wordt gezet...

helaas lijkt het me sterk dat microsoft voor alle nog in gebruik zijnde processors ineens nieuwe microcode gaat schrijven...; denk bv aan de vele s775 systemen die nog in gebruik zijn; ook in mijn familie zijn er nog verschillende s775 systemen in gebruik; core2duo, core2quad, waar win7 op stond en die ondertussen al de upgrade naar win10 gekregen hebben... en nog steeds perfect werken om te mailen, surfen, muziek, youtube, etc etc ... alles eigenlijk behalve zwaar 3D werk enzo, maar dat wordt door de meeste mensen toch niet gedaan.

Zelf heb ik ook nog systemen met een oudere intel cpu in gebruik; 1 is een Q6600 met dualboot vista/linux en is m'n testpc + bezoekers-game toestel waar we lan-games op spelen, dan heb ik nog een iets oudere laptop liggen die in gebruik is (intel celeron T1700) als surfmachine (was vista, is xubuntu sinds een jaar of drie); en ten slotte nog 1 machine waar ik aan twijfel en da's een netbookje met een Atom N450 (ook xubuntu; dagelijks gebruik om te surfen). De overige computers hebben ofwel een amd chip ofwel een recentere intel chip

[MrFax]

Huh? Wordt de CPU microcode niet geschreven door de moederbord fabrikant (de BIOS)?

Ik bedoel hiermee dat de moederbord fabrikant mogelijk een bios update kan geven om een workaround aan deze fout te geven?

[Reactie gewijzigd door MrFax op 25 juli 2024 04:54]

[bogy]

cpu microcode zit in de cpu zelf ...

is een soort van mini-firmware waarmee ze de chip bepaalde functies kunnen geven/ontnemen (bv het instellen van de mhz, multiplier lock, etc).

De microcode bestuurt je chip; maar soms is er per stepping een verschillende microcode. En gezien het aantal cpu's dat intel nog in het wild heeft (ik kom nog pentium4 tegen bij sommige klanten van me; pentiumIII is gelukkig wel al heel lang geleden. Pentium M daarentegen zie ik nog steeds laptops van (centrino's).

het zou intel vele miljoenen kosten en wellicht maanden tijd eer ze alle cpu's hebben kunnen updaten om het probleem op te lossen; wellicht dat daarom er niets an doen; het gaat tenslotte over oude cpu's en tegen de tijd dat ze allemaal gepatched zijn heeft er al lang een virus 10x de wereld rond gegaan dat de fout misbruikt.
Bovendien moet de hacker eerst al een programma met hardwaretoegang (dus root-access / administrator-rechten) kunnen uitvoeren op de aan te vallen pc en dit is een issue waarvoor je jezelf als gebruiker al voor 99% kan indekken door je systeem up to date te houden en je computer een beetje consequent te gebruiken (bv niet zomaar overal op klikken/alles openen/etc)

ik ben al heel tevreden dat de fout bij nader inzien niet zomaar in userland misbruikt kan worden (wat eerst zo in het artikel vermeld stond; en waarom ik dus in eerste instantie toch een beetje ongerust was); verder ben ik gewoon een user die zeer weinig risico's neemt (bv geen wares, geen IE wegens de integatie in windows;

[MrFax]

Maar de BIOS moet het dan ook kunnen updaten? Ik zag bij mijn oude (Sandy Bridge) moederbord veel "update cpu microcode" bios versies zitten.

[mae-t.net]

Dat klopt. Microcode-updates worden in de regel via het BIOS gedaan. In BIOS updates zitten in de regel ook microcode-updates.

Dank aan lezzmeister voor de correctie. Als je dus geen OS draait dat die updates bevat, zul je wel zorgvuldiger moeten zijn op je BIOS-updates.

[Reactie gewijzigd door mae-t.net op 25 juli 2024 04:54]

[lezzmeister]

https://support.microsoft.com/en-us/kb/2493989
https://support.microsoft.com/en-us/kb/936357
https://support.microsoft.com/en-us/kb/2970215
https://support.microsoft.com/en-us/kb/3064209
https://wiki.debian.org/Microcode

Van XP tot 7 word het al gedaan via OS updates. Bekijk het zelf. Bios updates kunnen microcode updaten, maar omdat veel gebrruikers dit niet doen word dit gedaan vanuit Windows/BSD wat ook. Sterker nog: microcode updates zitten wel eens bij gewone updates verstopt. Niet vaak, maar het gebeurd wel.

[Z80]

maar wel op het grote boze web rond wandelt.
een advertentie die misbruik maakt van een bug in het os en dit als opstapje gebruikt en je gaat alsnog nat.

[MSalters]

De thermische beveiliging in de "BIOS" is in werkelijkheid alleen maar de setting; de implementatie daarvan gebeurt door in SMM. Of niet dus, met deze hack.

[mae-t.net]

Na 30 jaar zijn de komma's kennelijk ook op, maar ik denk wel dat ik je zinnetje snap. Alleen zeg je er niet zoveel mee. Waar klopt het niet wat hij schrijft dan?

[halofreak1990]

Wat ik een beetje mis is een link met extra informatie; hoe werkt deze exploit, bijv.? Wordt er gebruik gemaakt van MSR's? Dan is het een ontwerpfout van Linux, aangezien alleen ring0 code een MSR kan aanpassen. Of is het toch iets anders?

[Joost]

Wat ik een beetje mis is een link met extra informatie; hoe werkt deze exploit, bijv.? Wordt er gebruik gemaakt van MSR's? Dan is het een ontwerpfout van Linux, aangezien alleen ring0 code een MSR kan aanpassen. Of is het toch iets anders?

Het is geen fout op os-niveau, maar op niveau van de x86-firmware.

Domas beloofde tijdens zijn talk hier meer informatie te uploaden, maar dat is nog niet gebeurd: https://github.com/xoreaxeaxeax/sinkhole

Zodra dat wel zo is, zal ik het in het stuk plaatsen, uiteraard.

[halofreak1990]

Net de broncode gelezen. Inderdaad via MSR's. In principe is elk OS met kernel-mode drivers en/of kernel modules kwetsbaar. Maar daar houd het bij op. Als een OS geen kernel-mode drivers of kernel modules ondersteunt is het niet kwetsbaar. Alleen bij fysieke toegang tot het systeem kan de exploit dan wellicht pre-boot worden geïnstalleerd zodat het ook op veilige besturingssystemen kan worden misbruikt.

uit WRMSR:

This instruction must be executed at privilege level 0 or in real-address mode; otherwise, a general protection exception #GP(0) will be generated.

[MSalters]

Oh oh, T.net zal ring 0 toch niet met user 0 hebben verward?

Ring 0 is het nivo's waarop drivers en het OS runnen. Dit is een x86 feature.

User 0 is root, een Linux concept. Processen van user 0 worden gewoon in ring 3 uitgevoerd, maar Linux geeft die root processen extra rechten in syscalls. Zo mogen ze alle files lezen. Dit zijn dus rechten op Linux nivo, niet x86 nivo. Een root proces heeft nog steeds een SegFault als het buiten z'n geheugenallocatie leest.

[hardwareaddict]

behalve als je rommelt met shared memory, dan krijg je dus die segfaults niet en is 't systeem zo gehackt (maar da's weer andere exploit die ze komende 30 jaar niet oplossen bij linux - niet zolang Linus leeft althans).

[MSalters]

Raymond Chen vat dat samen als "it rather involves being on the other side of the airlock". Ja, je hoeft geen root te zijn om via shared memory te schrijven naar geheugen wat root gemapt heeft. Maar dan moet je al een root proces gehijackt hebben. Je logica komt dus neer op " als ik een exploit heb (voor een root proces), dan heb ik een exploit (voor een ander proces wat geheugen deelt met root)." .

Een échte exploit brengt dus een escalation of privilege met zich mee. Concreet: zonder hulp van root dingen doen die alleen root zou mogen.

[ongekend41]

Inmiddels staat daar (https://github.com/xoreaxeaxeax/sinkhole) meer info waaronder een PoC van de APIC overlay attack.
_{Later volgt er nog meer maar misschien kan het al in een update.}

[NaliXL]

Het lijkt me interessant om eens uit te zoeken wat voor amerikaanse overheidsinstanties hier al achterdeurtjes e.d. hebben geïnstalleerd...

[Durandal]

Geen denk ik, want als dat uit komt (en vroeg of laat komt alles uit) dan
- is het bekend en gaat het weg
- kan intel wel opdoeken (alleen al vanwege de claims, en daarna vanwege het vertrouwen dat er niet meer is)

[brama]

Helaas, er is extreem grof geld te verdienen met het verkopen van exploits, en bedrijven die ze zoeken, verkopen ook aan overheidsinstanties. Het beveiligingslek bij HackingTeam laatst toont dat fijntjes aan. Lees hier maar eens: http://webwereld.nl/tag-hacking-team

Er is dus een meer dan redelijke kans dat dergelijke bedrijven dergelijke exploits zelf al gevonden hebben. Nu alles en iedereen al zijn informatie op internet al dan niet bewust deelt, is het echt geen alu-hoedjes-onzin meer om te bedenken dat hier ook daadwerkelijk actief en succesvol naar gehengeld wordt.

[Maurits van Baerle]

Zijn dit soort dingen niet met een update van het UEFI tegen te houden? Volgens mij is dat wel vaker gebruikt om bugs in CPU's "op te lossen".

[codeneos]

Je bedoeld een microcode patch, dit heeft niet direct iets met UEFI te maken. Wel is het zo dat microcode patches vaak via een BIOS of UEFI update verspreid worden.

Maar om antwoord te geven op je vraag, ik heb zo'n gevoel dat als dit mogelijk was Intel het al gedaan zou hebben. Zoals ik het lees is Intel al een tijdje op de hoogte van het probleem en hebben ze het in nieuwe CPUs, vanaf de i-series, opgelost.

[Thekilldevilhil]

Het is niet helemaal vanaf de i series opgelost. Nehalem is vatbaar, sandy bridge niet. Dus de eerste i serie is wel degelijk vatbaar. En dat is niet echt een detail. Ik ken nog ongelooflijk veel mensen en bedrijven met lynnfields en core 2's. Dus dit is toch wel iets waar je op relatief grote schaal misbruik van kunt maken.

[Bananenplant]

Vanaf welke concrete cpu-series is het nu opgelost? Sandy bridge?

[Joost]

Vanaf welke concrete cpu-series is het nu opgelost? Sandy bridge?

Yes, ik zal dat nog even verduidelijken in het stuk.

[Robin4]

Ik zou wel eens willen weten welke processoren die hier onder vallen, dus met dit probleem te kampen hebben..

Vind dat intel de laatste jaar heel wat stomme foutjes heeft gemaakt..

[Patriot]

Alles van Intel dat voor 2011 is gemaakt valt er sowieso onder. Vanaf Sandy Bridge is het pas opgelost.

[RoelZ]

Dat houdt dus in dat ik de sjaak ben?
http://tweakers.net/price...quad-q9550/specificaties/

Daargelaten dat het triggeren van een exploit en ook daadwerkelijk een target te zijn een kleine kans is.

...hoewel ik nu met dit bericht de kans vergroot heb...

[hardwareaddict]

Ze verkopen je graag een nieuwe CPU.

Heb niet de illusie dat organisaties die gebruik kunnen maken van dit soort exploits, dat enig ander goedkope PC cpu onder de 2000 dollar niet gehackt kan worden.

Kom je toch uit op oude van oorsprong RISC achtige CPU's, maar dan mag je je eigen OS schrijven wil je niet gehackt kunnen worden.

[MadEgg]

Dit klinkt absoluut niet ernstig, om eerlijk te zijn. Je moet een proces als root uitvoeren. Als root kun je ook UEFI/BIOS updates uitvoeren, waarmee je ook permanente rootkits kunt uitvoeren.

Over het algemeen kun je niet iemand root laten zijn die je niet vertrouwd, en moet je geen processen draaien als root die je niet vertrouwt.

Wat ik me afvraag is of je hier op de een of andere manier ook bijkan vanuit een VM. Ik vermoed van niet, maar als dat wel zo is, dan hebben we pas een echte risk factor te pakken.

[R4gnax]

Dit klinkt absoluut niet ernstig, om eerlijk te zijn. Je moet een proces als root uitvoeren. Als root kun je ook UEFI/BIOS updates uitvoeren, waarmee je ook permanente rootkits kunt uitvoeren.

Als je één keer een hack te pakken hebt om privileges te escaleren is het raak en kom je er nooit meer vanaf. UEFI/BIOS updates zijn op veel borden nog hardwarematig te blokkeren via een jumper. Dit is niet blokkeerbaar.

Daarnaast zijn flashing tools voor UEFI/BIOS nog vrij specifiek per fabrikant, wat het moeilijk maakt om één coherente exploit te bouwen die generiek toepasbaar is op een groot publiek. Hier gaat het om een exploit waar alle pre-Sandy bridge Intels ineens mee gepakt worden. Een stuk makkelijker te deployen, dus.

Wat ik me afvraag is of je hier op de een of andere manier ook bijkan vanuit een VM. Ik vermoed van niet, maar als dat wel zo is, dan hebben we pas een echte risk factor te pakken.

Als deze exploit leunt op een fout in de x86 instructieset zelf, dan kan het best wel eens vanuit een VM te misbruiken zijn wanneer er op het systeem in kwestie gebruik gemaakt wordt van hardware-assisted virtualisatie en de instructies onvertaald doorgaan naar de CPU zelf.

[Reactie gewijzigd door R4gnax op 25 juli 2024 04:54]