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 vinden nieuwe kritieke lekken in vrijwel alle Intel-cpu's

Onderzoekers van de Vrije Universiteit Amsterdam hebben een nieuw kritiek lek gevonden in Intel-processors. Ook andere universiteiten en beveiligingsbedrijven openbaren dinsdag nieuwe lekken. Intel en softwarebedrijven komen met patches.

De VU-onderzoekers noemen de kwetsbaarheid die ze gevonden hebben, RIDL. Dat staat voor Rogue In-Flight Data Load. Met het lek is alle data die de cpu verwerkt, inzichtelijk voor een aanvaller. Het lek is volgens de onderzoekers te misbruiken via bijvoorbeeld JavaScript op een website. Gebruikers met computers die niet van updates zijn voorzien, zijn daarom kwetsbaar.

Stephan van Schaik, student Informatica, kwam de kwetsbaarheid per toeval tegen tijdens een onderzoek naar een al bekend lek in Intel-processors. De technische details staan beschreven in een paper. Van Schaik ontdekte de kwetsbaarheid in september 2018, zegt hij tegenover NRC. Een Intel-processor uit 2008 bleek het lek ook te bevatten en Intel werd direct gewaarschuwd. Ook Intels Xeon-processors voor servers zijn vatbaar.

Een vergelijkbare kwetsbaarheid werd gevonden door andere onderzoekers, onder andere die van de KU Leuven. Zij noemen hun vondst Fallout. Beide worden door Intel gekenmerkt als Microarchitectural Data Sampling-kwetsbaarheden. De onderzoekers hebben gezamenlijk een MDS Attack-website online gezet met daarop hun bevindingen.

Wetenschappers van de Oostenrijkse Universiteit van Graz publiceren tegelijkertijd informatie over hun nieuwe kwetsbaarheid: ZombieLoad. Ook die treft Intel-processors. De onderzoekers van Graz hebben ook de website cpu.fail in het leven geroepen met daarop een overzicht van alle nieuwe ontdekkingen. Het gaat volgens onderzoekers om hardwarematige bugs die alle Intel-processors van de afgelopen tien jaar treffen.

De nieuwe lekken volgen ruim een jaar na de ontdekking van de Meltdown-kwetsbaarheid, waarmee informatie uit het geheugen onderschept kon worden. De nieuwe kwetsbaarheden hebben net als toen te maken met speculative execution; het voorspellen van berekeningen wat resulteert in prestatiewinst. Dezelfde teams die destijds Meltdown ontdekten, komen nu met de nieuwe kwetsbaarheden naar buiten.

'Intel probeerde de ernst van het lek te bagatelliseren'De Vrije Universiteit heeft het grootste deel van de lekken ontdekt en krijgt als enige partij een beloning van Intel. De universiteit uit Amsterdam ontvangt 100.000 dollar, dat is het hoogste bedrag dat Intel uitkeert aan ontdekkers van kritieke kwetsbaarheden. Volgens NRC probeerde Intel de ernst van het lek te bagatelliseren door 40.000 dollar als beloning aan te bieden en daarnaast nog eens een bedrag van 80.000 dollar los. De universiteit heeft dat aanbod afgeslagen.

Ook hekelt de VU dat Intel verzuimde om Google en Mozilla in te lichten en bovendien zou Intel lang gewacht hebben met het publiceren van de kwetsbaarheden. Herbert Bos, beveiligingsonderzoeker van de Vrije Universiteit, heeft afgedwongen dat Intel in mei naar buiten zou komen, anders zou de universiteit zelf gaan publiceren. Intel had volgens Bos nog wel een halfjaar willen wachten met publicatie. Of er kwaadwillenden van de lekken gebruik hebben gemaakt, is niet bekend.

De informatie over de nieuwe lekken is naar buiten gebracht op Patch Tuesday; het maandelijkse moment waarop Microsoft belangrijke patches uitbrengt voor Windows. Gebruikers wordt aangeraden om software zoals het besturingssysteem en browsers up-to-date te houden. Microsoft, Google en Apple hebben pagina's met informatie over updates die betrekking hebben op MDS-aanvallen, online gezet.

Intel heeft een eigen website ingericht over MDS-aanvallen en heeft microcode-updates voor zijn processors uitgebracht en claimt daarop dat een select aantal processors van de achtste en negende generatie hardwarematig beschermd zijn. De beveiligingsonderzoekers schrijven echter dat de RIDL- en Fallout-kwetsbaarheid in alle Intel-processors zit, ook de nieuwste met hardware-aanpassingen tegen Meltdown. Sommige processors van de negende generatie zijn volgens de onderzoekers zelfs kwetsbaarder dan oudere cpu's. AMD- en Arm-processors zijn niet getroffen door de nieuwe lekken.

Door Julian Huijbregts

Nieuwsredacteur

14-05-2019 • 21:14

303 Linkedin Google+

Submitter: hgkertjed

Reacties (303)

Wijzig sortering
OSX gebruiker kunnen updaten naar 12.7, 13.7 of 14.5
https://support.apple.com/en-us/HT210107

/edit @pBook heeft gelijk, er is geen 12.7 en 13.7

[Reactie gewijzigd door wica op 14 mei 2019 21:43]

macOS performance: Testing conducted by Apple in May 2019 showed as much as a 40% reduction in performance with tests that include multithreaded workloads and public benchmarks.
Wacht, dus als ik mijn Macs update, ga ik 40% in performance achteruit? :(

Kun je ook MacOS updaten zonder de Intel patch :?
Nee, door de update te installeren wordt je Mac niet langzamer.
Alleen als je volledige bescherming wilt, moet je nog wat extra commando's uitvoeren en dan kan die idd langzamer worden.
Full mitigation requires using the Terminal app to enable an additional CPU instruction and disable hyper-threading processing technology.
Heeft het uitzetten van Hyper-threading daad werkelijk volledige bescherming?
Heb door de gelinkte articles zitten bladeren maar daar ligt de focus meer op Hyper-V en deze werkt op cores met & zonder Hyper-threading features.

Nu neem ik de vermelding van Intel met een korreltje zout.


Is Intel recommending that I disable HT?
No. Intel is not recommending that users disable Intel® Hyper threading. It’s important to understand that doing so does not alone provide protection against MDS, and may impact workload performance or resource utilization that can vary depending on the workload.
Toch grappig, OpenBSD heeft vorige jaar HT uitgezet en niet meer vatbaar.
Linux erkent, door het niet uit zetten van HT, dat er een risico blijft bestaan.

Google stop helemaal met HT in hun ChromeOS.
https://www.theregister.c...er_threading_mitigations/
Hoe groot is de noodzaak/nut van Hyperthreading eigenlijk nog. Het aantal cores op een processor neemt snel toe. Sneller dan de software het kan bijbenen (zie Threadripper).

Dus als HT een grote bron van de lekken is, waarom HT dan niet gewoon uitschakelen als dit de veiligheid van je systeem vergroot.
Ik heb dat full mitigation gedaan op mijn mac. Hij werd er alleen maar sneller van. Met name opstarten. Virtualbox werkt ook sneller. Alleen xcode en dan vooral de simulator werkt een ietsiepietsie trager, maar evengoed nog prima hoor.
Maar gaat Apple het uitzetten van HT echt afdwingen denk je? Dan gaan alle performance claims het raam uit :)
Tuurlijk niet, ik zie de "class action lawsuits" al aankomen :)
Er zijn omgevingen waar je het wel moet doen. Want nu legt Apple de verantwoording bij de gebruiker waardoor gebruiker dus aansprakelijk is voor schade door misbruik van de lekken.

Je bankrekening wordt geplunderd door een skimmer, bank zegt, je systeem was onveilig, geen schadeloos stelling bijvoorbeeld.

Je bent ontwikkelaar, via het lek is er code aangepast waardoor bedrijven opeens gevaarlijke software binnen krijgen.

Je systeem wordt gehackt waardoor er gevoelige data naar buiten komt.

Je zou maar aansprakelijk gesteld worden omdat je niet wilde mitigeren.
Ik heb dat vaker gelezen dat banken bijvoorbeeld niet uitkeren als je je (computer)beveiliging niet op orde hebt. Heb je toevallig misschien een linkje dat dat ooit is gebeurd?
Ben wel benieuwd waar ze naar kijken en hoe streng ze dat doen.
Geen directe link, maar het zouden scenarios kunnen zijn. Als ik bij een bank zou werken en ik krijg te horen dat ik een ton moet vergoeden en dan zie ik dat klant een ongepatcht systeem heeft. Dan zou ik het wel weten en voor mijn bonus gaan.

