Intel waarschuwt voor nieuw lek in Core-processors dat gegevens prijsgeeft

Intel heeft gewaarschuwd voor een nieuwe kwetsbaarheid in zijn Core-processors die te maken heeft met speculative execution, zoals Meltdown. Het lek, dat door de chipmaker als 'medium' wordt geclassificeerd, geeft informatie tussen processen prijs.

Intel heeft een summiere waarschuwing gepubliceerd, waarin het onderzoekers van Amazon, Cyberus en Sysgo bedankt voor het melden van het lek. Ook bedankt het ontwikkelaar Colin Percival, die op Twitter meer details over het lek met kenmerk CVE-2018-3665 bekendmaakt. Het lek heeft te maken met een techniek die bekendstaat als 'lazy fp state restore'. Percival legt uit dat een aanvaller het lek kan gebruiken om gegevens uit het registergeheugen van een processor, of specifieker de floating point unit, buit te maken. Hij noemt het voorbeeld van encryptiesleutels. Daarvoor moet de aanvaller wel in staat zijn code uit te voeren op dezelfde cpu als het doelwit.

Hij stelt verder dat het mogelijk is om de aanval uit te voeren vanuit een browser, maar dat misbruik van het lek een stuk moeilijker is dan bij Meltdown. Het zou Percival ongeveer vijf uur hebben gekost om een exploit te schrijven, nadat hij een presentatie over het onderwerp had bijgewoond. Verschillende organisaties hebben inmiddels advisories gepubliceerd, waaronder Microsoft. Het bedrijf schrijft dat de 'lazy restore'-techniek standaard in Windows is geactiveerd en niet uitgeschakeld kan worden. Het geeft echter geen informatie over getroffen Windows-versies en vermeldt dat het nog met informatie daarover komt. Gebruikers van vm's in Azure zijn niet getroffen.

In de Intel-waarschuwing wordt vermeld dat het gebruik van 'eager fp state restore' voorkomt dat er misbruik van het lek kan worden gemaakt. The Register merkt op dat deze techniek sinds 2016, oftewel versie 4.9, wordt gebruikt in de Linux-kernel, waardoor recente kernels niet kwetsbaar zijn. Amazon zegt in een advisory dat zijn AWS-dienst niet is getroffen. Systemen die Xen draaien, zijn wel getroffen, maar er zijn patches beschikbaar. Ook Red Hat werkt aan patches voor RHEL 6 en lager.

Cyberus, een van de bedrijven die betrokken waren bij het melden van van het lek, schrijft dat het eigenlijk de bedoeling was om de details pas in augustus bekend te maken, maar dat er al eerder informatie naar buiten kwam. ZDNet, dat met Jon Masters van Red Hat sprak, schrijft dat er geen microcodepatches van Intel nodig zijn om het lek te dichten. Masters stelt dat het lek 'moeilijk te misbruiken en eenvoudig te dichten is'. Er zijn geen aanwijzingen dat Arm of AMD is getroffen.

Reacties (104)

En weer eentje, gaat lekker daar...

Begrijp ik nou goed dat Xeon-processoren niet kwetsbaar zijn? Ik heb een Xeon workstation CPU in mijn desktop, ik was onder de indruk dat de verschillen met een vergelijkbare Core i7 niet heel groot waren eigenlijk - heb hem met name voor ECC-ondersteuning gekozen.

Sowieso is Linux dus niet (meer) kwetsbaar dus ik zit al goed

