Intel fikst mogelijke privilege-escalationkwetsbaarheid in cpu's

Intel heeft een update uitgebracht voor een fout in zijn cpu's die misbruikt kan worden voor privilege escalation. De fout werd mede door Google ontdekt en zou voornamelijk gevolgen hebben voor aanbieders van clouddiensten.

De bug zat in de fast short repeat move-functie die sinds 2019 in Intel-cpu's zit en waarmee processors sneller code met kleinere strings kunnen verwerken. Intel zegt dat door de bug bepaalde instructies met tegengestelde of onlogische REX-prefixen crashes kunnen veroorzaken. Normaal gesproken zou de processor die verkeerde prefixen kunnen negeren, maar met de fsrm-functie gebeurde dit om onduidelijke redenen niet.

Intel spreekt over 'onverwacht gedrag' dat naast crashes in 'beperkte situaties mogelijk voor escalation of privilege' kan zorgen. Het bedrijf heeft een microcode-update uitgebracht voor de fout en geeft de CVE-2023-23583-bug een severity rating van 8,8. Bepaalde desktopprocessors vanaf de elfde generatie, of Rocket Lake, zijn getroffen door de bug, evenals bepaalde serverprocessors en mobiele cpu's die sinds 2019 zijn uitgebracht.

Google-onderzoekers die de fout ook hebben opgespoord, zeggen dat de fout 'serieuze veiligheidsproblemen' kan opleveren voor cloudproviders, maar dat het ook onduidelijk is hoe de bug precies werkt doordat er weinig publiekelijk bekend is over de precieze werking van fsrm. De onderzoekers konden daardoor niet met zekerheid zeggen dat de bug daadwerkelijk tot privilege escalation kon leiden. Voor zover bekend werd de kwetsbaarheid niet actief misbruikt.

Reacties (26)

[The Zep Man]

Microcode updates zijn tegenwoordig standaard en niet zo bijzonder. Met elke update ben ik slechts benieuwd naar twee zaken:

• Lost het het gestelde probleem op?
• Wat kost het qua prestaties?

In het geval van een beveiligingsupdate die enkel privilege escalation betreft kan het in bepaalde situaties lonen om de update niet te draaien of uit te stellen. In dit geval gaat het echter ook om crashes, en dat zou al kunnen door 'vieze' invoer (zonder slechte intentie).

[Reactie gewijzigd door The Zep Man op 27 juli 2024 14:54]

[Klauwhamer]

Toch vind ik de noodzaak er van nog steeds 'bijzonder'. Dat het steeds vaker noodzakelijk is om ernstige infrastructurele kwetsbaarheden op te lossen ten koste van -reeds gebudgetteerde en ingekochte- resources, vind ik storend, maar dat we dit soort ongein als norm "moeten" beschouwen vandaag de dag ronduit hemeltergend. Zeker als je nagaat wat Intel flikt als het gaat om willens en wetens kwetsbaarheden te laten voor wat het is.

[NotWise]

Veel bedrijven werken volgens het kosten/baten principe en dat gaat soms heel ver. Je zou eens op de Ford Pinto lawsuit moeten zoeken. Dit een beruchte zaak over hoe een fabrikant (Ford in dit geval) een afweging maakt tussen de kosten voor het repareren van een ontwerpfout, en het betalen van schadevergoedingen aan slachtoffers.

Hier een kleine stukje over de zaak.

Thus, Ford knew that the Pinto represented a serious fire hazard when struck from the rear, even in low-speed collisions. Ford officials faced a decision. Should they go ahead with the existing design, thereby meeting the production timetable but possibly jeopardizing consumer safety? Or should they delay production of the Pinto by redesigning the gas tank to make it safer and thus concede another year of subcompact dominance to foreign companies? Ford not only pushed ahead with the original design but stuck to it for the next six years.

What explains Ford’s decision? The evidence suggests that Ford relied, at least in part, on cost-benefit reasoning, which is an analysis in monetary terms of the expected costs and benefits of doing something. There were various ways of making the Pinto’s gas tank safer. Although the estimated price of these safety improvements ranged from only $5 to $8 per vehicle, Ford evidently reasoned that the increased cost outweighed the benefits of a new tank design.

Het is weliswaar niet het zelfde als een fout in een chip. Maar het principe blijft hetzelfde.

[Remzi1993]

Daarom moet er strenger gehandhaafd worden en grotere boetes uitgedeeld worden zodat het niet winstgevend is om dit soort dingen te doen.

[The Zep Man]

