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

Door Sander van Voorst

Nieuwsredacteur

Meltdown en Spectre - Q&A

Gegevens uitlezen door cpu-lekken

04-01-2018 • 17:10

167 Linkedin Google+

De belangrijkste vragen

Schreven we eind vorig jaar nog over het nut van branded vulnerabilities, beginnen we dit jaar meteen goed met twee nieuwe varianten met een eigen logo en website. Onderzoekers hebben details over de zogenaamde Meltdown- en Spectre-kwetsbaarheden gepubliceerd, die zich in het geval van het tweede lek voordoen bij moderne processors van Intel, ARM en AMD. De kwetsbaarheden maken het mogelijk om geheugen uit te lezen van de kernel en van andere processen, iets dat eigenlijk niet zou moeten kunnen door geheugenisolatie. Omdat dit wel blijkt te kunnen, behoort toegang tot gevoelige gegevens zoals wachtwoorden en privésleutels tot de mogelijkheden. In dit artikel gaan we kort in op de belangrijkste vragen rond de gepubliceerde lekken. Tweakers sprak daarnaast met Herbert Bos, die hoogleraar Systems and Network Security aan de VU Amsterdam is en aan het hoofd staat van de VUSec-onderzoeksgroep.

Waar hebben de kwetsbaarheden mee te maken?

Volgens Bos hebben alle kwetsbaarheden te maken met een techniek die bekendstaat als out-of-order execution: het berekenen van een resultaat voor het eigenlijk nodig is. Een goed voorbeeld hiervan is 
speculative execution, een truc die tot prestatiewinst moet leiden bij het uitvoeren van programma's. Bos legt speculative execution uit met behulp van een voorbeeld. Stel dat een programma de volgende instructies bevat: "Als een waarde in het geheugen, die geheim is en niet zichtbaar behalve voor de kernel, gelijk is aan een waarde n, laad dan uit het geheugen de waarde van het n-de element uit een tabel." Vervolgens legt hij uit hoe de processor hier speculatief aan gaat rekenen en hoe dit tot het lekken van informatie kan leiden.

"Wat een moderne cpu doet om dit sneller te maken, is alvast de waarde uit het n-de element van de tabel te laden, terwijl hij nog aan het bepalen is of de eerste waarde in het geheugen eigenlijk wel gelijk was aan n.  Als dat inderdaad zo was, dan heeft hij meteen de juiste waarde te pakken en dat scheelt tijd. Als dat niet zo was, dan heeft hij die waarde voor niks geladen. Maar dat geeft niet, want de cpu gooit die waarde dan gewoon weer weg. We noemen het laden van die waarde een 'speculatieve' operatie.  Er is niks aan de hand, tenzij een aanvaller op een of andere manier kan zien welke waarde speculatief werd geladen."

Dat laatste blijkt nu juist het probleem te zijn, vervolgt Bos. "Een slimme (Meltdown-)aanvaller kan zien welk element in de tabel werd geactiveerd. Dit heeft te maken met de manier waarop moderne processoren data die ze net gebruikt hebben tijdelijk in de cache zetten, zodat ze daar in de toekomst heel snel toegang toe hebben. Helaas is juist die extra snelheid een 'side channel' om informatie te lekken voor aanvallers. Door zelf te kijken of element n in de cache zit, bijvoorbeeld door te kijken of toegang tot deze data sneller gaat dan gebruikelijk, weten zij of het programma de waarde n had berekend. Op die manier lekt dus informatie uit het meest beveiligde deel van de kernel."

Wat zijn de verschillen tussen Meltdown en Spectre?

Zoals in het voorgaande nieuwsbericht al is beschreven, laat Meltdown het uitlezen van kernelgeheugen toe, terwijl Spectre dat toelaat voor processen onderling. De onderlinge verschillen worden ook nog eens duidelijk gemaakt door een afbeelding die het werk is van beveiligingsexpert Daniel Miessler. Het patchen van Meltdown is volgens de ontdekkers mogelijk, terwijl het voor Spectre moeilijker is om een omvattende oplossing te bieden en systemen te beveiligen. De onderzoekers stellen dat een oplossing in veel gevallen gezocht moet worden in aanpassingen van processorontwerpen en updates voor isa's. In het Meltdown-paper schrijven de onderzoekers dat ondanks tegenmaatregelen een attack surface overblijft. Zo blijft het mogelijk om pointers te lekken, die gebruikt kunnen worden om de kaslr-beschermingsmaatregel voor kernelgeheugen te omzeilen. De zogenaamde Kaiser-patches zouden echter de beste tegenmaatregel zijn.

Afbeelding via Daniel Miessler

Wie is getroffen? 

Uit het gepubliceerde onderzoek blijkt dat Meltdown zich hoofdzakelijk beperkt tot Intel-cpu's. Een proof-of-concept van Project Zero werkte op een Xeon-cpu van de Haswell-generatie en ook in het Meltdown-paper schrijven de onderzoekers dat ze hun aanval niet werkend konden krijgen op ARM- of AMD-processors. Ze stellen wel dat er een kans bestaat dat een geoptimaliseerde versie van hun techniek alsnog succes kan hebben op deze architecturen. Veel Intel-processors zijn kwetsbaar, volgens onderzoekers gaan getroffen cpu's terug tot 1995.

