Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Onderzoekers onthullen vierde variant van Spectre- en Meltdown-lekken

Onderzoekers van Microsoft en Googles Project Zero hebben informatie naar buiten gebracht over een nieuw lek, een zogenoemde vierde variant op de Meltdown- en Spectre-kwetsbaarheid die vooral bij het gebruik van bepaalde browsers beveiligingsissues teweeg kan brengen.

Microsoft en Google spreken van een nieuwe onderklasse van kwetsbaarheden, genaamd speculative store bypass. Deze kwetsbaarheid is net als de eerdere lekken gebaseerd op speculative execution. Volgens Intel is deze vierde variant gedemonstreerd in een 'language-based runtime environment'. Een voorbeeld daarvan is Javascript. In een webbrowser wordt voortdurend Javascript-code uitgevoerd.

Intel zegt dat de al uitgebrachte patches voor de eerdere varianten ook werken voor de nieuwe vierde variant, maar desondanks heeft het bedrijf ook al microcode en software-updates uitgebracht die specifiek voor de vierde variant zijn bedoeld. Bepaalde oplossingen voor kwetsbaarheden zijn standaard uitgeschakeld, zodat gebruikers ze handmatig moeten inschakelen. Intel zegt te verwachten dat moederbordfabrikanten in de komende weken patches in de vorm van bios-updates beschikbaar stellen. Deze kunnen een negatieve impact van 2 tot 8 procent hebben op de prestaties. Ook AMD en ARM komen met patches.

De Spectre- en Meltdown-kwetsbaarheden kwamen in januari aan het licht en maken het uitlezen van kernelgeheugen mogelijk. Meltdown treft vrijwel uitsluitend Intel-processors, terwijl Spectre ook gevolgen heeft voor onder meer ARM en AMD. Meltdown laat het uitlezen van kernelgeheugen toe, terwijl dat bij Spectre geldt voor processen onderling.

Door

Nieuwsredacteur

62 Linkedin Google+

Lees meer

Reacties (62)

Wijzig sortering
Spectre variant 4; wat is er nou precies aan de hand?

Deze variant draait om de 'speculative store bypass'; met andere woorden, er is een Store instructie naar een bepaald adres, en een opvolgende Load instructie kan speculatief van dit adres een oudere waarde uit het geheugen lezen en deze via de van de eerdere Spectre exploits bekende cache side-channel kenbaar maken. Nu zal je je ten eerste afvragen; hoe kan het dat een Load een oudere Store niet ziet? Dit heeft te maken met een agressieve out-of-order optimalisatie in processoren voor zogeheten 'RAW's (read after write) in geheugen;

Wanneer de processor een Load instructie uitvoert, zal hij proberen te bepalen of hij voor hetzelfde adres een Store instructie heeft uit staan, die wellicht nog niet zichtbaar gemaakt is in de cache/geheugen (bijvoorbeeld omdat ze allebei nog op een speculatief pad achter een branch zitten, en je pas het geheugen wilt updaten als je 100% zeker bent). Is dit het geval, dan zal de waarde van de Store doorgestuurd worden naar de Load, zodat deze niet hoeft te wachten om uitgevoerd te worden tot de Store werkelijk zichtbaar is. Dit soort situaties komen veelvuldig voor met operaties op de stack, waar de compiler tijdelijk even een variabele naar toegeschreven heeft en hem dan weer iets later nodig heeft (maar niet genoeg registers had om hem vast te houden, of tijdens function calls met veel argumenten). Nu kan het zo zijn dat het adres van de Store nog niet bekend is, omdat de adres berekening nog niet voltooid is of die waarden afhankelijk zijn van een eerdere berekening. De processor probeert dan (gebaseerd op eerder gezien gedrag van deze programma posities) te voorspellen of deze Load afhankelijk zal zijn van een voorgaande (maar nog niet zichtbare) Store. Wanneer de processor (correct) voorspelt dat deze Load onafhankelijk is, kan de waarde direct uit de caches/geheugen gelezen worden, en loopt alles soepel want je hoeft niet te wachten op de Store. Wanneer hij een afhankelijkheid voorspelt en deze is juist, wacht de Load op de Store, en wanneer deze voorspelling niet juist was heb je alleen onnodig lang gewacht met je Load voordat je in je caches/geheugen gaat kijken. Maar, wanneer de voorspelling onjuuist is dat er geen afhankelijkheid is, dan zal wanneer het adres van de Store bekend wordt de Load en alle opvolgende instructies geannuleerd moeten worden en opnieuw worden uitgevoerd met de correcte data van de Store.