Toch vind ik de noodzaak er van nog steeds 'bijzonder'. Dat het steeds vaker noodzakelijk is om ernstige infrastructurele kwetsbaarheden op te lossen ten koste van -reeds gebudgetteerde en ingekochte- resources, vind ik storend,

Dan heb je niet goed gebudgetteerd, want tegenwoordig moet je met een marge van verlies van topprestaties over de levensduur van processors werken om tot een realistisch plaatje te komen.

[Reactie gewijzigd door The Zep Man op 27 juli 2024 14:54]

[Klauwhamer]

Jij vindt dat het "mijn" fout is wanneer ik er niet vanuit ga dat ik pak 'm beet +30% capaciteit moet inkopen om te anticiperen op performance hits door micropatches voor Intel's kwetsbare hardware..? OK, dan.

[The Zep Man]

Jij vindt dat het "mijn" fout is wanneer ik er niet vanuit ga dat ik pak 'm beet +30% capaciteit moet inkopen om te anticiperen op performance hits door micropatches voor Intel's kwetsbare hardware..? OK, dan.

Als je kijkt naar de afgelopen tien jaar en de noodzaak en gevolgen van microcode-updates: ja.

Zoals @jaenster noemt is predictive computing risicovol. Als je daarop je infrastructuur inricht, dan accepteer je daarvan de risico's. Dit is ook geen nieuwe informatie, dus er is geen reden om hierover verbaasd te zijn.

[Reactie gewijzigd door The Zep Man op 27 juli 2024 14:54]

[jaenster]

Dit is toch ook vrij normaal voor accu's? Waarom is dat hier zo gek. Afgezien van dat een accu slijt (en een processor "slijt" door deze bugs), gaan we er ook vanuit dat als een fabrikant zegt dat dien auto 450km kan rijden op een volle lading, wij er al snel 75km vanaf tellen.

[Klauwhamer]

Vind je echt dat je een slijtende accu kunt vergelijken met infrastructuur dat in eerste plaats kwetsbaar blijkt voor een scala aan security vulnerabilities waarmee een VM-park ernstig gecompromitteerd kan worden waarbij de leverancier járen op de hoogte is en uiteindelijk komt aankakken met een "oplossing" die er voor zorgt dat je defacto 30% minder performance hebt dan aanvankelijk ingekocht..? Zo ernstig zelfs dat OpenBSD domweg stopt met het ondersteunen van hyperthreading op het Intel-platform?

Voor mij is dit écht van een heel andere orde dan reguliere slijtage [door gebruik]. En de attitude van "Ach, hoort er bij" vind ik in deze categorie echt heel misplaatst.

[jaenster]

Ik denk dat je het beter kan omdraaien. Hyperthreading, hoe fijn het ook werkt, is een hack die in beginsel niet veilig is. Er gaat altijd een beveilingsissue uit kunnen ontstaan omdat de chip simpelweg moet gokken wat daarna komt en je die zo om de tuin kan leiden. Het is gelukkig iets gecompliceerder dan dat.