Spectre werkt zowel op Intel-processors als op die van AMD en ARM. Er zijn verschillende varianten van Spectre, gekenmerkt door CVE-2017-5753 en CVE-2017-5715. Respectievelijk duidt Project Zero deze aan als bounds check bypass en branch target injection. De eerste variant testten de onderzoekers met succes op cpu's van alle drie de fabrikanten. Maar die variant werkt alleen op een AMD Pro-cpu als eBPF om de een of andere reden is ingeschakeld. Dit staat standaard uit. AMD heeft in een eigen bericht geschreven niet of nauwelijks vatbaar te zijn voor de CVE's eindigend op 5754 en 5715, die toebehoren aan Meltdown en een van de Spectre-kwetsbaarheden. Over CVE-2017-5753 zegt AMD alleen dat dit verholpen kan worden met patches.

Inschatting door AMD zelf, waarbij met variant 3 Meltdown wordt bedoeld

Ook ARM heeft een overzicht gepubliceerd. Daaruit is op te maken dat alleen de Cortex-A75 vatbaar is voor Meltdown en Spectre, andere in het overzicht genoemde processors zijn alleen kwetsbaar voor de laatstgenoemde aanval. Er staan nog wel drie exemplaren tussen, de A15, A57 en A72, die vatbaar zijn voor alleen een Meltdown-variant. Die behoeft volgens ARM echter geen patch.

Diensten als AWS hebben inmiddels maatregelen genomen. Hetzelfde geldt voor Google, dat een overzicht heeft gepubliceerd van getroffen diensten. Daarin is ook Android opgenomen, waarvoor deze maand patches zijn uitgekomen. Mozilla heeft eveneens een advisory gepubliceerd, waarin het schrijft dat uit interne experimenten blijkt dat een aanval via webcontent mogelijk is. Daarom heeft het eerste maatregelen genomen in Firefox 57. Chrome ontvangt tegenmaatregelen in versie 64, die op 23 januari moet uitkomen. In de tussentijd kunnen gebruikers site isolation inschakelen.

Wat is het risico? 

Het risico van Spectre voor gewone gebruikers is volgens Bos moeilijk in te schatten, omdat de aanval moeilijk uit te voeren is. Meltdown is makkelijker te gebruiken, maar daarvan bestaat er weer geen implementatie in Javascript. Het lijkt hem echter 'triviaal' om een dergelijke implementatie te ontwikkelen. Hij vervolgt: "Het probleem is sowieso dat dit soort kwetsbaarheden alleen maar erger worden. Meer en meer mensen gaan ernaar kijken en ontdekken dan nieuwe manieren om ze te misbruiken. Ondanks dat we deze kwetsbaarheden nog niet door criminelen misbruikt hebben zien worden, denk ik dat het een ernstig risico is."

Ook op de lange termijn kunnen de kwetsbaarheden effect hebben. "Dit soort aanvallen lijken de nieuwe frontlinie van computerbeveiliging. Waren zulke aanvallen tot voor kort nog te scharen onder science fiction, zien we nu elke paar maanden een nieuwe aanval in deze categorie. Het gevolg is dat besturingssystemen nu beduidend anders worden van structuur, dat veel van de aannames die we deden over de veiligheid van hardware opnieuw onderzocht worden en dat, specifiek voor deze kwetsbaarheden, computers significant langzamer worden."

Bos omschrijft de kwetsbaarheden als ernstig en stelt: "Zeker op computers waar code draait van meerdere gebruikers kan gevoelige informatie worden gelekt. Dit geldt bijvoorbeeld voor cloudomgevingen waar programma's van verschillende organisaties dezelfde fysieke hardware gebruiken, maar ook voor zoiets alledaags als een webbrowser, waarin voortdurend Javascript-code van websites wordt uitgevoerd."

Zijn er patches voor besturingssystemen?

Vooropstaat dat Meltdown patchbaar lijkt te zijn, terwijl dit voor Spectre moeilijker is. Verschillende fabrikanten hebben inmiddels patches gepubliceerd. Zo heeft Microsoft deze inmiddels beschikbaar gesteld voor Windows 10. Daarbij speelt de aanwezige antivirussoftware een rol, omdat sommige versies van av-suites niet compatibel zijn met de patches en het systeem deze daarom niet ontvangt. Beveiligingsexpert Kevin Beaumont werkt aan een overzicht waarin hij bijhoudt welke informatie door beveiligingsbedrijven naar buiten is gebracht. In de Linux-kernel zijn de patches in versie 4.15 vrijgekomen met backports naar versie 4.14.10. Ontwikkelaars voor de Linux-kernel werkten al een tijd aan zogenoemde Kaiser-patches. Die zijn begin december omgedoopt tot x86/kpti-patches, waarbij kpti staat voor kernel page table isolation. Volgens The Register is macOS gepatcht vanaf versie 10.13.2.

Draait mijn systeem trager door de patches? 