Maar dat zijn eigenlijk kleine persoonlijke drama's. Maar hoe veel data ligt er nu niet op straat welke door misbruik van dit soort exploits op straat ligt. Helaas meer dan wij weten en te horen krijgen.
Toch lijkt het mij nuttiger als banken meer naar ongewone activiteiten kijken (wat ze al doen. Naja, behalve de ING dan }> ).
Ik ben er zeer voor dat systemen altijd gepatched zijn. Ben daar thuis ook altijd streng op.
Maar je wil niet weten hoe onduidelijk en onbekend, op een goede manier, updaten is, bij hele volksstammen.
Dus om te stellen...eigen schuld, dikke bult....
Online bankieren is echt niet alleen een wens vanuit klanten geweest.
Met de (drog)reden van gemak is dat ook aardig opgedrongen aan de klanten. Er is mij namelijk nooit een keuze voorgelegd.
Er bestaat ook nog zoiets als zorgplicht van banken (wat een bank als de ING eventjes vergeten was).
Weer lekker ING bashen. Ik weet vrijwel zeker dat een veilig, up to date systeem in de voorwaarden van internetbankieren staat. En dat zal bij andere banken hetzelfde zijn.

Dat niemand die leest, daar kan de bank ook weinig aan doen. En je kunt ook niet al dit soort zaken in een notificatie op de inlogpagina zetten of bij het aanmaken van de rekening met de klant overleggen, tenzij je als een notaris de hele overeenkomt gaat voorlezen.
Maar een up-to-date systeem is vaak niet veilig...omdat daar bugs inzitten die nog gevonden moeten worden
Skimmen gebeurt door een aangepaste pinautomaat. Risico is voor de bank.
Hm, niet erg gemerkt met m'n latest, fully-specced Pro tijdens het renderen met Terragen. Na 1:30u gaan chunks nog net zo snel als aan het begin. Maar dat zal wel aan mij liggen.

(Fuck Ayporos)
Nou dan moet je je model maar koesteren want dat thermal throttlen is toch echt wel een dingetje.
Fijn dat jij er geen last van hebt, maar dat betekent (natuurlijk) niet dat het niet-bestaand is. Verre van zelfs...

Overigens is dat "fuck apple" een quote/ meme van Louis Rossman, (het zijn niet de woorden van Ayporos, maar dat moet je ook maar net weten). Die Rossman rant er regelmatig lustig op los als het op Apple aankomt (meestal met reden, maar soms is hij ook gewoon onredelijk).
Ook bij bijv. Linus tech tips hebben ze meerdere tests gedaan en daarbij kregen ze de macbooks telkens weer aan het throttlen.

Geweldig toch? Voor je klant besluiten dat het ding nog wel 2 mm. platter kan (wie vroeg er nog om?), daardoor de koeling een nog grotere uitdaging maken. Vervolgens toetsenbord aan moeten passen (met alle gevolgen van dien) en dan die intel chips die niet helemaal presteren als voorgesteld....

Het is best een clusterfuck eigenlijk.

[Reactie gewijzigd door SuBBaSS op 15 mei 2019 13:08]

Mooiste vind ik dat ze dan vervolgens in de nieuwe versie een nieuwere duurdere CPU doen.. maar dat ding vervolgens zo hard throttled dat de daadwerkelijke performance LAGER is dan het vorige model met oudere CPU.

Ik snap dat 'fuck Apple' resulteert in een -1 moderatie, maar het is MIJN mening (die ik deel met Louis Rossman en menig anderen) en het maakt mij geen moer uit dat er mensen zijn die daar van niet gediend zijn. Gelukkig leven we in een vrij land waar mensen (nog wel... *zucht*) de vrijheid hebben om kritiek te uitten op anderen/bedrijven/producten.
Dus wat jij wilt zeggen is.. omdat ik een negatieve mening heb over een bedrijf waarvan jij een product bezit dat IK dan vervolgens in jou ogen persona non grata ben?... wauw wat simpel. :+
Nou, je hebt in 2 comments drie keer de emoticon :+ gebruikt, krijgt niet alleen van mij een -1, maar van 56 (!) mensen. Je begint je post met "Ach nee joh" en eindigt met "Fuck Apple". Dus ja, je bent in mijn ogen een onwelkom persoon. En dat is niet (alleen) vanwege een negatieve mening over Apple. Het is vanwege je algehele negatieve houding. Nog een goede dag gewenst!
hahaha dat je nog reageert joh.

Als jij denkt dat mijn post een 'negatieve houding' omvatte dan heb jij waarschijnlijk nog nooit goede stand-up comedy gezien of wel?

Laat ik het, gezien jij ook de moeite nam om nog even te reageren, uitleggen:
- ik mag Apple niet, hier heb ik een waslijst van valide argumenten voor
- mijn post was niet 'negatief' maar eerder gebaseerd op sarcastische humor
- het gebruik van sarcastische humor illustreert beiden dat ik Apple niet mag, het me niet specifiek stoort (anders zou ik een directere grovere aanval gebruikt hebben) én dat ik bereid ben om enige concessies te doen mensen te trachten niet tèveel tegen de haren te wrijven (wat een directe grove aanval in grotere mate wél zou doen)
- het :+ emoticon is perfect toepasselijk in dit geval daar het illustreert dat mijn uitlatingen met een korreltje zout genomen dienen te worden, humoristisch van aard zijn en niet al te veel gravitas bevat.

Ik wens u ook een goede dag! ;) :+
Nee, dat klopt niet.

Specifieke operaties kunnen tot 40% langzamer zijn, maar het zou soms ook 5% of 10% kunnen zijn. Performance benchmarks die veel gebruik maken van zo'n operatie kunnen aanzienlijk lager scoren, maar deze benchmarks zijn vaak niet representatief voor werkelijk gedrag.

Waarschijnlijk gaat om het een relatief klein deel van de operaties. Wat de werkelijke impact is op dagelijks gebruik is moeilijk te voorspellen. Misschien dat het starten van een applicatie 5% langer duurt. De kans is echter groot dat je er niets van merkt.

Het is niet onverstandig een dagje te wachten met updaten om te kijken of het internet ontploft.
Gamen is geen specifieke operatie?
Nee, dat zijn duizenden verschillende operaties en de cpu is vaak niet eens de bottleneck.
De update kan je gewoon installeren, immers moet je eerst zelf wat commando's uitvoeren na de update om de extra bescherming te krijgen die de boel flink kan vertragen. (HT uitschakelen, essentially.) Daarmee kan je wel een paar dagen wachten natuurlijk.
Ja, klopt.
Kan je na gaan hoe belangrijk HT voor Intel is.
Voor AMD doet SMT ongeveer hetzelfde en net zo veel voor multithreaded loads. Maarja daar hoef je het vooralsnog niet uit te schakelen om veilig te zijn ;)
Maar SMT is een relatief nieuw iets voor AMD, waar HyperThreading al redelijk oud is. 2002 was de eerste HT implementatie, terwijl eerste partial SMT in bulldozer (2011) zat en bidirectional voor het eerst in zen (2017). Dus zelfs als AMD wel getroffen zou zijn, zou het om minder modellen gaan.
waar HyperThreading al redelijk oud is
Maar HT op de P4 was niet zo fantastisch. En tussen de HT op de P4 en HT op de Core i hebben meerdere generaties zonder HT support gezeten. Ik zou dus niet willen stellen dat de HT van nu hetzelfde is als de HT van toen :).
Ja, maar tussen 2011 en 2017 heeft AMD ook weinig noemenswaardige CPUs gemaakt. Pas met Zen zijn ze weer echt interessant geworden. (Op de sporadische APU voor een goedkope mediacenter na)
Kan je na gaan hoe belangrijk HT voor Intel is
Beweer je nu dat HT in de praktijk 30% performancewinst oplevert?

Volgens mij is het gemiddeld eerder 5 a 10% met uitschieters naar 40% in zeer bijzondere benchmark situaties en ook negatetieve uitschieters in zeer uitzonderlijke situaties.
Dat zegt Apple, niet ik
Apple zegt niet dat dat een typisch prestatie verlies is. Maar dat het in bepaalde situaties tot 40% kan oplopen.

Apple laat natuurlijk het worst case scenario zien, zodat mensen met klachten naar Intel verwezen kunnen worden. Maar dat is wat anders dan het gemiddelde prestatie verlies.

Als je vervolgens zegt dat HT zo belangrijk voor Intel is, dan praat je niet over een exotisch randgeval, want exotische gevallen zijn niet belangrijk voor Intel.
Dus nee, dit probeer je iets te makkelijk op Apple af te schuiven.
Ik schuif niets af op Apple. Apple kan hier niets aan doen.

Apple heeft dit zelf getest.
https://support.apple.com/en-us/HT210108
Testing conducted by Apple in May 2019 showed as much as a 40 percent reduction in performance with tests that include multithreaded workloads and public benchmarks. Performance tests are conducted using specific Mac computers. Actual results will vary based on model, configuration, usage, and other factors.
Jouw opmerking: "Kan je na gaan hoe belangrijk HT voor Intel is" probeer je af te schuiven op Apple.

JIJ beweert dat HT zeer belangrijk is voor Intel.
Apple zegt alleen dat het in bepaalde benchmarks in bepaalde workloads tot 40% impact kan hebben.

