'Recent door Intel gemelde AMT-lekken zijn ernstiger dan eerdere varianten'

Het beveiligingsbedrijf Positive Technologies, dat zich veel bezighoudt met onderzoek naar Intels Management Engine, laat weten dat Intel onlangs ernstige AMT-lekken heeft gemeld, die makkelijker te misbruiken zijn dan eerdere varianten.

In een blogpost verwijst Positive Technologies naar twee recente security advisories van Intel: SA-00112 en SA-00118. Het legt de nadruk op een kwetsbaarheid die in het eerstgenoemde bericht aan de orde komt. Intel omschrijft dat lek, met kenmerk CVE-2018-3628, als 'een buffer overflow in de http handler in AMT binnen de Management Engine, die een aanvaller willekeurige code laat uitvoeren'. Daarbij moet de aanvaller wel binnen hetzelfde subnet als het doelwit aanwezig zijn.

Volgens het beveiligingsbedrijf is er sprake van een lek dat het op afstand uitvoeren van code mogelijk maakt, waarbij de enige beperking nog de vereiste van het subnet is. "Dit is het scenario dat voor veel Intel-gebruikers een nachtmerrie betekende en het is nu werkelijkheid geworden", aldus het bedrijf. Er zou geen AMT-beheerdersaccount nodig zijn om het lek te misbruiken. Het lek zou lijken op een variant die halverwege vorig jaar door beveiligingsbedrijf Embedi werd beschreven. Intel zegt de huidige lekken zelf te hebben ontdekt.

Active Management Technology, oftewel AMT, is onder meer aanwezig op Intel-vPro-cpu's en -chipsets. De feature wordt gebruikt om een systeem op afstand te beheren. AMT is onderdeel van de Management Engine, die draait op een aparte processor in de chipset. De aparte processor werkt los van de cpu zelf en is daarom toegankelijk als deze is uitgeschakeld. De processor biedt toegang tot verschillende systeemfuncties. De Management Engine is op zijn beurt onderdeel van de Platform Controller Hub.

Intel schrijft in zijn waarschuwing dat het lek aanwezig is in AMT in alle versies tot en met nummer 11 van de Management Engine. Die zijn onder meer aanwezig in alle generaties van zijn Core-processors. Voor Core-processors vanaf de Skylake-generatie is het bovengenoemde lek gedicht in versie 11.8.50.

Daarnaast gaat het beveiligingsbedrijf in op een kwetsbaarheid met kenmerk CVE-2018-3627, dat in de andere advisory wordt beschreven. Dat maakt eveneens het uitvoeren van willekeurige code mogelijk en zou makkelijker te misbruiken zijn dan eerdere ME-lekken die door Intel zijn gedicht. Hiervoor heeft een aanvaller lokale toegang nodig. Positive Technologies zegt de nu gedichte lekken verder te gaan onderzoeken. Het bedrijf kwam er eerder achter dat de ME uit te schakelen is. Verschillende fabrikanten, zoals Purism en System76, maken van die optie gebruik. Critici noemen de ME een backdoor, omdat deze vergaande toegang tot het systeem biedt.

Reacties (71)

Voor mensen die hun Intel ME versie willen patchen naar de laatste versie voor beveiligingsupdates, op deze site zijn alle nieuwste ME versies en de tools om up te daten te vinden:
https://www.win-raid.com/...are-amp-System-Tools.html

Dank je ik zal eens kijken. Sinds ergens in 2016 kan je deze niet meer van de website van Intel downloaden voor (mijn) asus bord. De laatste versie die ik bij Asus kan downloaden is van 2013 en is een beta.

Sindsdien gaat het denk ik via windows update want de laatste versie die ik heb geïnstalleerd is van 28-3 2016. 11.0.5.1189 Ik heb een Asus Z77 Sabertooth uit 2012 met 5 jaar garantie. Maar niet lang update helaas. Dat viel mij erg tegen.

Sinds deze update gaat mijn computer niet meer goed uit de slaapstand/hybernate etc. Opstarten gaat ook niet altijd lekker. Waardoor ik mijn computer helaas 24-7 aan heb staan.

[Reactie gewijzigd door TurboTon1973 op 18 juli 2018 16:38]