Onder meer Phoronix, Hardware Unboxed en Computerbase publiceerden benchmarks na het toepassen van de nodige patches. De tests van Phoronix betroffen Linux en wezen op aanzienlijke prestatievermindering bij toepassingen als FS-Mark-, Compile Bench- en PostgreSQL. Hardware Unboxed ondervond bij i/o-benchmarks op Windows nagenoeg alleen een noemenswaardige prestatievermindering bij 4k reads en acces time reads. Bij gaming zou er bij zowel Windows als Linux geen verschil in prestaties optreden. Vooral het uitvoeren van syscalls zou trager verlopen. Volgens Microsoft gaat 'de meerderheid' van de Azure-klanten geen prestatieverschil merken. Een kleine groep klanten zou lagere netwerkprestaties kunnen ervaren, maar dit zou op te lossen zijn door Azure Accelerated Networking te activeren.

Bos stelt dat er percentages tot 30 procent prestatievermindering worden genoemd, maar dat hijzelf niet gelooft dat het zo hoog zal uitvallen. "Ik geloof zelf niet dat het 30 procent zal zijn, maar zelfs 5 procent vertraging van vrijwel alle computers ter wereld levert een grote schade op. Daarnaast worden er wel veel patches voorgesteld, maar lossen de huidige patches het echte probleem niet op. Ze houden dan enkele varianten van de aanval tegen, maar het probleem blijft. Vooral de Spectre kwetsbaarheid blijft problematisch", aldus Bos.

Wie ontdekten de kwetsbaarheden? 

Bij de ontdekking van zowel Spectre als Meltdown was Jann Horn van Googles Project Zero betrokken. In de blogpost van het project is genoemd dat Intel, AMD en ARM op 1 juni van vorig jaar op de hoogte zijn gesteld. Voor Meltdown geldt dat deze kwetsbaarheid daarnaast door Werner Haas en Thomas Prescher van Cyberus is ontdekt, naast een team van de Technische Universiteit van Graz. Spectre werd naast Horn door Paul Kocher in samenwerking met verschillende onderzoekers ontdekt.

Reacties (167)

Wijzig sortering
Allemaal overstappen op de Raspberry Pi, want die is niet vatbaar voor deze bugs.

Volgens ARM.

;)

[Reactie gewijzigd door Jan121 op 4 januari 2018 17:29]

Dat komt omdat alleen ARMv8 vatbaar is. (Sinds ARMv8 ondersteunt ARM 64 bits instructies, geen idee of het daarmee te maken heeft)
Dat komt omdat alleen ARMv8 vatbaar is. (Sinds ARMv8 ondersteunt ARM 64 bits instructies, geen idee of het daarmee te maken heeft)
Nee die uitspraak klopt niet, je moet hier de architectuur specificatie (ARMv8, ARMv7, IA32 etc) en de micro-architectuur implementatie (die wel/niet vatbaar is voor Spectre/Meltdown) niet door elkaar halen. Voor meer gedetailleerde uitleg hierover zie: Squee in 'nieuws: Onderzoekers openbaren details van lekken in moderne cpu's ...
Hier staan alleen de ARM processors beschreven die 'affected' zijn: https://developer.arm.com/support/security-update

De ARM's die in de Pi 1/2/3 worden gebruikt staan er niet tussen, te weten: Pi1 - ARM11, Pi2: Cortex-A7, Pi3: Cortex-A53. :)
Intel Atom is veilig. Dus beter kun je daar op overstappen want is krachtiger :D
Is Atom tegenwoordig niet een uitgeklede variant op de Core-microarchitectuur? Dan zullen die vatbaar zijn.

/edit
Oh en hier lees ik dat niet alleen Core vatbaar is :/
https://www.bleepingcompu...ltdown-and-spectre-flaws/

[Reactie gewijzigd door _Thanatos_ op 4 januari 2018 22:18]

Alleen de oudste Atoms zijn het niet, vanaf de Silvermont microarchitectuur is ook de Atom een out-of-order processor.

[Reactie gewijzigd door AlbertJP op 5 januari 2018 17:32]

IK begrijp nog steeds niet helemaal goed welke impact deze kwetsbaarheden nou zouden kunnen hebben op een gewone thuis- of kantoorgebruiker in lekentaal. Het gaat de hele tijd over "een andere user", wat mij relevant lijkt te zijn voor webhosts, niet voor gewone gebruikers. Maar kan b.v. een website ook mijn wachtwoord voor een andere website uitlezen, is dat hoe het kan gaan? Of toch niet?
Mainframe anyone? :P maar gaat Intel geseud worden met zoiets als dit ? Terug naar 1995 is wel ernstig.
He feit dat ze rechten van andere gebruikers kunnen omzeilen betekent ook dat ze ook toegang hebben tot alle processen die je zelf draait. Heel leuk als je bijvoorbeeld een paswoord manager draait en ze hiermee al je paswoorden kunnen ontfutselen.
Vooral het feit dat het zelf met Javascript (en dus een webpagina) kan vind ik het meest verontrustend.
Koop over een paar weken, maanden tijdens de grote dip maar aandelen van chipbakkers. Er zullen veel PC’s, telefoons,... en dergelijke moeten vervangen worden. Reken maar op een recordverkoop.
OK dan had ik het goed begrepen. Gelukkig hebben browsers hiervoor inmiddels als beveiliging ingebouwd (Chrome 64 heeft het eind januari, de nieuwste Firefox 57-nogwat heeft het al, en het komt eind januari naar Firefox 52 extended release).
IK begrijp nog steeds niet helemaal goed welke impact deze kwetsbaarheden nou zouden kunnen hebben op een gewone thuis- of kantoorgebruiker in lekentaal. Het gaat de hele tijd over "een andere user", wat mij relevant lijkt te zijn voor webhosts, niet voor gewone gebruikers. Maar kan b.v. een website ook mijn wachtwoord voor een andere website uitlezen, is dat hoe het kan gaan? Of toch niet?
In de Meltdown paper staat dat ze bijvoorbeeld de password manager van Firefox wisten uit te lezen en zo de opgeslagen wachtwoorden zichtbaar konden maken. Nu heb ik op dit moment nog geen versie van Meltdown gezien die vanuit JavaScript werkt, maar het zal me niet verbazen als die er komt. Nu dit onder meer aandacht gekomen is zullen er ook mensen met minder goeie bedoelingen naar gaan kijken, en met genoeg kennis en mankracht kan je hier wellicht een zeer succesvolle aanval mee opzetten.