Dat zijn twee totaal verschillende dingen.
Een schrikbarend getal die 40% performance verlies. Ik haal uit het bericht van NRC dat chips van AMD er niet gevoelig voor zijn. Maar dat zou dan betekenen dat de chips van AMD, nadat dit lek gedicht is bij Intel, significant sneller zijn? Zijn die processors dan zo radicaal anders?

Die 120k die Intel aan de VU wilde betalen is dan ook peanuts als ik deze getallen zo zie :| tot wel 40% performance verlies op alle processors van de laatste 10 jaar bij een update die, naar mijn eerste vlugge oordeel, absoluut uitgevoerd moet worden.

Dit moet toch wel enorme effecten gaan hebben? Ik kan me voorstellen dat veel systemen niet bruikbaar blijven met zo veel performance verlies

[Reactie gewijzigd door Jonnie Bahaar op 14 mei 2019 22:14]

het is natuurlijk compleet logisch dat je als je HT uitzet je in echte multithreaded scenario's flink achteruit kan gaan (de winst van HT)

Puur de patch doet niet zo veel maar om echt veilig te zijn moet HT gewoon uit blijkbaar.

De meeste systemen blijven dus prima presteren omdat HT lang niet overal inzit (i5 bijv) en ook lang niet zo effectief gebruikt wordt door alle software. Tenminste, dat idee krijg ik op dit moment :)

Vooral voor servers is als HT uit moet het echt ruk

[Reactie gewijzigd door maratropa op 14 mei 2019 23:02]

Ik snap wat je bedoelt maar mijn Core i5 heeft wel degelijk HT.
Dan heb je een hele jonge i5, of een mobiele dualcore i5.
Op de desktop zat het er tot zeker 2015 niet in, als ik me niet vergis was de 8-serie de eerste maar dat laatste durf ik niet met zekerheid te claimen.
I5 heeft op de desktop geen HT gehad op een i5-660 na uit de eerste generatie. I5 mobile heeft ook quadcores met HT tegenwoordig (i5-8250U)
8/9 serie desktop i5 is 6 cores zonder HT

De laatste desktop i5 met HT was westmere, ergens in 2009/2010 of zo

HT op desktop CPUs zit in i3 tm de 7 serie, i7 tm de 8 serie, i9 en recente pentiums
das waar ja, slecht voorbeeld dus :) Maar iig ook zat cpu's zonder HT, bedoelde ik :) (al vraag ik me af of je dan veilig bent)

[Reactie gewijzigd door maratropa op 14 mei 2019 22:38]

De software is niet altijd op de hoogte van hoe hij uitgevoerd word.
HT aware software maakt gebruik van HT voor gelijktijdigige uitvoerbare code te versnellen.
Maar het os zelf kan ook HT gebruiken voor NIET HT applicaties meer timeslices te bieden, hij regelt met andere woorden zelf de HT.
De app op zich zal dus niet sneller werken maar hij zal meer CPU tijd krijgen en sneller die CPU tijd ontvangen.
Wat versta jij onder
HT aware software
?
Volgens mij heb je multithreaded software en singlethreaded software. De software weet niks van de CPU, maar zorgt dat er threads gemaakt worden die parallel uitgevoerd kunnen worden als het system waarop het draait daar de mogelijkheden voor heeft.
Dat werkt optimal voor meerdere cores, maar kan ook winst bieden voor HT.

Je wilt echt geen code specifiek voor HT maken. Dat is veel te veel afhankelijk van één specifieke hardware configuratie. (Hoogstens interessant bij een game console)
Holy crap. Dat is enorm veel prestatieverlies zeg!! Bedankt voor de info.

Ik weet niet of ik deze patch wel wil 8)7
Volgens mij is het zo'n "tot 40%" prestatieverlies.
Kan goed zijn dat je niets merkt. Kan ook zijn dat je dagelijks werk veel trager wordt, maar die kans is vrij klein.
Full mitigation requires using the Terminal app to enable an additional CPU instruction and disable hyper-threading processing technology. This capability is available for macOS Mojave, High Sierra, and Sierra in the latest security updates and may reduce performance by up to 40 percent2, with the most impact on intensive computing tasks that are highly multithreaded.
Nogal een sensationele quote van de poster...
Is dit met Hyperthreading uit? Of met de patch en Hyperthreading nog aan?

Edit:
Full mitigation requires using the Terminal app to enable an additional CPU instruction and disable hyper-threading processing technology. This capability is available for macOS Mojave, High Sierra, and Sierra in the latest security updates and may reduce performance by up to 40 percent2, with the most impact on intensive computing tasks that are highly multithreaded.

[Reactie gewijzigd door Loggedinasroot op 14 mei 2019 21:29]

Dat vind ik nogal wat zeg...
Ik zou zelf ook weleens benchmarks op windows en linux willen zien, daar hoeft de impact niet zo groot te zijn. Macos gaat soms toch wel anders om met dingen als multithreading en performance verschil is nu ookal erg zichtbaar in sommige situaties. En meestal niet in het voordeel van macos...
Als je hyperthreading uitschakelt is dit op elk platform significant merkbaar, helaas.
Ik snap niet waarom bovenstaande reactie +2 heeft (op moment van schrijven). Het is een stukje uit het Apple Support artikel dat volledig uit de context getrokken is en doelbewust hier geplaatst lijkt te zijn om reacties uit te lokken danwel mensen bang te maken.

Voor alle duidelijkheid: De optie waarmee je 40% aan performance verliest, is volledig optioneel, zijn op dit moment geen enkele exploits voor bekend én geldt zoals Apple schrijft alleen voor mensen wiens laptop in een verhoogde risicogroep zit met het oog op hacks/aanvallen. Met andere woorden: door de bocht genomen hebben we het dan over de CEO's van deze wereld en zeker niet de gemiddelde gebruiker of Tweaker.
Kan iemand me uitleggen hoe dit zit: ik heb high Sierra op een late 2009 27inch Mac. Nu kan ik dus schijnbaar een update krijgen, maar er staat bij de patch op de site dat er voor mijn model geen microcode update is. Nu lijkt me die patch dan weinig zin hebben en hoogstens een slechtere performance opleveren? Of zie ik dat verkeerd?
Die patch helpt met sommige aanvalsvectoren, maar niet alle om dat je zonder de microcode niet 100% afgedekt bent. Kortom: gewoon patchen, je gaat er in elk geval op vooruit.
Heb je dan nog een core 2 duo?
Die hebben sowieso het Hyperthreading/probleem niet.

Alleen de late 2009 snelste iMacs (de quad cores) hadden een Core-i processor.

[Reactie gewijzigd door White Feather op 15 mei 2019 07:48]

Ik heb een i5... Net na de laatste C2D. Is daar wel een patch voor? Ik wil niet 40% performance inleveren dan patch ik nog liever gewoon niet. Ik draai Logic X die heeft alle threads nodig..

[Reactie gewijzigd door terracide op 15 mei 2019 10:54]

De performance van 40% is als de gehele patching gedaan is èn Hyperthreading uitgezet wordt.
Bij jou staat Hyperthreading niet eens aan (want die i5 heeft dat niet), dus het grootste snelheidverlies wordt je bespaard.

Zoals @Backspin hieronder linkt: De Applesite geeft aan dat er voor de volgende systemen geen update is omdat Intel geen update in de microcode heeft:

Unsupported Mac models

These Mac models may receive security updates in macOS Mojave, High Sierra or Sierra, but are unable to support the fixes and mitigations due to a lack of microcode updates from Intel.