Ook moderne Windows systemen en BSDs zijn niet kwetsbaar volgens The Register (https://www.theregister.c..._fpu_state_security_flaw/)

Weet niet waarom die niet in het artikel hierboven genoemd worden en Linux wel maar opzich lijkt de impact (vooral voor consumenten) mee te vallen.

Register roept wel iets over WIndows, maar Microsoft was niet bereikbaar voor commentaar,
En Microsoft gee in z'n eigen advisory geen versie nummers vrij....

De CVE is not niet openbaar dus waar is meer informatie te vinden dan alleen wat geruchten?

Ik vroeg mij dan gelijk af wat 'modern' precies betekent, dus voor het gemak uit je link:

Modern versions of Linux – from kernel version 4.9, released in 2016, and later – and modern Windows, including Server 2016, as well as the latest spins of OpenBSD and DragonflyBSD are not affected by this flaw (CVE-2018-3665).

Dus als je na 2016 ooit nog geupdated hebt ben je safe.

Dat ECC niet standaard in alle machines zit, is mij een raadsel.

Overigens is dit lek gefixed in OpenBSD sinds 5 juni 2018.

Dat ECC niet standaard in alle machines zit, is mij een raadsel.

Ik zou marketing / financiele motieven verwachten, maar de Xeon CPU was iets goedkoper dan de Core i7 variant. Het moederbord was wel veel duurder en Intel levert de chipset dus daar zal het waarschijnlijk mee te maken hebben. Dat doet AMD veel beter.

Overigens is dit lek gefixed in OpenBSD sinds 5 juni 2018.

En schijnbaar in Windows ook al. Niet veel impact dus.

Het financiële motief is dat ECC geheugen duurder is omdat je meer chips nodig hebt voor de ECC bits. 4 bits ECC op 32 bits data, is 12.5% meer. Marktwerking heeft er voor gezorgd dat er dus ook systemen zonder ECC worden verkocht. Het is niet iets waar de gemiddelde consument naar kijkt als die een PC koopt. De prijs echter wel.

Voor Intel ligt dat anders, Intel doet aan kunstmatige productdifferentiatie om de winst te maximaliseren.
AMD doet al die "premium features" ook in hun budget producten. Enerzijds omdat AMD niet zo groot is als Intel en productdifferentiatie ook geld kost, anderzijds omdat het de enige mogelijkheid was om met Intel te concurreren, want op performance ging dat tot voor kort zeker niet.

Overigens, is het verschil tussen die i7 en de Xeon niet dat de i7 een iGPU heeft en de Xeon niet? Dat is scheelt bijna de helft in die-size.

Overigens, is het verschil tussen die i7 en de Xeon niet dat de i7 een iGPU heeft en de Xeon niet? Dat is scheelt bijna de helft in die-size.

De Xeon E3-1270 v5 heeft geen iGPU, de Xeon E3-1275 v5 wel. Verder hebben die twee dezelfde specs, en het scheelt +- €5,- dus veel verschil maakt het niet.

Dat kan net zo goed betekenen dat er een E3-1275 faalde in een test op de GPU en dat die uitgeschakeld is en de hele chipset als E3-1270 verkocht is. Voor slechts EUR 5,-- verlies ipv. EUR 400 + afvoer kosten te betalen voor afval.

Kleine correctie, het is 8 bits ECC op 64 bits data. De soft fault rate van geheugen is ongeveer 1 bit flip per gigabyte per maand. Dus de behoefte aan ECC is gerelateerd aan de hoeveelheid geheugen en of de machine always on is.

Van Intel weet ik het niet, maar bij AMD hangen DIMMs rechtstreeks aan de (memory controller van de) CPU. Alleen de CPU hoeft ECC hardwarematig te ondersteunen, wat het geval is bij zelfs de goedkoopste AMD Sempron van €12(!).

De rol van het moederbord is alleen dat de firmware (die wordt uitgevoerd door de CPU) ECC aanzet, en af en toe scrubt. Mijn AMD mobo firmware heeft geen ECC support, dus activeer ik het vanuit Linux (google "ecc_enable_override" en "edac_mc_poll_msec").
Zo bekeken is het ook bullshit dat moederborden zoveel duurder worden van ECC support, het is alleen maar een extra stukje software (edit: en een paar draadjes, bedankt @xorpd, weer wat geleerd). Een Asrock AMD mobo van slechts €50 heeft dat ook al.

Het lijkt er meer op dat mensen die per se Intel+ECC nodig hebben, daar veel geld voor over hebben, dus vraagt Intel extra veel omdat ze ermee weg kunnen komen.

[Reactie gewijzigd door N8w8 op 15 juni 2018 12:27]

Klopt, ik heb in 2007 Sempron en Phenoms gebruikt icm ECC geheugen. Was geen enkel probleem.

Het is meer dan een stukje software. Op de meeste moederborden zijn namelijk de ECC datalijnen van en naar de processor en het geheugen niet geïmplementeerd. Vandaar Asrock ;-)

Volgens dit verhaal is het NIET opgelost in windows.
Windows kent uitsluitend Lazy FP state...
(Link uit het artikel)
https://portal.msrc.micro...idance/advisory/ADV180016

Er lijkt op dit moment geen fix release date bekend te zijn...

Ik ben best wel benieuwd welke Xeon jij hebt en met welke i7 je 'em hebt vergeleken?
Meestal is het namelijk zo dat Xeons over het algemeen lager geklokt zijn en een mindere Turboboost hebben en vaak een lagere TDP, echter kunnen ze veel beter over hele lang tijd een hoge piek snelheden aanhouden zonder dat het de levensduur verminderd.

Redelijk off-topic

Maar ik heb deze Xeon: pricewatch: Intel Xeon E3-1270 v5 Boxed
En die heb ik vergeleken met deze Core i7: pricewatch: Intel Core i7-6700K Boxed

De kloksnelheden van de Xeon zijn iets lager inderdaad, maar niet schrikbarend veel en ik verwacht niet dat dat in de praktijk veel uitmaakt.

je vergelijkt een 3.6 quad core met een 4ghz quad core, das toch een redelijk verschil als je mij vraagt .

Een vergelijkbare xeon zal de volgende zijn; pricewatch: Intel Xeon E3-1280 v6 Tray á >€400

Turbo van 4,2 vs 4,4 GHz. En de Xeon zou daar vaker gebruik van kunnen moeten maken, dus dat compenseert weer wat. De Xeon die je noemt was niet beschikbaar op het moment dat ik hem aanschafte, dat was juni 2016. Daarmee kon ik hem op dat moment dus ook niet vergelijken

Daarnaast lagen destijds de prijzen ook iets hoger - de genoemde Xeon en i7 zaten toen beide tegen de €400,- aan, de Xeon was een tientje goedkoper.

Turbo van 4,2 vs 4,4 GHz. En de Xeon zou daar vaker gebruik van kunnen moeten maken, dus dat compenseert weer wat.

Moderne i7 processors runnen gewoon 24/7 Turbo hoor. Gegeven dat er een enigszins adequate koeler op zit. En veel moederborden zetten zelfs all-core turbo aan en dat doet het ook prima 24/7, als het zou moeten. Het probleem zal hem eerder zitten in RAM bit flips.

Verschil is ook nog dat de i7 een geïntegreerde GPU heeft en de Xeon niet.

Ik heb de Xeon 1270, die heeft geen iGPU. De 1275 heeft dat wel, die kostte €5,- meer. Dat zijn de kosten niet.

400MHz ga je nergens in merken, niet in games en niet in je dagelijkse gebruik...

tja, dan kun je ook een 1,8 xeon nemen? as je 400 niet merk kun je nog wel 400 omlaag, en dan weer omlaag.