Ik hou een beetje een slag om de arm, maar het is best goed denkbaar dat op een gegeven moment een website je wachtwoorden voor een andere website zou kunnen uitlezen, zoals je vroeg, mits er niet genoeg voorzorgsmaatregelen getroffen worden.
Het is inderdaad onrustbarend, had ik het goed begrepen. Gelukkig zijn browsers dit al aan het beveiligen nu, zie boven.
IK begrijp nog steeds niet helemaal goed welke impact deze kwetsbaarheden nou zouden kunnen hebben op een gewone thuis- of kantoorgebruiker in lekentaal.
Spectre: Een website (javascript) kan bijv. alle wachtwoorden e.d. van alle websites, die de browser intern opgeslagen heeft uitlezen. Normaal kan javascript daar niet bij, maar met spectre is er een manier gevonden waardoor die informatie indirekt toch toegankelijk wordt. Er wordt gezegd dat de website ook gegevens in andere applicaties uit kan lezen, maar mij is nog niet helemaal duidelijk hoe dat dan werkt (de adresruimten van verschillende processen zijn zover ik weet volledig van elkaar gescheiden).

Meltdown: Een website, of een malafide app, of een virus, kan ongeveer alles wat in het geheugen staat uitlezen. Bijv. de enryptie-sleutel van jouw harddisk, het wachtwoord in jouw mail client, de key van jouw WiFi verbinding etc. etc.etc. Dit geldt alleen voor 64-bit applicaties; zover ik het begrijp is door een 32-bit applicatie veel minder uit te lezen, maar nog steeds wel de hele inhoud van de kernel. Dus wel de encryptie-sleutel van jouw harddisk (die zit in de kernel), maar niet jouw mail-wachtwoord (want die zit niet in de kernel, maar in een andere applicatie). De gegevens uit de kernel waar een 32-bit applicatie wel bij kan, zijn overigens waarschijnlijk al voldoende om op een andere manier alsnog bij de gegevens in andere processen te komen.

Spectre is dus al best wel vervelend, maar meltdown is een regelrechte ramp. Daarom worden er dus ook allerijl patches uitgebracht voor Meltdown...
Volgens mij is het ernstigste probleem op het moment de risicos in de cloud, waar meerdere clients in userspace van de processor zitten. M.A.W. het risico dat Cloudgebruiker A m.b.v. een tool informatie kan lezen uit de Cache van gebruiker B.

Voorwaarde is dat je op de proc van het target code kan executen, dus voor de huis tuin en keuken PC moet je wel zelf het kwaadaardige tool binnenhalen. Minen kan zo risicovol worden bijvoorbeeld.

Correct me if i'm wrong, ik ben zeker geen expert.
OK goed om te weten dat een 32-bits-applicatie veel minder kan uitlezen (ik zit namelijk op 32 bits...). Maar nog steeds te veel.
Ik vraag mij eigenlijk dit af, ik lees dat Intel met een firmware patch komt voor hun CPU's, maar nergens kan ik vinden hoe je dat op je PC toepast.

Of komt dat via Windows update binnen? (betwijfel ik)
Met andere woorden is dat daarin verwerkt.

Bedankt voor de verduidelijking :)
Voor Windows 7 is het KB4056897.

Voor Windows 8.1 is het KB4056898.

Een PowerShell tooltje `Get-SpeculationControlSettings` van Microsoft om the checken of je alle BIOS/Windows patches hebt: https://www.bleepingcompu...wn-and-spectre-cpu-flaws/

[Reactie gewijzigd door Henk Poley op 6 januari 2018 10:12]

Bedankt voor de info :) Ik zelf heb hier 3 x W10 Pro
Ik heb ook een link naar uitleg over een test tooltje `Get-SpeculationControlSettings` van Microsoft toegevoegd. Die vertelt of je alle mogelijke patches operationeel hebt.

[Reactie gewijzigd door Henk Poley op 6 januari 2018 10:12]

Die had ik reeds uitgevoerd :) maar bedankt in ieder geval.
Voor Meltdown heb je voldoende met de patch voor Windows.
Voor Spectre heb je echter naast de Windows patch ook een firmware update nodig

Je kan het testen met PowerShell:
Install-Module SpeculationControl
Get-SpeculationControlSettings

