Onderzoekers VU Amsterdam leggen kwetsbaarheid in Intel Xeons bloot

Onderzoekers van de Vrije Universiteit Amsterdam en ETH Zurich beschrijven een aanval met de naam NetCAT die toetsaanslagen van een ssh-sessie kan onderscheppen. Intel beschouwt de ernst als laag.

NetCat is een aanval via netwerken die gericht is op de last-level-cache van een machine op afstand. Door alleen netwerkpakketjes naar een doelwit te sturen zijn toetsaanslagen van een actieve ssh-sessie met succes aan te vallen om bijvoorbeeld wachtwoorden te onderscheppen. Het draaien van kwaadaardige software op die machine is niet vereist.

De onderzoekers maken gebruik van een side channel-aanval op een cache op afstand om de aankomsttijden van individuele netwerkpakketjes van ssh-sessies te achterhalen. Die pakketjes corresponderen met toetsaanslagen en dankzij statistische analyse van de tijden, via een zogenoemde keystroke timing attack, zijn de getypte toetsen te achterhalen. Die analyse is gebaseerd op de verschillen in tijd tussen het typen van bepaalde achtereenvolgende toetsen. De onderzoekers geven als voorbeeld dat het korter duurt om eerst een 'a' en dan een 's' te typen dan een 'g' na een 's'.

De aanval maakt gebruik van een kwetsbaarheid in Data-Direct I/O of DDIO, technologie die sinds 2012 in serverchips van de Xeon E5-, E7- en SP-families zit en tot prestatieverhoging leidt door randapparaten read/write-toegang tot de lastlevel-cache te geven. Dit delen van de cache door de cpu en een netwerkkaart in combinatie met Remote Direct Memory Access of RDMA opende de weg naar een soort Throwhammer-aanval, een Rowhammer-aanval die via netwerken is uit te voeren.

De kwetsbaarheid met aanduiding CVE-2019-11184 is aan te pakken door DDIO en RDMA uit te schakelen. Intel heeft een een advies uitgebracht met aanbevelingen. De chipfabrikant beschouwt de ernst van de kwetsbaarheid als laag vanwege de complexiteit van de aanval en de geringe kans op scenario's waarbij de kwetsbaarheid is te misbruiken.

Reacties (59)

[Chocoball]

Verwarrend is dat het NCSC de kwetsbaarheid hoger inschaalt (kans medium, schade hoog) maar naast Xeon ook de Core en Pentium families als kwetsbaar benoemt.

https://www.ncsc.nl/actueel/advisory?id=NCSC-2019-0703

[Houtenklaas]

Als er iemand op het LAN segment van je serverpark kan komen om dit te onderscheppen, heb je sowieso al een probleem.

[Reactie gewijzigd door Houtenklaas op 23 juli 2024 12:54]

[Sebazzz]

Ja, en nee. Security maak je door lagen te maken. Een fysieke laag: je hoort niet op het netwerk te kunnen komen. Andere lagen zijn firewalls, wachtwoorden of smartcards, two-factor authentication, etc.

[Z80]

Op https://slashdot.org/ (ligt nu plat) stond een stuk dat de aanval iets duidelijker maakte.
Het grootste probleem is bij shared servers. Virtual machine 1 kan bij alle andere virtual systemen op de zelfde host. En bij de host machine zelf.
Er wordt namelijk misbruik gemaakt van de gedeelde cache op hardware niveau.

[The Third Man]

Je hebt sowieso een probleem als er iemand toegang tot je pc heeft, maar dat maakt het nog geen slecht idee om een wachtwoord op je password-manager te hebben. Beveiliging is de combinatie van alle maatregelen, niet het bouwen van 1 muur en het verder opgeven als iemand daar voorbij komt.

[DohnJoe]

volledig off-topic, maar het 'alu hoedje' staat symbool voor paranoïde mensen die niemand/niks vertrouwen.
jij gebruikt het nu voor precies het tegenovergestelde!

[InsanelyHack]

Als ik security expertise zou inhuren die zo aan mij rapporteert nam ik de volgende dag al iemand anders.