Op een Z77 board zit geen AMT, deze lekken zullen dus ook niet toepasselijk zijn op je systeem

Op een Z77 board zit geen AMT, deze lekken zullen dus ook niet toepasselijk zijn op je systeem

Dank je zover had ik niet door gezocht omdat het volgende in de tekst stond:

Intel schrijft in zijn waarschuwing dat het lek aanwezig is in AMT in alle versies tot en met nummer 11 van de Management Engine. Die zijn onder meer aanwezig in alle generaties van zijn Core-processors. Voor Core-processors vanaf de Skylake-generatie is het bovengenoemde lek gedicht in versie 11.8.50.

En aangezien ik wel een Core cpu had dacht ik dat het voor mijn moederbord ook gelde. Met de net genoemde website word een nieuwere versie niet geinstalleerd vanwege een foutmelding welke te maken heeft met de fabrikant.

Mooi overzicht! Echter, ik wacht nu toch maar op ASUS vanwege de volgende tekst op die site:

It is generally advised to wait for your Original Equipment Manufacturer (OEM) to release a new BIOS which supports a newer CSME v11 firmware minor release. All systems which initially come with CSME v11.0, v11.5, v11.6 or v11.7 are upgradable to v11.8 firmware. In a similar way, all systems which initially come with CSME v11.10 or v11.20 are upgradable to v11.11 or v11.21 firmware respectively. In most cases, upgrading the CSME v11 to a higher compatible minor release works fine, even without a prior OEM BIOS update. However, there is always the risk that you will face compatibility issues between the older BIOS and newer CSME firmware, after which going back to your previous configuration is often very difficult. For example, if your OEM BIOS is up to date but the accompanying CSME firmware is still at v11.6, then it is generally advised to not update to v11.8 but only to latter v11.6 releases, unless you can recover your firmware in case of issues or can contact the OEM and ask for a new BIOS.

Je loopt dus het risico dat je systeem niet meer boot en dat je moet gaan testen hoe goed de recovery werkt. Nu zit ik al op 11.8.50.3399 dus waarschijnlijk is een update naar 11.8.50.3474 niet al te riskant..

De laatste bios update van Asus is uit april dus of die compatibel is met de nieuwe ME firmware? Een andere optie is wachten totdat Asus zelf een release doet maar de laatste versie is 11.7.0.1040 wat al lekker oud is.

Balen dat Intel deze zooi nog steeds niet laat uitschakelen...


EDIT: zoals @Nozmordre schrijft kan je hem inderdaad installeren op de Asus Z170, deze heb ik gebruikt: Intel CSME 11.8 Consumer PCH-H Firmware v11.8.50.3474

[Reactie gewijzigd door spoor12b op 19 juli 2018 09:38]

Ja die waarschuwing zetten ze er voor de veiligheid bij.
Ik heb er geen probleem mee gehad, mijn Z170 bios zat op 11.6 maar updaten naar 11.8 was geen enkel probleem.

bedankt.
Jammer dat Intel niet gewoon een auto-updater/patcher hiervoor uitbrengt. (Verwijst me naar fabrikant, die geen firmware patches heeft)
Het is me helaas niet duidelijk (en ingewikkeld genoeg dat het teveel tijd kost) welke intel versies nou vatbaar zijn. Ik neem aan dat nieuw uitgebrachte chips veilig zijn, en oudere geen amt hadden. Dus voor chips uit welke periode geld dit?
Of alleen voor zakelijke machines met vPro, en is de rest veilig?

Van wat ik begrijp zijn de consumenten chips ook kwetsbaar.
En veiligheidsproblemen worden altijd gevonden en gefixt, groot gepubliceerd of niet.
Persoonlijk vind ik het verstandig om altijd te laatste versie van ME te hebben voor je chipset voor de veiligheid.

Geweldig. Daar gaan we weer... Weer dagen kwijt aan het patchen van firmware voor een risicovolle management functie die we helemaal niet gebruiken.

Echt belachelijk dat dit niet gewoon officieel uit te schakelen is.

Veel BIOS bieden toch de mogelijkheid om AMT niet te gebruiken?

neen.
dit is niet uit te zetten. Het is een aparte chip on chip.