Persoonlijk denk ik, dat hyper threading prima is voor de thuis gebruiker maar in de zakelijke wereld waar de chip word gedeeld met andere (e.g. met vm's/containers) een onveilig iets. Je zou in een VM park geen hyper threading moeten willen gebruiken uberhaupt. Dus nee, dat hoort niet bij slijtage.

Dat neemt niet weg dat een fabrikant de performance graag zo positief mogelijk neerzet, en net als bij accu tijd/range, geloof ik een fabrikant niet op die stats.

[.oisyn]

Er gaat altijd een beveilingsissue uit kunnen ontstaan omdat de chip simpelweg moet gokken wat daarna komt en je die zo om de tuin kan leiden

Dit heeft weinig met hyperthreading te maken. Jij hebt het over speculative execution.

Hyperthreading is een implementatie van simultaneous multithreading (SMT) waarbij een enkele core meerdere threads in parallel kan runnen die de resources binnen de core (zoals ALU's en memory fetch units) sharen. Dat is op zich niet inherent onveilig.

[OruBLMsFrl]

Theoretisch veilig te maken hyperthreading, maar in praktijk is wat je schrijft:"waarbij een enkele core meerdere threads in parallel kan runnen die de resources binnen de core (zoals ALU's en memory fetch units) sharen"
Toch al snel en groot risico op data kunnen afkijken van andere threads. Nogmaals de theorie is solide, echter in praktijk om supersnel te schakelen tussen threads en processen, zie je niet altijd alles eerst schoongeveegd worden en dan pas iets anders gaan draaien.

[.oisyn]

Dat klopt, maar dat is niet waar @jaenster het over had, en bovendien kun je er altijd voor kiezen om in het geval van VM's altijd hele cores toe te wijzen aan een enkele VM (zoals @xorpd hieronder ook opmerkt).

echter in praktijk om supersnel te schakelen tussen threads en processen, zie je niet altijd alles eerst schoongeveegd worden en dan pas iets anders gaan draaien.

Dit is niet gelimiteerd tot hyperthreading en is sowieso van toepassing, ook bij pre-emptive multitasking op een enkele hardware thread.

[xorpd]

Het probleem is dat meerdere threads op 1 core informatie kunnen lekken naar elkaar. Dat is eigenlijk alleen problematisch als er meerdere VMs draaien en eenvoudig op te lossen door alleen hele cores toe te wijzen aan een VM.

[OruBLMsFrl]

Je hebt toch net zo goed isolatie nodig tussen core Windows processen en een browser die mogelijk onveilige code van internet draait? Bij VM's worden die risico's misschien nog wat groter, tegelijk even zo goed afhankelijk van wat voor VM's er dan op een platform draaien.

[Dennism]

Dat hangt imho vanaf, voor 2018 en het in de algemeenheid bekend worden van Meltdown / Spectre, was ik het volledig met je eens geweest, en had ik het niet redelijk gevonden om dat mee te nemen als aandachtspunt in een aankoop traject.

Kijk je echter naar de 'doos van pandora' die toen opengegaan is, en waarvan beveiligingsexperts destijds en nu nog steeds aangeven dat dit soort issues nog vele jaren gevonden zullen gaan worden en er bij doorontwikkeling van processoren ook meer van dit soort issues zullen gaan ontstaan nog zolang o.a. speculative execution een ding blijft (en dat zal het blijven, gezien de performance die het oplevert), dat vind ik het heden ten dage eigenlijk onverantwoord om het risico op security issues in de hardware, de mogelijke impact daarvan op zowel software gebied, maar ook performance gebied en dergelijke niet mee te nemen.

Je ziet nu deze weer van Intel, AMD had er gister weer een. En ze hebben gelukkig niet allemaal performance impact, en in een aantal gevallen zie ook dat performance verloren door iedere oplossingen terug wordt gewonnen omdat de opossingen ook meer geoptimaliseerd worden. Maar je kan er mijn inziens op dit moment niet meer vanuit gaan dat welke cpu je nu ook koopt, Intel, AMD, Qualcomm dat deze tijdens de te verwachten gebruiksduur (zakelijk vaak +-5 jaar, al wordt dat ook soms langer) er geen securtity issues kunnen komen die gepatched moeten worden en waarbij je (al dan niet tijdelijk) performance kan verliezen.

[Reactie gewijzigd door Dennism op 27 juli 2024 14:54]

[nzall]

Daarnaast gaat het ook over een crash op processorniveau, dus dat betekent dat het in een multitenant omgeving gevolgen kan hebben voor de VMs van andere gebruikers.

[The Zep Man]

Volgens mij kan elke privilege escalation-kwetsbaarheid op CPU-niveau gevolgen hebben voor de VMs van anderen. Deze kwetsbaarheid legt echter een extra nadruk op beschikbaarheid door de mogelijkheid tot crashen.

[Reactie gewijzigd door The Zep Man op 27 juli 2024 14:54]

[Verwijderd]

Prestaties in de gaten houden is inderdaad een interessante. Heb zelf Linux op een oudere laptop (i7-8565u) draaien, en met booten kan je een vlaggetje zetten 'mitigations=off'. Heb geen benchmarks, maar dit maakt het verschil tussen lekker in gebruik of traag.

[Vogel666]

Apart, ik redeneer precies anderom:
Dat een server crasht is vervelend maar verder niet zo boeiend.
Dat iemand middels privilege escalation maliciouscode kan uitvoeren kan het einde van mijn bedrijf betekenen.

[LieveGeit]

Hoe downloadt men updates voor de CPU? Gaat het automatisch via Windows update?

[xorpd]

Zitten in de BIOS en in je CPU driver.

[Username3457829]

Oftewel je geeft geen antwoord op zijn vraag.

[xorpd]

BIOS updates vind je bij de fabrikant van je moederbord, CPU drivers bij de fabrikant van je processor (al zitten deze laatsten ook in je Windows installatie en soms in je updates).

[The Zep Man]

Fikst.

[Reactie gewijzigd door The Zep Man op 27 juli 2024 14:54]