Cookies op Tweakers

Tweakers is onderdeel van DPG Media en maakt gebruik van cookies, JavaScript en vergelijkbare technologie om je onder andere een optimale gebruikerservaring te bieden. Ook kan Tweakers hierdoor het gedrag van bezoekers vastleggen en analyseren. Door gebruik te maken van deze website, of door op 'Cookies accepteren' 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 vinden nieuwe 'speculative execution'-kwetsbaarheden in Intel-cpu's

Onderzoekers hebben opnieuw een lek gevonden in het speculative execution-gedeelte van Intel-cpu's. De bug krijgt de naam CacheOut. Aanleiding tot het onderzoek waren eerdere chipkwetsbaarheden, maar nu kon specifiek worden gezocht naar uitgelekte bufferdata.

Het onderzoek naar het lek werd gedaan door wetenschappers van de Universiteit van Michigan en de Universiteit van Adelaide. Ze borduren voort op eerder onderzoek van de VUSec-afdeling van de Vrije Universiteit in Amsterdam, die eerder lekken zoals Meltdown en Spectre, en vorig jaar RIDL ontdekte. Dezelfde VUSec-onderzoekers hebben ook bij dit onderzoek een rol gespeeld. De nieuwe kwetsbaarheid heet CacheOut, omdat ze data uit de cache duwt zodat die af te lezen is.

Het lek zit in speculative execution, een functie in Intel-cpu's waarmee bepaalde berekeningen worden gedaan voordat ze nodig zijn. Door dat trucje worden de cpu's vaak sneller. Door speculative execution worden echter ook bepaalde berekeningen naar de buffercache uitgelekt. Onderzoekers toonden eerder al aan dat het mogelijk was die uitgelekte data uit de cache uit te lezen. CacheOut is een nieuwe manier om de cache af te luisteren. De onderzoekers tonen aan dat het mogelijk is om data te laten uitlekken uit de kernel van het besturingssysteem, uit virtuele machines op het systeem, en zelfs uit de Security Guard Extensions in de secure enclave van een chip. Dat is een functie voor Intel-chips waarmee derde partijen hun software in de standaard secure enclave kunnen draaien.

Opvallend aan de kwetsbaarheid is dat die een stukje verdergaat dan Spectre en Meltdown, en RIDL. De nieuwe bug weet de mitigaties die Intel voor die eerste instelde, te omzeilen. Voor de RIDL-aanvallen had Intel een andere mitigatie, waarbij de uitgelekte bufferdata werd overschreven door willekeurige content, zodat niet meer te achterhalen was wat daar oorspronkelijk stond. De onderzoekers hebben nu echter een manier ontdekt om data uit de L1-D-cache te verplaatsen naar een andere buffer, waaruit ze de data vervolgens kunnen achterhalen. Opvallend is ook dat het met het lek mogelijk is om specifieke output te achterhalen en niet alleen willekeurige, zoals bij RIDL het geval was. Als bewijs achterhaalden de onderzoekers een aes-sleutel uit de cache.

De bugs zitten alleen in Intel-cpu's. AMD-chips zijn volgens de onderzoekers niet kwetsbaar, omdat die geen gebruik maken van Transactional Synchronization Extensions, zoals Intel doet. De onderzoekers hebben het onderzoek gecoördineerd met Intel. Het bedrijf heeft inmiddels een update voor de microcode voor de cpu's uitgebracht, en tips voor een mitigatie gegeven. Omdat het echter om een kwetsbaarheid in de hardware gaat, is die niet volledig op te lossen.

Wat vind je van dit artikel?

Geef je mening in het Geachte Redactie-forum.

Door Tijs Hofmans

Redacteur privacy & security

28-01-2020 • 10:05

123 Linkedin

Submitter: NiLSPACE

Reacties (123)

Wijzig sortering
Zie hier de lijst met CPU's waar deze kwetsbaarheid betrekking op heeft.

Verder kan je in deze lijst zien wanneer Intel voor het laatst een microcode update heeft uitgebracht voor een specifieke processor. Het formaat (alle waardes in hex) is:
<CpuFamily>-<Model>-<Stepping>

Onder Linux kan je die waardes uit /proc/cpuinfo halen en in Windows kan het via CPU-Z en ongetwijfeld via PowerShell. Hou er rekening mee dat dit mogelijk decimale waardes zijn, en dat je het één en ander moet converteren. Linux toont decimale waardes en CPU-Z toont de waardes in hex (waar je mogelijk een 0 aan moet toevoegen per waarde).

[Reactie gewijzigd door The Zep Man op 29 januari 2020 06:46]

Noobmode/
Ik heb sinds ik mijn pc geïnstalleerd heb niet mijn cpu drivers geupdate. Kan ik deze speculative execution'-kwetsbaarheden fixen door een drive update van Intel te downloaden of is dit niet mogelijk?
Linux update de microcode van je cpu als de nieuwe kernel dat nodig heeft.
Linux update de microcode van je cpu als de nieuwe kernel dat nodig heeft.
Heeft niets met nieuwe kernels te maken. Microcode zit in een los bestand dat naast de kernel en initramfs ingeladen wordt tijdens het opstarten. Dit kan onafhankelijk van de kernel vernieuwd worden via een package, wat veel distributies doen.
Via Windows update in bepaalde gevallen. Het meest is trouwens gewoon een recente bios installeren wanneer beschikbaar. Dan ben je namelijk in alle gevallen beschermd en niet alleen wanneer je OS volledig up to date is.
Zijn niet al hun processors vulnerable? Ik zie bijvoorbeeld Xeon E5-2690 er niet tussen staan. Of kijk ik verkeerd?
Zie dit. Daar komt de lijst met producten waarop deze kwetsbaarheid van toepassing is vandaan.
Mooie tekst van Intel hoor. "Allows an authenticated user..." - ik wist niet dat je op een CPU kon inloggen. Al is het misschien moeilijk om een TSX-flow te bereiken als je geen binary kan installeren, en een binary installeren moet je logischerwijs een lokale gebruiker voor zijn. Zoiets?
Mooie tekst van Intel hoor. "Allows an authenticated user..." - ik wist niet dat je op een CPU kon inloggen.
Met 'authenticated user' bedoelen ze een gebruiker die code kan uitvoeren. Daarvoor moet je over het algemeen op een bepaalde manier aangemeld zijn op het systeem, tenzij je gebruik maakt van een andere kwetsbaarheid of een verkeerd geconfigureerd systeem.

Let ook op dat de 'authenticated user' niet de dader hoeft te zijn. Het kan ook een onwetende slachtoffer zijn die een verkeerde website bezoekt. Hierom worden er steeds meer mitigaties in browsers ingebouwd om misbruik van dit soort kwetsbaarheden te voorkomen.
In dit specifieke geval gaat het om een kwetsbaarheid in de TSX instructies. Zoals gemeld heeft een AMD die niet. Generieke x86 code zoals in een browser zal die TSX instructies dus ook nooit gebruiken, ook niet vanuit de Javascript Engine.

Het gaat dus wel degelijk om gebruikers die de mogelijkheid hebben om willekeurige executables uit te voeren.
Als het gaat om TSX - TSX is een speciale server-feature waarmee een reeks instructies kan worden 'teruggedraaid' op software-niveau. Je kan er een low-level lock mee maken dat niet blokkeert, maar de instructies na dat lock worden teruggedraaid als een ander je voor bleek te zijn.
Reuze krachtig, maar ook een fantastische manier of speculative execution uit te buiten, en ook de zwakheden daarin uiteraard.
Ik vermoed dat Intel dit ziet als een value-added feature, voor server-CPUs.
(De eerste releases van TSX waren onbruikbaar buggy, en daarom uitgeschakeld).
Ah nee... jammer i5 6600 staat er toch wel tussen (Skylake S)