dit soort hardware is simpelweg een backdoor.
ook als de pc uit staat is het nog te misbruiken. zolang de stekker maar in het stopcontact zit kan Intel, overheden en iedereen die er verstand van heeft tot op zekere hoogte zo'n pc 'beheren'.

PCI kaart gebruiken voor ethernet met een non intel chipset ipv onboard ethernet.

PCI kaart gebruiken voor ethernet met een non intel chipset ipv onboard ethernet.

Dit is inderdaad verreweg de meest recht-toe-recht-aan oplossing voor consumenten.

Ik gebruik een PCI Express-draadloze netwerkkaart met volgens mij één of andere Broadcom-chipset. Kan ik er dan vanuit gaan dat ik veilig ben voor dat remote gebeuren?

[Reactie gewijzigd door Commendatore op 19 juli 2018 00:00]

geen pci-express??Mij lijkt dat vele systemen geen pci meer hebben namelijk.

Gelukkig kan je eventueel voor AMT/IME bedoeld verkeer nog wel firewallen. Dus zolang je router/kabelmodem niet gehacked is ben je redelijk safe. Jammer genoeg zijn die dingen ook vaak zo lek als een mandje.

Ja je kan de firewall in je router gebruiken, maar dat beschermd je niet tegen een aanval vanuit je lokale netwerk. Waar misschien iemand je TV als opstap device gebruikt of die ene smart pop van je dochter.

Ja, echt goed te beveiligen is het allemaal nauwelijks nog. Heb zelf het wifi en utp netwerk (semi-) gescheiden (vlan, dus hoe gescheiden dat echt is hangt van de router hardware en OpenWRT af). Wil je van wifi naar het utp netwerk dan moet dat via een vpn. Wel hassle, maar je kan iig alle onzin als smart-dolls (niet dat ik die heb, maar wel random telefoons van vrienden) rustig(er) op je wifi laten.

Maar als non-it-nerd ben je wel redelijk het haasje als iemand je wil pakken.

Een fatsoenlijke accesspoint, bijvoorbeeld de Ubiquiti APs hebben "Guest mode", waarbij je wel in hetzelfde netwerk segment zit maar waarbij de guests zijn gefirewalled en geen toegang hebben tot andere apparaten.

Heb je dus 2 SSIDs, 1 met en 1 zonder firewall.

Dat kan ook idd. Heb ik ook een tijdje gehad. Maar de lekken in alle wifi auth protocollen (+ de nabijheid van een studentenhuis met informaticastudenten :-) ) maken dat ik liever mijn vpn gebruik. Die software moet ik toch al bijhouden om vanaf buiten bij mijn netwerk te kunnen. Kan eventuele wifi lekken lekker negeren.

Is alsnog een risico. Als je echt zo "panisch" bent over de beveiliging van je netwerk zou je Zero Trust moeten toepassen. Nu lijk je eigenlijk te zeggen dat "alles binnen de VPN is veilig", maar ik gok dat al die dingen die binnen dat beveiligde segment draaien, bv. een NAS, wel zelfstandig naar buiten kan (en dus malware kan binnenhengelen met bv. een firmware update)

Ja, je kan bezig blijven :-).

Ik vindt dit goed genoeg. De dingen op mijn vaste netwerk (2 linux PCs en een synology NAS en de wireless router met OpenWrt) houdt ik bij qua updates. Ik ben redelijk zeker dat eea geen malware bevat.

De tig mensen die mijn wifi password kennen kunnen allemaal rustig mijn wifi gebruiken zonder dat ik bang hoef te zijn voor malware op hun telefoons. En ja, dat komt voor. Ik heb al deze bende opgezet nadat mijn (inmiddels opgeheven) windows bak geinfecteerd was met malware vanuit een android telefoon.

off topic, maar is een extra Vlan met daarbij een gastnetwerk op je accespoint dan niet handiger? de meeste kunnen wel meerdere draadloze netwerken uitzenden. 1 voor jezelf met goed wpa2 pass en 1 voor vrienden enz. met eenvoudig te delen pass. eigen wifi koppelen aan je lan en geen VPN meer nodig voor jezelf terwijl je vrienden nergens bij kunnen. bij een goede router kun je ook nog instellen dat het beheer alleen via een vlan (of zelfs 1 specifieke lan poort) kan, dus dan zit dat ook al snel goed.

