Intel informeerde pas na geruchten overheid VS over Spectre en Meltdown

Chipontwerper Intel heeft pas na de eerste geruchten over Spectre en Meltdown de Amerikaanse overheidsinstantie US-CERT ingelicht over het bestaan van de lekken. De Amerikaanse ambtenaren hadden graag gewild dat Intel dat eerder had gedaan.

Intel redeneerde dat hackers nog geen misbruik hadden gemaakt van de lekken en dat er dus geen reden was om aan te nemen dat er een gevaar was voor de staatsveiligheid van de Verenigde Staten, zo blijkt uit brieven die Intel naar een commissie in het Amerikaanse Huis van Afgevaardigden heeft gestuurd en die persbureau Reuters heeft ingezien.

De chipontwerper wist vanaf juni van de lekken, nadat beveiligingsonderzoekers meldingen daarover hadden gedaan. Intel heeft geen analyse gedaan of Spectre en Meltdown ook kritieke infrastructuur zouden kunnen treffen. Het gelooft niet dat dat het geval is.

Informatie over Spectre en Meltdown kwam vanaf 3 januari naar buiten in de vorm van onbevestigde informatie, waarna de bevestiging de dag erna volgde. Toen heeft Intel US-CERT geïnformeerd over het bestaan van de lekken.

Reacties (61)

[Frubelaar]

Ik vraag mij echt af hoe betrouwbaar dit bericht is.
Wist Intel pas vanaf Juni 2017 v/d lekken? Of was het heel veel eerder?
Leuk om te weten dat US-CERT pas kort v/d lekken afweet.
Wat nog veel leuker is om te weten is vanaf wanneer NSA op de hoogte was v/d lekken.

[The Zep Man]

Wat nog veel leuker is om te weten is vanaf wanneer NSA op de hoogte was v/d lekken.

Niet direct gerelateerd aan Spectre/Meltdown, maar de NSA is op de hoogte van het bestaan van lekken in embedded software van Intel. Anders zou de NSA niet eisen dat deze software uitgeschakeld kan worden:

Thanks to the work of Positive Technologies, in August 2017 a new way of disabling Intel ME has been found: it appears that Intel put a "kill-switch" for Intel ME in the PCHSTRP (the configuration section of the Flash Descriptor) for the U.S. government's High Assurance Platform (HAP) program. This bit (for ME >= 11) and the MeAltDisable bit (for ME < 11, discovered by Igor Skochinsky) gave us a new way to disable Intel ME.

De overheid weet ervan. Daarom dat zij geen last van dit soort lekken willen hebben, en mitigaties afdwingen. Let op dat deze mitigaties niet met het publiek gedeeld worden door Intel of door de overheid, wat de algemene mentaliteit over hoe zij omgaan met serieuze kwetsbaarheden blootlegt.

Over Spectre/Meltdown specifiek: ik denk niet dat het veel uitmaakt of de NSA ervan af weet. Ja, het is een nare kwetsbaarheid, maar er zijn andere manieren om een systeem binnen te dringen voor three-letter alphabet agencies, waarbij er sneller en met meer zekerheid een verwacht resultaat bereikt wordt.

[Reactie gewijzigd door The Zep Man op 31 juli 2024 05:03]

[CH4OS]

Volgens mij hebben Spectre en Meltdown niets te maken met de Management Engine, aangezien oudere generatie CPU's die ME niet hebben ook last hebben van dit lek. Je kan dus niet stellen dat het zomaar uit te schakelen is vanuit ME.

[Dennism]

Dat zegt hij dan volgens mij ook nergens Voor zover ik zijn post leest stelt hij alleen dat de amerikaanse overheid een optie heeft bedongen om Intel ME uit te schakelen. Niet dat het uitschakelen hiervan een relatie heeft met Meltdown / Spectre

[Reactie gewijzigd door Dennism op 31 juli 2024 05:03]

[The Zep Man]

Volgens mij hebben Spectre en Meltdown niets te maken met de Management Engine,

Uit mijn post (eerste zin):

Niet direct gerelateerd aan Spectre/Meltdown

Met mijn verhaal wil ik de mentaliteit/het denkproces van partijen als Intel en overheden verduidelijken. Dat is dieper en breder dan alleen de huidige Spectre/Meltdown kwetsbaarheden. Om dat te begrijpen moet je wel begrijpend lezen.

[Reactie gewijzigd door The Zep Man op 31 juli 2024 05:03]

[Kain_niaK]

Er is zoveel samen werking tussen de Amerikaanse inlichtingendiensten en hun tech giants. Dat wil niet zeggen dat IEDEREEN binnen een bedrijf op de hoogte is. Maar het is triviaal om in eigen land, in een van je eigen bedrijven iemand te plaatsen die ofwel een spion is, of wel invloed kan uitoefenen over bepaalde ontwikkelingen die dan gunstig kunnen uitpakken voor diensten zoals de NSA.