Overigens doen niet alle out-of-order processoren dit, een makkelijkere manier om geheugen consistentie te behouden is namelijk om alleen Loads ten opzichte van Loads out-of-order uit te voeren (want dat is over het algemeen gegarandeerd veilig), en ze nooit een Store speculatief te laten 'inhalen'. Aangezien Intel's x86 vooral in de 32-bit tijd nogal weinig registers had, zullen er veel RAWs voorkomen voor variabele spill/fills van de stack, en hebben ze dit zeer zwaar geoptimaliseerd met hun "memory disambiguator" predictor. Door deze Loads bypass store optie uit te schakelen verliezen ze dus wat performance.

Maar... wat is het probleem nou eigenlijk?

Het probleem zit hem er in dat je op bepaalde momenten in je software stukken geheugen wilt wissen omdat je er tijdelijk bepaalde gevoelige informatie hebt opgeslagen. Denk bijvoorbeeld aan een system call die tijdelijk wat informatie op de stack zet, en wanneer je terugkomt deze weer wist voordat het userspace programma weer verder gaat. Dit wordt altijd prima veilig geacht, maar met voorzichtig genoege timing zou je dergelijke informatie kunnen lezen (door te zorgen dat de wis-operatie die uit Stores bestaat niet door de predictor verwacht wordt dezelfde adressen aan te raken als je speculatief probeert te laden). Nu is dit wel een heel ander kaliber dan het Meltdown (of Spectre v3) probleem waar je het gehele kernel geheugen uit kon lezen, of Spectre v1/v2 waar je de executie van andere code (in de kernel of andere processen) kon beinvloeden. Wat dat betreft lijkt me dit een veel kleiner data/informatielek, maar wellicht zijn er bepaalde corner cases waar het uitermate bruikbaar kan zijn, om bijvoorbeeld bepaalde informatie uit een runtime/sandbox omgeving te verkrijgen.
"Intel zegt dat de al uitgebrachte patches voor de eerdere varianten ook werken voor de nieuwe vierde variant, maar desondanks heeft het bedrijf ook al microcode en software-updates uitgebracht die specifiek voor de vierde variant zijn bedoeld."

Waarom uitbrengen van microcode voor deze specifieke variant als de eerdere patches ook voldoen . Ik snap het niet helemaal.
Waarschijnlijk omdat de eerdere patches een grotere performance impact hebben.
Ah, ja daar heb je een punt. _/-\o_
"Deze kunnen een negatieve impact van 2 tot 8 procent hebben op de prestaties."
Och, ik heb mijn PC toch hoger geklokt... helaas is die winst bij deze verloren gegaan ?
Hier kun je niet makkelijk tegenop 'overclocken'. Als een processor opnieuw data uit main memory (RAM) moet halen, dan kan het zijn dat de processor gewoon echt niets anders kan doen dan tientallen nanosecondes stilstaan en wachten op deze informatie. Een hogere kloksnelheid zal als effect hebben dat je processor meer cycles stil staat, maar in secondes gemeten staat de processor dan net zo lang te wachten.

Het is wel waar dat de instructies tussen zulke cache flushes door sneller uitgevoerd worden met een verhoogde kloksnelheid. Dus je zal wel degelijk een snellere computer krijgen van een hoge kloksnelheid, maar de performance impact van deze patches slaat voornamelijk op een vaste tijdsvertraging per cache flush.