[Giesber]

Ik wet niet hoe het NCSC hun risico inschattingen doet, maar Intel zuigt niet zomaar een cijfer uit hun duim moest iemand dat denken (ik heb het niet op jou overigens). Ze gebruiken het Common Vulnerability Scoring System. Intel heeft het als volgt geclassificeerd:
https://www.first.org/cvs...PR:L/UI:R/S:C/C:L/I:N/A:N

[eelco74]

Intel heeft er als commercieel bedrijf natuurlijk alle belang de ernst van de zaak te onderdrukken. We hebben inmiddels genoeg gevallen gehad die openbaarheid kwamen, waarvan men eerst zei dat het te ingewikkeld was om te misbruiken. Maar vervolgens wel al jaren door bepaalde staten successvol gebruikt werd.

[Dennism]

Dat is inderdaad vreemd daar die cpu's de DDIO functionaliteit niet hebben.

[The Zep Man]

Een workaround kan ook in SSH clients (en in elke client die toetsaanslagen van de gebruiker direct omzet in netwerkpakketten) geïmplementeerd worden door een kleine willekeurige vertraging toe te voegen aan het verwerken van elke toetsaanslag van de gebruiker. De gebruiker zal hier niets van merken omdat het om onwaarneembare fracties van seconden gaat, en voor servers maakt het ook niet uit omdat die toch wachten op input.

Op langere termijn zou een functie van hardened kernels/goed geconfigureerde besturingssystemen kunnen zijn dat elke toetsaanslag een willekeurige vertraging krijgt voordat het wordt doorgegeven aan de applicatielaag. Entropie toevoegen is simpeler dan verwijderen. Dit zou daarom een relatief simpele functie kunnen zijn, die ook andere (nog niet ontdekte) kwetsbaarheden oplost die gebruik maken van dezelfde zwakte.

[Reactie gewijzigd door The Zep Man op 23 juli 2024 12:54]

[Cergorach]

Wat ik me zit af te vragen is hoeveel mensen die secure aanmelden via bv. SSH nog typebare ww gebruiken, Ik pak een lange random generated string vanuit mij ww manager en dat is het ww, als deze gebruikt wordt om aan te melden is het een copy/paste actie. Wellicht dat het aan mij ligt, maar dan zitten er toch geen verschillende wachttijden tussen 'toetsaanslagen'? De enige toetsaanslag is dan immers CTRL+V...

[The Zep Man]

Wat ik me zit af te vragen is hoeveel mensen die secure aanmelden via bv. SSH nog typebare ww gebruiken,

Dat is niet relevant voor deze kwetsbaarheid. Bij het invullen van het wachtwoord wordt deze niet per karakter verstuurd. Sterker nog, het wachtwoord wordt helemaal niet verstuurd naar de server. Enkel een afgeleide (gebaseerd op challenge/response). Dat is niet afhankelijk van de tiksnelheid van de gebruiker.

[Reactie gewijzigd door The Zep Man op 23 juli 2024 12:54]

[fastedje]

Het veiligste is natuurlijk om ssh keys of certificates te gebruiken en password access in sshd uit te zetten voor system die aan internet hangen.

Ik denk ook dat deze aanval niet gaat over het password dat je met een ssh sessie gebruikt, maar dat ze een password bedoelen dat je handmatig over een opgezette ssh verbinding intypt, zoals bij een su of sudo commando. Dit lijkt me wel een lastige aanval omdat je over het algemeen veel meer karakters typt, waarbij ze dan eerst nog het su of sudo commando moeten herkennen.

[analog_]

Het is sowieso een bijzonder optimistische theorie gezien Nagle’s algorithm default wordt toegepast.

[MSalters]

In de praktijk is die vertraging zelfs nog kleiner dan onmerkbaar, omdat je in die situatie meerdere toetsaanslagen in één (versleuteld) bericht verstuurt.