Je moet geen appels met peren vergelijken, maar gewoon bijna gelijke cpu's. Niet op basis van prijs. Xeon is altijd duurder dan een gelijke consumer cpu mede door de ECC ondersteuning en toch iets andere stabiliteits eisen.

Daarbij is een xeon over het algemeen iets beter in z'n turbo handhaven.

Dat betwijfel ik. Ligt er maar net aan hoe de moederbord fabrikant omgaat met turbo's. Als die Xeon op een intel bordje prijkt, kan die ook alle cores naar de max gooien? Of gaat het van core 1 3.6, core 2 3.4 etc?
Bij consumer spul, denk aan MSI, gaan alle cores naar max, en draait dan goed.

Wat jij zegt klopt ook niet, je trekt het helemaal uit verband in je poging een punt te maken.

Het gaat om de relatieve verschillen tussen de kloksnelheden van 2 CPU’s, en dat is hier 10%. Gezien hoe CPU’s ingezet worden door het OS ga je dat verschil inderdaad never nooit merken, zeker als je de turbo meerekent. Daarnaast zijn er veel meer factoren die meespelen waardoor de verschillen in prestaties groter of kleiner worden.

Benchmark is het enige waar je verschillen gaat zien van 400MHz.
Tijdens het web surfen of gamen ga je het niet merken, simpel.

Als jij en allen die me klakkeloos weggemod hebben even wat onderzoek had gedaan had je snel uitgevonden dat cpu nog altijd heel veel uitmaakt met gamen...

https://nl.hardware.info/...080-ti-battlefield-1-dx12

Die halve seconde met een fotobewerking is misschien minder boeiend maar een mogelijk verschil van zo enorm veel fps is toch echt een wereld van verschil...

ik heb niks gemod, dit is de toedoen van anderen.
Zie: https://imgur.com/6lMRgog

Ga ergens anders salty wezen wil je?

En 400MHz GA.JE.NIET.MERKEN.
Kijk naar die graph die jij gepost hebt, letterlijk de bovenste helft is gelijk, en er zit minstens 400MHz verschil tussen de CPU.

Ik zeg ook nergens dat CPU niet belangrijk is btw, dus als JIJ dan even LEEST voordat je klakkeloos salty comments neergooit, dan ben je ook weer een stukje meer volwassen geworden.

[Reactie gewijzigd door Joeri.Bijlsma op 15 juni 2018 10:22]

Dat ECC niet standaard in alle machines zit, is mij een raadsel.

Het zou mij ook niet eens verbazen dat het verschil tussen de Xeon en de i7 alleen maar in microcode zit en je dus de één naar de ander om zou kunnen flashen.

Ze zijn heel anders gebinned, dan moet je wel heul veul geluk hebben. als het al kon.

Een core i7 heeft geen ECC-circuits en de bijbehorende datalijnen. Ook niet de RAS features.

ECC is natuurlijk wel 3x zo duur als normaal geheugen wat ook voor jan met de pet al duur is tegen woordig

Zelfs vroeger niet. ECC geheugen is tegenwoordig zo'n 10-20% duurder. Maar verwacht alleen JEDEC geheugen, dus 2400 MHz max.

Gaat lekker inderdaad. Ik ben zelfs eigenlijk de tel kwijt geraakt na spectre en meltdown. Iemand die een lijstje kan maken?

Mijn Xeon E3 1231v3 is helaas wel kwetsbaar volgens de website van Intel.

Edit: Oeps, je bedoelt natuurlijk deze nieuwe kwetsbaarheid, daar weet ik niks over, ik doelde op Spectre en Meltdown.

[Reactie gewijzigd door Randfiguur op 14 juni 2018 12:19]

Gewoon amd, rock solid performance, iT never Lets you down, rock solid OCing, en het beste van allemaal, goede prijs, en nu gaat Intel ook ontwikkelen. Als Intel gaat ontwikkelen, gaat amd ook weer innoveren, en dan komen we weer bij de dagen (toen leefde ik nog niet... komt dus uit filmpjes) dat de race wie het eerst dit heeft, of dat beter heeft. Net als toen de 64 bit race.

Volgens mij is de kans dat de doorsnee nederlander infected raakt met deze exploits enorm klein.
Er wordt ook nergens vermeld HOE je infected kunt raken, (kon het niet vinden in ieder geval) maar ik denk dat als ze willen hacken, dat bij een groter bedrijf is.

Kan het natuurlijk fout hebben, zo ja, please enlighten me

Je kan zelfs geïnfecteerd worden via een JavaScript-code die op een site draait: https://react-etc.net/ent...wn-spectre-via-javascript

[Reactie gewijzigd door AnonymousWP op 14 juni 2018 11:16]

Hmm, dus gewoon chrome blijven gebruiken en niet naar dodgy sites gaan?
Of dingen zoals facebook en youtube moeten je kunnen infecteren, maar lijkt mij niet (dan had dit allang in het nieuws geweest)

Hoe ik het aanpak:

• Nieuwste security-patches installeren (van je OS, browser en BIOS voornamelijk)
• Ads blokkeren (die kunnen dus ook dit soort kwaadaardige scripts draaien, via adblocker)
• Malware domeinen blokkeren (via adblocker)
• Tracking blokkeren (via adblocker)
• Je browser third-party cookies laten blokkeren
• Flash verwijderen
• Java verwijderen (ik weet dat dit iets anders is dan Javascript, maar Java is ook niet bepaald veilig als je het nog amper nodig hebt tegenwoordig)

Hier wat ik gebruik: https://adblockplus.org/nl/
Met deze filters: https://adblockplus.org/nl/subscriptions