Voor zover ik begrepen heb, zorgen de spectre/meltdown patches ervoor dat deze cache flushes geforceerd plaatsvinden wanneer een processor een context switch uitvoert. Dat gebeurt wanneer een processor wisselt aan welk proces het z'n rekenkracht besteed. Welk proces dat is, wisselt sowieso een aantal keer per seconde, maar wanneer een proces moet wachten op externe communicatie (met een harde schijf, netwerkkaart, etc.), kan een proces al eerder uitgewisseld worden voor een proces dat niet hoeft te wachten. Zo komt het dat sommige workloads (zoals het draaien van een database server) meer last hebben van zulke patches dan andere (bijvoorbeeld het spelen van een spel).

Wat het precieze mechanisme is waarmee deze vierde variant beveiligd wordt, is me nog niet helemaal duidelijk, maar ik vermoed dat het een vergelijkbare aanpak is, en daarmee zullen servers en andere parallelle workloads waarschijnlijk meer last hebben van deze patches dan de gemiddelde eind-gebruiker applicatie/game.

[Reactie gewijzigd door Laloeka op 22 mei 2018 17:21]

Hier kun je niet makkelijk tegenop 'overclocken'. Als een processor opnieuw data uit main memory (RAM) moet halen, dan kan het zijn dat de processor gewoon echt niets anders kan doen dan tientallen nanosecondes stilstaan en wachten op deze informatie. Een hogere kloksnelheid zal als effect hebben dat je processor meer cycles stil staat, maar in secondes gemeten staat de processor dan net zo lang te wachten.

Het is wel waar dat de instructies tussen zulke cache flushes door sneller uitgevoerd worden met een verhoogde kloksnelheid. Dus je zal wel degelijk een snellere computer krijgen van een hoge kloksnelheid, maar de performance impact van deze patches slaat voornamelijk op een vaste tijdsvertraging per cache flush.
Over het algemeen zal hij niet helemaal stil staan te wachten en altijd zoveel mogelijk instructies speculatief proberen uit te voeren, maar je hebt wel in principe gelijk dat overclocken weinig zal helpen omdat je geheugen latency het zelfde blijft. Nou hoef je alleen in het algemeen niet helemaal naar RAM en zal de waarde nog in een van je caches staan, en die schalen over het algemeen qua snelheid wel mee met je kloksnelheid. Je verhaal over cache flushes begrijp ik niet helemaal in deze context, want die vinden niet "zomaar" plaats.
Voor zover ik begrepen heb, zorgen de spectre/meltdown patches ervoor dat deze cache flushes geforceerd plaatsvinden wanneer een processor een context switch uitvoert. Dat gebeurt wanneer een processor wisselt aan welk proces het z'n rekenkracht besteed. Welk proces dat is, wisselt sowieso een aantal keer per seconde, maar wanneer een proces moet wachten op externe communicatie (met een harde schijf, netwerkkaart, etc.), kan een proces al eerder uitgewisseld worden voor een proces dat niet hoeft te wachten. Zo komt het dat sommige workloads (zoals het draaien van een database server) meer last hebben van zulke patches dan andere (bijvoorbeeld het spelen van een spel).
De Meltdown patch deed (in sommige gevallen) TLB flushes, maar niet op modernere implementaties die een notie van Context ID hebben in de TLBs. Een deel van de oplossing voor Spectre v2 was het flushen van je branch predictor. Cache flushes werden juist door de aanvallers gebruikt om de verandering in cache state waar te nemen, dat was niet onderdeel van de oplossing.
Wat het precieze mechanisme is waarmee deze vierde variant beveiligd wordt, is me nog niet helemaal duidelijk, maar ik vermoed dat het een vergelijkbare aanpak is, en daarmee zullen servers en andere parallelle workloads waarschijnlijk meer last hebben van deze patches dan de gemiddelde eind-gebruiker applicatie/game.
Een complete serialisatie (memory barrier) zou voldoende moeten zijn nadat je systeem bepaalde gevoelige informatie heeft overschreven (gewist met Stores), voordat je de controle teruggeeft aan een 'onbetrouwbaar' deel van het programma. Dan weet je zeker dat alle Stores uitgevoerd en zichtbaar in het geheugen zijn, en je niet meer speculatief de oude waarden kan teruglezen.
ik krijg het idee dat er met alle meltdown en spectre patches er een 486 overblijft van bv je moderne i7 7700/6700k