MacBook (13-inch, Late 2009) (Core 2 duo)
MacBook (13-inch, Mid 2010) (Core 2 duo)
MacBook Air (13-inch, Late 2010) (Core 2 duo)
MacBook Air (11-inch, Late 2010) (Core 2 duo)
MacBook Pro (17-inch, Mid 2010) (Core 2 duo)
MacBook Pro (15-inch, Mid 2010) (Core 2 duo)
MacBook Pro (13-inch, Mid 2010) (Core 2 duo)
iMac (21.5-inch, Late 2009) (Core 2 duo)
iMac (27-inch, Late 2009) (Core 2 duo/Core i5/i7 quad (Lynnfield)
iMac (21.5-inch, Mid 2010) (Core i3/i5 dual (Clarkdale))
iMac (27-inch, Mid 2010) (Core i5/i7 quad (Lynnfield))
Mac mini (Mid 2010) (Core 2 duo)
Mac Pro (Late 2010)

Over de laatste is Wiki niet duidelijk. De varianten met 1 processor, werden namelijk geleverd met een quad core Xeon (Bloomfield) of 6 core Gulftown Xeon, terwijl de varianten met 2 processoren altijd geleverd werden met quad of hexacore Gulftown Xeons. Waarschijnlijk bedoelen ze met Late dat de Gulftowns ook niet gesupport worden.

Het is dus allemaal core 2 duo/1e generatie i7 dat geen ondersteuning meer krijgt.
Voor de duidelijkheid, er is geen 10.12.7 of 10.13.7. Gisteren is 10.14.5 uitgebracht waarin o.a. deze patch zit. Deze patch is ook als “Security Update 2019-003” uitgebracht voor 10.12.6 en 10.13.6.
Je hebt gelijk, ik ging er vanuit dat ze de 12 en 13 ook de minor version zouden verhogen.
En voor Sierra en High Sierra de security updates 2019-003. Oudere versies zoals El Capitan worden niet gepatcht!

Ook zijn er problemen met de volledige patching van wat oudere modellen van Apple die geen microcode updates van Intel krijgen. Zie hier: https://support.apple.com/en-us/HT210107
Op deze pagina van Apple staat een lijst van Macs uit 2009 en 2010, waar het volgende bij gemeld wordt: "These Mac models may receive security updates in macOS Mojave, High Sierra or Sierra, but are unable to support the fixes and mitigations due to a lack of microcode updates from Intel."
Dit zijn Macs die over het algemeen nog prima zijn om op te werken, ook door Apple ondersteund met High Sierra en soms zelfs Mojave, maar zijn nu eigenlijk per direct allemaal onveilig omdat Intel geen microcode updates uitbrengt voor de oudere processoren in deze computers. Dit zal ook gelden voor Windows PC's met processoren uit die generaties.
Ik ben heel benieuwd of Intel hiermee weg gaat komen zonder rechtszaken.
Er staat toch letterlijk "due to a lack of microcode updates from Intel." Hoezo is dat dan een smoes van Apple? Alsof Apple tegen Intel zou kunnen zeggen: "hé jongens, die microcode updates voor die oudere processoren, laat die maar lekker zitten, gunstig voor onze verkoopcijfers."
Of Apple het heel erg vindt, is een tweede, maar de insinuatie dat het een smoes van Apple is slaat echt helemaal nergens op.
Tool om te testen of je systeem kwetsbaar is hier:
-Windows https://mdsattacks.com/files/mdstool-win.zip
-Linux https://mdsattacks.com/files/mdstool-linux.zip

Net gedraaid, AMD Ryzen (1200) inderdaad niet kwetsbaar voor de onderste (MDS = RIDL).

Wel kwetsbaar voor Direct / Indirect Branch Speculation en Speculative Story Bypass.
Prachtig dat de universiteit naar buiten brengt dat Intel probeerde ze om te kopen.
Zou daar ook niet een boete op moeten staan? Of mag dat, omkopen?
Of nog even lekker verzwijgen zodat de release van de nieuwe generatie 14nm+++++ Kwa verkoopcijfers niet in gevaar komt, zo vlak voor de komst van ryzen 2.
Ze wilden uiteraard niet omkopen, enkel middels een alternatieve wijze meer bijdragen aan de universiteit... :/
Erg interessante ontdekking, vooral ook omdat ze konden aantonen met een proof-of-concept hoe bijvoorbeeld de encrypted passwords uit /etc/shadow gelekt konden worden, dus het is iets wat werkelijk aantoonbaar te misbruiken is. Mijn eerste indruk is dat deze lekken heel sterk gerelateerd zijn aan Meltdown (meer dan aan Spectre - al gebruiken ze dezelfde methode om het speculatieve resultaat zichtbaar te maken in de caches). Bepaalde veiligheidscontroles worden niet uitgevoerd en waar bij Meltdown waardes uit de L1-datacache gevist konden worden, kunnen ze nu uit andere speculatieve structuren uit de processor gevist worden; de load buffer, store buffer en line fill buffers. Vanwege de aangetoonde proof-of-concepts klinkt dit ook ernstiger, net zoals Meltdown, in tegenstelling tot de Spectre aanvallen.

Mijn impressie is dat dit vooral heel erg goed uit te buiten valt met SMT (HyperThreading) waar je via deze structuren waarden van de andere thread kan afleiden. Ik zou verwachten dat als SMT uit staat, je bij een context-switch dermate veel serializatie hebt in je processor dat de load/store buffers geen nuttige (speculatieve) informatie meer bevatten. Ik verwacht ook eigenlijk dat dit wellicht zal leiden tot de "dood" van SMT. Iets waar ze bij OpenBSD al langer op gerekend hadden.

Als ik me niet vergis zou Intel met Cascade Lake de eerste hardware matige fixes hebben voor Meltdown en aardig wat Spectre varianten. Ik ben benieuwd of die fixes ook voldoende zullen zijn voor deze nu vrijgegeven problemen.

[Reactie gewijzigd door Squee op 14 mei 2019 21:35]

SMT != HyperThreading
Er staat in het artikel specifiek dat ARM en AMD niet getroffen worden, dus aan SMT an sich zal het niet liggen.
SMT != HyperThreading
Nee dat is gewoon kul. SMT (Simultaneous Multi-Threading) is de algemeen geaccepteerde technische term in dit vakgebied voor een core met meerdere hardware threads. HyperThreading is niets anders dan een Intel merknaam voor hun implementatie van SMT. Het enige verschil is dat de term "SMT" ook andere implementaties dekt.
Er staat in het artikel specifiek dat ARM en AMD niet getroffen worden, dus aan SMT an sich zal het niet liggen.
Arm heeft op de recente Neoverse-E1 processor nog nooit een SMT ontwerp gemaakt, dus dat is niet zo gek. Dat AMD niet getroffen wordt door dit probleem is omdat ze blijkbaar in hun implementatie beter op dit soort corner-cases controleren; waarschijnlijk door de sterke gerelateerdheid van deze exploit aan Meltdown is AMD voor dezelfde reden niet vatbaar (het niet speculatief doorgeven van een waarde op een permissie fout, ongeacht waar deze waarde vandaan komt).

Waar het mij om ging is dat SMT inherent een bepaald risico heeft, omdat je een fysieke core met meerdere contexten tegelijkertijd deelt, en dus de structuren binnen een core deelt en daar eventueel informatie uit kan weglekken. Dat is precies de observatie die de OpenBSD mensen hebben gemaakt; er zal altijd waarneembare interferentie kunnen zijn die een informatielek zou kunnen opleveren. Nu is hier en eerder bij Spectre gebleken dat Intel's SMT implementatie daar gebreken toont. AMD en Arm bij dit speciefieke geval niet, maar ik vraag mij bijvoorbeeld af of POWER of SPARC getroffen zijn, aangezien dit ook ontwerpen met SMT implementaties zijn.
HyperThreading is niets anders dan een Intel merknaam voor hun implementatie van SMT.
Exact het punt wat ik dus maakte. Blijkbaar ligt het dus grotendeels aan HyperThreading en is SMT an sich goed genoeg dicht te timmeren om dit soort problemen te voorkomen
ARM zelf heeft wellicht geen SMT CPUs maar de Cavium ThunderX2 heeft toch wel degelijk SMT: 4 threads per core. Ik ben benieuwd of deze ook kwetsbaar is. Ik snap dat door de beperkte beschikbaarheid onderzoekers dit lastiger kunnen onderzoeken, maar dit geeft natuurlijk geen garanties dat een ThunderX2 niet getroffen is.
Waar het mij om ging is dat SMT inherent een bepaald risico heeft, omdat je een fysieke core met meerdere contexten tegelijkertijd deelt,
En dan ga je opnieuw in de fout, want dat is NIET een inherent risico van SMT.
Het is een inherent risico van HT. (En andere soortgelijke implementaties)

Maar een multicore cpu is ook SMT maar zonder dat inherente risico.
En dan ga je opnieuw in de fout, want dat is NIET een inherent risico van SMT.
Het is een inherent risico van HT. (En andere soortgelijke implementaties)

Maar een multicore cpu is ook SMT maar zonder dat inherente risico.
Ik denk dat er hier wat spraakverwarring is ontstaan want ik ga toch echt niet in de fout hier. Ik heb aan de ontwikkeling van meerdere SMT processoren meegewerkt dus ik denk dat ik toch wel weet waar ik het over heb. ;)

SMT is gedefinieerd als een enkele core die gedeeld wordt door meer dan een hardware thread. Een multicore systeem is niet per definitie SMT (meestal wordt dat CMP genoemd - Chip Multi Processor), wat niets zegt over of je een of meer hardware threads per core hebt. SMT en CMP zijn orthogonale technieken. Zodra je structuren en de executie resources binnen een enkele core gaat delen (dus met SMT), zal je altijd op moeten passen dat de ene executie context informatie kan afleiden over wat de andere executie context aan het doen is. Of dit nou specifiek het lekken van data is zoals in de lekken in dit artikel - die specifiek lijken te werken op Intel's SMT implementatie - of dat het op basis is van het gebruik van de executie units zoals bijvoorbeeld PortSmash. Dit zijn alllemaal problemen die voortkomen uit het feit dat er dingen binnen de core gedeeld worden tussen de hardware threads, en vandaar dat ik de observatie maak dat dat inherent is aan het concept van SMT. Dat is nog steeds een observatie waar ik achter sta, maar daar kan je het mee oneens zijn.
SMT is gedefinieerd als een enkele core die gedeeld wordt door meer dan een hardware thread
Blijkbaar is de definitie van SMT over de jaren dan veranderd.
Hoewel IBM SMT nog steeds definieert als de mogelijkheid voor een enkele fysieke processor om meerdere threads af te handelen.