Overigens is het sowieso een klein probleem omdat er twee alternatieven al breed gebruikt worden. Password managers zenden je SSH password in één keer uit; de keyphrase die je gebruikt voor de password manager loopt niet via SSH maar blijft lokaal. verder zijn SSH certificates een sterker alternatief dan passwords via SSH, een ook die certificates gaan in één pakketje over het netwerk.

[2green]

Verwarrende naam zeg!

Netcat is ook de naam van een van de populairste Linux tools voor netwerk testen, monitoren, etc.

Helemaal niet verwarrend gezien het feit dat beiden iets met netwerken doen...

[cavey]

Wellicht omdat het veel op netcat lijkt, dat ze het zo genoemd hebben. Aangezien netcat ook alles doorgeeft dan wel echo’d wat je typt. Doet deze tool dat in de vorm van deze kwetsbaarheid ook.

Tl;dr: pun intended

[basmevissen]

Mooie vondst. Alweer een kwetsbaarheid veroorzaakt door een optimalisatie. Het doet mij vrezen dat we nog heel wat dingen gaan ontdekken over al die optimalisaties in processoren. Zeker nu er wereldwijd veel mensen mee bezig zijn. Grote voordeel van onderzoekers verbonden aan een universiteit is dat ze tenminste erover publiceren. Ik heb een sterk vermoeden dat er al lang veel meer ontdekt is, maar niet in de openbaarheid is gebracht.

Snap alleen niet waarom ze niet eerst eens gegoogled hebben naar de naam NetCat voordat ze de kwetsbaarheid die naam gaven. Al heel wat jaren bestaat er namelijk al een veelgebruikte utility met die naam: https://en.wikipedia.org/wiki/Netcat

[Reactie gewijzigd door basmevissen op 23 juli 2024 12:54]

[laptopleon]

Die pakketjes corresponderen met toetsaanslagen en dankzij statistische analyse van de tijden, via een zogenoemde keystroke timing attack, zijn de getypte toetsen te achterhalen.

LOL. Ik vind dit een extreem onwaarschijnlijk scenario.

Die analyse is gebaseerd op de verschillen in tijd tussen het typen van bepaalde achtereenvolgende toetsen. De onderzoekers geven als voorbeeld dat het korter duurt om eerst een 'a' en dan een 's' te typen dan een 'g' na een 's'.

Eh… misschien als je met twee vingers typt? Om te beginnen typt de serieuzere computergebruiker – en dat is toch wel de categorie die überhaupt SSH gebruikt – blind. Gaat ‘gs’ dan nog sneller dan ‘sh’? De tijden liggen dan heel dicht bij elkaar en dan nog… beetje wachtwoord heeft een special teken er in, wat vaak langer duurt, maar qua tijd weet je dan alleen dat het waarschijnlijk geen letter is. Ja, ja, statistisch een voordeel maar heel klein bier allemaal dit. Sowieso typt iedereen weer anders qua ritme.

[lenwar]

Ja, het klinkt allemaal van 'uh huh! 8)7'. Er zijn echter allerlei studies gedaan naar dit onderwerp. En door iemand z'n typgedrag eventjes te analyseren creëer je simpel gezegt en matrix die je tegen een model aan kan zetten, en daar kom je blijkbaar een heel een me.

Hier een rapport in een Javascript omgeving :
https://mlq.me/download/keystroke_js.pdf

Andere studies laten zelfs een soort typhandtekening zien, waardoor je aan het typgedrag kan zien /horen wie er typt op basis van snelheid per letter - hoelang je je toetsaanslag per letter ingedrukt houdt, tijd tussen aanslagen en extern op basis van een typritme.

[Immutable]

Dit vind ik pas gevaarlijk. Je kan met AI deze patronen aanleren en vergelijken. Dit is een natte droom om mensen via internet te volgen. Een javascript file die al mijn keystrokes volgt zoals deze comment die ik invul.... en dan mij linkt aan ee ghostprofile die steeds meer en meer aangevult wordt....

Dit is de reden voor ghostery. En andere tracking block programma's. Gebruikers analyseren heeft voor mij de grens tot aan AI. Want ik weet donders goed hoe goed AI pattern matching werkt.

[laptopleon]