Tuurlijk is dit wat extreem, maar doordat je de updates *moet* installeren (windows en cumulatieve updates)
heb je geen keus meer om evt wel de snelheid te behouden (en wel dan vatbaarder voor aanvallen)
Je kan toch prima updates uitzetten? Als je toch de bewuste keuze maakt om hiervoor kwetsbaar te zijn, wat maakt het dan uit dat je andere beveiligingsupdates niet meer binnen krijgt?

Persoonlijk snap ik niet waarom je die patches niet zou willen hebben, zelfs als je besluit never nooit niet op je gamepc te internetbankieren is toch ergens op die machine bijvoorbeeld je steam wachtwoord te vinden, of zouden lekken als deze een achterdeurtje kunnen vormen naar remote code execution.
Op mijn gamepc kom ik alleen in steam, twitch en discord. Ik kom niet op malafide websites en download alleen in bekende stores als steam, uplay of origin. Ik zie geen reden waarom ik voor dit mijn pc trager moet maken voor beter beveiliging.
heb je dan ook elke vorm van advertenties/javascript geblocked?

Zelf weten hoor, ik vind het best, maar ik snap dan dus niet waarom je uberhaupt windows updates aan hebt staan, als je zo tegen beveiliging aankijkt
Je kan toch prima updates uitzetten? Als je toch de bewuste keuze maakt om hiervoor kwetsbaar te zijn, wat maakt het dan uit dat je andere beveiligingsupdates niet meer binnen krijgt?

Persoonlijk snap ik niet waarom je die patches niet zou willen hebben, zelfs als je besluit never nooit niet op je gamepc te internetbankieren is toch ergens op die machine bijvoorbeeld je steam wachtwoord te vinden, of zouden lekken als deze een achterdeurtje kunnen vormen naar remote code execution.
in het geval van windows updates: bij 10 is het nagenoeg onmogelijk om geen updates te krijgen.

mocht je dat wel lukken dan kan je er donder op zeggen dat windows er alles aan zal doen om je systeem minder bruikbaar te maken.
Zit je in ieder geval weer op de stock speed ;)
Precies, dat bedoelde ik ook, vóór de patch is de PC overclocked, ná de patch blijft hier mogelijk niets meer van over?
Ik heb begrepen dat bij Spectre-NG het mogelijk is om uit de virtuele machine te breken, en zo bij de host te recht te komen en/of dat het mogelijk is om keys te onderscheppen.

De Nederlandse bank heeft het goedgekeurd, dat banken o.a. de AWS-cloud gebruiken.
Zou deze goedkeuring niet herzien moeten worden door DNB?

https://thehackernews.com...pectre-vulnerability.html
Ik neem aan dat AWS al lang de Spectre en Meltdown patches hebben doorgevoerd.
Wat zeggen ze ook al weer over aannames? :)

Maar in het tempo dat er nieuwe bugs gevonden worden, is het ook voor een AWS niet mogelijk alles op tijd te patchen.
Inplaats van speculeren kan je natuurlijk ook even opzoeken, hoe of wat. https://aws.amazon.com/se...y-bulletins/AWS-2018-013/

Voor iedereen hieronder: Ik reageerde vooral over stukje over aannames, Overigens staat in het artikel: "Intel zegt dat de al uitgebrachte patches voor de eerdere varianten ook werken voor de nieuwe vierde variant".

[Reactie gewijzigd door jayjay1990 op 22 mei 2018 15:02]