zie ook
https://www.bleepingcompu...wn-and-spectre-cpu-flaws/
Kan het zijn dat deze 'firmware update' ook via Windows' processor microcode update kan binnen komen? En dus iedere keer bij de start van Windows wordt ingeladen door een driver. Helaas lijkt Intel slechts microcode updates voor 'ondersteunde' processors uit te geven, die van de laatste 5 jaar.

[Reactie gewijzigd door Henk Poley op 6 januari 2018 10:15]

Is dit alles een reëel risico voor de "gewone" PC gebruiker of is het gewoon een storm in een glas water?
De proof of concept draait op Javascript. Dus in theorie kan het vanaf een gewone webpagina toegepast worden.
Storm in een glas water absoluut. Immers beide kwestbaarheden zijn alleen bruikbaar als men uitvoer rechten heeft op een systeem.. Dus je moet eerst malware op je systeem draaien maar dan heb je toch al malware en is toch al niks op je systeem meer veilig.

Bovendien 99% van de gebruikers draait al met admin rechten en doet weinig met VM's... vooral voor cloud providers is dit mogelijk een issue... maar als thuis gebruiker NEXT..
Recht hebben om code uit te voeren is echt niet moeilijk. Zoals aangegeven in het artikel is er een POC voor Meltdown geschreven met behulp van javascript. Je zet dat script op een site, je browser voert de code uit, kwetsbaarheid misbruikt. Met een beetje geluk kan je met de gevonden data je eigen rechten weer verhogen en voor je het weet heb je malware te pakken die heel je systeem om zeep kan helpen.

En de admin rechten die je vandaag nog in Windows hebt geven je helemaal niet veel rechten. Ze voorkomen alleen dat je je wachtwoord moet ingeven op de UAC prompt (als je niet zo dom bent om die uit te schakelen).
Maar Javascript is normaal gesproken zwaar beperkt in wat het op een gebruikers systeem kan uitvoeren, betekent dat dan niet dat er tevens OOK een javascript "sandbox" exploit nodig is om de andere exploit mogelijk te maken?
De bug zit direct in de CPU en daardoor is hij door alles wat indirect op de CPU draait in staat deze lekken te misbruiken. Vanuit javascript is dat wat lastiger, omdat je minder direct controle hebt over hoe je code wordt uitgevoerd, maar blijkbaar is het mogelijk.
https://noscript.net/

Blokkeert standaard de javascript op een pagina. Handmatig de javascript toelaten per domein is irritant maar maakt wel dat je 100% controle hebt over welke script er draaien in je browser. Ook meteen alle crypto-miner-scripts buiten de deur gehouden. Aanrader!
Toevallig al een oplossing voor global pollutants (delegated riscs)?