Neem nu een oud en stom voorbeeld dat nooit bevestigd is geweest. Onder windows XP kon je vanuit de software je MAC adres van zowel Ethernet als WIFI spoofen. Since Vista kan dat niet zo maar meer. Je kunt alleen nog het MAC adres van WIFI spoofen met X2-XX-XX-XX-XX-XX, X6-XX-XX-XX-XX-XX, XA-XX-XX-XX-XX-XX of XE-XX-XX-XX-XX-XX

Dit maakt het natuurlijk makkelijk voor systeem beheerders van WIFI netwerken om mac spoofing tegen te gaan. Je blokkeer gewoon elk MAC addres dat 2 of 6 of A of E of X als tweede hexadecimaal character in je MAC adres.

Let wel, het gaat hier over MAC spoofing vanuit het besturingsysteem, niet vanuit de drivers. Er zijn een aantal wifi kaarts die rechstreeks vanuit de driver MAC spoofing toelaten en dat is ook de enige manier om aan MAC spoofing te doen bij Vista en latere OS.

Nou is de vraag, waarom heeft Microsoft een software regel ingebouwd die er voor zorgt dat je WIFI alleen met een spoof adres werkt als die flags er in zitten. Een spoof adres zonder die karakters zal niet werken.

Nou, het maakt het leven voor system beheerders van WIFI hotspots een stuk makkelijker. Geef iemand 10 minuten gratis internet word meestal via MAC address gedaan. Een linux gebruiker kan natuurlijk gewoon elke 10 minuten een random mac als spoof in stellen en heeft nergens last van.

Maar het maakt het ook een stuk makkelijker om hardware te tracken als er een unique nummer aan de hardware is dat niet verandert, zoals een MAC address.

Dat vind de NSA natuurlijk wel zo gemakkelijk. Ik kan het niet bewijzen maar ik kan me goed voorstellen dat dat ooit door iemand bij Microsoft is ingevoerd die precies wist waarom dit zo leuk was voor iedereen behalve de gebruiker want die heeft opeens minder vrijheid en controle over zijn eigen systeem.

[Reactie gewijzigd door Kain_niaK op 31 juli 2024 05:03]

[RJG-223]

Het lijkt me onwaarschijnlijk dat dit te maken heeft met NSA e.d. Er is in ieder geval een véél betere verklaring dan een vage komplottheorie:

MAC adressen worden door de fabrikanten in de hardware geprogrammeerd. Die moeten uniek zijn, zodat er op een netwerk geen conflicten onstaan. Iedere fabrikant krijgt dus een eigen range toegewezen waaruit ze mogen putten. Als iedereen op een netwerk een willekeurig/zelf gekozen MAC adres kan gebruiken, dan is er een (al dan niet opzettelijke) kans dat dat een conflict oplevert met een MAC adres van een ander device op dat netwerk. Gevolg: beide apparaten kunnen niet goed met de buitenwereld communiceren, en wellicht raakt de access point en misschien ook de router wel in de war. En als mensen per ongeluk (uit onwetendheid) een multicast adres in zouden stellen, dan kan een netwerk zelfs overbelast raken.

Omdat het soms toch nodig is om een MAC adres zelf in te stellen (bijv. bij virtuele machines, of virtuele netwerk interfaces), moet dat ook mogelijk zijn. Daar is rekening mee gehouden: de MAC adres ranges die jij noemt, en die windows toestaat (dwz: het eerste bit van de eerste byte is 0, en het tweede bit is 1) zijn unicast-adressen die vrij gebruikt mogen worden. Men gaat er vanuit dat als je dat doet, je ook weet waarmee je bezig bent, en dat je ook met de gevolgen kunt leven.

Wat windows dus enkel doet is zorgen dat alleen vrij programmeerbare unicast MAC adressen gebruikt kunnen worden. Zo beschermen ze alle gebruikers tegen die ene onwetende gebruiker, die de klok heeft horen luiden, maar van een klepel geen weet heeft, en die dus probeert WiFi beperkingen te omzeilen bijvoorbeeld, of die gewoon probeert cool te zijn, en een ander MAC adres programmeert zonder idee van de mogelijke gevolgen voor het netwerk en andere gebruikers.

Dit gaat dus niet om vrijheid en controle over je eigen systeem die zij willen beperken, het gaat om bescherming van andere gebruikers, wat alleen kan door bepaalde vrijheden te beperken. Net zoals je ook niet een willekeurige frequentie in mag stellen in je WiFi kaart. Dat is ook een beperking van jouw vrijheid, maar ter bescherming van andere gebruikers van de frequentieruimte (radio, TV, marifoon, luchtvaart, etc. etc.). Dat laaste is zelfs wettelijk geregeld.