maar helemaal mee eens, zonder netwerk kennis wordt het al snel een lastig verhaal alles goed te beheren tegenwoordig. Daar hoeven dit soort zaken als AMT niet bij.....

vandaar 'tot op zekere hoogte'.

je zou dus eigenlijk iedere pc door een eigen firewall kastje heen moeten laten gaan voordat hij naar de rest van het netwerk gaat.

maar het kan zijn dat iemand al eens is binnengedrongen en via een andere port naar buiten toe connectie maakt met een evil controlserver vanuit die management module... dan heb je ook niets meer aan je firewall. moet je gaan sniffen en hopen dat je iets geks ziet voorbij komen.

Wellicht dat dit zelfs standaard in de firmware al gebeurd.. maar dat weet niemand want die firmware blobs zijn encrypted.

en overigens, al helemaal je wifi niet meer gebruiken.

system76 en librem proberen met hun pc's die management engine zoveel mogelijk te beperken met hardware switches en libre-/coreboot maar helemaal veilig ben je ook daar nog niet mee.

Dus het gebruik van de MINIX microkernel maakt IME niet zo veilig als ze zelf hadden gehoopt.

Als je C blijft gebruiken dan blijf je kans houden op dit soort snafu's. Eigenlijk moet de wereld over naar een veilige systeemprogrammering taal zoals Rust.

Eigenlijk moet je uberhaupt geen 'always on' backdoor inbouwen zonder op zijn minst een dip-switch/jumper om hem hardwarematig te ontkoppelen.

Ik ben er ook al een tijd voorstander van dat PC en router fabrikanten een hardware schakelaar inbrengen waarmee je de Read / Write pin van het Flash geheugen kan instellen. Als je hem op Read-only zet dan wordt het onmogelijk voor een aanvaller om het Flash geheugen te overschrijven, dat is dan fysiek niet mogelijk. Het maakt het qua gebruiksgemak iets ingewikkelder, vooral voor de gewone consument, maar wel een stuk veiliger.

En als er dan zo'n bug in blijkt te zitten?

Dan zet je de schakelaar tijdelijk om en update je de boel.

Ahh een schakelaar waar de consument bij kan. Ik snap hem.
Dat zal dan geen jumper maar een knopje op de router of dergelijke worden.

Precies, een fysiek knopje waarmee je letterlijk de Read/Write lijn van het Flash geheugen onderbreekt.

Er moet uberhaudt geen (always on) backdoor in zitten. Ik verbaas me dat Intel nog niet helemaal leeg is aangeklaagd. Neem aan dat Amerikanen hier goed geld in kunnen ruiken met paar rechtzaken.

Heb jij liever terroristen in de US? Support je de troops wel?

Ik denk dat dat nog wel een dingetje is om de intel community aan te klagen in de US.

Waarom de EU nog geen boete heeft uitgedeeld geen idee.

Precies, daar gaat het al mis.

Bedankt voor de tip, zie op wikipedia dat de syntax van Rust hetzelfde is als dat van C maar dan veiliger qua memory management. Veilig genoeg om de in dit artikel genoemde lekken op te vangen? Interesting!
Edit: Maar zoals blijkt uit onderstaande reactie van 'totaalgeenhard' misschien wel niet zo low-level.

[Reactie gewijzigd door Orion64 op 18 juli 2018 16:28]

En Rust is weer geschreven in?

Juist C

Nee, misschien dat de eerste compiler versie in C was geschreven, maar dat doet er niet toe. Je zou die compiler in bijna elke taal kunnen schrijven zolang deze maar de mogelijkheid heeft om assembler uit te kunnen spugen.

Antwoord: ja, een buffer overflow is niet mogelijk in Rust tenzij je de code als 'unsafe' markeert.

Wablief?

Wat heeft Minix en C er mee te maken?

Want beide voorkomen niet dat iemand met een achterlijke implementatie oplossing komt.

Bovendien is Minix voor educatieve doeleinden gemaakt door Tanenbaum en niet als OS voor productie omgeving.

Zonder de taal C bestond jouw digitale wereld niet en vrijwel geen enkele OS.