Inb4 mensen zeggen 'ja maar er wordt gewhitelist bij ABP': Instellingen > Algemeen > 'Acceptabele advertenties toestaan' uitvinken.

Hoe ik het aanpak:

• Nieuwste security-patches installeren (van je OS, browser en BIOS voornamelijk)
• Ads blokkeren (die kunnen dus ook dit soort kwaadaardige scripts draaien, via adblocker)
• Malware domeinen blokkeren (via adblocker)
• Tracking blokkeren (via adblocker)
• Je browser third-party cookies laten blokkeren
• Flash verwijderen
• Java verwijderen (ik weet dat dit iets anders is dan Javascript, maar Java is ook niet bepaald veilig als je het nog amper nodig hebt tegenwoordig)

Hier wat ik gebruik: https://adblockplus.org/nl/
Met deze filters: https://adblockplus.org/nl/subscriptions

Inb4 mensen zeggen 'ja maar er wordt gewhitelist bij ABP': Instellingen > Algemeen > 'Acceptabele advertenties toestaan' uitvinken.

Java verwijderen kan wel, maar er zijn aantal programma's die van Java gebruik maken, o.a. Cisco Packet Tracer en om Oracle databases te bouwen, onderhouden en aan te passen.
Infecteren via ads is mogelijk (zie de geschiedenis met Marktplaats, Telegraaf en nog hoop andere sites), een adblocker is een goede manier om het probleem te minderen (bovenop een goede AV)
Javascript blokkeren kan niet altijd handig zijn, sommige sites sturen een prompt via JS. Scripts wel blokkeren die willen minen.
Flash verwijderen kan wel, maar nog niet alle sites zijn overgegaan naar HTML5 en dus hebben sommige sites flash nog nodig.

Maar voor BIOS updates is het soms wat lastiger, niet elke fabrikant brengt nog updates uit voor de BIOS. mijn MSI gaming laptop van 4 jaar geleden, heeft in 2016 voor het laatst een BIOS update gekregen. Windows houd ik altijd up-to-date, behalve bij de 'service packs'. Daar wacht ik het liefst aantal weken mee, totdat ik weet dat mijn hardware wel wordt ondersteund en ik de boel niet opnieuw hoef te installeren.

En daarnaast is een goede AV van belang, alhoewel sommige mensen of de proefversie op hebben draaien, of virusdatabase van de AV niet updaten... Ik gebruik zelf Kaspersky Total Security (Ja, I know dat er een hoop negativiteit is rond Kaspersky, maar ze zijn meestal wel een van de eersten die bepaalde virussen vinden), op mijn eigen laptop. Het werkt goed, detecteert heel snel mining scripts, malafide sites enz en de interface is gebruiksvriendelijk. Op mijn Windows tablet draai ik Avast Free, omdat die net iets lichter is dan Kaspersky Free.

De meeste gebruikers zouden wel bang zijn (ow, er iets een nieuwe lek, dat is niet goed), maar zelf hebben ze verouderde OS en software. Je kan wel tegen iedereen zeggen dat ze alles up-to-date moeten houden, maar niet iedereen wil dat of heeft zien om het te doen. Of ze kunnen ook denken van 'ach, mij overkomt het toch niet'.

Masters stelt dat het lek 'moeilijk te misbruiken en eenvoudig te dichten is'. Er zijn geen aanwijzingen dat Arm of AMD is getroffen.

Waaraan ligt het dan dat er een lek is in de processors? Ligt het aan de manier hoe het gemaakt wordt, of aan de manier hoe de code geschreven wordt zodat de alle hardware goed met elkaar kan omgaan? Spectre en Meltdown troffen beide partijen, ben ook benieuwd of deze ook gevolgen zou hebben voor ARM devices.

Toch jammer dat alleen bij recente pc's de bios überhaupt een update krijgt. Mijn core i7 920 pc draait nog op een bios uit 2010...

Niet direct van toepassing voor dit artikel, want geen microcode nodig om dit op te lossen. Maar als je moederbord fabrikant geen biosupdate meer uitgeeft voor jouw specifieke moederbord kan je altijd nog met o.a. deze VMware tool (Microcode update driver) de laatste microcode zelf laden onder Windows.

De VMware Tool: https://labs.vmware.com/f...u-microcode-update-driver
De Microcode kan je hier bij Intel downloaden: https://downloadcenter.in...essor-Microcode-Data-File

Onder Linux heb je als het goed is niet eens een tool nodig, enkel de microcode files in de juiste map zetten met de juiste naam.

Voor Sandy Bridge of hoger wanneer je Windows 10 gebruikt kun je ook deze Windows Update installeren en heb je bovenstaande oplossing ook niet nodig https://support.microsoft...7/intel-microcode-updates

Kortom: Een nieuwe bios is eigenlijk nooit noodzakelijk (gelukkig niet, want mobo fabrikanten lijken aardig laks te zijn bij deze issues en updates voor oudere moederborden).

De VMware Tool, laadt de mircocode te laat in Windows, dit is dus een schijnoplossing

Hoe bedoel je dit, heb je hier enige verdere informatie over? Er is voor zover ik weet enkel een zeer kleine theoretische (praktrisch eigenlijk niet uitvoerbaar) mogelijkheid dat een proces dat eerder start via een op spectre gebaseerde exploit enkele bits zou kunnen bemachtigen. Maar dicht de VM tool verder eigenlijk alles gewoon correct af. Voor het grootste gedeelte van de gebruikers die momenteel nog oudere, niet meer ondersteunde, hardware gebruiken zal dit ruim voldoende zijn en aanzienlijk veiliger dan helemaal niets doen.