‘Zelfs’ impliceert dat zo’n soort typhandtekening bijzonderder is dan het wachtwoord raden, maar ik zou dat juist veel knapper vinden.

Dat verschillende mensen een makkelijk uit elkaar te houden ‘typhandtekening’ hebben is juist heel aannemelijk. Er een wachtwoord uit destilleren is dat niet.

Bovendien heeft de aanvaller geen vergelijkingsmateriaal van het typegedrag en welke aanslagen bij welke characters horen.

[lenwar]

Dat probeerde ik niet te impliceren. Ik doelde slechts op het feit dat 'ze' best een boel informatie uit iemand z'n toetsaanslagen kunnen halen, waaronder, onder de juiste omstandigeden 'wat ze typen'. Dat bepaalde letters vaker sneller na elkaar aangeslagen worden hebben zij blijkbaar kunnen meten. (ongetwijfeld zal het niet een 100% score zijn).

Ik kan me overigens voorstellen dat als je blind typt de a en de s sneller na elkaar komen aangezien de g en de s, gezien je je vinger moet verplaatsen, maar dat is puur een aanname van mij. Allicht is er een andere reden voor.

Ik denk overigens dat als iemand een 'complex wachtwoord' heeft dat het dan niet zo lekker zal werken/uit te buiten is als dat er wordt gesuggereerd. Desalniettemin vind ik het een interessante exploit

[laptopleon]

De vraag is of gs in praktijk sneller is omdat mensen een beter getrainde wijsvinger hebben dan pink

Aan de andere kant kan een geoefend blindtyper twee handen tegelijkertijd / door elkaar gebruiken voor sh.. Vandaar dat het me niet zou verbazen als beiden heel dicht bij elkaar liggen / elkaar afwisselen qua timing / niet te onderscheiden zijn.

Maar inderdaad wel interessante materie.

[Scriptkid]

Idd maar ik mag ook hopen dat je in je ssh geen wachtwoorden typt.

Ssh zelf dien een certificaat te hebben en root paswoorden dienen kang en complex te zijn dus je moet vaak van een ander scherm kijken dus ke aanslagen tijden zijn 3+sec.

Applicative pasw zou je niet via ssh moeten doen maar via de applicatie

[Horatius]

Ik dacht eerst dat het ook ging om de typ snelheid van de persoon en vond t ook vrij raar, zeker met typfout en backspace etc. Maar gaat hier niet om hoe snel de processor het verwerkt? Dus een s verwerkt sneller dan een g etc?

[latka]

Nee, type snelheid en daarmee een statistisch profiel maken is goed mogelijk. Zelfs als je niet 100% zeker bent van de getypte letters kun je de zoekruimte waarbinnen het paswoord moet liggen flink verkleinen.

[Reactie gewijzigd door latka op 23 juli 2024 12:54]

[Fido]

Gebruik 2 factor, dus een key met wachtwoord. En anders complexe wachtwoorden die je plakt vanuit een password manager.

[OddesE]

Ja precies. Beetje opgeklopt. Maar het heeft gewerkt want ze staan op de frontpage. Overigens denk ik dat dit systeem juist heel slecht werkt bij onervaren gebruikers want die typen heel onregelmatig

[Cergorach]

Gaat ‘gs’ dan nog sneller dan ‘sh’? De tijden liggen dan heel dicht bij elkaar en dan nog…

Juist met gs vs. sh zal je dat verschil erg merken ivm dat gs in dezelfde regionen zit bij blind typen en sh in twee verschillende. Het analyseren van dat gedrag zal ook niet door iemand met een timer gebeuren, maar is een automatisch proces welke natuurlijk met heel wat cijfertjes achter de komma kan werken...

[laptopleon]

Een beetje ervaren blindtyper kan zowel gs als sh zeer snel aanslaan. Dat ze in verschillende regionen liggen maakt juist voor blindtypers weinig uit.

Sterker nog het zou zomaar kunnen dat de ene blindtyper gs een fractie sneller typt, de andere sh en weer een ander afwisselen sneller en langzamer.