Overigens heeft het weinig zin om elke 10 minuten je MAC adres te wijzigen. Dat is zelfs onverstandig: de DHCP server kan in de war raken, en jou ineens een ander IP adres geven, waardoor jouw verbindingen wegvallen. Als je je MAC adres wilt wijzigen, doe dat dat 1 keer per dag. En koop dan een verzameling oude netwerk / wifi-kaarten en gebruik de adressen die je daarop vindt.

Overigens: als je je MAC adres wijzigt, dat val je juist op. Ten eerste val je op omdat het MAC adres veranderlijk is. Dan behoor je tot de 0.1% (of 0.0001%? of nog minder) van de mensen die dat doen. Ten tweede val je op omdat jouw adres niet 'standaard' is.

Overigens denk ik dat er weinig WiFi spots zijn die die speciale MAC adressen detecteren en blokkeren. Ten eerste omdat weinig mensen die (om die reden) gebruiken, zodat het de moeite niet loont, ten tweede omdat virtuele machines óók zo'n speciaal MAC-adres (moeten) gebruiken, en dus alle virtuele machines geblokkeerd zouden worden. En er zijn vast nog wel meer manieren waarop zulke adressen normaal gebruikt worden.

[Cerberus_tm]

IK vraag me alleen af hoe groot de kans op collision is bij MAC-adressen. Is het aantal mogelijkheden niet zo groot, dat de kans verwaarloosbaar is dat twee mensen toevallig hetzelfde MAC-adres kiezen? En als die kans niet verwaarloosbaar is, kan dat dan niet alleen maar zo zijn doordat ze beiden volgens een patroon werken? En in dat geval is het hun eigen schuld als ze botsen. Maar daar hebben gewone gebruikers dan geen last van.

[--Andre--]

Bij (psuedo)random gegenereerde adressen is de kans op collision inderdaad klein, maar als je zelf iets in gaat kloppen, hoe random is het dan?

[Cerberus_tm]

Minder, maar dat is dan je eigen schuld; als je dat goed random maakt heb je geen probleem. En mensen die hun adres helemaal niet veranderen hebben geen last van je.

[RJG-223]

En in dat geval is het hun eigen schuld als ze botsen. Maar daar hebben gewone gebruikers dan geen last van.

Als er een botsing is, hebben minstens twee mensen daar last van. Waarschijnlijk weet een van die twee sowieso van niets (gewone gebruiker), en de kans dat de andere gebruiker precies begrijpt wat ie aan het doen is, is ook niet al te groot. Er is dus (bijna) altijd één gewone gebruiker die last heeft van een collision, en mogelijk heeft de veroorzaker er ook last van zonder te weten waarom... En dat kun je die veroorzaker niet verwijten als ie gewoon gekopieerd heeft wat iemand anders die wellicht ook de details niet weet op z'n blog heeft gezet...

En als de gebruiker hetzelfde MAC adres gekozen heeft als dat van de router of het access point, dan heeft het hele netwerk er last van. En als de gebruiker een multicast adres kiest, dan hebben andere netwerksegmenten wellicht ook last van problemen (te veel load). Zeker als er een aantal mensen met zelfgekozen MAC multicast adres in een gebied aanwezig zijn.

En ja, de kans is niet héél erg groot, maar ook weer niet zo klein als je zou denken. Met 7 miljard mensen op aarde, en in de toekomst een veelvoud daarvan aan devices (IOT en andere) worden kleine kansen op een gebeurtenis als snel grotere kansen dat er mensen op de wereld last van krijgen (alleen misschien toevallig niet jij). En als mensen regelmatig van MAC adres wisselen, dan wordt de kans nog veel groter.

[rud]

MAC-adressen moeten lokaal, in de door jou gebruikte netwerken, uniek zijn.

Sommige fabrikanten hergebruiken hun ranges. De kans dat jij een kaart met hetzelfde MAC-adres in je lokale netwerk treft is bijzonder klein met 16 miljoen mogelijke MAC-adressen per range per fabrikant.

[ajolla]

Ik denk dat de VM's intern met elkaar en de hypervisor via virtuele interfaces communiceren. Het internet, of de LAN, ziet een hardware interface en ziet die VM's niet eens.

[RJG-223]

Met een virtuele interface heb je nog steeds een MAC adres nodig, en in de praktijk zal dat MAC adres ook zichtbaar moeten zijn op het LAN. Met IPv4 kun je met NAT eventueel nog wel iets doen om dat te vermijden, maar met IPv6 gaat dat feitelijk niet. Nog afgezien van het feit dat VMs meestal gemigreerd moeten kunnen worden, en nog afgezien van het feit dat je in het algemeen wilt dat een VM ook op het netwerk gezien wordt als een aparte machine, en niet als een onderdeel van de host machine. Dus dan heb je normaal een MAC adres nodig dat zichtbaar is op het netwerk. Elke andere oplossing is complexer.