Maar als het tegenwoordig vooral word gedefinieerd als een enkele core die meerdere threads afhandeld, dan heb je helemaal gelijk.

Als jij meegewerkt hebt aan de ontwikkeling van meerdere SMT processoren dan ben ik wel benieuwd hoeveel aandacht er bij die ontwikkeling word/werd geschonken aan dit soort kwestbaarheden.
Is het een relatief nieuwe terrein, waar bij het originele ontwerp van deze Intel chips nooit aan gedacht is, of is het iets wat al lange tijd vanzelfsprekend is om mee te nemen in je chip ontwerp. En heeft Intel hier flinke steken laten vallen?
Blijkbaar is de definitie van SMT over de jaren dan veranderd.
Hoewel IBM SMT nog steeds definieert als de mogelijkheid voor een enkele fysieke processor om meerdere threads af te handelen.

Maar als het tegenwoordig vooral word gedefinieerd als een enkele core die meerdere threads afhandeld, dan heb je helemaal gelijk.
Zou het kunnen dat je het door elkaar haalt met SMP, Symmetric Multi Processing, wat over het algemeen voor multi-processor systemen wordt gebruikt? Want al eind jaren 90, begin 2000, toen Alpha bezig was met SMT voor de EV8 was het toch al een algemeen geaccepteerde term. Wat ook erg verwarrend is geworden is wat de term "processor" betekent sinds we naar multi-cores gegaan zijn. Zelf hou ik in het algemeen de definitie aan dat de "CPU" of "processor" het deel is wat je in een socket steekt, maar vanuit een OS of software perspectief wordt er vaak een enkele core bedoeld. Vandaar dat ik liever expliciet over een core praat, terwijl zelfs die term soms vaag is zoals bij AMD's Bulldozer design.
Als jij meegewerkt hebt aan de ontwikkeling van meerdere SMT processoren dan ben ik wel benieuwd hoeveel aandacht er bij die ontwikkeling word/werd geschonken aan dit soort kwestbaarheden.
Is het een relatief nieuwe terrein, waar bij het originele ontwerp van deze Intel chips nooit aan gedacht is, of is het iets wat al lange tijd vanzelfsprekend is om mee te nemen in je chip ontwerp. En heeft Intel hier flinke steken laten vallen?
Er wordt bij processor ontwikkeling vooral enorm veel aandacht besteedt aan functionele correctheid. De problemen die Spectre, Meltdown, en ook deze exploit bloot leggen vloeien uit de bij-effecten van speculatieve executie, en dat is niet makkelijk te testen en verifieeren. Wat deze bij-effecten zijn is ook niet onderdeel van de architectuur specificatie van de processor, dus wat er "juist" is, valt niet echt te bepalen. Functioneel gezien is de processor namelijk wel correct.

Bij de SMT implementatie waar wij aan werkten was er vooral veel aandacht voor fairness tussen de SMT contexten; dat niet een hardware thread alle resources binnen een core kon opslokken en de anderen enorm zou vertragen. Ik denk dat niemand of zeer weinig mensen hebben stilgestaan bij de security aspecten er van. De bovengenoemde verificatie zal wel hebben gegarandeerd dat een thread niet direct waarden van een andere thread kan lezen. Dat dit nu wel mogelijk bleek via de bij-effecten, dat was enigsinds een verassing.

Het probleem wat bijvoorbeeld hier in deze exploit wordt blootgelegd is in theorie ook zonder SMT uit te buiten, maar SMT geeft bepaalde condities die veel gunstiger zijn om het uit te buiten. Dit omdat je niet een context switch (in software perspectief) hoeft te doen om tussen de attacker en victim code te schakelen maar deze tegelijkertijd op dezelfde core actief kunnen zijn in een aparte hardware thread. Hierdoor heb je een veel betere kans dat de data nog beschikbaar is in een van de structuren van de processor die hier wordt misbruikt. Na een software context switch op een enkele hardware thread is het meeste hiervan waarschijnlijk al overschreven, en is er veel minder informatie te verzamelen.

Dus kort samengevat; alle speculatieve exploits die we de afgelopen anderhalf jaar gezien hebben zijn iets waar veel hardware designers nooit aan gedacht hebben. Het was niet onderdeel van het processor ontwerp verificatie proces, en het feit dat Intel nu hier kwetsbaar is en AMD en Arm niet of in mindere mate (let op dat ze beiden zeggen dat ze op dit moment niet bekend zijn met enig ontwerp van hun wat vatbaar is, maar het ook niet uitsluiten!), heeft meer met "mazzel" te maken dan dat Intel het heel erg slecht gedaan heeft. Je zou hooguit kunnen zeggen dat er in bepaalde gevallen net iets *te* veel afgesneden is en ze een veiligere keuze hadden kunnen maken. Maar dat deden ze niet, omdat ze niet dachten dat dit ooit een probleem zou zijn. Dit zijn problemen in algemeen geaccepteerde mechanismen in processoren die al jaren worden toegepast.
Bedankt voor je reactie. Tenzij je echt in de praktijk betrokken bent geweest bij processor ontwikkeling is het erg moeilijk om in te schatten of Intel hier iets te verwijten valt. Het aantal mensen hier die in zo'n situatie hebben gezeten is waarschijnlijk op één hand te tellen. Wellicht ben je zelfs de enige.

Wat je verteld bevestigt wel mijn vermoedens.
Hoe waarschijnlijk is het dat SMT het leven laat? Want zonder SMT springen we volgens mij 10 jaar terug wat multicore prestaties betreft, of valt dat wel mee? Juist net wanneer software baat lijken te hebben bij meerdere cores. Of er moet zoveel media aandacht en zo'n grote, bij de massa, merkbare, performance hit komen dat ze wel moeten. Hoewel de performance hit bij de vorige lekken, in sommige zeer specifieke gevallen, ook enorm was. Ik ben benieuwd wat er dan gaat gebeuren als dit echt een ding wordt.
Hoe waarschijnlijk is het dat SMT het leven laat? Want zonder SMT springen we volgens mij 10 jaar terug wat multicore prestaties betreft, of valt dat wel mee? Juist net wanneer software baat lijken te hebben bij meerdere cores. Of er moet zoveel media aandacht en zo'n grote, bij de massa, merkbare, performance hit komen dat ze wel moeten. Hoewel de performance hit bij de vorige lekken, in sommige zeer specifieke gevallen, ook enorm was. Ik ben benieuwd wat er dan gaat gebeuren als dit echt een ding wordt.
Dat is zeer lastig te zeggen. SMT kan een enorme performance/efficiency winst geven, zoals je bijvoorbeeld bij de SPARC processoren zag met 8 threads per core. Van 1 naar 2 threads per core gaan geeft in mijn ervaring zo'n 30-40% extra performance gemiddeld. Daarboven loopt het wel sterk af, maar afhankelijk van je ontwerp en de software die je er op draait kan je met nog meer SMT threads bijna dubbel de throughput performance uit je core persen. Verder is het natuurlijk ideaal voor virtualisatie omgevingen met heel veel VMs. Het is ook erg nuttig voor het schalen tussen veel parallelle throughput taken en single thread performance (met maar 1 thread per core actief) als je een goeie SMT implementatie hebt.

Maar...als er toch te veel inherente security issues blijven bestaan met SMT, zal ik me niets verbazen als het toch weer op de schop gaat. Dat kan natuurlijk op verschillende manieren. Wellicht moeten we de OS schedulers aanpassen zodat we alleen nog maar threads van een enkele applicatie een core laten delen via SMT. Of wellicht zijn we dan toch beter af met meer, kleinere, cores die meer isolatie geven dan een grotere gedeelde core met SMT. Erg duidelijk is het niet, maar ik denk dat niet veel mensen bij deze situaties stil hadden gestaan bij SMT ontwerpen; het was voornamelijk een relatief goedkope manier om zonder veel extra hardware een hogere efficientie uit je core te krijgen.
Hoe waarschijnlijk is het dat SMT het leven laat? Want zonder SMT springen we volgens mij 10 jaar terug wat multicore prestaties betreft, of valt dat wel mee?
Je gaat in het geval van Intel consumer CPUs met een lager aantal fysieke cores met elk meerdere hardware threads middels SMT, een laterale beweging krijgen naar meer fysieke cores zonder SMT.

Vergeet ook niet dat de praktijk-winst van SMT nooit 100% is. Er zijn altijd een boel scenario's waar de hardware threads niet parallel op dezelfde core uit te voeren zijn en elkaar gaan remmen. De waarheid ligt daarom ook wss. dichter bij een gemiddelde van x1.4 performance oid.

Dat is nog goed te compenseren door meer fysieke cores te nemen.
Maar ja; dat wordt dan wel duurder, natuurlijk.

[Reactie gewijzigd door R4gnax op 15 mei 2019 00:26]