[Reactie gewijzigd door AtariXLfanboy op 28 januari 2020 12:12]

Je kunt HT ook gewoon uitschakelen en OpenBSD doet dat standaard al. Ik heb het zelf nog niet gedaan bij mijn i7-6700HQ en i7-7700HQ, maar ik zal er binnenkort eens naar kijken.
Sorry ik had m'n reactie al gewijzigd, maar idd ... kan uiteraard wel performance verlies opleveren, want dat HT hebben ze er natuurlijk niet voor niets op de CPU gezet.
Als je linux draait, vanaf kernel 4.4, dacht ik, kan je het live aan en uit zetten. Dan kan je bijvoorbeeld als je iets moet compileren of iets dergelijks, het even snel aan, en weer uit zetten. Ik heb alle patches disabled, en gebruik die methode. Qua prestaties merk ik er vrij weinig van, tenzij je software moet compileren.

om uit te zetten
echo off > /sys/devices/system/cpu/smt/control
de opties zijn: on, off, forceoff

[Reactie gewijzigd door denPes op 28 januari 2020 14:38]

De 6600 heeft geen hyperthreading.
Het was in het algemeen bedoeld. Mijn processoren hebben wel HT en ik zou wel willen testen hoeveel het in prestaties scheelt. Als het niet veel uitmaakt, schakel ik HT namelijk ook gewoon uit in UEFI en/of de kernel.
Hyperthreading is niet per se nodig als de aanvaller opdezelfde thread zit.
De architectuur van intel is nauwelijks veranderd sinds skylake dus dat is niet zo verrassend.
Dank voor de link, Whiskey Lake, ik heb wat gemist, biedt met fluid cooling nieuwe dimensies :)
And another one...

Ik hoop dat ze bij de volgende architectuur de boel wat meer op safety inzetten
And another one...

Ik hoop dat ze bij de volgende architectuur de boel wat meer op safety inzetten
Het begint er op te lijken dat ze in elk geval niet minder op safety kunnen inzetten :) .

De huidige architectuur is een voortbouwing van de Core architectuur, die op zich weer gebouwd is op de Pentium M architectuur. Die laatste was de zuinige laptop variant ten tijde van de energieslurpende Netburst architectuur (Pentium 4). Die Pentium M architectuur is op zich uiteindelijk gebaseerd op de Pentium Pro, uit 1995.

Nu is er al enorm veel veranderd, maar uiteindelijk is er elke keer voortgebouwd op de generatie van toen, wat toch elke keer beperkingen zal hebben bij het intruduceren van de nieuwe architectuur. Om echt serieus op safety in te zetten vrees ik dat ze beter van de grond af aan beginnen aan een nieuwe architectuur. Als ze daar al niet mee bezig zijn (maar daar heb ik geen weet van).
Het grappige is wel dat de meeste van deze fouten niet lijken te komen uit het oude Pentium pro stuk, maar meer uit hyperthreading en Core/Core 2. Dus daar zijn ze (in een poging AMD 64 bij te halen) uit de bocht gevlogen.

Volgens mij was de meeste recente Intel CPU zonder problemen een eerste generatie ATOM (A270?), die dingen hebben zijn hyperthreading en zijn ook niet OoOE, want moest allemaal heel simpel en low power :P

Zelfde zag je ook bij ARM, de Cortex A53 in mijn telefoon is nog gewoon in Order, de wat meer high end varianten zijn Out of Order, en zijn dus wel vatbaar voor SPECTRE
maar dan snap ik eerlijk gezegd niet waarom er geen oudere i7's en i5's enzo in die lijst staan.
Mijn i7 2600 staat er b.v. niet tussen (altijd goed om een tijd achter de trend aan te hiphoppen blijkt maar weer haha)
Ik heb net even de lijst bekeken, die lijst is puur de CPUs waarvoor intel een microcode update uitbrengt, waarschijnlijk is je 2600 dus net zo lek, maar gewoon zodanig EOL, dat ze er geen updates meer voor uitbrengen.
Dit klopt niet, de lijkt klopt gewoon, hier een lijst met meer detait: https://software.intel.co...ted-l1d-eviction-sampling en https://software.intel.co...-vector-register-sampling
Veel Intel cpu's zijn niet kwetsbaar, waaronder Sandybridge omdat deze exploit TSX nodig heeft. Een feature die pas redelijk recent actief is op Intel cpu's, namelijk in enkele Broadwell Sku's en Skylake en nieuwer.

De nieuwste generaties cpu's zijn echter dan wel op hardwarematige wijze beveiligd, cpu's (of nieuwe steppings van bestaande cpu's) uitgebracht in Q4 2018 of later zijn in hardware beveiligd.
Dank voor de correctie! Alles voor Skylake is dus daadwerkelijk imuun.
Kan goed zijn dat die inderdaad voor deze specifieke vulnerability niet kwetsbaar is, of misschien is ie gewoon niet getest. Ik had het ook meer in het algemeen over de basis kwa SE/OoOE/SMT, en waar meltdown/spectre vandaan kwamen.

Persoonlijk zie ik eigenlijk alle nog bruikbare (kwa performance) Intel CPUs als "lek"
Dat die er niet bij staat is logisch. Deze vunerability leunt op TXS support. Deze instructies zitten niet op cpu's voor Broadwell (Haswell heeft ze wel, maar ze zijn uitgeschakeld op de meeste Haswell en Broadwell cpu's).

[Reactie gewijzigd door Dennism op 28 januari 2020 13:41]

Het kan zijn dat ze processoren die end of life zijjn niet meer hebben getest.
Ik heb meerdere machines met ARM Cortex A53 cores en als ik `lscpu` uitvoer op Linux 5.4 op mijn desktop krijg ik wel deze regel eruit:

Vulnerability Spectre v1: Mitigation; __user pointer sanitization.

Dat is dan ook de enige kwetsbaarheid die aangegeven wordt en ik weet niet of deze in Cortex A55 en A76 en nieuwer aanwezig is en eventueel verholpen is.
Hmm, google levert toch wat blogs op waarom de A53 imuun zou moeten zijn:
https://www.raspberrypi.o...e-to-spectre-or-meltdown/