En is deze theoretische mogelijkheid zelfs vrijwel uit te sluiten door te zorgen dat alle applicaties met data die je wil beveiligen pas starten nadat de VM tool de microcode geladen heeft.

[Reactie gewijzigd door Dennism op 14 juni 2018 14:04]

Laadt de laatste microcode update maar met deze tool, en controleer daarna de status voor Meltdown/Spectre maar met de Microsoft tool eg: https://www.powershellgal.../SpeculationControl/1.0.8

Bedoel je niet de false negative die script soms veroorzaakt? Ik heb diverse systemen getest voor klanten waarbij VMware microcode driver en dat script volledig beschermd aangaven, maar ook systemen waarbij dit niet het geval is. Doe je dan echter verdere checks dan blijkt dat de microcode wel degelijk correct geladen is, daar dat het script schijnbaar (volgens de MS forums) een waarde uit het register haalt die niet klopt.

Zover ik weet en lees en hier moet de nieuwe microcodes geladen zijn voor/tijdens kernel initialization, en dat is met de VMWare driver simpelweg niet het geval, vandaar mijn initiële opmerking dat de VMWare driver de microcodes te laat laadt

De VMware CPU Microcode Update Driver kan dus wellicht wel werken in virtual machines (gast OS) maar helaas niet voor de host OS

[Reactie gewijzigd door RJWvdH op 14 juni 2018 15:53]

Ik ga daar nog eens naar kijken, maar eens kijken of ik ergens nog een systeem heb dat inmiddels nog niet voorzien is van een nieuwe bios, want wat daar aangegeven wordt komt niet overeen met de resultaten die ik op diverse test machines gezien heb in het verleden.

Dat is het verschil tussen 'consumenten-meuk' en 'business-meuk'. Workstations en zakelijke laptops (ThinkPads, EliteBooks, etc) krijgen meestal vele jaren na EOL nog updates in dit soort gevallen.

Het heeft toch niet veel zin als deze lekken bestaan? Je kan dan wel alle Security aanbevelingen toepassen, maar deze lekken staan er totaal buiten. Hetzelfde geld voor exploits die niet bekend zijn, zoals de lekken in een PDF-parser (die gebruikt kon worden voor iOS) en je bent totaal kansloos.

Ja, als je zo denkt kan je net zo goed helemaal geen drol erom geven en helemaal geen security patches installeren. Deze maatregelen helpen wel degelijk. Tuurlijk ben je dan niet 100% veilig, maar dat ben je nooit.

Heb je toevallig ook gebruik gemaakt van Unlock Ublock Origin? Ikzelf gebruik dat al paar jaar en naast het idee dat ik denk dat het beter werkt (ook voor mining scripts op websites) zijn er ook meer mogelijkheden.

[Reactie gewijzigd door Settler11 op 14 juni 2018 12:50]

Ublock Origin bedoel je denk ik? Nog nooit gebruikt (heb geen zin om over te stappen ).

ik gebruik beide (adblock en ublock) just to be safe

Thanks voor de replies btw.

Dit is eigelijk best wel onnodig dubbel, ik ben zelf overgestapt van abp naar destijds gewoon ublock, en nu gebruik ik ubo. Httpseverywhere en privacy badger zijn ook 2 leuke addons (van de EFF).

ublock blokkeert en sluit pop-ups, abp niet (voor zover ik weet)
En dubbel of niet, ik ben wel zeker dat er niks door komt

Ze gebruiken allebei EasyList, dus je dubbel ja. Je maakt alleen je eigen browser performance slechter. Ik zou ABP er gewoon uit knikkeren.

Wat apart, dat klinkt alsof je dan ook 2 antivirusproggramma's nodig hebt om 'just to be safe' terwijl dat just erg tegenstrijdig is. Heb vaak meegemaakt dat de ene antivirusprogramma de ander als virus zag. En ik denk ook dat dit onder de motorkap bij Chrome ook het geval is.

ABP doet niets dat Ublock al doet.

Tip: houd het lekker bij Ublock en kletter ABP weg, de laatste heeft ook een nogal twijfelachtig 'whitelist' business modelletje namelijk. En Ublock is vele malen beter op elk front.

Oeps, ja. Mm, had wel wat meer verwacht van iemand met 2 beveiligingstags (security + beheer & beveiliging) haha.

Zou zeggen, check met maar even. Misschien schakel je over.

Heb ik al vaker nagekeken, maar zie geen enkel voordeel buiten het feit RAM-gebruik.

Een stap in de goede richting! Ik mis alleen wat zaken wat betreft fundament:

• De nieuwste security-patches - dit op reguliere basis. Als bare minimum zou ik een keer per week aanraden, beter om het ietwat vaker te doen.
• Javascript standaard uitschakelen - dit bijvoorbeeld door middel van NoScript (browser extensie). Dit vergt natuurlijk flink wat werk in het begin, de betrouwbare sites dienen gewhitelist te worden.
• Browser hardening - Als je zaken als WebRTC nooit gebruikt, zet die gewoon uit. Een goede guide is bijvoorbeeld bij VikingVPN te vinden.
• Een antimalware oplossing - Ietwat omstreden, dit soort programmatuur 'hookt' in de kernel en bevat zelf ook te misbruiken lekken. Maar, beter dan niets denk ik.
• Least privilege - Werk standaard onder een beperkt account die geen wijzigingen in het systeem kan aanbrengen. Als er iets geinstalleerd dient te worden, gewoon even switchen naar Administrator of een gebruiker in de wheel groep.
• Patch-hulp - Tools als Heimdal houden apps up-to-date, patchen waar mogelijk zelf en geven een alert indien dat geen optie is.
• Sandboxing/browser keuze - Ik weet niet wat de huidige staat van Firefox is, maar pre-Quantum miste het belangrijke security features die Chrom{e,ium} wel had. Haat aan Google? Check Iridium of Ungoogled Chromium eens! Verder kun je een browser ook Sandboxen met bijvoorbeeld Sandboxie. Als je wat verder wilt gaan, draai het in een eigen VM (ala Qubes).
• Rand/netwerkapparatuur - Natuurlijk ook geen onbelangrijke, hou randapparatuur (vooral hetgeen wat verbonden is met een netwerk) up-to-date. Modems, router, IoT-meuk, etc.