Hoe waarschijnlijk is het dat SMT het leven laat? Want zonder SMT springen we volgens mij 10 jaar terug wat multicore prestaties betreft, of valt dat wel mee?
Valt heel erg mee, SMT wordt lang niet op alle CPUs gebruikt (alle recente desktop i5s hebben het niet bijvoorbeeld), SMT/HT is niks anders dan een paar extra virtuele cores maken, die minder kosten dan een echte core (kwa transistors), maar ook minder winst geven onder volle load.
Net nieuwe Intel microcode update geinstalleerd.
Net nieuwe Intel microcode update geinstalleerd.
En waar heb jij die kunnen downloaden dan??
Net aan de chat gezeten met een Intel helpdesk medewerker. De beste man wist by God niet war het over ging (....). En op de hierboven genoemde speciale Intel website zie ik alleen dat dit in de updates zal worden opgenomen, al dan niet via OS.
Voor Linux o.a. hier: https://github.com/intel/...ssor-Microcode-Data-Files
Voor Windows: Bij Microsoft hier: https://portal.msrc.micro...idance/advisory/adv190013 (link naar het artikel voor de microcode download (moet deze zijn, https://support.microsoft.com/en-us/help/4093836 ) is nog dood, volgens mij is MS de site nog aan het bijwerken.
Een 3de optie is bij bij je mobo of systeem fabrikant doormidden van een geupdate bios. Deze zullen waarschijnlijk de komende dagen beschikbaar gaan komen.

[Reactie gewijzigd door Dennism op 14 mei 2019 22:30]

Zover ik weet is een bios een meer 'permanente' oplossing gezien de bios ervoor zorgt dat de microcode wordt geladen zonder afhankelijk te zijn van besturingssysteem updates.

Net zoals Meltdown bijvoorbeeld door Windows een microcode wordt geladen om te beveiligen maar zoiets wordt in beiden gevallen niet permanent in de CPU zelf weggeschreven. Dus als je het OS opnieuw installeert of de patch verwijderd (of indien mogelijk kan uitschakelen zoals het tooltje 'inspectre') dan is de beveiliging ook niet langer actief.

Mensen die graag permanent beveiligd willen zijn kunnen maar het beste de bios als geprefereerde optie kiezen als er überhaupt een nieuwe bios voor hun producten beschikbaar komt.
Bios is ook niet permanent. De fix is namelijk een wisselwerking tussen software patches en de microcode.
Heb je de microcode niet, maar wel de software updates ben je niet (volledig) beveiligd. Heb je de software patches wel, maar niet de microcode ben ik je ook niet (volledig) beveiligd.

Heb je dus een systeem met een up-to-date bios maar je installeert een ongepatched OS ben je dus niet beveiligd.
Daar staat bij Microsoft dus alleen informatie, geen updates.
Er valt weinig te downloaden, alles wordt via Windows Update voor je klaar gezet.
Dat komt gewoon mee met de Windows updates, dat zal gewoon in de patches van vandaag zijn verwerkt.

Zie ook: Microsoft - Windows client guidance for IT Pros to protect against speculative execution side-channel vulnerabilities
UPDATED ON May 14, 2019: On May 14, 2019, Intel published information about a new subclass of speculative execution side-channel vulnerabilities known as Microarchitectural Data Sampling. They have been assigned the following CVEs:

CVE-2018-11091 – “Microarchitectural Data Sampling Uncacheable Memory (MDSUM)”
CVE-2018-12126 – “Microarchitectural Store Buffer Data Sampling (MSBDS)”
CVE-2018-12127 – “Microarchitectural Fill Buffer Data Sampling (MFBDS)”
CVE-2018-12130 – “Microarchitectural Load Port Data Sampling (MLPDS)”
Important: These issues will affect other systems such as Android, Chrome, iOS, and MacOS. We advise customers seek guidance from their respective vendors.

Microsoft has released updates to help mitigate these vulnerabilities. To get all available protections, firmware (microcode) and software updates are required. This may include microcode from device OEMs. In some cases, installing these updates will have a performance impact. We have also acted to secure our cloud services. We strongly recommend deploying these updates.
Hou er wel rekening mee dat Windows Updates met Microcode lang niet altijd via Windows Update binnen komen, deze moeten geregeld zelf handmatig uit de microsoft update catalog gedownload worden en geïnstalleerd.

[Reactie gewijzigd door Dennism op 14 mei 2019 22:31]

Hij zit bij de updates (patch tuesday) -> KB4494441
En dat is dus precies wat ik bedoel, dat zijn enkel de software fixes voor Windows, daar zit de benodigde Microcode niet bij in. En zonder de Microcode doen deze software fixes weinig.

Voor de Microcode heb je bijvoorbeeld deze nodig https://support.microsoft...2-intel-microcode-updates (Voor de 1709 versie, 1803/1809 versie's lijken nog niet beschikbaar te zijn).

Met daarbij de volgende note:
How to obtain and install the update
Microsoft Update Catalog
To get the standalone package for this update, go to the Microsoft Update Catalog website.
Deze krijg je dus niet binnen via Windows Update, maar zal je als gebruiker zelf moeten gaan halen in de Microsoft Update Catalog.

[Reactie gewijzigd door Dennism op 15 mei 2019 08:00]

Mag ik vragen hoe jij bij deze microcode update bent beland?
Wij draaien hier allemaal 1803 op de werkstations en houden dit ook in de gaten.
We gaan hem in de gaten houden, staat er nog niet op.
Dankjewel. ;)
Vandaag zag ik alleen een security update voor Office voorbijkomen. Geen MDS updates.
Als je handmatig checkt zou je de maandelijkse patches al moeten binnenkrijgen, dat kreeg ik tenminste wel op twee Windows 7 PC's en een Windows 10 virtuele machine.
Sorry voor de late reactie, maar kreeg het vanzelf binnen via updates. Geen Windows. maar Linux.

[Reactie gewijzigd door desalniettemin op 15 mei 2019 19:57]

Waar vond je die en hoe voerde je die uit?
sudo apt update && sudo apt upgrade

Met andere woorden, Canonical heeft de update al vrijgegeven voor Ubuntu Linux, in mijn geval 16.04 LTS. Ik neem aan dat hij er ook voor Ubuntu 18.04 LTS is maar dat kan ik niet bevestigen omdat mijn thuis server een AMD processor heeft.
Ze hebben en beperkte fix uitgebracht, ze laten SMT (HT) aanstaan,ondanks ze weten dat het een risico is.
met dit commando
cat /sys/devices/system/cpu/vulnerabilities/mds
Kan je hier zien, welke bescherming je hebt.
Blijkbaar was de microcode update die ik binnen heb gekregen dan nog niet voor mds. Ik mis namelijk dat bestand in de directory die jij noemt. Ik heb daar wel de oude bekenden zoals spectre_v1 en _v2, meltdown, spec_store_bypass en l1tf. Of betekent het dat mijn i5-8400 niet vatbaar is voor mds? Nee, blijkbaar moet de file hoe dan ook bestaan, als je niet vatbaar bent staat er "Not affected" in.

[Reactie gewijzigd door rbr320 op 14 mei 2019 22:45]

Hier hetzelfde hoor, diverse Ubuntu en Debian bakken waar het bestand niet bestaat. En ze zijn 100 procent up to date.

Zal de komende dagen wel komen denk ik.
Is idd gek, heb net zelf een image opgestart en idd ook hele maal up to date met kernel 4.15 en zie het ook niet. Heb ondertussen begrepen dat niet iedereen deze code gebackport heeft.
Dat las ik ook ergens, net getest op een test Ubuntu 18.04 en daar stond vanmorgen een kernel update klaar en het bestand is nu aanwezig.

Ik denk dat ik te vroeg was, de uitrol is net na mijn onderzoek gisteravond gestart.
Ik kreeg de microcode update voor de nieuwe kernel update. Is de 4.15.0-50.
Ook ontvangen voor 18.04.
Sorry voor de late reactie, maar ging automatisch. Maar ik gebruik Linux.
Ik mis eigenlijk een beetje de impact van deze lekken voor de normale gebruiker in dit artikel...
Is dit remote te doen of is er fysieke toegang tot de machine nodig?
Zal vast wel ergens in de gegeven links staan, maar zou wel fijn zijn om dat meteen te kunnen lezen. :)
Check out three RIDL exploits in action, leaking the root password hash from an unprivileged user, sensitive data from the Linux OS kernel, and JavaScript.
https://mdsattacks.com/

Dus zowel op het systeem met normale gebruikersrechten, maar ook via javascript. Al demonstreren ze dit niet direct in de browser, maar dat zal niet lang op zich laten wachten.

[Reactie gewijzigd door GoBieN-Be op 14 mei 2019 21:45]

Thx. Dat maakt het wel iets duidelijker. Had ook wel in het artikel vermeld mogen worden denk ik :)
Uit jouw de link:
We show that attackers who can run unprivileged code on machines with recent Intel CPUs - whether using shared cloud computing resources, or using JavaScript on a malicious website or advertisement - can steal data from other programs running on the same machine, across any security boundary: other applications, the operating system kernel, other VMs (e.g., in the cloud), or even secure (SGX) enclaves.