Wat op het LAN zichtbaar is, is één hardware interface, met daarachter een of meer MAC adressen, en één of meer IP-addressen (een voor de host, en een voor elke VM). Dat ziet er dus hetzelfde uit als een switch met daarachter weer een aantal machines elk met hun eigen MAC adres.

[ajolla]

Ok, IPv6 weet ik weinig van. De situatie die ik voor ogen heb is mijn eigen laptop met QubesOS met VM's die via NAT van 1 gezamelijke interface gebruik maken die aan een netwerk VM hangt. Op deze wijze ziet het netwerk dus niets van de virtuele interfaces van de andere VM's, dus ook geen MAC adressen.

[litebyte]

Samenwerking is verplicht. Techcompanies in de VS zullen natuurlijk altijd ontkennen dat er een vorm van samenwerking is. Ik kan me berichtgevingen herinneren dat diensten van de VS overheid zich ook nestelden in ontwikkelteams en/of middels financiering (the VS overheid heeft een eigen financierings afdeling om invloed te kopen) invloed kochten op de ontwikkeling.

Losstaande daarvan als je iets hebt gelezen over bijv. programma's zoals het XKeyscore program dan is gewoon de hele wereld overgeleverd aan de dataverzameldrang van de VS. Online, offline, hardware of softwarematig het maakt niet uit.

De grootste achterlijkheid ervan is nog niet eens de enorme schaal waarop het wordt uitgevoerd, maar de achterlijkheid en de valse naiviteit van de rest van de wereld wat er niets tegen doet.

[Wim-Bart]

Een beetje goede netwerk beheerder heeft sowieso 802.1x in combinatie met iets van port security waarbij poort of wifi verbinding permanent wordt dichtgezet bij een mac address change binnen een bepaald tijdsbestek met bijbehorende snmp-trap.

[Iblies]

Je ziet de overheid als een uniform orgaan,

de waarheid is dat het toch terdege een complex is van verschillende onderdelen.

[litebyte]

correct, maar de hoofddoelstelling is wel uniform, net zoals overigens bij overheden in China of Rusland.
Behoeft gen toelichting neem ik aan.

[robvanwijk]

de NSA is op de hoogte van het bestaan van lekken in embedded software van Intel. Anders zou de NSA niet eisen dat deze software uitgeschakeld kan worden

Die redenering werkt alleen als de enige mogelijke reden voor het uitschakelen een lek is. Er zijn echter ook andere redenen om het uit te willen schakelen, denk aan een soort "defence in depth": we zijn niet op de hoogte van lekken, maar als we het toch niet gebruiken kunnen we het, voor de zekerheid, beter uitschakelen. Een soort van "baat het niet, maar het schaadt ook niet" redenering. Hieruit afleiden dat de NSA gegarandeerd op de hoogte is van een lek is onzin. (Je kunt hooguit zeggen dat de kans behoorlijk groot is, maar dat komt omdat er pas recent flink onderzoek naar wordt gedaan door onafhankelijke experts, niet omdat de NSA het uit wil kunnen zetten.)

[Jerie]

Ja, het is een nare kwetsbaarheid, maar er zijn andere manieren om een systeem binnen te dringen voor three-letter alphabet agencies, waarbij er sneller en met meer zekerheid een verwacht resultaat bereikt wordt.

Met dezelfde impact en reach? Welke?

Spectre is stukken lastiger uit te buiten dan Meltdown, en Meltdown is vrijwel alleen Intel-only. Dus je hebt een kwetsbaarheid die 1) makkelijk is uit te buiten 2) bijna op elk systeem werkt 3) remote via het netwerk.

Als de NSA wist van Meltdown, dan had de NSA zo'n beetje elk systeem kunnen hacken. Als je dat niet wilt, dan moet je zorgen dat organisaties die dit soort informatie doorspelen aan de NSA er geen lucht van krijgen. Laat de baas van de NSA (de federale overheid) nou precies een organisatie zijn die dat zou doorspelen. Dus is het verstandig om ze achteraan het rijtje aan te laten sluiten. De overheid is immers ook geen vendor. En vergeet ook niet: hoe meer mensen hier van weten, hoe groter de kans dat het uitlekt.

[litebyte]

Zoals The Zep Men prima aangeeft...zie het lage niveau van de betrouwbaarheid van dit bericht maar tweeledig.
Bericht kan heel goed een vorm van indekking zijn.

Dit soort berichtgevingen zijn nauwelijks op (volledige) waarheid te toetsen.

[Reactie gewijzigd door litebyte op 31 juli 2024 05:03]

[CAPSLOCK2000]

Chipontwerper Intel heeft pas na de eerste geruchten over Spectre en Meltdown de Amerikaanse overheidsinstantie US-CERT ingelicht over het bestaan van de lekken. De Amerikaanse ambtenaren hadden graag gewild dat Intel dat eerder had gedaan.