Hoe ik het zelf doe (dit gaat veel verder dan rendabel voor de meeste gebruikers):

• Workstation, laptop, NAS en router/firewall draaien alle vier OpenBSD-current met FDE, minimaal een keer per dag update naar nieuwste snapshot en packages. Smartphone draait CopperheadOS - voor nu, maar daar stap ik waarschijnlijk op korte termijn vanaf.
• Mics/cams hardwarematig verwijderd - alleen de camera op telefoon zit er nog steeds, maar met sticker erop. Bellen met headsetje (bedraad, want Bluetooth yikes).
• Hardening toegepast op systemen zelf, op netwerk, etc. Firewall op basis whitelist policy (in en uitgaand), poorten anders dan 80/443 uitgaand zijn whitelisted op IP basis.
• Netwerkverkeer altijd encrypted, ook intern verkeer!
• Browser, Iridium, binnen een VM en niet op OS zelf.
• Netwerk volledig gesegmenteerd, onbetrouwbare apparatuur zoals een mediaspeler in een eigen VLAN die enkel naar buiten kan communiceren (en al het traffic wordt gelogd).
• Enige IoT apparatuur is een smart-TV - smart functionaliteit niet in gebruik en TV niet verbonden met wat dan ook.
• Zo min mogelijk devices/services, alles wat niet strikt noodzakelijk is komt er niet in/verwijderd/disabled.

Update 1: Sandboxie miste
Update 2: Eigen scenario toegevoegd

[Reactie gewijzigd door jurroen op 14 juni 2018 13:03]

Hoe ik het aanpak:

• Java verwijderen (ik weet dat dit iets anders is dan Javascript, maar Java is ook niet bepaald veilig als je het nog amper nodig hebt tegenwoordig)

Je bedoelt de Java Web Plugin.

Door de Java Runtime Environment te verwijderen schiet je jezelf enkel in je voet. Want hierdoor werken geïnstalleerd applicaties die het nodig heeft niet meer.

Tegenwoordig moet je rare fratsen uithalen wil je die Java Web Plugin te activeren. Alle browsers houden het hardnekkig gedeactiveerd.

Inb4 mensen zeggen 'ja maar er wordt gewhitelist bij ABP': Instellingen > Algemeen > 'Acceptabele advertenties toestaan' uitvinken.

En als je uBlock gebruikt hoef je niet in de config te duiken.

Ik gebruik umatrix hiervoor, dan is alles geblokkeerd (ook nieuwe zaken) tenzij gewhitelist.
Na een paar weken is het meeste dat gewhitelist moet worden wel gewhitelist
umatrix is beschikbaar voor chromium en firefox.

Er zijn regelmatig situaties waarbij betrouwbare sites onbetrouwbare advertenties serveren en de infectie via die advertenties bij jou binnenkomt. Dus ga er niet te hard van uit dat enkel vertrouwde sites bezoeken je vrijwaart van het binnenkrijgen van kwaadaardige code.

Maar als je adblock gebruikt dan zou dit geen probleem meer moeten zijn....toch? (sorry, noob in dit soort dingen, heb wel gegoogled wat meltdown en spectre was toen de tijd, maar was mij allemaal wat te ingewikkeld)

Als je advertenties blokkeert dan heb je daar geen last van nee.

Duidelijk, bedankt voor de reactie!

In principe niet. Er van uitgaande dat je adblock een blokkade voor die advertentie provider heeft opgenomen.

Je bedoelde natuurlijk Edge.

Chrome gebruiken helpt op zich wel ja. Net zoals het continue bijhouden van security updates.

Dodgy sites... de vraag daarbij is natuurlijk een beetje hoe een hacker te werk gaat. Denk bijvoorbeeld aan het kopen van ads met javascript, een stukje javascript pushen naar een library, wellicht zelfs proberen het ergens op een bedrijfsintranet te publiceren als het gaat om overheidshackers, etc.

Moet hier niet de toevoeging bij, als je Windows draait, want Linux is sinds kernel 4.9 NIET kwetsbaar volgens het artikel.

Dus Ubuntu 18.04 LTS (4.15), en ook Ubuntu 16,04 LTS HWE (4.13) zijn niet kwetsbaar.

Oude niet gepatchte Windows versies ja, grappig genoeg is het dus een grotere kans om infecteren te raken voor mensen die hebben lopen kloten met hun Windows en dus Tweakers zijn. Jan met de pet heeft die patches al tijden.

De meeste (zo niet alle) van deze lekken zijn in de browser toch op te lossen door de timer nauwkeurigheid te verlagen? Iets wat voor de meeste browsers al is doorgevoerd.

Dat vraag ik me ook af. Stel dat ze van de Steam servers een lijst met ip-adressen verzamelen met de daarbij behorende system specs die ze eens in de zoveel tijd vragen aan gebruikers. Zou je dan relatief makkelijk een grootschalige hack uit kunnen voeren?