Ik baseer mezelf ook vooral op wat ik destijds heb uitgezocht, het kan goed zijn dat een van de spectre subgevallen die daarna zijn gevonden alsnog op de A53 werkt, of er een andere reden is waarom die patch toch aan staat.
maar meer uit hyperthreading en Core/Core 2. Dus daar zijn ze (in een poging AMD 64 bij te halen) uit de bocht gevlogen.
De superagressieve prefetchers zijn het moment van introductie, waardoor een Core/Core2 CPU een AMD met meer cores en hogere klok gewoon zijn achterwerk liet zien. Op dat moment hoognodig voor Intel, want de netburstperiode was catastrofaal aangezien AMD toen gewoon betere producten had.
Eigenlijk vreemd dat dit nog zo lang op zich heeft laten wachten, want ergens is het natuurlijk logisch dat superaggressieve prefetch zonder enige security check vooraf (dat zou de boel weer vertragen), beveiligingsissues met zich meebrengt.
Eigenlijk heeft Intel dus 10 jaar gehad om de techniek te verbeteren en dit issue er niet meer te laten zijn voordat het ontdekt werd. Ze kunnen mij niet wijsmaken dat er niemand aan veiligheid gedacht heeft, de prioriteit op dat moment was echter de snelste zijn.
Daarna hebben ze enkel maar ingezet op de afstand vergroten, terwijl AMD met Bulldozer een blunder maakte waardoor die druk er voor Intel de daarop volgende periode niet eens meer zo was.
In die tijd waren de checks ook helemaal geen security checks. De checks waren puur om te zorgen dat je de goede byte uit de cache haalde. Het OS zou er wel voor zorgen dat jij in jouw address space alleen je eigen bytes had, dat was de security.
Het grappige is vooral dat er weinig gepusht wordt door de markt om dit te veranderen. Stel je voor dat dat in andere branches zo was: dan reden we nu bijv. in auto's met een onderstel dat in wezen teruggaat naar een onderstel uit de jaren 70 (net als jouw Pentium Pro-voorbeeld)!

[Reactie gewijzigd door TheVivaldi op 28 januari 2020 12:23]

Ze waren nog niet begonnen met een nieuwe architectuur, toen de eerste concurenten al populairder werden. Intel heeft rond de pentium architectuur hier veel over gecommuniceerd en wat pogingen gedaan zoals de itanium architectuur om los te komen van x86.

Maar inmiddels zijn er al nieuwe architecturen die steeds populairder worden en zelfs vanuit mobile devices hun weg hebben gevonden naar laptops, desktops en zelfs servers (amazon met name). Denk dat ze nu te laat zijn, tenzij ze met een heel innovatieve oplossing komen.

Komen ze niet met iets innovatiefs, dan vrees ik dat het spel binnen nu en iets van 10 jaar voorbij is qua intel cpu's. Mede omdat verbruik steeds belangrijker wordt. Intel probeert al tijden net zo groot te worden als op pc gebied met hun chips, maar dat lijkt nog niet te lukken.

Edit: itanium even gegoogled, kon er niet opkomen.

[Reactie gewijzigd door 2green op 28 januari 2020 14:07]

Sorry, maar dat verhaal "zelfde architectuur" is maar heel erg beperkt waar. Zo had de Pentium M bijvoorbeeld maar 2 nivo's cache, terwijl alle CPU's waar we het hier over hebben 3 nivo's cache hebben. Je ziet dus dat de cache kant van de architectuur wel degelijk verandert, en dat is nu juist de kwetsbare laag.
Met een beetje geluk gaat enterprise ook meer richting AMD met al deze lekken.
AMD en Intel hebben beide last van dit soort lekken. Processoren worden vaak gebaseerd op modellen van vorige generaties, want ontwerpen is gewoon een dure kostbare bezigheid. Dus als er in een model van 7 jaar oud een issue zat en je hergebruikt dat elke keer weer als basis....

Zonder te controleren staat de teller voor Intel overigens wel hoger dan AMD volgens mij. En AMD wordt opdracht ook wel interessant voor enterprise, dus dat is we leen goed ding :)

[Reactie gewijzigd door n9iels op 28 januari 2020 10:17]

Echter zit er wel een enorm verschil in de hoeveelheid. AMD heeft momenteel 16 CVEs, Intel maar liefst 246.
Enkel een lijstje CVE's opdreunen zegt natuurlijk niet zoveel, die lijst is immers voor al Intels producten, van cpu's, gpu's, netwerkkaarten, chipsets tot alle software die ze ooit geschreven hebben.

De meeste CVE's van Intel hebben dan ook betrekking op software.

Waar in de lijst van AMD 13 van 16 CVE's cpu gerelateerd zijn en 3 software gerelateerd.
Kom ik bij Intel op zo'n 30 CVE's die direct cpu gerelateerd zijn, de rest heeft betrekking op andere producten.

Intel heeft inderdaad meer CVE's voor cpu's, maar simpelweg de 246 CVE's van Intel tegenover de 16 van AMD zetten zonder verdere duiding is niet heel erg relevant aangezien beide bedrijven een totaal verschillend product portfolio hebben.

Tomshardware had hier laatst ook al artikel over waarin ze dezelfde fout maakten: https://www.tomshardware....md-most-secure-processors

Wil je AMD en Intel vergelijken moet je enkel naar de CVE's kijken gerelateerd aan CPU's.

Daaruit kun je zeker opmaken dat AMD momenteel de veiligere is van de 2.
Met nadruk op 'momenteel'. Want dat een white-hat onderzoeker ze niet gevonden heeft, betekend helaas niet dat een black-hat onderzoeker dat niet heeft. Eigenlijk het enige dat je kunt zeggen is dat zowel AMD als Intel security issues kennen.
Wat een nutteloze kolder. Zo kan u ook redeneren dat zonder gordel al bellend rijden met je ogen dicht zonder rempedaal in je auto net zo gevaarlijk is als vooruitkijkend zonder telefoon met gordel met rempedaal; want bij allebei vallen doden.

Het enige wat mensen die er verstand van hebben ervan zeggen, is dat de bron-oorzaak bij Intel niet opgelost is, terwijl AMD er geen last van heeft.

Intel lost de oorzaak (dak is een zeef) niet op, maar doet alleen iedere maand een pleistertje over het gaatje van de zeef dat beveiligings-onderzoekers toevallig die maand gevonden hebben.

Dit gaat de komende maanden nog zo door, want Intel geeft geen r*k om veiligheid van hun gebruikers. Als je Intel klant bent: Intel lacht je gewoon keihard in je gezicht uit; ze staan klaar met een pakje pleistertjes en roepen dat je huis niet lek is, zolang je hun pleistertjes maar plakt.

In onderzoekers-taal:

Kim Zetter, Intel Fixes a Security Flaw It Said Was Repaired 6 Months Ago. Nov. 12, 2019 - New York Times
Whenever a new class of vulnerability is discovered, it is standard practice for engineers fixing the code to search for additional instances of the problem beyond what is known and reported.

None of the attack variants the Dutch researchers gave Intel were fundamentally different from the ones Intel did patch, so Intel should have been able to extrapolate and find the others on their own, the researchers argued.

“Many of the attacks they missed were a few lines of code different from the others. Sometimes a single line of code,” Mr. Giuffrida said. “The implication of this is of course worrisome. It means until we give them all possible variations of the problem, they won’t actually fix the problem.”
tja, hoe groter je bent hoe groter de kans is dat men fouten vindt, vergelijkbaar met Windows en Linux, beiden zitten vol met lekken, maar bij Windows worden ze eerder gevonden omdat meer mensen daar op targetten vanwege dat dat een veel grotere doelgroep is.
Andersom juist, er draaien naar alle waarschijnlijk veelmeer machines met een Linux kernel dan met een Windows.
Van IoT apparaat, mobiele telefoons, servers in een rack tot supercomputers. Windows is populair in de desktopmarkt, daarbuiten een stuk minder. Daarnaast zijn er nog virtuele en fysieke servers waar een Windows Server variant op staat. Maar dat aantal is een stuk kleiner dan Linux gebaseerde servers. Microsoft heeft niet voor niets hard meegetimmerd aan de Linux kernel om de Azure support daarin in orde te krijgen. Er draait meer Linux op Azure dan Windows.