En ik wil een pony, maar zo werkt het niet. De afspraak is dat iedereen tegelijk de informatie krijgt, met uitzondering van de mensen die het probleem moeten oplossen. Als de een voorrang wil hebben boven de ander dan werkt het systeem niet.
Als de Amerikanen de informatie 1 dag eerder willen, dan gaan de Chinezen eisen dat ze de info 2 dagen eerder mogen, en de Russen willen zelfs 3 dagen eerder. Op die manier lukt het nooit om het onder te pet te houden, dan stoppen mensen met informatie delen en gaan we weer alles geheim houden tot problemen zo groot worden dat ze niet meer kunnen worden genegeerd.

[Reactie gewijzigd door CAPSLOCK2000 op 31 juli 2024 05:03]

[A4-tje]

Ik denk dat ze meer doelen op het feit dat het dus al een half jaar bij Intel bekend was en ze dus die kennis eerder hadden moeten delen (met het publiek).
Raar om zonder onderzoek maar te bedenken dat het geen kwaad kan. Volgens mij wisten ze direct wat een impact dit kon hebben en is dat de reden dat ze het stil hebben gehouden. Dom genoeg dachten ze niet aan internet en dat alles (vroeger of later) bekend wordt.

[mcDavid]

Het is in zulke gevallen gebruikelijk dat je éérst een patch ontwikkeld, die eventueel deelt met cruciale partijen zoals kernel-ontwikkelaars zodat zij updates kunnen ontwikkelen, en dán pas het issue disclosed aan het publiek. Zero-days zijn NIET grappig.

Wat je Intel in deze wel kwalijk kan nemen is dat het bizar lang geduurd heeft voordat er actie ondernomen werd. 90 dagen tussen 1e melding en disclosure is redelijk gebruikelijk, maar Intel heeft gewoon een half jaar op haar handen gezeten, om vervolgens als de paniek al is uitgebroken, op de proppen te komen met een slecht geteste patch die later weer teruggetrokken moet worden.

[GeroldM]

Aan de andere kant denkt Intel dat zij ineens beter zijn in spionage, contra-spionage en binnenlandse veiligheid. Volgens mij heeft de Amerikaanse overheid specifiek daarvoor grote ambtenaarsapparaten ingezet die zich hiermee dagelijks bezighouden.

Dat zijn ook consequenties van het achterhouden van dit soort informatie. Intel zet hiermee de effictiviteit van alle veiligheidsdiensten en in principe de gehele VS regering op het spel. Wie is Intel omdat zo even voor de gehele regering maar eventjes te bepalen?

Intel heeft opnieuw steken laten vallen. Eerst door de foute aannames in het chip-ontwerp, daarna met wazige verstrekking van gegevens over het probleem ("security" by obscurity/disinformation) en nu dan met het niet tijdig op de hoogte brengen van veiligheidsdiensten met als taak hun eigen land te beschermen.

Is Intel je vriend? Heb je echt geen vijand meer nodig....

[/advocaat van de duivel modus]

[CAPSLOCK2000]

Dat zijn ook consequenties van het achterhouden van dit soort informatie. Intel zet hiermee de effictiviteit van alle veiligheidsdiensten en in principe de gehele VS regering op het spel. Wie is Intel omdat zo even voor de gehele regering maar eventjes te bepalen?

Misschien had Intel de informatie eerder moeten publiceren maar dat ik niet goed beoordelen. Wat "op tijd" en wat "te laat" is, is een kwestie van smaak. We zouden het er over kunnen hebben dat Intel alle fouten die gevonden worden onmiddellijk moet melden; dat is een redelijk standpunt. Maar dan is de vraag aan wie ze die fouten gaan melden? De Amerikanen vinden natuurlijk dat die fouten bij de Amerikaanse regering gemeld moeten worden maar als Nederlander vind ik dat niet eerlijk. Ik vind dat ze het bij de Nederlandse regering moeten komen melden. Andere landen zullen er ook zo over denken. De enige eerlijke oplossing is om het dan bij alle landen te melden. Dan krijgen dus alle geheime diensten dus te horen dat er een gat is waar niemand nog een oplossing voor heeft. Terwijl de techneuten die het probleem moeten gaan oplossen nog van niks weten. Kassa! Kraak maar raak.

Dan is er nog het probleem dat we wereldwijd honderden (duizenden?) ambtenaren gaan informeren. Dat maakt het moeilijker om het geheim te bewaren. Iedere professionele kraker koopt dan een ambtenaar in arm land om en krijgt zo de informatie.

De beste werkwijze is op dit moment toch echt om de informatie geheim te houden tot er een oplossing is en dan iedereen tegelijk te informeren.

We kunnen het wel hebben over termijnen en wie er wel of niet moeten worden geïnformeerd, maar sommige regeringen eerder informeren als anderen lijkt me over het algemeen geen goed idee.