Ik ken Rust niet maar ik durf te betwijfelen dat deze taal en diens compiler in assembler geschreven is.

Intel IME is feitelijk een aparte processor binnen een x86 processor die MINIX draait.

MINIX is in C geschreven.

[Reactie gewijzigd door ArtGod op 18 juli 2018 18:31]

De Intel ME draait op Minix..

Dus het gebruik van de MINIX microkernel maakt IME niet zo veilig als ze zelf hadden gehoopt.

Ik heb voor een eindopdracht van één van de vakken voor m'n studie nog eens aan wat file-system zaken voor MINIX v3 mogen werken. Als je nagaat dat er op dat niveau van fijngevoeligheid al allerlei fouten in zaten m.b.t. het door elkaar heen gebruiken van signed en unsigned waardes; long, int en short wat afwisselend naar elkaar gecast werd zonder te letten op truncation; pointer arithmetic met impliciete aannames dat bepaalde numerieke types bepaalde geheugengrootte in zouden nemen; etc.

Man; wat een zootje was dat.

[Reactie gewijzigd door R4gnax op 18 juli 2018 19:44]

Tja, MINIX is gemaakt door studenten en dat zijn misschien wel intelligente jongeren, maar zeer onervaren. Toch wel vreemd dat Intel het toch goed genoeg bevonden heeft voor zijn processoren.

Maar misschien is de microkernel architectuur toch veilig ondanks alle programmeerfouten die er in zitten. Het aanvalsoppervlak is in elk geval wel veel kleiner.

De hele ontwerpfilosofie van Minix is dat de kernel minimaal is (minder dan 100 regels), de rest gedaan wordt in user space, en dat threads met elkaar communiceren dmv rendezvous wat simpel en rock solid is. Geloof me, Minix is veilig maar natuurlijk niet bugfree. Maar knappe jongen die de kernel kan laten crashen.

LOL, wat een lulkoek. Je moet gewoon opletten waarmee je bezig bent. En sowieso is achteraf praten altijd makkelijk. Even alles herschrijven kost ook tijd, en ook rust is niet zaligmakend, het wordt ook ontwikkeld door developers en heeft ook gewoon bugs.
In C kun je perfect veilig programmeren, maar dan komt het dus wel meer aan op jouw kennis en kunsten en wordt niet een hoop dingen door het framework voor je afgevangen (als jij het toch eens fout zou doen).

Precies, en buffer overflows zijn eenvoudig te voorkomen met strlcpy en strlcat.

Wanneer kunnen we deze nutteloze rommel voor ons domme consumenten eens permanent uitschakelen zonder hacks?

Niet, want het geeft bepaalde instantie met hack bevoegdheden toegang tot die ene PC.

Als je consumenten hardware hebt is de kans groot dat je deze hardware niet eens hebt.

Als het aan Intel en AMD ligt nooit. Zelf kijk ik naar Talos II hardware met POWER9 processoren en eventueel systemen gebaseerd op RISC-V processoren, zoals die waar Esperanto Technologies aan werkt.

Nadenkertje: Is een processor nog conform aan de verwachtingen van de consument als deze een ernstig, niet te verhelpen lek heeft? En kunnen kwetsbare systemen in Nederland dus ten alle tijden worden geretourneerd vanwege non-conformiteit?

Denk het niet, de functionaliteit werkt naar behoren. Er is hier sprake van een bug die misbruik mogelijk maakt maar niet direct afbreuk doet aan de functionaliteit.

Dat ligt eraan wat men onder "conformiteit" verstaat bij een processor. Het is de vraag voor mij: Is de processor nog conform aan de geschepte verwachtingen bij de consument, als deze het toestaat dat het systeem zeer low-level wordt binnengedrongen en zo o.a. bankzaken, overheidscommunicatie en gegevens bekeken onder geheimhoudingsverklaring kunnen worden onderschept?

Denk het niet, de functionaliteit werkt naar behoren. Er is hier sprake van een bug die misbruik mogelijk maakt maar niet direct afbreuk doet aan de functionaliteit.

De eigenschap 'veiligheid' moet je wss. ook onder conformiteit zien. Als je gaat kijken naar een op handen zijnde richtlijn voor conformiteit op het gebied van software wordt dat zelfs expliciet benoemd.