Dat "grotere doelgroep" wil ik daarmee counteren, want dat is onjuist in mijn ogen. Wat niet wegneemt dat het interessant is om een Windows lek te vinden. Daar zitten namelijk de meeste gebruikers en wat kunnen die? Bij data. De data waar je mogelijk in bent geïnteresseerd. Daarom blijft het zeker interessant om een Windows lek te vinden. Deze reden geef je in een reactie zelf ook al zie ik nu. Het doel is de data, Windows hacken is dan vaak de makkelijkere weg dan een gaatje in een Linux gebaseerde server proberen te vinden. Weg van de minste weerstand denk ik. Veroorzaakt door populariteit op de desktop.

Een exploiteerbaar lek in de Linux kernel vinden is een stuk significanter dan een lek in Windows vinden wmb. Je raakt veel meer devices, waaronder een hoop die vrijwel nooit updates ontvangen (IoT, routers, TVs, smartphones, applicances). Alleen wat kun je er dan mee? ;)
Dat is helemaal niet waar. Linux is een van de meest gebruikte kernels op allerlei apparaten variërend van servers en desktops tot embedded apparatuur zoals routers en televisies. Je zou kunnen stellen dat de doelgroepen van gelijke orden van grootte zijn.

De reden waarom er meer worden gevonden bij Windows is dat het product zo lek is als een mandje. Dat wil niet zeggen dat Linux inherent veilig is, maar wel relatief veiliger. Wil je meer veiligheid, dan zijn er ook systemen zoals OpenBSD, SeL4 en OpenVMS.
Nee, de reden dat er meer gevonden wordt is echt omdat Windows veel populairder is bij het grote publiek, waarbij dus veel interessanter is om lekken te zoeken om zo mensen te kunnen targetten. Ja, Linux kernel wordt op veel dingen gebruikt, en je ziet ook dat langzaamaan daar steeds meer aandacht aan besteed wordt door hackers. Maar nog steeds is het niet zo interessant als een gebruikers OS te targetten waarbij ook nog eens de kans groter is dat het grootste veiligheidslek (ofwel de gebruiker) meewerkt om hun eigen OS te hacken..
Dat is dus onzin. Als het echt even makkelijk zou zijn, dan zouden we al lang gehoord hebben van gijzelsoftware die websites platlegt.
Maar IIS wordt ook niet keihard gepakt door gijzelsoftware of andere hack gerelateerde problemen. Dus ook dat argument gaat nergens op.

Dat Windows populairder is bij het grote publiek, als in, end-user gebruik. Speelt wel degelijk een grote rol in het aantal gevonden lekken. Wat niet automatisch betekend dat Windows zo lek als een mandje is.

Want miljoenen van die Linux routers zijn ook zo lek als een mandje, hier in Nederland staan er al genoeg die gewoon keihard kwetsbaar zijn. Want de doelgroep en effectiviteit speelt een grote rol. Veel Linux machines moeten van buitenaf exploits bevatten voordat ze zonder interactie van gebruikers vatbaar zijn voor hackers en ook Windows heeft bar weinig van dit soort exploits op zijn naam staan. Dit soort exploits zijn hoe dan ook een heel stuk zeldzamer dan 9,9/10 Windows exploits waarbij er eerst een bestand gedownload moet worden, een website geopend moet worden, een mail gelezen moet worden of iets uitgevoerd moet worden. Linux is een _heel_ stuk minder kwetsbaar voor zulke semi-PEBCAK problemen dan Windows, want Linux wordt niet massaal gebruikt onder het 'grote publiek'. En waar Linux op de desktop gebruikt wordt, is de technische kennis gemiddeld gewoon een stuk hoger dan bij Windows, waardoor het risico automatisch een stuk kleiner is.

Puur naar het aantal exploits kijken is in deze vergelijking alles behalve eerlijk.

Juist doordat Windows al tientallen jaren zo in de hacker-schijnwerpers staat maakt de kans aannemelijk dat Windows wel degelijk veiliger is dan Linux. Geef Linux dezelfde marktgrootte en marktwaarde en je moet dan niet verrast zijn als het aantal exploits en problemen op Linux ook erg gaat toenemen. Zet maar eens 1 miljard Apple/Android/Windows gebruikers op Linux neer, het aantal CVE's zal enorm toenemen.

Sterker nog
Linux met 7 CVE exploits in 2019 met een score van 10
VS
Windows 10 met 4 CVE exploits in 2019 met een score van 10.

Slechts een kernel vs een geheel OS, toch wint Windows het in de zwaarste categorie.

[Reactie gewijzigd door batjes op 28 januari 2020 15:33]

En alles hoger dan 8 kom je uit op een score van 11 bij Linux, en 109 bij Windows.

https://www.cvedetails.co...06aee2984815f2416605cc930

https://www.cvedetails.co...068d05f172a93f2cd93cd4ca7

..maar dat paste waarschijnlijk niet in je verhaaltje. :)
Misschien je inlezen in wat die cijfertjes betekenen. Bij de cijfers <10 is enige vorm van user interactie vereist of moet er op 1 of andere manier al toegang zijn tot het systeem zelf. Ik wou met mijn vergelijking inderdaad liever Linux tegenover Windows zetten waar ze een beetje op gelijk niveau zitten en het verschil in gebruik of doelgroepen geen bal uitmaakt, want in deze categorie heb je wat meer aan de statistieken als je puur naar aantal lekken = veiligheid kijkt. Bij de lagere getallen moet je nogal wat meer variablen mee nemen of je een OS (of software) tot gatenkaas toeberekend of niet.

10 staat voor ernstige lekken waarbij een buitenstaander fluitend het systeem op binnen wandelt.

En dan heb ik de distro's niet eens meegenomen, want daar had ik geen zin in. Had wel meer impact gemaakt op mijn verhaal.
Alles tussen 8 en 10 is "critical". Dat maakt dat de statistieken die ik gaf het hebben over alles dat critical is, terwijl die van jou alleen gaan over alles waarbij men op 10 uit is gekomen.

Ik werk dagelijks met deze onzin, dus mij hoef je niets wijs te maken.

Iemand die deze cijfertjes gebruikt als een of andere bijbel (of voor dit soort statistieken) kan ik dan ook niet serieus nemen :D want ik weet als geen ander hoe vaak CVSS 3.0 en 3.1 er naast zit (met CVSS 2 was het nog erger). Bovendien zul je die scores ook toe moeten passen op de situatie (middels ES en TS wat geen hond gebruikt). Bij benadering is het wel handig. Om een prioriteit te geven, ook.

Verder kun je een desktop OS (Windows 10) lastig vergelijken met een kernel (Linux kernel). De Linux kernel is namelijk een onderdeel van een OS. Ik vind Linux als desktop OS niet zo interessant qua beveiliging want bijna niemand gebruikt dat. Android is dan interessanter.

Verder wil ik je graag nog even laten inlezen over CVSS 3.1:
The CVSS Specification Document has been updated to emphasize and clarify the fact that CVSS is designed to measure the severity of a vulnerability and should not be used alone to assess risk.
https://www.first.org/cvss/v3.1/user-guide

De conclusie die jij probeert te maken, is dus gebaseerd op losse schroeven. Nog een fijne dag heh! :)
Allicht eens proberen reacties te lezen alvorens je reageert. Nergens beweer ik dat de CVE lijst de enige info is die je moet gebruiken om de veiligheid van een systeem te bepalen.