Cloudflare bijvoorbeeld draagt arbitrair meuk bij aan verschillende websites; wat nu als ik specifiek de meuk op één website wčl wil toestaan en op de rest niet? Ik heb de oplossing nog niet gevonden in NoScript ;(

Wčl leuke manier dit voor site owners om de eigen verantwoordelijkheid weer te maskeren door te serveren via nňg meer derden ;( ;(
Dat soort dingen kun je doen met Umatrix. Per domein kun je dan beslissen van welk ander domein het welke soorten bestanden mag binnenhalen. Zelf gebruik ik Request Policy, dat net zo werkt, maar waarschijnlijk is Umatrix beter. Met Request Policy sta ik per domein ook alleen een bepaald subdomein van Cloudflare toe (dat moet je dus wel voor elke nieuwe website toestaan, best veel geklik).
@BStorm: Het kan ook met Ublock Origin als je "ervaren gebruiker" aanzet, dan kan je bij "verbonden domeinen" de boel tweaken.
"Scripts van derden" globaal blokkeren, scripthosts zoals jquery.com kan je eventueel nog globaal toestaan, voor de rest kan je per site bepaalde script-domeinen toestaan (alibaba mag wel van alicdn laden bijv.)

Eerst had ik daarnaast ook NoScript/RequestPolicy/Umatrix, maar sinds ik een "ervaren" Ublock gebruiker pretendeer te zijn, weegt de extra fijnmazigheid daarvan, voor mij niet meer op tegen het tunen van 3-4 addons en 10x reloaden, alleen om een random pagina even snel te kunnen bekijken. Maar goed voor elk wat wils :)
Right! Met Ublock kan het in principe ook (zelfde maker als Umatrix). Maar ik meen dat het met Umatrix veel handiger werkt?
Umatrix kon alleen maar blokkeren adhv hostnaam, dat was te grof om reclame netjes te blokkeren zonder collateral damage. Dus had ik daarnaast sowieso Ublock nodig, om te blokkeren adhv pad en css e.d. (dus binnen 1 hostnaam).

Twee van die geavanceerde blockers gebruiken (naast https-everywhere e.a.) werd mij echter te onoverzichtelijk. Dan is iets bijv geblokkeerd door Umatrix maar toegestaan door Ublock (zonder dat ik t weet, ik zie een lege site bijv).
Ok eerst ns kijken in Umatrix... hmm, lijkt in orde, dan moet het wel Ublock zijn... hmm, lijkt ook in orde. Of hoe staat die ene host nou precies in Umatrix? Nog n keer kijken dan... Ah ok, dat zag ik net niet, klik. Dan nu weer terug naar Ublock om de test-toestemmingen weer terug te zetten. Zo, kan ik na 8 reloads eindelijk dit ene google-resultaat bekijken dat waarschijnlijk toch niet is wat ik zoek.
Dus, daarom was alles in Ublock voor mij het makkelijkst.

Wat ik zei, met Umatrix kan je wel preciezer aangeven wat ie mag doen (behalve dus op content binnen 1 host filteren, wat alleen Ublock kan), dus met de combi kan je het vast wel veiliger maken.
Maar ik ben hier gewoon tevreden over en heb geen behoefte aan extra controle. Ipv (gevoelsmatig) 90% veiliger ben ik mss 85% veiliger, in ruil voor een relatief enorme aandacht-/tijdsbesparing.

Als je geen behoefte hebt aan een echte adblocker ernaast, is voor dit doel Umatrix alleen mss beter/handiger, dan Ublock alleen, maar dat ga ik niet uitproberen :)
Het is wel al lang (1-2 jaar?) geleden dat ik Umatrix gebruikte, dus weet niet meer hoe het precies werkte, of mss is het inmiddels wel een goeie totaaloplossing geworden.
Je hebt zeker gelijk dat meerdere blokkers tegelijk extra gedoe is qua analyseren van problemen. Zelf gebruik ik Ublock, Noscript en Request Policy. Soms best gedoe. Maar ik vind het fijn om met een whitelist te werken voor alle externe inhoud, wat wel werkbaar is met Request Policy / Umatrix. Met Ublock is dat denk ik niet werkbaar, toch?

Verder hoop ik de volledige Javascript-blok-functionaliteit van Noscript te kunnen vervangen door die van Umatrix, wanneer ik overga. Als het goed is moet dat Umatrix wat dat betreft hetzelfde kunnen? En dan vervang ik uiteraard ook Request Policy door Umatrix. Dan ga ik van 3 naar 2 blokkers.

[Reactie gewijzigd door Cerberus_tm op 5 januari 2018 07:42]

Zie hier hier. Met Ublock kan je complete categorieen externe inhoud, of losse hosts, globaal (linker kolom), of alleen voor de huidige site (rechter kolom) toestaan/blokkeren.
(Zonder "ervaren gebruiker" heb je maar 1 kolom, ik weet even niet wat die precies doet).
Dus in die zin kan je bepaalde dingen wel whitelisten, ik noemde eerder al dat ik alle 3rd party scripts blokkeer, maar o.a. jquery whitelist voor alle sites.
(Rechtstreeks in de instellingen, kan je evt nog wat preciezer regels zetten dan 1 klik in zo'n kolom, om bijv wel scripts maar geen iframes toe te staan).
Maar als je bedoelt dat je abonneert op een door anderen onderhouden whitelist met updates, dat kan geloof ik niet (behalve natuurlijk de "gewone" adblock lijsten als Easylist etc).
Dat ik Umatrix/NoScript/RP gebruikte is al n tijd geleden, daarom kan ik er niet veel meer over zeggen (vergeten). Al had NoScript wel wat leuke script beveiligingen, tegen clickjacking etc.

[Reactie gewijzigd door N8w8 op 5 januari 2018 09:06]

Hmm ik geloof dat ik nog steeds niet helemaal begrijp wat Umatrix in dezen dan niet kan. De dingen die ik zie in het menu van Ublock lijk ik ook in Umatrix te zien:
http://s20.postimg.org/te...problem_w_marketwatch.png

Uit je eerdere bericht:
met Umatrix kan je wel preciezer aangeven wat ie mag doen (behalve dus op content binnen 1 host filteren, wat alleen Ublock kan)
Misschien lees ik dit verkeerd, en ik heb Umatrix nog nooit echt zelf gebruikt, maar je kunt met Umatrix toch wel gewoon b.v., als je op Tweakers.net bent, geen css toestaan afkomstig van Tweakers.net zelf, maar wel plaatjes? Of is dat niet wat je bedoelde?

Bedoelde je misschien andersom toestaan: dat alle sites, waaronder b.v. Tweakers, vanaf Jquery dingen mogen inladen, en dan een specifieke categorie of specifiek bestand van Jquery? Dat dat kan met Ublock maar niet met Umatrix?

Ik ga er binnenkort nog wel eens naar kijken wanneer ik Ublock en Umatrix samen gebruik.
Zie bij Ublock instellingen onder "filters van derden" en "mijn filters".
Daarbij kan worden gefilterd op padnaam, bijvoorbeeld "/scripts/ads/*.png". Ook kan ie op basis van (CSS) elementnaam filteren, dus binnen 1 pagina bepaalde elementen verbergen.
(Dat bedoelde ik met "binnen 1 host ... Ublock", en ja dat was niet zo duidelijk)

Bovengenoemde is wat Umatrix niet kan (kon?), en dat is nodig om netjes ads of andere irritaties (zoals floating menubalken of "subscribe now!" gezeik) uit pagina's te slopen.
Maar ja idd kan Umatrix desondanks nog wel categorisch css/plaatjes filteren, per host.
(dat bedoelde ik met "Umatrix ... preciezer", en ja dat was ook niet zo duidelijk).

Ik weet niet wat je bedoelt met je "andersom toestaan" vraag. Maar wat ik zei over Jquery was weer een ander verhaal.
iig, ikzelf sta toe dat alle sites, scripts mogen laden van jquery.com. Dat kunnen zowel Ublock als Umatrix regelen.
Maar nu je het zegt, inderdaad kan Ublock in theorie ook specifieke files/paden van jquery.com blocken/toestaan, en Umatrix niet.

Ik gebruik zelf geen Umatrix, en wil er verder ook niet mee bezig zijn. Het is moeilijk precies uit te leggen. Voor zover het nog niet duidelijk is, ik zou zeggen 1 minuutje uitproberen scheelt 10 minuten uitleggen. Of google op "umatrix vs ublock". Succes :)
OK ik denk dat ik het nu allemaal begrijp!

Schrap dat gedoe over "omgekeerd".

Wat betreft cosmetische/CSS-filters: ik gebruik Ublock ook daarvoor, en wel door met de rechtermuisknop op een pagina op een element te klikken dat ik wil verbergen, dan "Block element", en je krijgt de picker van Ublock. Is handiger dan handmatig regels toevoegen. Je kunt ook eerst Ublock openen en dan met de pipet op elementen drukken.

Fonts blokker ik overigens ook, tegen malware, behalve van vertrouwde sites.
Dank! @N8w8

Ik ga die dan zeker ook bekijken wanneer ik binnenkort overstap van MozFF v55 > ESR v<

(FOSS gaan/gingen niet zo hard dat ze afdoende de v57 overhaul gaan overleven en LOSS[Lgpl] & $S bieden niet wat nodig is :Y) )