[Reactie gewijzigd door fm77 op 14 mei 2019 21:45]

Interessante page. Echter als ik de mdstool op mijn verouderde ubuntu bak draai dan is alles unaffected op een 5th generatie intel I7 U processor...

Weird.
Niet louter je telefoonnummer, want als dat zo was dan was hij binnen no-time gevonden (geprobeerd met hashcat op mijn 2080 Ti). De input is namelijk ontzettend gelimiteerd.

[Reactie gewijzigd door .oisyn op 15 mei 2019 00:14]

Hmm het is niet 06-xxyyxxyy, noch 06xxyyxxyy, noch +316xxyyxxyy. Ik denk niet dat het een hash is van een telefoonnummer.
Als dit daadwerkelijk de hash is van je telefoonnummer, dan zou ik het even weghalen.

Van sha256 naar een willekeurig origineel is niet te doen.
Alle mogelijke telefoonnummers hashen en dan kijken of jouw hash ertussenin zit is een fluitje van een cent.

Daarom is het voor wachtwoord hashes zo belangrijk dat het berekenen ervan langzaam is.

Dit is verder een proof-of-concept. Het kunnen achterhalen van informatie die tot roottoegang leidt is voldoende om aan te tonen dat er een serieus probleem is.
Het is een hash, er gaat als het goed is bijna altijd informatie verloren bij het hashen en je kunt dus bijna nooit het origineel achterhalen, enkel iets met dezelfde hash.
Sha256 heeft 256 bits output, dat is meer dan het gemiddelde wachtwoord aan entropie heeft: de meeste mensen gebruiken een subset van ascii en minder dan 32 tekens. Je hoeft dus geen collisions te verwachten.
root password hash from an unprivileged user.
Als in sudo?
Eerder te beperken dan te vermijden. Standaard gebruikt sudo het root account.
Daarnaast speel ik ook nog weleens vals door een interactive sudo te openen ;-)

Overigens is bij ons het 'root' (en administrator) account uitgeschakeld.
Wij hebben specifieke root/admin users (in mijn geval 'admin_dave') welke via Active Directory --> LDAP --> PAM beschikbaar is. Via PAM hebben we ook ingesteld dat admin users niet kunnen inloggen via SSH of console. Daarvoor dient het reguliere user account ('dave') gebruikt te worden. Vanuit 'dave' kan ik naar 'admin_dave'.

Af en toe wat omslachtig, maar het voorkomt dat je continue als admin/root aan het werk bent. Hoewel veel van mijn taken wel admin rechten nodig hebben..
ik moet nog de eerste concrete virus nog tegen komen die MDS gebruikt
Geen virus voor nodig. Deze lekken zijn heel eenvoudig te misbruiken. Een aanvaller hoeft alleen maar te zorgen dat jouw computer een Javascript uit voert, of bijvoorbeeld een gemodificeerd plaatje opent in bijvoorbeeld mail, of website. Daarna meldt je computer zich bij de hacker (gewoon over internet) en nemen ze je systeem over.

Verdiep je maar eens in tools en plugins van Metasploit. Wormen en virussen zijn nergens voor nodig en het werkt op Windows, IOS, OSX, Linux als het maar een Intel heeft.
Ik geloof best wat je zegt. Maar is de theorie niet iets anders dan de praktijk?
Hetzelfde werd er namelijk gezegd over de meltdown lekken. Maar daar hoor je ook niets over...
Ik geloof best wat je zegt. Maar is de theorie niet iets anders dan de praktijk?
Hetzelfde werd er namelijk gezegd over de meltdown lekken. Maar daar hoor je ook niets over...
Dat is het erge, je hoort er niks van. Dus wordt het niet ontdekt. Ik heb een demo mogen aanschouwen paar weken geleden. Waar iemand met een eenvoudige Linux bak even een Windows bak over nam met een variant hier van. Binnen 10 seconden na de aanval zat hij binnen als SYSTEM.
Dan ben ik heel benieuwd welke variant dit dan was, klinkt namelijk een beetje als een onzin verhaal. Met exploits als deze (maar ook metldown en spectre varianten) kan je namelijk niet direct een systeem overnemen, je kan ze enkel gebruiken om kleine beetjes data te vergaren. Dit zou in theorie een wachtwoord kunnen zijn, waarna je dan op het systeem in zou kunnen loggen, echter moet je dan wel of lokale toegang tot het systeem hebben, de gebruiker van het systeem moet iets als RDP naar de buitenwereld open hebben staan (zeer ongebruikelijk) of er is een andere exploit nodig om met de buitgemaakte gegevens het systeem over te kunnen nemen.
Ik weet ook niet welke variant het was. Het was eigenlijk best wel simpel. Eerst een scan, toen kwam de Windows versie en patch level naar boven. Met andere tool werden toen de CVE's er bij gezocht. Daarna werd er een e-mail verzonden met een gemodificeerd plaatje die geopend werd op het systeem. Outlook crashde maar op dat moment melde het systeem zich aan bij metasploit op de machine van de hacker.

Indrukwekkend om te zien. Ik wist niet dat het zo makkelijk kon. Het grappige was, toen er controle was van de client, in dit geval was het een VM, was zonder moeite door te hoppen naar een andere VM op de zelfde host. Dit was stukken complexer en kon door tijdsdruk niet gedemonstreerd worden.

Overiges is dit een onderdeel van Ethical Hacking (bij deze instructeur).
Welke exploit het was is natuurlijk wel redelijk relevant, er zijn namelijk zeker exploits die dit kunnen. Echter met de hier beschreven exploits of bijvoorbeeld Meltdown en Spectre kun je geen systeem overnemen en "inloggen" of een systeem aansturen als zijnde als "system". Je kan enkel (fragmentjes van) data verzamelen en deze langzaam maar zeker combineren tot bijvoorbeeld een cryptografische sleutel of een bijvoorbeeld een wachtwoord.

Met die data zou je dan verder in kunnen breken in een systeem, maar dan moet je wel toegang hebben tot de machine, fysiek, remote of via een andere exploit.
En dat is weer een demo. Maar in de praktijk hoor ik er dus verdomd weinig over.
Al die verhalen beginnen een beetje op theoretische lucht te lijken.
Ja het kan. Maar waarom gebeurt het niet in het wild?
Dat is dus mijn vraag. Het is mogelijk, maar het lijkt er op dat het niet grootschalig ge(/mis)bruikt wordt.
Waarom is dat?
Dit soort hack tools worden niet bij gewone gebruikers ingezet.
Dat levert te weinig op.
Maar bij financiële instellingen of grote bedrijven. Waarna ze bv. losgeld gaan vragen of de boel platgooien. Er zullen weinig bedrijven zijn die dat publiekelijk maken, ivm. met hun imago.
Dat ben ik met je eens. Het einde van het computer tijdperk werd ingeluid met de meltdown lekken. Echter is het daarna heel erg stil gebleven. De fixes zouden een behoorlijke performance impact hebben. Maar ook daar hoor je weinig meer van.
Niet dat ik de lekken onderschat, maar wat voor echte problemen geven die voor de "normale gebruikers"?
Misschien dat als je net op Digid ingelogged hebt, geen 2-factor authentication ingesteld hebt staan, en dan de PC ‘s nachts aan laat staan terwijl er nog een malafide pagina open staat met zo’n virus erop, dan kan zo’n website aan je Digid wachtwoord komen en inloggen.

Maar inderdaad, de kans dat iemand er echt de jackpot mee weet te halen zal klein zijn.
Voor de echte eindgebruiker was het nooit echt een issue gezien die alleen betrekking had tot een guest OS op een hypervisor.

Ik kan alleen niet helemaal uit de text opmaken of het deze keer ook weer de guest OS is of ook de host HT treads.
Huh, meltdown was voor meer te gebruiken dan uit een VM breken hoor.. En deze lekken zijn volgens de whitepaper ook voor van alles en nog wat te gebruiken, VM of niet.
Ja maar om met local admin permissies een hack te gebruiken om mem uit te lezen terwijl je er zo al bij kunt 😂
Dat is een kwestie van tijd en misschien nu hier en daar al het geval.