Misschien dan ook even de exploitlijst even doorlezen.
Je eigen link Windows;
1) Local 2) local 3) user 4) local 5) user 6) user 7) local 8) local 9) local 10) local. Etcetc

Allemaal situaties waar je niet tegen aan loopt op een router, de meeste servers, IoT etc. Ofwel het gross van de Linux markt.

Lekker eerlijk om dat te vergelijken met een gemiddelde-enduser OS zoals Windows, OSX, iOS of Android. Terwijl je de CVE's met cijfertje 10, vanaf buiten het systeem fluitend mee naar binnen wandelt. Waarbij het speelveld voor Linux en Windows in dat opzicht (van aantal -gevonden- exploits) veel eerlijker te vergelijken zijn.

Ik reageer verder ook half op de rest van de discussie om ons heen, met het idee. Het is maar net hoe je naar de veiligheid van het OS aan kijkt. Om ons heen wordt iets te vaak Linux als de veiligheid zelfde gezien en Windows als 1 grote gatenkaas.
Windows verliest het keihard puur in het aantal. Waarbij weet-ik-hoeveel variabelen mee spelen. Neem je toch zo veel mogelijk van die variablen weg (er zijn er echt veel te veel om puur naar de totale nummers te kijken), is het speelveld ineens veel gelijker en leunt het zelfs naar het voordeel van Windows.
Neem je dan ook alle distro's, Android en whatever mee in de vergelijking, zelfs als je naar het pure marktaandeel kijkt, gaat het zelfs op alles boven 8, nog best gelijk op.

[Reactie gewijzigd door batjes op 28 januari 2020 17:47]

Je hebt het over malware en gebruikers. Een goed OS verdedigt een gebruiker zoveel mogelijk tegen malware. Bijvoorbeeld op iOS gaat het een stuk moeilijker zijn. Android idem.

Ik beweer nergens dat Windows een grote gatenkaas is (hoewel ik de CryptoAPI kwetsbaarheid wel ernstig vond). Heck, er is niet eens zoiets als "Windows". Er zijn zoveel versies van Windows...

Wat ik beweer is dat je vergelijking van CVEs gewoonweg krom loopt, om meerdere redenen waar we het al over hebben gehad.

Waar ik mij meer zorgen over maak is de privacy van gebruikers of data. Qua desktop maak ik me dan vooral zorgen over Windows 10; niet macOS. Dan heb ik het over out of the box. De Duitse overheid acht bijvoorbeeld Windows niet geheel GDPR-compliant.
Die software is er wel hoor, net als dat er cryptolockers zijn die op Linux gebaseerde NAS devices targetten. Wat dat betreft heeft Linux en software draaiende op Linux ook genoeg CVE's die je moet patches of je OS / software is zo lek als een mandje.
Misschien bij het grote publiek, maar het is veel interessanter om een Linux server te pakken omdat daar waardevolle data op kan staan. Er zijn veel meer Linux servers dan Windows servers (en de tweede neem ik niet echt serieus).
Daarnaast, doordat het open source is worden er veel meer code reviews gedaan.
Ja, Linux kernel wordt op veel dingen gebruikt, en je ziet ook dat langzaamaan daar steeds meer aandacht aan besteed wordt door hackers.
Je ziet? Waar blijkt dit uit? "Hackers" zijn al sinds jaar en dag bezig om lekken te vinden in "Linux" (de kernel, en OSen die gebruik maken van de kernel).
Maar nog steeds is het niet zo interessant
Het is zelfs interessanter. De Linux kernel wordt ontzettend veel gebruikt in embedded apparatuur, IoT, servers, en smartphones. 99,99% van alle smartphones draait ofwel Linux kernel, ofwel een afgeleide van macOS (iOS & familie).
Het meest populair bij het publiek is linux. Zowel IOS als Android zijn Linux.
Je vergeet veel routers en supercomputers. Ik denk dat het neerhalen van een Amerikaanse supercomputer best wel een interessant doelwit is voor Noord-Korea. Of wat dacht je van een doordeweekse crimineel die weet in te breken op zulke supercomputer en gedurende lange tijd onder de radar kan blijven om een fractie van die rekenkracht te gebruiken om bitcoins ofzo te minen...
Is daar eigenlijk ergens een duidelijk bron voordat er meer lekken worden gevonden in Windows dan in Linux, puur kijkende naar de nummers (die uiteraard niet alles zeggen) staat Linux namelijk vrij hoog met het aantal CVE's ( https://www.cvedetails.com/top-50-products.php )
Wat jammer, elders beweert u terecht dat alleen naar CVE's kijken geen goed meetinstrument is, en nu trapt u er zelf in.

Als ik u een tip mag geven: Zoek eens de getallen op per 'ernstigheids-klasse' (severity ratings), en meldt u dan nog eens terug.

Afgezien daarvan, als ik kan kiezen tussen:
-En airbag waarvan het ontwerp door iedereen bekeken kan worden en er 2 fouten werden gerepareerd en gefixt,
-Een airbag waarvan het ontwerp angstvallig geheim wordt gehouden, en er wordt maar 1 fout gefixt,

dan denk ik dat de eerste voor mij als veiliger zal voelen. Terugkomend op het onderwerp (want iedereen hier dwaalt behoorlijk af), namelijk Intel en veiligheid: Dat is ook een van de redenen om hardware-crypto (AES-modules) van Intel te wantrouwen, daarvan wordt het ontwerp immers ook geheim gehouden.
Zo jammer is dat niet, de context is immers volledig anders. Hier reageer ik op een post waarin beweerd wordt dat er in Linux minder lekker worden gevonden dan in Windows en dan is een lijst met het aantal CVE's best bruikbaar, de cijfers laten immers in dit lijstje anders zien. Vandaar dat ik hem ook vraag zijn stelling te duiden, mogelijk heeft hij andere cijfers die een ander aantal kwetsbaarheden laat zien tussen Windows en Linux laat zien die zijn stelling kan onderschrijven.

De ernstigheidsklasse is bij een vraag in welk OS meer of minder vunerabilities worden gevonden meer minder van belang. Ik zie dan ook de relevantie daarvan niet direct. Het gaat hier immers om de absolute aantallen in de stelling waar ik op reageer, niet om de aantallen per ernstigheidsklasse.

Wat wel jammer is, is de op de man spelende toon van je reactie, terwijl je zelf de context niet door lijkt te hebben.

[Reactie gewijzigd door Dennism op 29 januari 2020 07:14]

Nee, de situatie is niet zo anders, ik denk dat uw vraagstelling het verkeerde principe is.

Als u in een onderzeeër zit, wilt u in degene zitten waardoor het minste water ook nog eens zo kort mogelijk naar binnen lekt, die is het veiligst.

Daarom kan u gerust in de onderzeeër stappen met de meeste gaatjes: Als de ander door een torpedo is geraakt en slechts 1 groot gat heeft weet u waarom.

Dus terug naar uw lijst: Ik zoek torpedo-gaten van ernstigheid 8 en hoger.

Linux kernel: 7 per jaar jaar,
Debian: 7 per jaar,
Windows 7: 36 per jaar.
Windows 10: 46 per jaar.

Aangezien hier op Tweakers vroeger astroturfers actief waren, die betaald gesteund werden door Microsoft om het soort misleidende beweringen als dat van u te maken , reageer ik daar erg allergisch op ja: mijn fout.