Volgensmij is https://aws.amazon.com/se...y-bulletins/AWS-2018-015/ relevanter voor deze specifieke vulnerability.
Uit jouw link:
Concerning: CVE-2017-5715, CVE-2017-5753, CVE-2017-5754

Update As Of: 2018/03/05 3:00 PM PST
Zoek de CVE bulletins er even bij. Ik denk niet dat deze vierde variant daar al bij zit. Deze pagina is ook nog eens op 5 maart voor het laatst bijgewerkt, ver voor de bekendmaking van de vierde variant. Dus voor het moment heeft dit artikel nog niets over de nieuwste variant. ;) De door @Hakulaku gegeven link is relevanter, die is dan ook vandaag bijgewerkt. ;)
Ik speculeer niet.
AWS en welke cloud provider dan ook kunnen alleen maar updates uitvoeren voor wat bekent is en waar patches voor zijn.

Maar in het tempo dat er nieuwe bugs gevonden worden vraag ik mij hard op af, of het wel verstandig om om een shared cloud omgeving te gebruiken voor gevoelige zaken.

Meltdown en Spectre zijn niet de eerste bugs, waarmee je uit een VM kan brengen, gemiddeld komen er per jaar zo'n 2 a 3 van dit soort bugs naar boven.
Volgens mij is wat je net omschrijft definitie van speculeren.
http://www.woorden.org/woord/speculeren
dingen bedenken die misschien waar zijn of misschien gebeuren
Het is een feit dat je alleen iets kan patchen waar van je weet hebt.
Het is een feit, dat er bugs zijn, waardoor je uit je VM kan breken.

Ik weet zeker, dat er nog meer bugs naar boven, waarmee je uit een VM kan breken. Daar is het tenslotte software voor.

ruim 10 jaar geleden, was ik idd aan het speculeren, dat dit een risico van virtual zou kunnen zijn. Maar de tijd heeft ondertussen bewezen.
Lees anders eerst even Heise.de: Het grootste beveiligingsgat van de meerdere 'Spectre NG'-gaten gaat Intel pas in Augustus pleisteren. De aanvalsmethode is nu nog geheim, maar als criminelen of drieletterdiensten hem al hebben, hebben ze tot Augustus vrij spel.
"Assumptions are the mother of all f**kups" toch?
Ik nam al aan dat dat het was ;) hah! See what I did there!
Of: when you ASSUME, you make an ASS out of U and ME.
je mag op het internet best vloeken hoor
Dat doe ik buiten het internet al méér dan genoeg ;)
Deze nieuwe variant is vandaag wereldkundig gemaakt, dus ik denk niet dat die patches al zijn uitgerold.
Het zeer aannemelijk, dat bedrijven als AWS en Google de patches wel eerder ontvangen hebben, dan de rest van de wereld. Je zit dit namelijk steeds vaker bij critische bugs, dat eerst de grote jongen de patches krijgen en een paar weken later het wereldkundig gemaakt wordt.

Heel vervelend vind ik deze ontwikkeling, maar ja wat doe je er tegen?
Kan maar zo, vind ik het erg? Nee, dat ze de patch gekregen hebben wil nog niet zeggen dat het uitgerold is. Een omgevings als AWS is zeer complex en is niet van de ene op andere dag uitgerold. Overigens heeft Intel aangegeven aan welke soort partijen ze de patch hebben gegeven, zie CH4OS in 'nieuws: Onderzoekers onthullen vierde variant van Spectre- en Meltd....
"Intel zegt dat de al uitgebrachte patches voor de eerdere varianten ook werken voor de nieuwe vierde variant"
Staat in het bericht...
Quote dan de gehele zin, ipv selectief alleen de eerste helft te doen;
...maar desondanks heeft het bedrijf ook al microcode en software-updates uitgebracht die specifiek voor de vierde variant zijn bedoeld.

[Reactie gewijzigd door CH4OS op 22 mei 2018 15:29]