Het zal vaak meer invloed hebben qua tijd, waar je vingers ‘vandaan moeten komen’ oftewel wat de voorgaande toetsen waren. Dat maakt het giswerk extreem complex want voor het eerste er heb je geen ‘tussentijd’ dus je hebt geen enkele aanwijzing welke dat is. Als je dus al niet weet waar die vingers vandaan moeten komen voor de tweede aanslag, stapel je dus onzekerheid op onzekerheid bij elke volgende character.

Daarbij weet je niets over de typist. Je weet zijn ‘typhandtekening’ niet.

Ik denk daarom dat het hooguit wat helpt om het gokwerk waar de ‘speciale tekens’ en cijfers zitten te verbeteren.

[mjab93]

Wat blijft dit toch een poppenkast op de processormarkt in 2019, zeg. in de ene hoek Intel die dus, als Zwitserse kaas, vol kwetsbaarheden zit en enorm met de prijzen moet gaan zakken in HEDT om nog competitief te blijven en in de andere hoek hebben we AMD met hun eindeloze boost "fixes", vreemde temperatuur schommelingen, processoren die tot de uiterste maximum af fabriek worden overgeklokt en de wereldklasse marketing (remember 3900X op 4.6GHz?)...

[Reactie gewijzigd door mjab93 op 23 juli 2024 12:54]

[Sp3ci3s8472]

Denk dat ik liever 100Mhz mis dan een lekke cpu, tenminste voornamelijk als het een server is. Desktop maakt het vrij weinig uit.

Ontopic:
Volgens mij ontloop je een boel problemen door gewoon gebruik te maken van een ssh key en indien je toch een wachtwoord moet intikken dat het in een password manager waardoor het copy/paste is.
Daarnaast mag ik hopen dat een server zo is ingericht dat het account waarmee je ernaar toe sshed zelf geen root rechten heeft en het account persoons gebonden is zodat dingen te traceren zijn.

Edit:
Volgens mij verwoord ik het verkeerd? Ik heb liever dat mijn cpu 100Mhz mist dan een gatenkaas .

[Reactie gewijzigd door Sp3ci3s8472 op 23 juli 2024 12:54]

[XiniX88]

Ik snap niet dat iedereen hier zo over valt. Er zijn benchmarks uitgevoerd waaruit blijkt dat AMD prima functioneert. Dat het dan niet de absolute snelheid haalt zie ik zelf niet direct in als een onwijs probleem. Kloksnelheid zegt ook vrij weinig, vind het zelf nogal een storm in een glas water.

Intel aan de andere kant kent behoorlijk wat lekken (meeste gelukkig wel gepatcht in de nieuwste generatie) + stukken duurder. Geef mij inderdaad maar een chip die net iets minder presteert dan geadverteerd dan een ietwat overpriced CPU van Intel.

[Reactie gewijzigd door XiniX88 op 23 juli 2024 12:54]

[Sandor_Clegane]

En die 100 Mhz lever je bij Intel weer in met alle fixes.....

[Azbest]

Ik mis liever helemaal niets. CPU's zijn ontworpen met oog op prestaties, achteraf hardware patchen met software is gewoon bagger.

Nu moet ik wel zeggen dat ik dankzij deze hele affaire opeens een stuk voordeliger kan experimenteren met Intel hardware. Ik heb verschillende systemen getest met de kernel parameter "mitigations=off" en zelfs met browsen kun je soms al verschil vernemen.

Mijn xeon e5450 draait hier met mitigations=off, weet iemand of er ook al een manier is omdat met Windows 10 te kunnen doen?

[Houtenklaas]

En daarom is het goed dat je beseft of de "kwetsbaarheid" inderdaad op jou van toepassing is. Mijn auto heeft een glazen zijruit en is daarmee ook kwetsbaar voor inbraak door dat ding in te meppen. maar blijkbaar is dat onvoldoende "kwetsbaar" om de autoverkoop onder druk te zetten. Als ik deze kwetsbaarheid lees, dan is het terecht dat Intel dit als "laag" inschat. De typesnelheid van mensen onderling, het links- of rechtshandig zijn heeft al invloed. Daarnaast moet ik denken aan een onderzoek dat door toetsaanslagen auditief te onderzoeken hetzelfde al mogelijk was. En je moet hier toegang hebben tot het netwerksegment van de processor/PC in kwestie. Prima onderzoek en een prima actie van Intel. Patch uitgebracht met de kwalificatie "doe normaal".