[Dark_man]

Hoe kan het zo zijn dat Intel niet wist dat ze meer dan 20 jaar een lek hadden?

Ik geloof dat gewoon niet.

[Dennism]

Er kunnen 2 zaken zijn, of alle cpu fabrikanten wisten er van en hebben het allemaal onder de pet gehouden al die jaren, daar ze allemaal in meer of mindere mate kwetsbaar zijn (o.a. Intel, AMD, ARM, IBM en Oracle), iets dat me vrij onwaarschijnlijk lijkt, normaliter was zoiets een stuk eerder uitgekomen omdat er altijd wel iemand "uit de school klapt".

De andere optie is dat ze het allemaal echt niet wisten en dat het onderzoeksteam van Google (Project Zero) inderdaad gewoon de eersten zijn geweest die dit gevonden hebben. Dit laatste lijkt mij op de momenteel beschikbare informatie in ieder geval het meest waarschijnlijk.

[latka]

De bug is pas ontstaan door veranderend gebruik van computers. Als je alleen maar software draait die 100% te vertrouwen is, is er niets aan de hand. Het probleem komt pas met cloud en Javascript in de browser. Beide zorgen ervoor dat je walled garden doorbroken wordt er software op je CPU komt die je niet persoonlijk hebt kunnen controleren. En dan nog is het geen bug als de sandbox goed zou werken en dat is het probleem: je kunt uit je sandbox in andere sandboxes kijken. Dit soort bugs zijn op andere vlakken al jaren bekend (race conditie bij maken van een tijdelijke file en de rechten zo zetten dat niemand er in kan kijken voordat je paswoorden erin gaat schrijven). Theoretisch was al lang bekend dat dit zou kunnen, maar niemand dacht dat het praktisch haalbaar was. De techniek die erachter ligt heeft er echter wel voor gezorgd dat CPUs achterlijk snel zijn geworden. Een 100% side-channel vrije PC zal een stuk trager zijn.

[Dennism]

Ben ik toch niet volledig met je eens, ook in de jaren 90 kon je er niet zeker van zijn dat alle software te vertrouwen is, alleen al om het feit dat veel software closed source is. Cloud / het gegroeide Internet gebruik zal dit verergeren.

Maar ook eind jaren 90, begin 2000 begonnen zaken als terminal server al te groeien in populairiteit. Het eerste project waar ik aan gewerkt heb wat enigszins op een moderne (Private) "Cloud" begon te lijken was een grote Terminalserver implementatie (uit mijn hoofd even snel zomer 2000) op basis van Windows 2000 voor een bedrijf met meerdere vestigingen waar alle IT infra destijds al gecentraliseerd werd naar de hoofdvestiging. En theoretisch gezien zijn dat soort implementaties al die tijd vatbaar geweest.

Het laatste ben ik volledig met je eens trouwens, de achterliggende techniek in de cpu's heeft voor een hoop snelheidsverbeteringen gezorgd.

[latka]

Het gaat erom dat je een 'trustzone' definieert. Een terminal server voor een bedrijf en alle gebruikers + software die ze draaien zitten in je trustzone: je vertrouwt dat ze geen kwade bedoelingen hebben. Net zoals je, nadat je de voordeur door bent bij een bedrijf, je niet meer gecontroleerd wordt. De firewall gebruik je om indringers erbuiten te houden en een virusscanner gebruik je om onbedoelde troep eruit te houden. Als je software niet wilt draaien omdat het closed source is dan installeer je dat niet. Als gebruikers het installeren dan waarschuw je ze omdat je tooling aangeeft dat er troep op de machine staat.

Zie de cloud met VMs een beetje als je voordeur openzetten voor software van jan en alleman toelaten op je netwerk. Dat doe je niet omdat je niet weet wat je in huis haalt. Dus een VM en dan hopen dat ze erin blijven. Als je de parallel met een huis gaat doen: je maakt allemaal kamertjes die je gaat onderverhuren. Alleen de wanden maak je van gipsplaat. Grote kans dat je met de buren mee kan luisteren. Dat is dan een onbedoeld bij-effect wat pas aan het licht komt omdat je het gebruik van je huis aanpast. Tot die tijd woonde je alleen met je familie in de woning en was gipsplaat geen echt probleem.

[ajolla]

Haha, als autorijder las ik 'snelheidsovertredingen' in je laatste zin.

[Jerie]

Het probleem komt pas met cloud en Javascript in de browser.

JavaScript is uit 1995. Het werd misschien niet meteen veel gebruikt, maar wel meer sinds de jaren '00.

Dit soort bugs zijn op andere vlakken al jaren bekend (race conditie bij maken van een tijdelijke file en de rechten zo zetten dat niemand er in kan kijken voordat je paswoorden erin gaat schrijven).