Ed: Het allervervelendste is dat die 46 torpedo-gaten in Windows 10 gevonden zijn door degenen die geen toegang tot de broncode hebben.
De Chinese en Russische regering hebben dat wel, dus ga maar na hoeveel onbekende en voor andere veel moeilijker vindbare exploits die _daarbovenop_ nog eens kunnen misbruiken:

https://www.infoworld.com...icrosoft-source-code.html

[Reactie gewijzigd door kidde op 29 januari 2020 19:55]

Dat is helemaal niet waar. Linux is een van de meest gebruikte kernels op allerlei apparaten variërend van servers en desktops tot embedded apparatuur zoals routers en televisies. Je zou kunnen stellen dat de doelgroepen van gelijke orden van grootte zijn.

De reden waarom er meer worden gevonden bij Windows is dat het product zo lek is als een mandje. Dat wil niet zeggen dat Linux inherent veilig is, maar wel relatief veiliger. Wil je meer veiligheid, dan zijn er ook systemen zoals OpenBSD, SeL4 en OpenVMS.
Op desktops komt Linux amper voor, en daar heeft SuperDre gelijk in, op Desktop gebruikt 77.64% Windows, en MAAR 1.85% gebruikt Linux, dus ja dan vinden ze VEEL meer lekken en fouten bij Windows dan bij Linux, en woorden er ook in theorie meer fouten gerepareerd dan op Linux, en zijn er minder veel fouten bij Windows dan bij Linux.

https://gs.statcounter.com/os-market-share/desktop/worldwide

[Reactie gewijzigd door AmigaWolf op 28 januari 2020 19:55]

Die logica snap ik even niet, maar ik hoop dat die wel werkt voor jou en je gelukkig maakt. Bovendien heeft iemand anders diezelfde percentages vorig week ook al ergens gelinkt, maar het gaat natuurlijk om alle platformen.

https://gs.statcounter.com/os-market-share.

Een GNU/Linux distributie maakt net zo goed gebruik van de Linux kernel als Android of ChromeOS. Alles wat geen systeemtools of de kernel zelf is, bestaat uit middleware en applicaties en is derhalve niet specifiek onderdeel van het besturingssysteem zelf.

Waar je volgens mij voornamelijk naar op zoek bent, is bevestiging van je keuze voor Windows, maar niemand zegt hier tegen jou dat je dat niet moet gebruiken. Er zijn alleen mensen die het liever niet gebruiken op de desktop en op alle andere markten is Linux de kernel die het meest gebruikt wordt, al dan niet met een GNU, BSD or propietair userland en GUI.

Ik zeg niet eens dat Linux de beste kernel is, dan kom je eerder uit bij iets als seL4. Bovendien denk ik dat de zwakte van Windows niet de NT kernel is, maar de compromissen die Microsoft door de jaren heeft gesloten en het gebrek aan serieuze ontwikkelingen om moderne bestandssystemen te ondersteunen.
In het geval van Intel heeft Intel jaren geleden wat keuzes gemaakt om AMD voor te blijven waarbij wat bochten afgesneden zijn. Toegangs controle NA parallel met data fetch bv. Waardoor data al wel in de cache staat... Hierdoor kun je door te kijken wat er in de cache staat zelfs de inhoud van data bepalen waar je geen toegang to hebt. (Meltdown en Sperctre werkent vanuit een Javascript applicatie in een browser)

Dit is een heel andere orde dan de schaal waarop je iets toepast. AMD & Intel zijn beide target omdat x86 de grootste architectuur is. ARM is ook een grote al zijn er daar beperkte mogelijkheden. Itanium, HPPA, PPC, AXP, MIPS etc. zijn in dat kader mogelijk minder interessant, maar bieden de mogelijkheden niet om een cache, met potentieel interessante, data te scannen.

Intel heeft een loopje met beveiliging genomen (en blijft dat blijkbaar doen) en die hardware is niet zomaar gefixed zonder draconische gevolgen voor performance. BLijkbaar heeft AMD betere engineers in huis dan Intel en gaat Intel voor een halfbakken risk assessment van features.
Dat is hier niet aan de hand, AMD is met zijn ontwerpen minder kort door de bocht gegaan dan Intel.
Met zulke cijfers geloof ik wel dat Amd veiliger is, maar het is niet 1 op 1 te vergelijken.

In de populairste software / OS / hardware zijn ook vaak de meeste backdoors bekend. Amd wint nu wel populariteit terug, maar er is veel meer onderzoek gedaan naar Intel cpu's
AMD en Intel hebben beide last van dit soort lekken.
Waar, maar wel een beetje kort door de bocht. Intel's security rondom speculative execution/SMT is echt zo lek als een mandje, en waar AMD slechts beperkt vatbaar is voor bepaalde SPECTRE varianten, is het bij Intel nu echt schering en inslag.

Vooralsnog zijn er voor zover ik weet geen gevallen van misbruik in het wild, maar ik wordt er zelf toch niet heel blij van, moeten kiezen tussen of een berg patches die performance kosten, of je CPU zo lek als een mandje laten zijn (waarbij je ook moet beseffen dat al die patches geen garantie zijn dat er niet nog meer lek is)

Dus ja, alle CPU vendors hebben last van security problemen (bepaalde ARM cores zijn ook vatbaar voor SPECTRE), maar Intel is wel echt een klasse apart momenteel
Daarnaast zijn de AMD lekken tot nu toe, in mijn ogen, minder ernstig te misbruiken (of moeilijker) dan wat er bij intel nu allemaal boven drijft. Althans als ik de use cases ervoor lees lijkt dit het geval te zijn. Natuurlijk moet je niet al je schepen gelijk afschieten bij het eerste deukje maar het begint nu toch wel aardig op een patroon te lijken.

(disclaimer: volgens mij altijd intel (niet zeker, thats how much I care) gehad maar als ik wat koop kijk ik enkel naar prijs/performance + wat is mijn usecase en hoelang is de periode die ik wil overbruggen)
Is dat wel zo? Is dit gepubliceerde lek wel zo simpel te misbruiken net zoals een hoop anderen? En hoeveel impact heeft dit lek werkelijk bij realistisch gebruik, ofwel kan men ook echt zinvolle informatie hiermee fatsoenlijk binnenhalen ipv theoretisch wat mogelijk zou kunnen zijn. Dat zijn ook allemaal zaken die je je moet afvragen. Ja tuurlijk is het het hopen dat Intel eens hun hele security gaat onderzoeken wat betreft hun CPU's (en dat zullen ze ook al wel heel hard proberen). Maar bedenk ook, hoe lang heeft het geduurd voordat iemand hier op kwam om de CPU's zo te targetten op zulke lekken, zeker als je weet dat die Spectre pas sinds 2 jaar ofzo bekend is, maar wel teruggaat naar CPU's van lang geleden.. Hetzelfde kan bij alle CPU's gebeuren als er weer eens iemand een geniaal idee heeft voor een mogelijkheid, en dan kan het best zijn dat alle CPU's weer zo lek als een mandje zijn.
Ik weet niet of dit zo is, vandaar ook dat ik het als een op een mening gebaseerde observatie neerzet waarbij n=1 alsook dat deze n=1 vrij weinig van cpu's intern afweet. Echter als ik kijk naar de hoeveelheid cve's bij beide kampen en de beschrijvingen dan onstaat bij mij wel dit beeld.
Is dit gepubliceerde lek wel zo simpel te misbruiken net zoals een hoop anderen?
Nee, nog makkelijker, dat staat er toch?
Moreover, unlike previous MDS issues, we show in our work how an attacker can exploit the CPU's caching mechanisms to select what data to leak, as opposed to waiting for the data to be available
Dus makkelijker dan bij MDS.
Hetzelfde kan bij alle CPU's gebeuren
Nee, alle Intel-lekken stammen uit 1 principiele fout, en uit dat ene principe wordt onderhand iedere maand een nieuw "Intel-only"-lek afgeleid. Dat komt omdat Intel die 1e principiele fout niet heeft opgelost, waar AMD geen last van heeft. En zoals u zelf al netjes aangeeft: Intel heeft die fout al twee jaar lang niet opgelost, want de veiligheid van hun gebruikers boeit ze eigenlijk helemaal niets.