+AliCDN >> Exact, dáárom ook al dus. :) _/-\o_
De echte oplossingen liggen in aanpassingen van processorontwerpen. Is al bekend of Intel dit lukt in cpus die in 2018 uitkomen?

Ik vermoed dat Cannon lake (tick) cpu's nog steeds de bugs zullen hebben. Maar wellicht Ice lake (tock) niet meer.
Het zou niet snugger zijn om ten eerste zelf naar buiten te treden dat er een probleem is met cpu's. Om vervolgens daarna een volledige generatie CannonLake onbeveiligd uit te brengen..

We zullen zien :)

[Reactie gewijzigd door Bishiii op 4 januari 2018 18:34]

Het zou niet snugger zijn om ten eerste zelf naar buiten te treden dat er een probleem is met cpu's. Om vervolgens daarna een volledige generatie CannonLake onbeveiligd uit te brengen..
Ze moeten er wel mee naar buiten treden, omdat anders hun klanten met een kwetsbaar zijn voor aanvallen. Geheim houden zou juist in 't geheel niet snugger zijn. Overigens is de informatie niet in eerste instantie via intel naar buiten gekomen. En als het eenmaal bekend is, is ontkennen van iets wat aantoonbaar een probleem is voor je klanten echt heel erg dom.

Wat betreft meltdown, is er een patch voor. Dus het uitbrengen van een nieuwe generatie met dezelfde bug is alleen een performance probleem. Dat is acceptabel. Daar kan intel mee wegkomen. Op z'n hoogst zien ze zich genoodzaakt de prijzen iets verlagen.

Ik ben geen CPU-design expert, maar het lijkt me waarschijnlijk dat dit probleem niet 1-2-3 opgelost is, en als er een oplossing is, moet die nog het hele traject doorlopen van ontwerp naar massa-geproduceerde chip. Daar gaat zeker een jaar of meer overheen. Ik zou dus niet verwachten dat de performance binnen een jaar weer op het oude niveau terug is.
Nu deze kwetsbaarheden wereld kundig zijn. Gaan uiteraad de cyber crminelen nu massaal aan de slag om uit te vogelen hoe er misbruik mee gedaan kan worden. Het tuig wordt hiermee ook wakker geschud.
Daarom meld men vooral eerst naar de CPU OS bedrijven die dan maatregelen kunnen nemen.
Alleen is de ramp dat deel van problemen hardware gerelateerd zijn en dus pas goed aangepakt kunnen worden met hardware architectuur revisie.

Gezien dit gewone nieuws ook gehaald heeft lijkt mij dit toch een groot probleem.
Ik heb vandaag een cumulatieve update voor W10 Pro versie 1709 ontvangen gelukkig :)
Ik heb vandaag een cumulatieve update voor W10 Pro versie 1709 ontvangen gelukkig :)
Zit zelf nog op de eerdere 1703 tak en als ik op updates probeer te controleren krijg ik de 0x80244007 error. Bij de 1709 versie staat er vermeld dat dit een bekend probleem is en dat je het build nummer moet controleren, omdat de patch toch succesvol geinstalleerd zou zijn.