In zo'n geval kun je gebruik maken van atomic writes. C/C++ doen dat standaard niet, dus dat moet je dan aangeven.

[latka]

Het punt is: je moet je er bewust van zijn. De eerste golf aan (software) security bugs waren zo beschamend dat je je afvraagd hoe ze dat konden verzinnen. En mijn punt rondom JavaScript is het toegenomen gebruik ervan en de toevoegingen zoals hele goede timers die deze side-channel mogelijk maken. Met de JavaScript uit 1995 kun je geen Spectre attack doen. Dat lukt eigenlijk alleen goed met de moderne JavaScript sinds 2015...

[Verwijderd]

Atomic writes (of dus, m.a.w. op POSIX rename(oud, nieuw) doen, nadat je een temp-file geschreven hebt) is onvoldoende. Dat beschermt je enkel tegen het feit dat een file descriptor die ge- close(x) 'd in process A wordt daarom nog niet onmiddellijk zo door process B gezien wordt (het FS enof de kernel zijn daartoe niet verplicht). Daarom dat je nadien ook een rename() moet doen (en eigenlijk best ook eerst een fsync(x), als je ook enige zekerheid wil dat het fysiek op disk staat). POSIX stelt namelijk dat rename() wel atomic moet zijn (ook tussen processen).

Maar beveiliging tegen waar @latka het over heeft (de temporary files van andere processen manipuleren), daar helpt rename() (of dus atomic writes) op zich niet echt tegen.

Op POSIX maak je voor het aanmaken van temporary files gebruik van mkstemp (en hier voor de GNU/Linux variant(en)).

Je eigen technieken zijn vermoedelijk een dikke vette security fout. Ook en vooral wanneer die eigen techniek een Not-Invented-Here techniek van je is. Bv. omdat jij het altijd beter weet. Dan is het vooral en zo goed als zeker een dikke vette security fout en daarbij merk ik met kracht op dat het enkel maar tussen je twee oren leeft dat je het beter weet (en ook dat mensen zoals jij best wel lastig zijn voor de wel ervaren programmeurs). Je moet ook umask() zetten. Dat staat onderaan de GNU man page van mkstemp().

In Qt gebruik je, als je mkstemp() wil gebruiken op een Qt-manier, de QTemporaryFile. Zo werkt je code juist op alle platformen waar Qt op ondersteund wordt. Want temporary files op de juiste manier aanmaken is wel degelijk platform afhankelijk.

In Python heb je tempfile. En zo verder (ja ik weet dat jij als aandachtige lezer Ruby en/of <insert heilige programmeertaal> veel geweldiger vindt. Voor Ruby en zo zal je dat ook wel hebben).

Zo, nu kan iedereen het.

[Kain_niaK]

Processoren zijn gigantisch complex. Er worden allemaal truukjes en slimme systemen bedacht om die processoren meer instructies te laten uitvoeren zonder dat de Ghz omhoog moet. Daarom dat we nu al jaren proc's hebben die 4 Ghz als maximum doen. Je ziet geen 5 of 6 of 7 Ghz. Vroeger, ging dat wel omhoog. Maar nu is de grens een beetje bereikt. Dus dan moeten het aantal instructies per kloktik omhoog en daarom zijn er slimme dingen bedacht zoals branch prediction. Hier probeert de processor een beetje te voorspellen welke weg de code op gaat, en probeert al voordat het zeker weet dat een programma een bepaalde richting opgaat al vast wat berekeningen te doen die ALS het programma inderdaad die richting omgaat dan niet meer uitgevoerd hoeven te worden. Dit geeft natuurlijk een snelheids winst. Nou en de mensen die dat toen ontworpen hebben hebben er niet bij stil gestaan dat je een implementatie voor dit idee kunt schrijven die dus dit misbruik mogelijk maakt. En niet elke implemenatie is exact hetzelfde. AMD heeft het bijvoorbeeld net even iets anders gedaan dan Intel en heeft dus nu iets minder last er van.
In dit geval kan er dus informatie uitlekken van een programma naar een andere programma.

En ja als jij een VPS user bent en jouw programma je opeens toegang kan geven tot het geheugen van een programma van een andere klant .... dat is een heel erg grote zwakte.

Maar dat dat 20 jaar geleden toen express zo gemaakt is geweest ... jaren voordat er uberhaupt iets was zoals VPS .... nee dan maak je van de NSA gasten echt een soort goden die de toekomst kunnen voorspellen.

Het is veel aannemelijker dat deze proc engineers er alles aan hebben gedaan om hun proc's zo snel mogelijk te maken en daar dus dit over het hoofd hebben gezien.