[Stoffie22]

. Mijn auto heeft een glazen zijruit en is daarmee ook kwetsbaar voor inbraak door dat ding in te meppen. maar blijkbaar is dat onvoldoende "kwetsbaar" om de autoverkoop onder druk te zetten.
Slecht voorbeeld hoor, een autoruit is noodzakelijk en zit in alle auto's van ieder merk. Kijk als er bvb ramen in zaten welke ongewild plotseling willekeurig open gingen, en dit is bij een bepaald merk weet ik zeker dat men daar problemen mee zou krijgen!

[[Yellow]]

Ik kan niet echt een patch vinden achter de 'uitgebracht' link, maar dat zal dan wel aan mij liggen. Het enige dat daar staat is het volgende: "Where DDIO & RDMA are enabled, limit direct access from untrusted networks." oftewel een Xeon is niet default te gebruiken als firewall.

Dat deze kwetsbaarheid de status laag krijgt is waarschijnlijk omdat Xeon's zelden als firewall gebruikt worden.

[JohanNL]

Ik denk dat er nu ook gewoon meer aandacht voor is dan voorheen, niemand heeft in het verleden processoren echt onderzocht op kwetsbaarheden maar sinds dat met Spectre is het balletje gaan rollen.

[bjp]

ja deze kwetsbaarheid is dus vrijwel lastig te gebruiken.
Je gaat toetsenaanslagen gaan meten in de tijd, en daarmee proberen te raden wat de gast getypt heeft. Enkel op bepaalde Xeon's...

Je moet er wel controle over het netwerk hebben.

Intel heeft een grote sprong in performance gedaan, en nu veel later blijkt dat hier en daar een risico op problemen (veiligheid) niet 100% afgedekt was. Speculatieve aanvallen. Dit is een nieuwe klasse van problemen en aanvallen. ARM en zo hebben er soms ook last van.

Ja het zou beter kunnen, je zou zelf beter durven verwachten van Intel.

[Scriptkid]

Hoho x3900 loopt gewoon op 3.8. Dat hele boost verhaal is door de consumenten uit verband getrokken.

4.6 is de max boost niet de sustainable boost.

Eerst liepen tweskers altijd zelf te overclokken en nu krijg je een factory overclock en gaat men lopen bitchen dat ze niet allemaal evengoed overclocken. Volgensmij is dit al 20 jaar bekend dat niet alle chips het zelfde zijn.

[Countess]

Ga je nu echt een piep klein en tijdelijk performance probleem (als het al verschil maakt) van AMD vergelijken met de maar aanhoudende stroom aan veiligheidslekken bij Intel?

[Nieuwevolger]

Vindt het heel bijzonder al die kwetsbaarheden in intel cpu’s, zijn amd cpu’s dan wel 100 procent veilig of worden er gewoon niet zoveel onderzoek op gedaan. En hoe zit het met kwetsbaarheden in mobiele socs?

[EXos]

Ze hebben een gaatje gevonden in Intel chips en zijn gaan pulken en proberen.
Het gaatje bij AMD bleek oppervlakkig.

Het is gewoon Intel's moment om door de mangel gehaald te worden.
Ik denk dat ze de aanvallen ook op AMD proberen maar de chips zitten gewoon anders in elkaar.

[Dennism]

Niemand is 100% veilig. AMD is momenteel wel veiliger dan Intel wanneer je apparatuur niet of niet correct gepatched / geconfigureerd is. Maar 100% veilig is ook AMD niet en wat er in de toekomst nog ontdekt gaat worden is sowieso koffiedik kijken.