Dat is toch absoluut irrelevant. Als de eerste patches werken voor deze variant, is het niet nodig om nog patches door te voeren voor deze. En zoals ik al zei: ik neem aan (wat ook bevestigd is door anderen) dat AWS de eerdere patches al doorgevoerd heeft.
Dat is toch absoluut irrelevant. Als de eerste patches werken voor deze variant, is het niet nodig om nog patches door te voeren voor deze. En zoals ik al zei: ik neem aan (wat ook bevestigd is door anderen) dat AWS de eerdere patches al doorgevoerd heeft.
Schijnbaar is het relevanter dan je denkt. Als dat werkelijk zo was, had Intel natuurlijk helemaal niets hoeven te patchen. Laat staan wederom een patch ervoor uitbrengen. Denk je dit werkelijk of zit je gewoon te trollen nu? Het is niet dat Intel niets beters te doen heeft he. ;) Schijnbaar zijn er dus wel situaties waarbij deze vierde variant (ondanks de eerdere patches) alsnog te misbruiken is, anders hoeft Intel niets te patchen.

EDIT:
Dit staat in het persbericht (al is die reeds gelinkt in het artikel):
Starting in January, most leading browser providers deployed mitigations for Variant 1 in their managed runtimes – mitigations that substantially increase the difficulty of exploiting side channels in a web browser. These mitigations are also applicable to Variant 4 and available for consumers to use today. However, to ensure we offer the option for full mitigation and to prevent this method from being used in other ways, we and our industry partners are offering an additional mitigation for Variant 4, which is a combination of microcode and software updates.

We’ve already delivered the microcode update for Variant 4 in beta form to OEM system manufacturers and system software vendors, and we expect it will be released into production BIOS and software updates over the coming weeks.
This mitigation will be set to off-by-default, providing customers the choice of whether to enable it. We expect most industry software partners will likewise use the default-off option. In this configuration, we have observed no performance impact. If enabled, we’ve observed a performance impact of approximately 2 to 8 percent based on overall scores for benchmarks like SYSmark® 2014 SE and SPEC integer rate on client1 and server2 test systems.

This same update also includes microcode that addresses Variant 3a (Rogue System Register Read), which was previously documented publicly by Arm* in January. We have not observed any meaningful performance impact on client or server benchmarks with the Variant 3a mitigation.3 We’ve bundled these two microcode updates together to streamline the process for our industry partners and customers. This is something you will see us continue, as we recognize that a more predictable and consolidated update process will be helpful to the entire ecosystem.
In concreto is het dus een patch om te zorgen dat je er zeker van kan zijn dat de vierde variant echt gepatched is, al is het niet meer dan een bepaalde functie uit te schakelen 'by default', die eventueel weer aan te zetten is waarbij je ook niet vatbaar bent voor het lek, maar lever je 2%-8% performance in.

[Reactie gewijzigd door CH4OS op 22 mei 2018 16:27]

Ligt er ook aan wat je op AWS draait. Het is prima mogelijk om een volledig custom VM te draaien met een kernel naar keuze. Dan is het dus per se niet gepatcht, want buiten software om kunnen ze niet "even" alle cpu's in the hypervisors vervangen door niet-vatbare cpu's (als die al bestaan). Ze zullen de hypervisors zeker wel gepatcht hebben, maar zou dat voldoende zijn?...

Ik neem aan (daar gaan we weer) dat banken hevig gecustomized software draaien, omdat banken nou eenmaal zo zijn. Legacy-systemen van 800 jaar oud moeten immers blijven draaien. Dus het kan goed zijn dat banken een eigen VM draaien, en dus zelf verantwoordelijk zijn voor patches van de kernel. Maar wie weet hebben ze die patches nog niet doorgevoerd, omdat dat 800 jaar oude systeem dan ook gepatcht moet worden, terwijl niemand daar aan durft te komen.