En die proc's zijn dus ZO complex dat het 20 jaar geduurd heeft voor dat een pen tester daar achter kwam. Het is goed mogelijk dat de NSA dit al 10 geleden wist. Om misschien weten de israeliers het al 15 jaar. Of de chinezen 20. Die hebben natuurlijk allemaal hackers en hele slimme mensen in dienst die als ze zo een zwakbaarheid vinden het aan NIEMAND laten weten .. en dan gaan misbruiken in voordeel van de dienst en het land waar ze voor werken.

Maar er worden door mensen meer fouten gemaakt dan complotten gesmeed. Anders kan er ook wel iemand gaan beweren dat ik gesponsord word door een spellingscontrole bedrijf.

[Reactie gewijzigd door Kain_niaK op 31 juli 2024 05:03]

[sdk1985]

Kleine correctie, je bent niet up to date. Mijn 8700K doet 5200 Mhz op alle cores wanneer Hyperthreading uit staat. Gewoon met luchtkoeling . De stock boost op 1 core gaat ook richting de 4700 Mhz als ik me niet vergis.

[Macboe]

Intel doet ook gewoon aan struisvogelpolitiek. Ok, beter geven ze netjes van te voren aan waar bijv. Coffee Lake last van heeft.

[litebyte]

Mogelijk hebben ze het onder druk van zolang mogelijk onder de pet gehouden...wie die druk uitoefende kan je naar gissen.

[WhatsappHack]

“Intel heeft geen analyse gedaan of Spectre en Meltdown ook kritieke infrastructuur zouden kunnen treffen. Het gelooft niet dat dat het geval is.”

Ja hoor.
Maar als je geen analyse hebt gedaan kan je dat natuurlijk wel makkelijk roepen.

[Kabouterplop01]

Ik wilde precies hetzelfde quoten met dezelfde strekking.

Iets met boter en hoofd

[Raphaelo]

Intel redeneerde dat hackers nog geen misbruik hadden gemaakt van de lekken...

Hoe weten ze dat zeker?

[_Thanatos_]

Geldt dit niet voor alle overheden? Moet Intel de overheid van ieder land apart gaan inlichten? Ze kunnen beter de hele wereld in 1x inlichten, dat lijkt me veel efficiënter. Dan worden ook niet alleen de overheden van de wereld voorgetrokken t.o.v. bijv commerciele organisaties, die dit ook hadden willen weten.

[Origin64]

Intel redeneerde dat inbrekers nog geen misbruik hadden gemaakt van het gat waar de deur zou moeten zitten en dat er dus geen reden was om aan te nemen dat er een gevaar was voor de staatsveiligheid van de Verenigde Staten

[Splorky]

Melden van bugs is belangrijk, maar het bij de overheid melden er er verder niet zo veel aan doen is ook een veiligheids risico.

Ben wel benieuwd or van af dat momend de volgende generatie cpu's worden aangepast zodat ze de bugs er niet in zitten of dat ze daar ook niets aan doen tot dat ze echt moeten onder druk van imago schade.

[Dennism]

Ze hebben een maand geleden al aangekondigd bij het presenteren van de kwartaalcijfers dat de volgende generatie fixes heeft "in silicon". Zie o.a. https://arstechnica.com/g...d-xpoint-ram-not-so-much/

Deze generatie wordt eind 2018 verwacht.

[Reactie gewijzigd door Dennism op 31 juli 2024 05:03]

[Dennism]

Dat is natuurlijk volledig te testen, maar fundamenteel blijven al die cpu's gewoon kwetsbaar, met OS patches en microcode kun je ervoor zorgen dat de exploits niet meer uit te voeren zijn op het systeem met de betreffende cpu, maar zet je de cpu in een ongepatched systeem ben je weer kwetsbaar.

En dan zullen er ook nog legio gebruikers / bedrijven zijn die helemaal niet, of niet volledig zullen patchen (bijv. wel de OS updates maar niet de microcode patches). Hoe eerder deze zaken in silicon opgelost zijn, hoe beter. Gelukkig zijn er andere methoden om microcode te laden (o.a. https://labs.vmware.com/f...u-microcode-update-driver voor Windows machines) dan alleen bios updates, want Intel zal de microcodes wel uitbrengen, maar gaat ook iedere fabrikant bios updates releases van mobo's / machines van 5 tot 10 jaar of zelf nog ouder?

[Dennism]

MS heeft dit allang gepatched voor zover zij kunnen, zie o.a. https://support.microsoft...-against-spectre-meltdown

Als je de updates niet binnen krijgt, check dan dit artikel eens: https://support.microsoft.com/en-us/help/4072699

Je anti-virus oplossing moet namelijk een registry key zetten. Doet deze dit niet, omdat deze niet up-to-date is, of (nog) niet compatible met deze patches dan zal je deze patches inderdaad nooit automatisch binnenkrijgen (en ook de opvolgende cumulatieve updates niet meer om begrijpelijke redenen).

[RJWvdH]

Je slaat de plank volledig mis...MS patches? De patches moeten misschien van Intel komen?