De beveiligers leggen het hier uit, extraspeciaal voor allen die willen ontkennen dat Intel meer problemen heeft dan AMD.

[Reactie gewijzigd door kidde op 29 januari 2020 02:34]

Intel heeft die fout al twee jaar lang niet opgelost, want de veiligheid van hun gebruikers boeit ze eigenlijk helemaal niets.
Dat is natuurlijk gewoon pure bullshit.. Alleen is het niet zo simpel om zulke problemen even snel op te lossen..
Natuurlijk wel, tenzij u Intel incompetent acht? Het is niet meer dan een 'privilege check' op de TLB / load execution unit. Heeft zelfs ARM, binnen een budget van 1 Watt.

Acht u Intel zo incompetent dat ze zoiets niet binnen twee jaar kunnen maken? Mag van mij, maar ik heb persoonlijk _wel_ een hoge pet op van de ontwerpers bij Intel. Het zijn daar de procesmensen, management en HR die incompetent zijn, maar de architectuur ontwerpers deugen.

[Reactie gewijzigd door kidde op 29 januari 2020 19:20]

Intel currently has 242 publicly disclosed vulnerabilities, while AMD has only 16. That's a 15:1 difference in AMD's favor. The gap is just too large to ignore.
https://www.tomshardware....md-most-secure-processors

Elk software en hardware bedrijf hebben ''last van dit soort lekken'' maar je kan de waarheid niet onder de tafel schuiven met de argumentatie dat ze modellen baseren op vorige generaties en fouten daardoor hergebruikt worden. Zie mijn artikel. Het is evident dat AMD veiliger is/minder beveiligingsproblemen heeft t.o.v. de concurrent en ook zij bouwen voort op vorige generaties. Blijkbaar is hun productie/engineering proces gewoon beter of minder foutgevoelig.

Ik deel de mening van @jaenster , hopelijk wordt de enterprise markt wakker en komen we af van de OEM Intel monopolie. Laat de beste en veiligste processor winnen, dat zorgt voor innovatie.

[Reactie gewijzigd door Blackboard op 28 januari 2020 10:23]

Dat artikel van Toms is nogal slecht geschreven. Het gros van de Intel CVE's heeft niet eens direct betrekking op de cpu's. Het gros heeft betrekking op software.

Als ik door beide lijsten heen loop heeft zijn bij AMD 13 van de 16 cve's gerelateerd aan hun recente cpu's. Bij Intel kom ik op +- 30 van de 247 CVE's. Nog steeds een stuk meer aan de kant van Intel, en nog steeds een duidelijke aanwijzing dat AMD het op security momenteel een stuk beter doet. Echter brengt het wel een flinke nuance in het 247 v.s. 16 CVE geroep.

AMD heeft hier juist het voordeel doordat ze niet al te veel voortborduren op oudere producten. AMD heeft bij de ontwikkeling van Zen juist relatief weinig uit oudere architecturen meegenomen, AMD's Zen ontwerp is daardoor gebouwd op redelijk nieuwe security principes. Intel borduurt echter nog steeds door op hun ontwerp uit halverwege jaren 2000 voort en dat ontwerp borduurde eigenlijk al voort op ontwerpen (o.a. Pentium Pro) uit de jaren '90.

Doordat Intel hun 10nm process niet aan de praat krijgt kan Intel ook niet heel erg vlot overstappen op hun nieuwe ontwerpen die ongevoelig zijn voor een (groot) deel van dit soort issues.
Intel heeft wel veel meer van zulke trucs, daardoor konden ze jaren klok-voor-klok sneller zijn. Het blijkt nu maar eens te meer waar die snelheid vandaan kwam en wat het gevaar daarvan is.
AMD en Intel hebben beide last van dit soort lekken.
In ieder geval niet van dit lek. Uit het artikel:
De bugs zitten alleen in Intel-cpu's. AMD-chips zijn volgens de onderzoekers niet kwetsbaar, omdat die geen gebruik maken van Transactional Synchronization Extensions, zoals Intel doet.
Veelal als ik deze artikelen lees, zie ik een opmerking staan dat er ook naar de AMD processoren is gekeken. Dit is nu ook weer het geval en de conclusie is dat AMD niet vatbaar is. Bij vorige security issues was dit ook het geval of is AMD in ieder geval minder vatbaar.

AMD is ook minder op oude archtectuur door gegaan dan Intel, nu zeker met Ryzen en Ryzen2, zijn er zaken aangepast. AMD doet bepaalde zaken sowieso anders dan Intel.
Ik zie er gewoon meer bij Intel, maar dat komt omdat het design van Intel gewoon fouten bevat. Veel erger is de opmerking van Intel, dat het niet hardwarematig opgelost kan worden. Je bent eigenlijk compleet gestoord dus wanneer je nog Intel in je enterprise gaat neerzetten wanneer nu nog hardware aanschaft.
Met een beetje geluk gaat enterprise ook meer richting AMD met al deze lekken.
Oh maar dat is zeker al aan de gang. Zeker voor apparatuur die essentieel is voor de beveiliging zie ik vrijwel alleen AMD gebruikt worden op dit moment. Het is gewoon een betere keuze.
Niet zo gek ook. Meer performance, nieuwere standaarden, lager energieverbruik en lagere prijs. Dan wordt het heel snel aantrekkelijk.
De vraag is of dat iets oplost.

Het is een beetje te vergelijken met de Windows-MacOS-Linux discussie. Het is logisch dat een populair product (Windows & Intel) onder een vergrootglas ligt en er dus veel meer problemen worden gevonden. Het loont de moeite niet (of in ieder geval minder) om AMD, MacOS of Linux onder het vergrootglas te leggen.

Dat betekent niet dat AMD, MacOS en Linux veiliger of minder kwetsbaar zijn dan Intel en Windows. Als de markt zou verschuiven naar AMD en Linux als populairste producten dan zal je zien dat er daar ook genoeg in gevonden gaat worden.
Onderzoeken worden parallel uitgevoerd, dus zowel op Intel en AMD. Er wordt niet specifiek naar Intel onderzoek gedaan, er wordt onderzoek naar beide gedaan.
Met een beetje geluk gaat enterprise ook meer richting AMD met al deze lekken.
Het lijkt me ook wel voordelig dat een wereldwijd belangrijke markt (processors) niet voor het grootste deel afhankelijk is van Intel... Stel je voor dat Ford de enige fabrikant van auto's zou zijn....