Dat is worst case scenario dus. Best case scenario is dat ze alles netjes gepatcht hebben, maar dat er nog steeds een hoop data bij een Amerikaanse derde partij ligt te wachten op het volgende lek.

[Reactie gewijzigd door _Thanatos_ op 22 mei 2018 13:31]

Amazon bij AWS kan als supervisor wel bij de Guests gaan kijken...

Welkom in de wereld van data mining door gewoon te spieken bij alles wat je op hun computer doet of opslaat.
Welkom in de wereld van data mining door gewoon te spieken bij alles wat je op hun computer doet of opslaat.
'There is no cloud, it’s just someone else’s computer'.
Zijn er gebruikers die dit kunnen bevestigen?
Met deze tool kan je checken of je systeem beschermd is: https://www.grc.com/inspectre.htm
De laatste update is van 11 April, dus werkt mogelijk niet voor de nieuwste lekken.

Heb zelf de bios firmware van mijn moederboard moeten updaten om Spectre "protected" te zijn.
Mmmm...
Spectre & Meltdown Vulnerability Status

System is Meltdown protected: YES
System is Spectre protected: NO!
Microcode Update Available: YES
Performance: GOOD
CPUID: 306C3
Same here...
Al gekeken voor een moederboard firmware update?
DIe is er (nog) niet.
Nou vraag ik me af als che chips uitkomen met een hardware fix en hopelijk geen cpu performance impact hebben de bios fixes en windows update fixes dan nog steeds een performance impact?
Ze zouden immers niet meer nodig zijn.
Klopt, die zijn dan niet meer nodig. in de bios moet er dan ook voor ELKE cpuid een dedicated microcode patch aanwezig zijn. Voor nieuwere cpus zal dit gedeelte dan niet meer gepatched zijn.
Volgens Intel is deze vierde variant gedemonstreerd in een 'language-based runtime environment'. Een voorbeeld daarvan is Javascript. In een webbrowser wordt voortdurend Javascript-code uitgevoerd.
Kan de bron zo snel niet vinden, maar ooit de vuistregel gelezen dat als je een 3e partij code laat uitvoeren op jouw systeem, je het systeem als gecompromitteerd moet beschouwen.

Die regel blijkt dus nog steeds op te gaan.
[...]

Kan de bron zo snel niet vinden, maar ooit de vuistregel gelezen dat als je een 3e partij code laat uitvoeren op jouw systeem, je het systeem als gecompromitteerd moet beschouwen.

Die regel blijkt dus nog steeds op te gaan.
Wat een onzin regel, vrijwel alle systemen gebruiken software van derde partijen die uitgevoerd wordt. Je OS komt van een derde partij, de firmware die daarvoor wordt geladen komt van een derde partij etc.