Bij de 1703 tak lijkt dat in elk geval niet het geval te zijn.
Chapeau Microsoft. :(
Bedankt, maar ik draai geen lokale WSUS en dit is geen store app, maar een windows update.

Ik heb een uurtje later nog een keer naar updates gezocht en deze keer werd de cumulatieve update wel gevonden en geinstalleerd zonder error code terug te geven. Mss. dat Microsoft nog iets aangepast heeft; het lijkt nu in elk geval goed te zijn.

Op pre-Haswell CPUs merk je de performance impact bij het gamen trouwens wel degelijk. Net even door een paar van mijn geinstalleerde Steam games heen gegaan en een aantal heeft nu aanzienlijk meer last van 'hitches' (stotteren) wanneer resources ingeladen worden. O.a. bij Shadow Warrior 2 is dat tijdens de opening FMV een flink stuk erger geworden en heel goed zichtbaar. Die was al nooit helemaal soepel, maar nu is het echt drama.

[Reactie gewijzigd door R4gnax op 5 januari 2018 13:24]

Er is (of wordt gewerkt aan) een Linux kernel met de nodige patches.

Een VPS-hoster maakt het mogelijk dat meerdere mensen tegelijk gebruik maken van een computer.
Mijn vraag gaat over een VPS dat werkt met KVM. Bij dit soort VPS kan een klant een zelf gekozen OS en kernel installeren.

Is het voldoende als ik de kernel upgrade van mijn VPS, of moet de hoster het ook doen op het host-systeem... of misschien maakt het niet uit of ik de kernel upgrade, als de hoster het maar doet?
Bij cloud-servers (VPS-hosters) ligt wel een groot praktisch probleem, iig bij Intel en ARM servers. Daarvoor dienen de hypervisors gepatch te worden (de hoster systemen).

Dat gebeurt één dezer dagen.

Zie o.a. deze blogpost van Online.
Even ter info wat wel interessant is... Microsoft Azure heeft twee weken geleden announced dat ze 10 januari beginnen met het patchen en rebooten van azure VM`s echter.... is er gisterenavond laat een bericht uitgekomen dat ze die nacht gereboot worden... (tegelijk met google amazon e.d.) Het lijkt er dus op dat Microsoft en consorten info hadden/hebben m.b.t een eventuele breach en daardoor adhoc allemaal instant azure/google/amazon vm`s zijn gaan rebooten... Ik ben het meest nieuwsgierig naar waarom de grote partijen af hebben geweken van hun initiële planning... (dat is namelijk hoogst uitzonderlijk)
Omdat het gelekt is vóór de door de partijen afgesproken datum (dat was volgende week).
Het is al 6 maanden bekend, tot nu toe moest iedeen zijn mond houden en was er tijd om patches voor te bereiden.
Wanneer wordt er bekend gemaakt welke CPU's er allemaal kwetsbaar zijn? Ik ben voornamelijk geďnteresseerd in de Xeon E5500 en E5600 serie, gezien ik vrijwel niets nieuwers heb.

Iemand enig idee?
The following Intel-based platforms are impacted by this issue. Intel may modify this list at a later time. Please check with your system vendor or equipment manufacturer for more information regarding updates for your system.

IntelŽ Core™ i3 processor (45nm and 32nm)
IntelŽ Core™ i5 processor (45nm and 32nm)
IntelŽ Core™ i7 processor (45nm and 32nm)
IntelŽ Core™ M processor family (45nm and 32nm)
2nd generation IntelŽ Core™ processors
3rd generation IntelŽ Core™ processors
4th generation IntelŽ Core™ processors
5th generation IntelŽ Core™ processors
6th generation IntelŽ Core™ processors
7th generation IntelŽ Core™ processors
8th generation IntelŽ Core™ processors
IntelŽ Core™ X-series Processor Family for IntelŽ X99 platforms
IntelŽ Core™ X-series Processor Family for IntelŽ X299 platforms
IntelŽ XeonŽ processor 3400 series
IntelŽ XeonŽ processor 3600 series
IntelŽ XeonŽ processor 5500 series
IntelŽ XeonŽ processor 5600 series
IntelŽ XeonŽ processor 6500 series
IntelŽ XeonŽ processor 7500 series
IntelŽ XeonŽ Processor E3 Family
IntelŽ XeonŽ Processor E3 v2 Family
IntelŽ XeonŽ Processor E3 v3 Family
IntelŽ XeonŽ Processor E3 v4 Family
IntelŽ XeonŽ Processor E3 v5 Family
IntelŽ XeonŽ Processor E3 v6 Family
IntelŽ XeonŽ Processor E5 Family
IntelŽ XeonŽ Processor E5 v2 Family
IntelŽ XeonŽ Processor E5 v3 Family
IntelŽ XeonŽ Processor E5 v4 Family
IntelŽ XeonŽ Processor E7 Family
IntelŽ XeonŽ Processor E7 v2 Family
IntelŽ XeonŽ Processor E7 v3 Family
IntelŽ XeonŽ Processor E7 v4 Family
IntelŽ XeonŽ Processor Scalable Family
IntelŽ Xeon Phi™ Processor 3200, 5200, 7200 Series
IntelŽ Atom™ Processor C Series
IntelŽ Atom™ Processor E Series
IntelŽ Atom™ Processor A Series
IntelŽ Atom™ Processor x3 Series
IntelŽ Atom™ Processor Z Series
IntelŽ CeleronŽ Processor J Series
IntelŽ CeleronŽ Processor N Series
IntelŽ PentiumŽ Processor J Series
IntelŽ PentiumŽ Processor N Series

Bron: intel
Moet de hacker niet eerst toegang hebben tot je computer (ofwel je bent al gehacked) voordat deze bij je processor kan?

Op dit item kan niet meer gereageerd worden.


Apple iPhone XS HTC U12+ dual sim LG W7 Google Pixel 3 XL OnePlus 6 Battlefield V Samsung Galaxy S10 Google Pixel 3

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