100% veiligheid is denk ik ook een utopie, maar als je momenteel een in de markt bent voor een systeem en veiligheid is een hot issue voor je dan is momenteel AMD zeker de betere keuze.

[litebyte]

Klopt, dan weet natuurlijk ook (vrijwel) iedereen.

Wat dan wel frappant is, is dat de kwaliteitsmedia aan de ene kant de niet eens bewezen 'onveiligheid' van een grote mobiele communicatie fabrikant uit China op de voorpagina zet. Terwijl de onveiligheden (backdoors) in Intel chips nauwelijks enige vorm van media aandacht krijgen.

[Wim-Bart]

Ondanks dat je gelijk hebt over de toekomst is het vanuit een security punt gewoon niet verstandig om Intel aan te schaffen. Ik zie het als een ziek persoon, daarbij zeg je ook niet, hij kan in de toekomst weer ziek worden, dus medicatie geven heeft geen zin.

Wanneer je nu een Xeon aanschaft weet je dat je onveilig bent. Het probleem zit namelijk niet in de gevonden gaten, het probleem zit hem in het caching design en branch prediction van de Intel chips, er is daar in de basis iets fout wat in AMD dus anders heeft ontworpen. Er zullen dus meer en meer vulnerabilities gevonden worden in Intel chips.

Je kan dus gewoon stellen, zolang er geen nieuwe architectuur ligt van Intel chips dan is het wachten op het volgende probleem.

En hier zie je ook aan waar het fout gaat bij Intel, door de architectuur zijn de chips snel, maar boet je in op veiligheid, en wat dus verbazingwekkend is, is dat AMD dus zonder security te compromiteren in staat is geweest om de IPC boven Intel te brengen.

Mijn vermoeden is dan ook dat Intel nu issues heeft met nieuwe ontwerpen om de zelfde IPC te halen en de veiligheid op te schroeven.

[Dennism]

Ondanks dat je gelijk hebt over de toekomst is het vanuit een security punt gewoon niet verstandig om Intel aan te schaffen. Ik zie het als een ziek persoon, daarbij zeg je ook niet, hij kan in de toekomst weer ziek worden, dus medicatie geven heeft geen zin.

Ben ik met je eens, echter ontkom er maar eens aan. AMD Epyc is amper fatsoenlijk leverbaar, in HA opgezette virtualisatie clusters kan je geen AMD en Intel mixen, heb je dus al Intel moet je of via een Big Bang migratie naar AMD toe of toch Intel aankopen als je nu capaciteit nodig hebt.

Wanneer je nu een Xeon aanschaft weet je dat je onveilig bent. Het probleem zit namelijk niet in de gevonden gaten, het probleem zit hem in het caching design en branch prediction van de Intel chips, er is daar in de basis iets fout wat in AMD dus anders heeft ontworpen. Er zullen dus meer en meer vulnerabilities gevonden worden in Intel chips.
Je kan dus gewoon stellen, zolang er geen nieuwe architectuur ligt van Intel chips dan is het wachten op het volgende probleem.

En hier zie je ook aan waar het fout gaat bij Intel, door de architectuur zijn de chips snel, maar boet je in op veiligheid, en wat dus verbazingwekkend is, is dat AMD dus zonder security te compromiteren in staat is geweest om de IPC boven Intel te brengen.

De kans dat er meer vunerabilities voor Intel worden gevonden is zeker aanwezig en zelfs vrij waarschijnlijk.
Dit lijkt voornamelijk te komen omdat de basic van Intels huidige architectuur gelegd is begin tot midden jaren 2000, toen dit soort vunerabilities niet op het netvlies stonden van de engineers verantwoordelijke voor het ontwerpen van cpu's, Tweaker Squee heeft daar eens een mooie post over geschreven.
AMD's Zen architectuur is veel nieuwer. Daardoor vind ik het ook niet zo vreemd dat qua IPC Intel is gaan overstijgen. Intel zit vast aan een oude architectuur tot ze hun 10nm proces aan het werk krijgen of meer waarschijnlijk hun 7nm proces. Daar het er niet op lijkt dat Intels 10nm echt in volume productie gedraaid zal gaan worden.