Dan kun je beter gewoon stoppen met het gebruiken van een computer en in een hutje op de hei gaan wonen.
Wat een onzin regel, vrijwel alle systemen gebruiken software van derde partijen die uitgevoerd wordt. Je OS komt van een derde partij, de firmware die daarvoor wordt geladen komt van een derde partij etc.
Dat is duidelijk niet wat daarmee wordt bedoeld 8)7. De verwijzing is naar code die niet door jou (of je systeembeheerder oid) is geïnstalleerd, maar van een externe bron wordt ingeladen. Virtual machines en sandboxing zou dat in theorie veilig moeten maken, maar er zijn natuurlijk altijd potentiële attack vectors om daarbuiten te kunnen treden.
daar gaan we weer hoor. :( ik was nog niet eens helemaal beschermd tegen de oudere varianten. mag hopen dat ze hier wat van leren zodat toekomstige cpu's geen kwetsbaarheden meer bevatten. ik lever liever wat performance in als daar betere beveiliging tegenover staat.
A vulnerability in the CPU kernel that has been present and undetected for 20 years?
There are some that have been present way longer than that, some even became features[1]

It's just that as far as we know nobodies yet found a way to exploit them...

[1] The oldest that most will remember was the 86 "wrap around" issue. Using segment registers and offsets It was easy to create a "physical address" above 1M. But due to the external bus it actually "wrapped it around" to the bottom of memory which got used by programmers including those at MS who were writting MS-DOS. All should have known better, especially Intel with it's plans for 286 and later processors. So when the 286 came along an external hardware fix (A20 line gate) got added, but this in turn went wrong with the 386, then when internal cache poped up in the 486 ... It took quite a while (Haswell IIRC) to sort things out. And this was an oh so simple and well recognised and entirely predictable problem...

[Reactie gewijzigd door sugarlee89 op 22 mei 2018 13:20]

Beetje een vaag verhaal. Bronvermelding had wel zo fijn geweest, maar een Google search naar de tekst verwijst naar een comment onder een artikel.

Het is niet zozeer een hardware bug, het is een software "bug" (of eigenlijk het exploiteren van undocumented gedrag) waar ze om compatibiliteitsredenen een hardware-oplossing voor hebben moeten verzinnen. Waar het om gaat is dat de oude 8088/8086/80186 CPU's maar 20 adresbits hadden op de adresbus, zodat ze max 1MB geheugen aan konden spreken. De 16-bits processoren gebruikten een segment:offset addressering, waarbij het fysieke adres gelijk is aan segment*16+offset. Aangezien zowel de segment als offset registers 16 bits waren, is het hiermee mogelijk om geheugenadressen boven de 1MB aan te spreken. Omdat er maar 20 adreslijnen waren, mapte de adressen 0x100000..0x10ffef naar 0x000000..0x00ffef. Sommige software maakte daar handig gebruik van, zoals MS-DOS zelf, omdat ze dan maar 1 segment register nodig hadden om zowel kernel-code en data aan te spreken (aan het eind van de 1MB range), als standaard zaken zoals de interrupt table die juist aan het begin van de 1MB range stonden.

Maar ja, toen kwam de 286 met 24 bits adreslijnen, en toen was de bestaande software ineens incompatible omdat die wrap-around niet meer plaatsvondt. IBM, die een PC rond de op dat moment al bestaande 286 aan het ontwerpen was, heeft daar een moederbord-oplossing voor bedacht, namelijk om een logic gate voor de A20 lijn te zetten zodat die op 0 geforceerd kon worden, en zo de wrap-around te forceren voor oudere software (en het signaal om dat te regelen te huisvesten in de keyboard controller, want die had nog wel een ongebruikte bit over |:(). De CPU wist hier feitelijk niets vanaf.

Uiteindelijk zijn in de loop der tijd steeds meer geheugenzaken naar de CPU verhuisd, en het A20 probleem kwam daardoor steeds weer terug. De 386 had een virtual memory controller om virtuele geheugenadressen te mappen op fysieke adressen. Dit maakte overigens een andere oplossing mogelijk, omdat je de virtuele adressen boven de 1MB dan gewoon terug kon mappen naar de eerste MB in fysiek geheugen. De 486 kreeg een cache (die werkt op basis van virtuele adressen), dus om dat correct te laten werken moest de chip zelf de adressen als gelijk gaan beschouwen. Vanaf Haswell is die legacy compatibiliteit idd stopgezet.

Maar zoals gezegd, dit heeft puur te maken met backwards compatibiliteit, het is absoluut geen hardware bug zoals je meltdown en spectre wel kunt beschouwen.
Zie je wel dat niets werkt tegen die meltdown en zelfs spectre. Er zullen gewoon nieuwe ontwerpen moeten komen.

Op dit item kan niet meer gereageerd worden.


Call of Duty: Black Ops 4 HTC U12+ dual sim LG W7 Google Pixel 3 XL OnePlus 6 Battlefield V Samsung Galaxy S9 Dual Sim Google Pixel 3

Tweakers vormt samen met Tweakers Elect, Hardware.Info, Autotrack, Nationale Vacaturebank en Intermediair de Persgroep Online Services B.V. © 1998 - 2018 Hosting door True

*