Een gebruiker kan:
- "vulnerable" zijn: een kwetsbaarheid die mogelijk gebruikt kan worden.
- "infected" zijn: getroffen door malware die gebruikt maakt van een kwetsbaarheid.

Alle vormen van Spectre en Meltdown zijn kwetsbaarheden. De kwetsbaarheid zit in de CPU, maar een OS of virusscanner kan voorkomen dat de kwetsbaarheid gebruikt wordt.

Er zijn NOG geen virussen of hacking tools die effectief misbruik maken van de kwetsbaarheid.

Door updates van je OS, applicaties en virus scanner te installeren dicht je kwetsbaarheden en voorkom je dat je infected kan raken als er een virus of andere malware verschijnt.

AMD processoren hebben hier dus (nog) geen last van?

Dat ligt eraan of de TS vlag (Task Switched) in het CR0 register wel of niet speculatieve executie blokkeert.

Wat @xorpd hier meldt klopt, inderdaad.
En om je een idee te geven hoe speculative execution bij Intel in zijn werk gaat:
Code die onder speculative execution wordt uitgevoerd bij Intels, controleert niet of geheugentoegang vanuit de cache toegang heeft tot het bevoorrecht kernel geheugen. Het begint met het uitvoeren van de instructies zonder het kernel geheugen te checken, en als het tijd is om vast te leggen of de speculative execution moet worden voortgezet, zal de controle plaatsvinden. Maar tijdens dat venster hebt je de mogelijkheid om een reeks instructies in de cache uit te voeren zonder kernel geheugen controles. Je kunt dus code schrijven met de juiste reeks vertakkingsinstructies om branchevoorspelling te laten werken zoals jij dat wilt, en dan kun je dat gebruiken om geheugen te lezen dat je niet zou moeten kunnen lezen. En nu is het zo dat bij CPU's van andere merken, ook "gewoon" speculative executions aanwezig is, alleen wordt het van merk op merk op verschillende manieren geïmplementeerd in de CPU.

Edit: Typo

[Reactie gewijzigd door SSDtje op 14 juni 2018 14:51]

Moest er even voor zitten, maar thanks voor de uitleg!

No probe, happy toch help.

Ik ben een beetje zoekende naar hoe erg dit nou eigenlijk is.

- Linux is niet vulnerable omdat ze de eager FP state restore gebruiken. Zie https://news.ycombinator.com/item?id=17304947 .
- Windows is niet vulnerable volgens @Luminai : https://www.theregister.c..._fpu_state_security_flaw/ .

Hij noemt het voorbeeld van encryptiesleutels.

Het gaat hier alleen maar om de (80-bit) FP registers die worden opgeslagen in xsave / xrestore. Moderne compilers gebruiken vanaf SSE2 de (2x 64-bit) XMM registers om FP in op te slaan en FP mee te berekenen. "Encryptie sleutels uitlezen" lijkt me dus vrij sterk...

Ik wil ook wel het voorbeeld noemen dat iemand anders dan naar je naaktfoto's kan kijken als je die toevallig aan het bewerken bent, maar dat slaat ook niet echt ergens op...

De floating-point state bevat architectureel ook de XMM state (fxsave/fxrstor).

Jawel, xsave/xrestore ook, maar de vraag is wat er precies lazy wordt weggeschreven. Wat ik er zo snel van las gaat het echt om de FP registers hier - maar als ik inderdaad alle XMM registers affected zijn dan zie ik het probleem wel ja...

-edit-

Ah gevonden, het staat in de Intel architecture vol 3 uitgelegd. HTML'ish versie: https://xem.github.io/min...fe12b1e2a880e0ce-461.html .

The TS flag in control register CR0 is provided to allow the operating system to delay saving/restoring the x87 FPU and SSE state until an instruction that actually accesses this state is encountered in a new task. When the TS flag is set, the processor monitors the instruction stream for x87 FPU, MMX, SSE instructions.

Kortom, SSE is ook affected. Ja, dat is wel een probleem, bijv. aangezien AES-NI ook via die registers werkt.

Het Intel document geeft overigens ook aan dat lazy restore eigenlijk praktisch nooit zinnig is.

[Reactie gewijzigd door atlaste op 14 juni 2018 14:57]

lazy restore is alleen van belang als er een minderheid aan taken de betreffende registers gebruikt.
Dus de DURE context switch van de FPU kon af en toe overgeslagen worden, kans was zeer groot dat er maar een proces met FP registers bezig was.
Met de kost van SSE etc. worden deze registers veel vaker gebruikt dus uitstel is letterlijk alleen maar uitstel en levert een extra complicatie in context switch code op, zeker bij multicore's als een een taak naar een andere CPU moet, eerst nog even de wachten op de FP data.

Dus het had z'n waarde in het 80386 en 80468 tijdperk. Zeker met de komst van multi core systemen was dat een stuk minder nuttig en eerder een complicatie.

Volgens mij is het allemaal onzin. Je moet hoe dan ook eerst geinfecteerd worden en dan is een screengrabber,keylogger,file uploader veel makkelijker en er zijn jaarlijks nog steeds miljoenen mensen die daar in trappen.
Dus ik maak me nul zorgen omdat ik goed oplet wat ik install en waar ik op klik dus ondanks dat mijn pc sinds april 2012 niet geupdate is heb ik nog nergens last van gehad dat niet mijn schuld was (uit nieuwsgierigheid getest na backup). Ik ken echter mensen die strikt iedere week updaten en het allerlaatste van alle beveiliging hebben en iedere maand weer de lul zijn. Zelfs mn oma van 78 heeft na een paar tips zonder enige firewall of beveiliging in 6 jaar dat ze nu de pc heeft nergens last van.
Verifieer de link en hou je statusbalk in de gaten. De veiligsye manier om op internet te browsen zelfs met uac uit.