Een paar regels code op een website zouden al voldoende moeten zijn!
het is hartsikke (.....) maar voor mijn gigabyte GA-H81M-DS2V rev 1.0 zijn er al sinds augustus 2015 geen updates meer uitgekomen. straks is het intel outside en ga ik voor amd.
als ik zoveel intel setjes weg mogen gaan omdat er zoveel ernstige bugs in zitten :( en dan ook nog nieuwe laptops en nucs omdat die niet naar amd te upgraden zijn. bedankt intel :(

[Reactie gewijzigd door Ludwig005 op 15 mei 2019 07:42]

Dan download je toch gewoon de bijbehorende Windows patches met Microcode? De bios van de fabrikant is slechts een mogelijkheid om de Microcode updates te verkrijgen, niet de enige optie.
Het bewijst dat concurrentie - en het verdelen van uw cpu eieren over meerdere mandjes (zoals je belegt moet je ook je IT beheren!) - lonen.
We hebben ons laten foppen door die monopolist en de faktuur is loodzwaar. Da's mijn staalharde conclusie.
Volgens mij is concurrentie juist de oorzaak van dit probleem.

Als ik het mij nog goed herinner, is Intel met HT gekomen. Omdat ze toen der tijd AMD in hun nek voelde.

[Reactie gewijzigd door wica op 14 mei 2019 22:36]

Allicht Intel's karma?

Ik heb niet veel Intel systemen in beheer, maar die ik nog wel heb kan ik nu dus al bijna net zo goed in de bak gooien. Wat een flater dit zeg, destijds snel maar even een ontwerp gemaakt om maar nummer één te kunnen blijven en de klant zit nu met zooi opgescheept.

Zelfs met een lifecycle van 5 jaar wordt je al benadeeld door dit soort gebreken.
In hoeverre is Intel eigenlijk aansprakelijk? In principe is er sprake van dwaling, immers de prestaties zijn rooskleuriger gemaakt dan eigenlijk bruikbaar is.
De aansprakelijkheid zal wel meevallen, volgens mij adverteert Intel niet eens met performance nummers, en als wqnner ze het wel doen is dat zeer summier.

Ik zie eigenlijk alleen het aantal cores, de kloksnelheid e.d. door Intel en bijv. De OEM's geadverteerd worden.

Verder zul je hier in Nederland bij de verkoper moeten zijn wanneer een product non-conform is. Als je dus niet direct bij intel gekocht hebt heb je als koper al niets met Intel te maken in de zin van aansprakelijkheid.
Hyperthreading was toch echt wel een ding hoor terug in de P4 tijd, CPU doosje van toen:
https://images-na.ssl-images-amazon.com/images/I/919Q6one1eL._SX425_.jpg

En dat blijkt dus nu alweer waardeloos te zijn, terwijl het toch min of meer nog in de marketing mix zat van gisteren.
In dit soort markten vind de meeste marketing achter de schermen plaats en die zie je dan ook terug in de advertenties van OEM's (naar mijn idee).

Ook wordt er dikwijls gestrooid met cijfers wanneer er weer een nieuwe chip is: https://tweakers.net/nieuws/144369/intel-krijgt-kritiek-op-core-i9-9900k-test-die-amd-processors-benadeelt.html

Rechtszaken zullen we toch ook nog wel zien als ik het nieuws er op teruglees: https://www.theverge.com/2018/2/16/17020048/intel-spectre-meltdown-class-action-lawsuits

Voor de Europese consument zal het inderdaad wel lastig zijn om van zoiets individueel een zaak te maken.

Waar ik best boos om ben is dat men zo lang dingen in de doofpot wil stoppen terwijl het probleem gewoon zo duidelijk als wat is. Ook doet Intel helemaal geen updates meer voor de lekken, kortom ze hebben geen respect voor hun klanten.

Toen AMD met de TLB bug zat zijn er wel degelijk terugroepacties gedaan en prijsverlagingen doorgevoerd. Dat terwijl die bug minder impact had als deze ontwerpfouten.
Hyperthreading was toch echt wel een ding hoor terug in de P4 tijd, CPU doosje van toen:
https://images-na.ssl-images-amazon.com/images/I/919Q6one1eL._SX425_.jpg

En dat blijkt dus nu alweer waardeloos te zijn, terwijl het toch min of meer nog in de marketing mix zat van gisteren.
HT wordt uiteraard ook nu nog wel mee geadverteerd, echter dat zijn geen performance claims, maar gewoon een feature die bij het product zit (of niet). De P4 tijd ligt alweer zo'n 17 jaar achter ons, dat is in IT termen spreekwoordelijk in de steentijd, dat is nu niet echt relevant meer, dat is geen "gisteren" :P
In dit soort markten vind de meeste marketing achter de schermen plaats en die zie je dan ook terug in de advertenties van OEM's (naar mijn idee).
Ik heb dagelijks te maken met OEM's binnen mijn werk en ik zie eigenlijk nooit harde performance claims langskomen in de marketing.
Ook wordt er dikwijls gestrooid met cijfers wanneer er weer een nieuwe chip is: https://tweakers.net/nieuws/144369/intel-krijgt-kritiek-op-core-i9-9900k-test-die-amd-processors-benadeelt.html
Dat er met cijfers gestrooid wordt klopt, dat gebeurt hier op Tweakers ook. Echter is het in de regel de media (review sites / bedrijven) die deze cijfers publiceren, niet de hardware fabrikanten zelf.
Rechtszaken zullen we toch ook nog wel zien als ik het nieuws er op teruglees: https://www.theverge.com/2018/2/16/17020048/intel-spectre-meltdown-class-action-lawsuits
In de US zal je zeker rechtszaken krijgen, echter is dat voor niet direct relevant. Voor zover ik weer zijn er in Europa nog geen zaken gestart, dat zou voor ons veel interessanter zijn.
Waar ik best boos om ben is dat men zo lang dingen in de doofpot wil stoppen terwijl het probleem gewoon zo duidelijk als wat is. Ook doet Intel helemaal geen updates meer voor de lekken, kortom ze hebben geen respect voor hun klanten.
Dit klopt natuurlijk van geen kant. Voor alle processoren tot en met Sandy Bridge van ruim 8 jaar geleden heeft Intel al updates beschikbaar gesteld. Ik weet niet waar jij op baseert dat Intel geen updates meer uit zou brengen maar dat klopt gewoon totaal niet. Niet direct iets om boos op te zijn imho.
Dit klopt natuurlijk van geen kant. Voor alle processoren tot en met Sandy Bridge van ruim 8 jaar geleden heeft Intel al updates beschikbaar gesteld. Ik weet niet waar jij op baseert dat Intel geen updates meer uit zou brengen maar dat klopt gewoon totaal niet. Niet direct iets om boos op te zijn imho.
https://www.tomshardware.com/news/intel-spectre-patch-older-chips,36815.html

Ik heb juist desktops omdat die een veel langere levensduur hebben als mobiele apparaten, maar een beetje service voor een miljardenbedrijf als Intel is kennelijk teveel gevraagd. Ik vind niet dat een technologie antiek is als het het meest recente OS van Microsoft er nog prima mee draait.
Uiteindelijk heb ik al die oude systemen kunnen weggooien, omdat ik de veiligheid en prestaties niet meer kan garanderen. Klanten waren er zodoende ook niet blij mee, want ze moesten plots een uitgave doen.
En met dit nieuws zie ik alweer een volgende ronde aan afschrijvingen, de houding begint in ieder geval verkeerd.
Tja, dan hebben we het dus, zoals ik al aangaf, over cpu's van bijna 10 jaar oud tot veel meer dan 10 jaar oud. Ik weet niet waar jij die cpu's nog tegenkomt, maar ik zie ze nooit meer bij klanten en ik beheer o.a. vrij veel desktops en workstations bij zakelijke relaties. Een enkel systeem kan ik nog inkomen, maar vaak zal je dit niet meer tegenkomen, hoogsten een 1-2ish % van de systemen gok ik.

Een ander probleem is, dat hoewel Intel voor voor veel oudere CPU's updates heeft uitgebracht, de mobo fabrikanten als Asus, MSI, Gigabyte e.d. (en de OEM's als HP / Dell) deze niet meer doorvoerden voor oudere systemen. Waardoor Intel deze patches eigenlijk "voor niets" gemaakt heeft. Dan zou ik als ik Intel was ze bij een volgende update ook laten lopen, het heeft dan weinig zin daar nog tijd in te steken.

Ten opzichte van een jaar geleden veranderd er nu niet veel trouwens, enkel de "Lynnfield" serie en afgeleiden krijgt nu geen update, al met al zou dan niet tot afschrijvingen mogen leiden, die hardware zal immers allang officieel afgeschreven zijn in de boekhouding, anders doen je klanten toch echt iets verkeerd. Verder gaat het er ook niet in bij me dat klanten "plots" een uitgave moesten doen. Als je een PC hebt van minimaal 9 jaar oud (of nog veel ouder) weet je dat vervanging er aan zit te komen. Is het niet om dit soort zaken, dan wel vanwege defecten of omdat bepaalde software niet officieel supported meer is. Die vervanging had allang begroot moeten zijn, dat je dan wat tijd / geld gewonnen hebt omdat het systeem langer is meegegaan is leuk, maar in de begroting had een vervanging allang meegenomen moeten zijn.

[Reactie gewijzigd door Dennism op 16 mei 2019 15:26]


Om te kunnen reageren moet je ingelogd zijn


OnePlus 7 Pro (8GB intern) Microsoft Xbox One S All-Digital Edition LG OLED C9 Google Pixel 3a XL FIFA 19 Samsung Galaxy S10 Sony PlayStation 5 Huawei P30 Pro

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