Natuurlijk is het goed dat dit in de essentiële eisen wordt opgenomen maar dat betekend niet dat het product vrij van dit soort 'defecten' zal zijn. Intel heeft dit soort zaken er niet met opzet in gestopt, het is een bug. Zoiets zal gewoon onder de garantie gaan vallen, wat inhoudt dat de consument daar niet heel veel mee gaat opschieten aangezien dit soort zaken zelden binnen de garantietermijn naar voren gaan komen. Microsoft update zijn OS ook regelmatig maar dit gaat er echt niet toe leiden dat mensen hun geld terug gaan krijgen. Om schadeloos gesteld te worden moet je namelijk ook kunnen aantonen dat je daadwerkelijk benadeeld bent. Voor de meeste gebruikers zal dat gewoon niet gelden of zelfs ook maar aantoonbaar zijn.

Natuurlijk is het goed dat dit in de essentiële eisen wordt opgenomen maar dat betekend niet dat het product vrij van dit soort 'defecten' zal zijn. Intel heeft dit soort zaken er niet met opzet in gestopt, het is een bug. Zoiets zal gewoon onder de garantie gaan vallen, wat inhoudt dat de consument daar niet heel veel mee gaat opschieten aangezien dit soort zaken zelden binnen de garantietermijn naar voren gaan komen. Microsoft update zijn OS ook regelmatig maar dit gaat er echt niet toe leiden dat mensen hun geld terug gaan krijgen. Om schadeloos gesteld te worden moet je namelijk ook kunnen aantonen dat je daadwerkelijk benadeeld bent. Voor de meeste gebruikers zal dat gewoon niet gelden of zelfs ook maar aantoonbaar zijn.

Wettelijk bestaat er niet zoiets als 'garantie'. Er bestaat het conformiteitsbeginsel, wat aangeeft dat een aangeschaft goed conform de verwachtingen voor dat goed moet zijn.

De EU dwingt daarbij een minimale periode af van 2 jaar waarbinnen consumenten conformiteit kunnen claimen, maar laat lidstaten de ruimte een langere periode in te stellen. In Nederland is het zo dat de periode waarbinnen conformiteit geclaimd kan worden de volledige te verwachten levensduur van het goed is - met een ondergrens van 2 jaar.

Daarnaast heb jij als consument helemaal niets met Intel te maken, tenzij je direct bij Intel ingekocht hebt. Jij hebt te maken met de verkoper waar je je moederbord* vandaan hebt.

* De Management Engine leeft in de Platform Controller Hub op het moederbord. Niet in de CPU.

[Reactie gewijzigd door R4gnax op 18 juli 2018 23:12]

Gezien Intel gewoon de CoffeeLake serie lanceerden terwijl ze al een half jaar van Meltdown/Spectre af wisten maakt het hun niet zoveel uit.

Meltdown/Spectre was toen trouwens nog niet openbaar.

De lancering een paar maanden uitstellen totdat er een fix was? Zodat iedereen die een nieuwe Coffeelake CPU koopt een CPU koopt gelijk een patch kan installeren.

Ipv een CPU verkopen waarvan je weet dat hij zo lek is als een mandje aan een persoon die hier geen weet wat heeft.

Doet me denken aan die Jeep case waar de banden niet goed waren ofzo.

Dit toont nogmaals aan dat er nagedacht moet worden over wat er wel en wat er niet in een CPU gestopt moet worden.

Leuk en aardig dat het allemaal richting semi-SOC gaat door alles op 1 chip te bakken, maar nu lijkt het erop dat het modulaire van vroeger (iedere chip in een aparte socket) een betere aanpak lijkt in een wereld waarin technologie steeds sneller veranderd.

Dat het in de CPU zit en blijkbaar lastig geupdate kan worden(?) is één ding, maar dit draait op een aparte processor die dus ook toegangelijk is als hij uit staat. Voor een desktop trek je dan lekker de stekker er uit maar voor een laptop gaat dat een stuk lastiger.

hoezo een stuk lastiger?? meeste laptops kan je toch zo de accu eruit trekken?