Ik denk dat dat wat te kort door de bocht is. Je hebt immers ook een hoop servers op deze wereld die shared hosting en VM's enzo aanbieden.

Ja buisness is altijd een ander verhaal maar voor de huis tuin en keuken gebruiker is het gevaar van deze lekken echt nihil.
Die moeten zich eerder zorgen maken om waar ze wel of niet op klikken online.

Naja, heb je er eentje (Spectre/Meltdown) is het waarschijnlijk voortborduren op hetzelfde type lek/kenmerken.

Dit zal vast niet het laatste lek zijn in de Core CPU's....

Ik kan me voorstellen dat er partijen zijn die bij een datacentrum inbreken, en op deze manier data kunnen stelen.

Best veel 'Mission: Impossible' of sci-fi mogelijkheden dan je zult kunnen bedenken.

Of ergens een VPS huren en uitbreken. Zo spannend hoeft het niet te wezen.

Echt deprimerend om te horen hoeveel fouten er in de speculative execution van processoren zitten. Er is bij de ontwikkeling ervan totaal niet nagedacht over de veiligheid.

Het is vooral beangstigend dat men via het internet je encryptie sleutels kan uitlezen.

[Reactie gewijzigd door ArtGod op 16 juni 2018 07:29]

Goed dat Intel nu zelf met deze info naar buiten komt, in plaats van dat het door derden wordt bekend gemaakt
Oh het is toch een reactie op een eerdere lek...

[Reactie gewijzigd door 12_0_13 op 14 juni 2018 11:08]

Had Intel al deze lekken kunnen weten en voorkomen?

Daar gaan we weer... Laten we eens kijken wat mogelijk het probleem is, gebaseerd op achtergrondkennis. Ik ben niet zo super bekend met de details van de x86 architectuur en de FP/MMX/SSE/etc details, maar het is denk ik vrij duidelijk wat er aan de hand is;

Wanneer een besturingssysteem een context-switch doet, moet het alle registers van het ene proces wegschrijven naar geheugen, en de eerder bewaarde register waarden van het volgende proces inladen. Aangezien er vrij veel extra FP/MMX/SSE/etc registers zijn, is dit een vrij kostbare operatie. Een algemeen bekende optimalisatie (niet x86 specifiek) is wanneer je schakelt tussen processen die helemaal geen FP/MMX/SSE/etc instructies gebruiken, dat je het wegschrijven/laden van deze registers achterwege laat. Zo te zien ondersteund x86's XSAVE instructie precies dit, waar je slechts een deel kan wegschrijven. Om te garanderen dat een proces deze registers niet probeert te gebruiken, schakel je de FP unit en dergelijke uit in een control register; zoals in CR0 in x86. Wanneer je dan een instructie executeert die wel een van deze registers gebruikt, dan krijg je een Device not Available exception; het besturingssysteem zal in de exception handler dan de FP/MMX/SSE/etc registers alsnog inladen (of het proces markeren zodat het weet dat de volgende context switch de registers gewisseld moeten worden), en dan de instructie opnieuw uitvoeren, die dan wel slaagt.

Maar hoe is dit dan een probleem?
Wederom, speculatieve executie. Het probleem is erg vergelijkbaar met Meltdown; je kan speculatief een instructie uitvoeren die een exception zal gooien, maar pas wanneer deze instructie gegarandeerd niet meer speculatief is. Ondertussen kan je wel speculatieve effecten meten. Het probleem scenario zal ongeveer als volgt gaan:

- Proces A is bezig met encryptie data te verzenden, en gebruikt hiervoor Intel's AES instructies, en die gebruiken de SSE registers. Wellicht heeft het gevoelige informatie, of (deel van) de encryptie sleutel geladen in de SSE registers
- Proces B gebruikt geen FP/MMX/SSE/etc registers en is onder controle van de aanvaller
- Een context switch van Proces A > Proces B vindt plaats, de FP/MMX/SSE/etc registers blijven onaangeraakt en het besturingssysteem update CR0 zodat een FP/MMX/SSE instructie een 'Device not available' exceptie zal genereren
- Proces B voert speculatief operaties uit op de FP/MMX/SSE registers (bijvoorbeeld achter een verkeerd voorspelde branch), op een zoals van Spectre/Meltdown bekende manier om de waarde zichtbaar te maken door de staat van de caches te beinvloeden.
- Proces B meet de staat van de caches, en achterhaalt informatie over de encryptie van proces A

Aangezien de "Device not available" exceptie alleen op architectureel non-speculatief uitgevoerde instructies zal afgaan, zal het besturingssysteem nooit de FP/MMX/SSE registers van Proces A wissen en vervangen door de waarden die Proces B mag zien (waarschijnlijk initialisatie op 0). Omdat het speculatief gebeurt, kan Proces B (een deel van) de waarden achterhalen die Proces A in die registers had staan. Het is dus wel gelimiteerd tot die waarden, maar aangezien dat dus ook encryptie informatie kan lekken, is dit wel een probleem.

Wat is de oplossing?
Vrij simpel; elk besturingssysteem moet niet meer de eerder genoemde optimalisatie gebruiken, of de registers wissen op een context-switch. Ik verwacht niet dat dit iets is wat makkelijk in hardware op te lossen zal zijn. Een algemenere oplossing voor dergelijke problemen (en ook Meltdown) zou zijn om exceptions vroeg te detecteren en instructies die een exceptie krijgen nooit een speculatieve waarde (of altijd 0) te laten doorgeven als hun resultaat.