Maar had AMD, (niet dezelfde problemen? Heeft AMD het wel opgelost? Was AMD al minder vatbaar?
Het Enterprise architecten heeft een hard bord voor zijn hoofd en het zijn luie honden en de managers daarboven laten liever alles zoals het was. Nee, security flaws spelem voor een Enterprise niet direct een rol en is geen motivatie om spontaan te gaan veranderen. Het is de vraag (klant), kosten (dienst verlener) dat voornamelijk bepaald en een berg aan factoren.
Welke?
Meer cores?
Hogere IPC?
Meer PCI lanes?
Sneller?
Minder duur?
Hun beste processoren zijn nog niet leverbaar in laptops. Zen 2 chips lastig verkrijgbaar in laptops.

En ja voor een nieuwe desktop overweeg ik nu ook geen Intel meer.
Waar ik niet veel over vind is wat er voor nodig is om dit te misbruiken.
Bij veel van de gevonden bugs is het misbruiken dermate lastig dat de hele lek wat mij betreft irrelevant is. Als ieman bijvoorbeeld toegang tot mijn pc nodig heeft om een bios te flashen dan heeft die persoon al toegang tot mijn data. Veel van deze lekken zijn helemaal niet eventjes door software als een keylogger of dataminer te misbruiken.

En wat betreft performance impact. Voor 99.99% van de thuis gebruikers hebben deze patches helemaal geen invloed op de performance. Ik heb een 9900k en met al deze patches en bios updates zijn test resultaten in benchmarks die al een worst case zouden zijn omdat ze onrealistische loads creëren binnen de foutmarge.
Er zijn heel heel veel windows updates met grotere impacts op performance!
Dit soort vulnerabilities is met name een issue voor cloud providers of gevirtualiseerde omgevingen. Een klant A kan dan klant B aanvallen of zelfs via hun guest de hele host overnemen.
Zal de komende microcode update weer een performance hit hebben? ;(
Ongetwijffeld, de vraag is hoeveel.

[Reactie gewijzigd door tweaknico op 28 januari 2020 12:41]

En met welke workloads.
Ja dat is precies wat ik me ook af vroeg. Ik vind het erg goed dat er gekeken wordt naar security, maar met dit soort van 'lekken' blokkeren gaat ten koste van de peformance (die ik eigenlijk liever heb, dan het kleine risico dat er op deze manier een keer info naar buiten lekt). Ik doe miljarden berekeningen per dag, en die data staat op een veel eenvoudiger uit te lezen manier dan ook in het geheugen en op de harde schijf. Als er een programmatje geinstalleerd kan worden wat dit misbruikt, dan zou je toch zeggen dat ze ook wel in staat zijn om de bestanden die er voor worden ingelezen, dan ook gelijk uit te lezen.

[Reactie gewijzigd door Jouke74 op 29 januari 2020 11:11]

Dat is maar net afhankelijk van je workflow....

Als je een zelf een server runt is er minder een probleem.
Als er op je server ook code van derden kan lopen is het al wat anders. (Denk aan Hosters, Amazon micro-services, etc.).
Er kunnen ook harde juridische eisen zijn. Durf je als bank nog op een shared server zaken te faciliteren?.. als ook de sleutels uit jouw processen kunnen worden getrokker door een proces van een ander
Is met de microcode update het risico helemaal weggenomen?

Wat is de impact op performance?

Ik kon niet zo snel vinden op de intel pagina wat je kunt doen om te mitigeren. Heb ik niet goed gezocht?
Staat gewoon in het artikel:
Het bedrijf heeft inmiddels een update voor de microcode voor de cpu's uitgebracht, en tips voor een mitigatie gegeven. Omdat het echter om een kwetsbaarheid in de hardware gaat, is die niet volledig op te lossen.
Wat zijn die tips?
Kerel, maat, makker... lees het artikel, daar staat de link in.
Ja, de microcode, maar soms kun je iets doen als een tijdelijke mitigatie totdat je kunt patchen. Die zijn er niet zo te zien. :)
Jawel, gewoon even lezen en doorklikken.
On processors not yet updated to mitigate vector register sampling, SMT scheduling restrictions may reduce the risk of cross-thread secret data exposure. The vector register sampling method cannot be performed on processors that are not affected by MDS or TAA1.

Processors that are affected by only TAA and not MDS2 can mitigate this issue by disabling Intel® Transactional Synchronization Extensions (Intel® TSX) through the IA32_TSX_CTRL MSR. Disabling Intel® TSX will help prevent malicious software from inferring store buffer contents and thus also help prevent vector register sampling.
https://software.intel.co.../vector-register-sampling
Het was een stuk nuttiger geweest als het tweakers artikel de aard van de mitigaties: - processor extensies uitschakelen - had benoemd.
Al die kwetsbaarheden gaven Intel al die jaren wel een voordeel.. Alleen hoeveel is de vraag.
Of in goed Cruyviaans: Elk (performance) voordeel hep z’n (Security) nadeel... ;)
Hmm nog een paar en je zit met een intel proc inmiddels op negatieve performance :'(
Wel lastig om nu een laptop aan te schaffen, veel alternatieven zijn er nog niet en om nou te zeggen dat het lek inmiddels boven is bij Intel ...
Als het goed is komen over een paar maanden de eerste AMD 4000u laptops uit, die zitten kwa perf/watt en perf als het goed is boven Intel (want 7nm), nu nog hopen dat de OEMs ook doorzetten en er een breder aanbod komt

Voor mij is alles Intel momenteel in ieder geval no-go, ik mis alleen aan de AMD kant de ultra-mobile laptops, ik zou eigenlijk een mooi 11.6 inch machientje met een Ryzen chip willen
Hoe worden deze updates verspreid? Via windows update of moet je deze echt zelf handmatig installeren?
Grote kans dat ook deze update een performance hit met zich meebrengt. Van mij hoeft deze update dan niet op mijn thuis pc geïnstalleerd te worden voor die minuscule kans dat er ooit iemand mijn pc probeert binnen te komen.
Dat kan op meerdere manieren, via bios updates, via OS updates, in het geval van Linux kan je ze hier downloaden en zelf installeren zodra Intel ze daar plaatst, meestal een paar dagen na release van de advisory: https://github.com/intel/...ssor-Microcode-Data-Files
Het houdt maar niet op, hoeveel heeft deze (microcode) patch weer invloed op de CPU performance?

Het is makkelijk om te roepen natuurlijk, maar AMD lijkt het allemaal tig beter voor elkaar te hebben. Tevens kunnen ze met de nieuwe Zen's nog meer flinke stappen zetten tegenover vrijwel elke Intel CPU. Voor de markt is het goed, maar ik blijf het raar vinden dat Intel ondanks al dit nog vrij zacht lijkt worden aangepakt.
Kijk maar eens bij Phoronix, die test deze performanceverschillen met en zonder mitigations onder linux. Laatste benchmarks zijn van 13 januari:

https://www.phoronix.com/...=spectre-meltdown-2&num=2
Afhankelijk van processorgeneratie en type benchmark is er performanceverlies tot 25%

[Reactie gewijzigd door MartineEekhof op 28 januari 2020 13:01]

Aan de CPU kant idd wel... GPU kant met oa de Vega en 5600XT is het een drama bij AMD.

Op dit item kan niet meer gereageerd worden.


Nintendo Switch (OLED model) Apple iPhone 13 LG G1 Google Pixel 6 Call of Duty: Vanguard Samsung Galaxy S21 5G Apple iPad Pro (2021) 11" Wi-Fi, 8GB ram Nintendo Switch Lite

Tweakers vormt samen met Hardware Info, AutoTrack, Gaspedaal.nl, Nationale Vacaturebank, Intermediair en Independer DPG Online Services B.V.
Alle rechten voorbehouden © 1998 - 2022 Hosting door True