Mijn vermoeden is dan ook dat Intel nu issues heeft met nieuwe ontwerpen om de zelfde IPC te halen en de veiligheid op te schroeven.

Dat vraag ik me af, Intels nieuwe architectuur (Sunny Cove) zou deze kwetsbaarheden niet hebben (moet natuurlijk nog wel blijken) en deze nieuwe architectuur laat IPC verbeteringen zien van +-18% over de huidige Core architecuur. Vooralsnog is deze architectuur echter enkel verkrijgbaar in 2/4 core laptopships en is het maar de vraag of deze ooit naar de desktop gaat komen. Wel gaan er geruchten over Xeons in 2020 op basis van deze architectuur, maar ook dat is eerst zien, dan geloven.

[K-aroq]

Je moet er bij security altijd vanuit gaan dat niets veilig is. Of dat nu iets in een CPU is, of jouw voordeurslot. Vervolgens ga je na een risico analyse aanvullende maatregelen nemen. Bijvoorbeeld een afgesloten tuinhek om de toegang tot jouw voordeur moeilijker te maken.

[Countess]

Het zijn bijna allemaal varianten op eigenlijk het zelfde, de side channel attack. En Intel patched de buitenkant iedere keer, maar het onderliggende probleem in de hardware blijft bestaan, dus zal de stroom aan exploits blijven komen.

Intel heeft zeker 2 ontwerp keuzes gemaakt voor meer performance ten koste van security: een sequential TLB en bij speculatieve execution de beveiliging pas achteraf controleren.

AMD niet en daarom is de enige side channel attack die bij AMD gewerkt heeft er een waarbij de zelfde thread informatie voor zichzelf verborgen moest houden (in de browser).

[MSalters]

Side channel attacks tegen crypto (zoals SSH) zijn al veel langer bekend. Dat is geen recent Intel probleem. Het is bijvoorbeeld expliciet meegenomen in AES; in 1998 schreef Bruce Schneier er al over.

Wat hier dus wél meespeelt is dat Intel niet de maker van SSH is, ze doen de crypto niet zelf. Intel heeft wel crypto algoritmes op de Xeon, maar dat zijn dus timing-onafhankelijke AES algoritmes.

[Countess]

Sorry, double post.

[Reactie gewijzigd door Countess op 23 juli 2024 12:54]

[franssie]

De classificatie is lastig. De kan is klein 0 de gevolgen kunnen groot zijn maar die gevolgen zijn afhankelijk waar je het systeem gebruikt. Mijn hobby apple server met xeons mogen ze hacken en dan hebben ze wat lokaal spul. Als het een server is waar zeer gevoelige data op draait dan is zowel de kans dat ze het hacken groter, maar zeker de gevolgen.
En dat lijkt steeds meer een probleem te worden van de slimme meedenkende processors. Soms wil je denk ik gewoon ruwe brute kracht ipv allerlei slimme alogritmes die je cache etc verdelen.

[K-aroq]

Maar als er zeer gevoelige data is, zullen er ook weer meer lagen beveiliging zijn dan bij jouw Apple server. Waardoor je de risico impact een individueel risico weer verkleint.

[MSalters]

Het is een nogal theoretische aanval. Je hebt speciale high-end Intel features nodig (Data-Direct I/O) die bedoeld zijn voor servers met hoge load, maar tegelijekrtijd heb je een lage load nodig om de timing betrouwbaar te maken. Met tienduizenden IP pakketjes per seconde kun je die paar SSH keystrokes er niet uit vissen, en al zou je het kunnen, de timing ervan is dan onnauwkeurig.

Wat ze in Amsterdam hebben gedaan is een zware Xeon testen zonder load. Dan reageert die inderdaad instantaan op een SSH pakketje, wat dus een precieze timing geeft. Ik daag ze uit om het effect te reproduceren op een VPS in een cloud-omgeving, waarbij de CPU en het netwerk gedeeld worden en de timing dus variabel is.

[bluegoaindian]

Disable HYPTER THREADING....