Dan leg je het onhandige gedoe wel bij de consument neer i.p.v. dat de fabrikant (Intel) haar verantwoordelijkheid neemt. Ooit, ten tijde van de Pentium(-1 60/66 MHz) processoren hield Intel een terugroepactie nadat er een fout uit sommige berekeningen kwam.

Intel zou verplicht moeten worden de processoren te vervangen, of een andere vorm van zware financiele vergoeding: dan heb je de grootste kans dat men beveliging en veiligheid weer serieus gaat nemen.

klopt, ben ik helemaal met je eens.

maar ik reageerde ook echt puur alleen op het feit van het ongemak van hoe het system van de power af te krijgen.
als intel al een terugroep actie zou gaan organiseren, dan zullen er toch eerst aan een paar Eisen voldaan moeten worden.

1: ze moeten een vervangend product hebben
2: voordat dit product ingezet wordt, moet ie zeeeer uitvoerig getest worden om zeker te weten dat dit soort dingen niet kan gebeuren
3: een hele operatie op touw zetten, want wat denk je? dat grote bedrijven met datacenters of cloud hosting companies effe zeggen…..ach, stuur die cpu's maar op, we vervangen ze zelf wel?? denk het niet.

Krijg nu steeds minder zin in een Intel CPU voor de upgrade.

Je kan er niet eens fatsoenlijk mee internet bankieren zonder dat je zorgen moet maken dat je CPU backdoor niet wordt gebruikt door een hacker. Een backdoor die NIET is uit te schakelen. Als die is gehackt mag je die dure CPU wel weggooien.

Ryzen klinkt zo gek ook niet.

Ik zie de zakelijke wereld ook overschakelen naar AMD want die werken ook met sensitive informatie.

Ja ik weet dat AMD PSP heeft maar naar mijn gevoel nemen zij beveiliging veel meer serieus dan Intel kijk maar naar Meltdown.

[Reactie gewijzigd door TehEnforce op 18 juli 2018 17:20]

Ik heb als het goed is zéér snel m'n Threadripper componenten binnen, want om heel eerlijk te zijn, alles bij elkaar opgeteld, is de nét wat meer extra performance (voor eigenlijk meer euro's) het me niet waard. Zelfs niet op HEDT budgetten. Naast het heerlijke (los van de techniek en het feit dat security firma's ook graag dingen opblazen en in de picture lopen) PR-debacle waar tanenbaum zelf nog moest ingrijpen rond de IME & Minix, hebben we natuurlijk ook:

• Solder-gate, waar Intel gestopt is met het solderen van IHS-en en zéér slechte thermal paste gebruikt waardoor we haast weer in Prescott tijden zijn qua thermals. Niet omdat ze nou zoveel verbruiken, maar ze kunnen het gewoon niet kwijt
• Heerlijkheden rondom zéér geknepen PCI-E lanes. Consumer-grade Coffee lake CPU's zitten doorgaans op 16, en de chipset geeft ook nog een paar (latency!) waardoor mooie nVME/GPU/Optane/USB-C/Thunderbolt/etc. configs out-of-the box geknepen zijn. HEDT platformen hebben meer (soms wel 28! Een enkele absurd dure CPU zelfs 40!) maar het blijft een beetje... meh...

Ik heb de komende jaren m'n centen maar aan team rood gegeven. Ik ben geen fanboy, wil ik ook niet zijn (single threaded blijft Intel koning), maar ik stem met m'n portefuille. Mochten ze tegen de tijd van m'n volgende rig iets anders hebben, overweeg ik het natuurlijk weer.

Je zou denken dat een normaal bedrijf al haar distributie keten gaat informeren met verzoek klanten te informeren met een oplossing.

Je stil houden indien er serieuze problemen al decennia met je producten zijn helpt misschien ook.

Jammer dat je in Nederland geen serieuze schade vergoeding kunt krijgen.

Ik heb hier zelf 0 verstand van, maar zo te lezen heb ik hier geen last van? Ik heb een Kaby Lake processor, kan iemand dit bevestigen? In het artikel staat dat vanaf skylake het lek is gedicht dus ik neem aan van wel.

[Reactie gewijzigd door coolkingler1 op 18 juli 2018 20:19]

Ik zou graag al die rommel slopen - kunnen we Intel daar juridisch niet gewoon toe verplichten?