EFF: Management Engine in Intel-processors is gevaarlijk
De Management Engine in Intel-processors is een serieus beveiligingsrisico en gebruikers moeten de mogelijkheid krijgen die te controleren en uit te schakelen, zo wil de Amerikaanse burgerrechtenbeweging EFF. De ME is een subsysteem dat uit een losse processor bestaat. Het heeft toegang tot het netwerk, randapparatuur, het besturingssysteem, het geheugen en de cryptografische engine.
De ME kan zelfs op afstand worden gebruikt als de computer is uitgeschakeld. De code van de Management Engine is echter gesloten, waardoor het publiek de werking niet kan controleren. Vorige week werd er een ernstige kwetsbaarheid in de Intel Active Management (AMT) module ontdekt, die in de Management Engine van zakelijke Intel-processors aanwezig is. Gebruikers kunnen de AMT uitschakelen, maar dat geldt niet voor de Management Engine zelf. "Intel moet hier dringend voor zorgen", zegt Erica Portnoy van de EFF.
Volgens Portnoy moeten gebruikers de vrijheid hebben om te kiezen wat ze op hun systeem draaien, en moeten ze code kunnen verwijderen die mogelijk beveiligingslekken bevat. "Omdat de Management Engine alleen door Intel gesigneerde code draait, houdt dit in dat er een mogelijkheid moet zijn om de ME uit te schakelen of te vervangen door minimaal gecontroleerde firmware", merkt ze op.
Portnoy stelt dat het een verschrikkelijke ontwerpbeslissing van Intel was om een geheime, niet aan te passen managementchip aan elke processor toe te voegen, waardoor gebruikers aan beveiligingsrisico's worden blootgesteld zonder dat ze hier iets aan kunnen doen. De EFF-medewerker spreekt zelfs van "ongekend onverantwoordelijk gedrag".
Controleren
De EFF wil dat gebruikers de machines die ze hebben gekocht dan ook kunnen controleren en dat Intel officiële support gaat bieden om de potentiële dreiging en het aanvalsoppervlak van de Management Engine te verkleinen. Intel is nu concreet opgeroepen om duidelijke documentatie van alle softwaremodules te geven die standaard in de verschillende Management Engines aanwezig zijn. Daarnaast moeten gebruikers de mogelijkheid krijgen om de ME op kwetsbaarheden te controleren.
Verder moet Intel een manier aanbieden om de ME uit te schakelen en als dat niet mogelijk is moet die via een door de gemeenschap gecontroleerde firmware-update vervangen kunnen worden. Op systemen waar de ME is vereist vanwege andere beveiligingsfeatures, zoals Boot Guard, moet Intel een extra optie bieden zodat er ook een door de gemeenschap gecontroleerde minimale ME-firmware met alleen die beveiligingsfeatures kan draaien en verder niets anders.
"Totdat Intel deze maatregelen neemt, hebben we reden om te vrezen dat de ongedocumenteerde mastercontroller in onze Intel-processors een bron van ernstige kwetsbaarheden in computers, servers en de vitale infrastructuur blijft. Intel moet snel reageren om de gemeenschap een controleerbare oplossing voor deze dreigingen te geven", besluit Portnoy.
schade opkomen.
Hmm - voor de schade opkomen zeg je? Stel dat een processor 50 euro kost. Is dan het schadebedrag beperkt tot de kostprijs van de processor, of kan die ook hoger zijn - zeg 100 euro? Even de parallel met een liftenfabrikant: de lift kost 1000 euro, maar wordt gebruikt om de Nachtwacht mee te vervoeren. Liftkabel knapt, alles flikkert naar beneden, Nachtwacht stuk. Kan je dan op de liftenboer de kosten van dat schilderij verhalen?
Zou iemand ooit nog software durven schrijven als je min of meer persoonlijk/hoofdelijk aansprakelijk bent voor schade door die software? Of zou jij een applicatie durven verkopen voor een tientje dat verkeerslichten regelt, hartapparatuur bewaakt, of gewoon een camera aanstuurt - wetende dat iemand bij jou later een miljoen kan claimen als er een bug in zit?
Hmm - voor de schade opkomen zeg je? Stel dat een processor 50 euro kost. Is dan het schadebedrag beperkt tot de kostprijs van de processor, of kan die ook hoger zijn - zeg 100 euro? Even de parallel met een liftenfabrikant: de lift kost 1000 euro, maar wordt gebruikt om de Nachtwacht mee te vervoeren. Liftkabel knapt, alles flikkert naar beneden, Nachtwacht stuk. Kan je dan op de liftenboer de kosten van dat schilderij verhalen?
Zou iemand ooit nog software durven schrijven als je min of meer persoonlijk/hoofdelijk aansprakelijk bent voor schade door die software? Of zou jij een applicatie durven verkopen voor een tientje dat verkeerslichten regelt, hartapparatuur bewaakt, of gewoon een camera aanstuurt - wetende dat iemand bij jou later een miljoen kan claimen als er een bug in zit?
De bovengenoemde bedragen zijn nogal laag.
Bovendien heeft dit wel iets weg van grove nalatigheid, en als dat "bewezen" wordt, dan zijn schadebedragen die veel hoger liggen dan de aanschafprijs goed mogelijk.
Bovendien heeft dit wel iets weg van grove nalatigheid, en als dat "bewezen" wordt, dan zijn schadebedragen die veel hoger liggen
zegt dat dit geen spyware is.
Ik weet dat het zowat onmogelijk is om een foutloze programma te schrijven, maar dit is iets anders denk ik.
De bovengenoemde bedragen zijn nogal laag.
Bovendien heeft dit wel iets weg van grove nalatigheid, en als dat "bewezen" wordt, dan zijn schadebedragen die veel hoger liggen dan de aanschafprijs goed mogelijk.
Autofabrikanten en andere leveranciers worden ook niet voor elk ongeval aansprakelijk gesteld.
Er moet sprake zijn van opzettelijke schuld en opzettelijke nalatigheid niet iets van wat men niet kon weten. Daarvoor zijn er al die tests waaraan voldaan moet worden voordat het in de handel mag.
Er zal eerst een onafhankelijk testinstituut moeten komen voordat we met ict zover zijn. Nu is het de ene vind dit de ander dat. Wat nu als voor de meeste thuiscomputers er helemaal niets aan de hand is. Dat omdat amt eerst bewust geactiveerd moet worden voordat het actief wordt. Die instructie staat in de handleiding voor AMT.
Is er eens al een lijst van hoeveel thuiscomputers wel en niet (ns controle) getroffen zijn.
Is er al een lijst van het aantal thuiscomputers die A en getroffen zijn en B bloot opengesteld zijn aan het Internet omdat de Router Firewall alles doorlaat. Gaarne ook daar de verhouding komt door/komt niet door.
Dan verwacht ik dar er zeer klein promillage overblijft.
standaard aan hadden staan en dat ik indertijd heb moeten uitzoeken hoe je dit uit zet, en dat dit niet zo simpel was.
Je moest er eerst een sterk wachtwoord op zetten en dan pas kon je het uitzetten.
Voor je dit wachtwoord er op zette heette het dat het niet actief was maar mooi wel dat de systemen als ze uit waren
een DHCP lease vroegen en pingbaar waren. Dus ik weet niet of ze dan in het licht van deze bug vulnerable waren
maar dat zal vast wel.
Is er al een lijst van het aantal thuiscomputers die A en getroffen zijn en B bloot opengesteld zijn aan het Internet omdat de Router Firewall alles doorlaat. Gaarne ook daar de verhouding komt door/komt niet door.
Dan verwacht ik dar er zeer klein promillage overblijft.
Deze zullen dan door de klant zelf opengezet moeten zijn en dat gaat (voor zover ik weet) alleen per poort, en wie verzint nu zo'n poort nummer..........
Er moet sprake zijn van opzettelijke schuld en opzettelijke nalatigheid niet iets van wat men niet kon weten. Daarvoor zijn er al die tests waaraan voldaan moet worden voordat het in de handel mag.
In hoeverre dat zich naar deze situatie laat vertalen weet ik niet. Schade aan data is geen fysieke schade. Misbruik van de Management Engine is niet alleen een kwestie van een defect in de beveiliging maar er moet ook nog iemand zijn die dat defect daadwerkelijk misbruikt; de schade is geen gevolg van normaal gebruik ervan. Ik vermoed dat dat factoren zijn die maken dat de aansprakelijkheid een stuk minder duidelijk ligt. Dat Intel een probleem heeft op te lossen is overigens overduidelijk, maar het zou hier wel eens kunnen gebeuren dat reputatieschade meer doet dan juridische aansprakelijkheid.
Grove nalatigheid, waar buttonius het over had, is trouwens ook al geen kwestie van opzet. Scherp gedefinieerd is het niet, voor zover ik heb kunnen vinden, het lijkt zoiets als "meer dan normaal slordig" te zijn. Die omschrijving gebruikte Arnoud Engelfriet hier:
https://blog.iusmentis.com/2013/12/12/de-nieuwe-veiligheidsregels-van-de-banken/
https://blog.iusmentis.com/2013/12/12/de-nieuwe-veiligheidsregels-van-de-banken/
Wat ik in het van de ME engine niet goed vind is het delen van het TCP/IP verkeer. Een apart stekker was fraaier geweest duidelijk fysiek gescheiden. Een apart MAC adres met twee duidelijk gescheiden herkenbare datastromen is ook nog acceptabel. Maar echt alles gedeeld... Dat het klaarblijkelijk door het OS nog onderschept en teruggezet kan worden (MITM) is raar.
Voor die Pizza die niet goed zou zijn. Daarvoor hebben we hier allemaal keuringen met eisen van kwaliteit. Is het aangetoond dat die kwaliteit herhaalbaar en goed is dan mag het verkocht worden. Wordt er aan het proces met de kwaliteit gerommeld dan is er nalatigheid met schuld. Probeer dat zelfde verhaal eens in een land waar er niet van dat soort eisen zijn. Wat verkeerds in het eten pech gehad, geen verhaal mogelijk (voedselvergiftiging lokaal eten op reis).
Ik ben een voorstander van kwaliteitseisen voor cyberspul met de nodige keuringen en classificaties (geschikt voor).
4- je weet niet welke libraries en andere functies als vertrouwde code blokken binnengehaald zijn
3- je weet niet hoe de compiler(s) werkt (werken) Welke zou het dan moeten zijn.
2- je weet niet hoe de microcode in de processor werkt
1- je weet niet hoe de hardware in elkaar steekt en reageert.
(1,2,3) waren 30 jaar terug al een fundamenteel onoplosbaar iets, no 4 is er bij gekomen. Het betekent de mysterieuze aanname dat er veel goed zit zonder een echt bewijs. mysterieus open/close geen verschil.
Ik kan geen auto band controleren of die wel goed in elkaar zit, onbegonnen werk voor een gebruiker. Afgaan op ervaringen van anderen en kijken/waarnemen lukt nog.
Zo is de verwachting dat een gebruiker elk detail in een modern apparaat (ME of niet) zou kunnen controleren een illusie.
Tip: niet blijven dromen.
Deze posting is gelocked. Reageren is niet meer mogelijk.
Junior DevOps Engineer
Certified Secure is op zoek naar een Junior DevOps Engineer. Deze functie is een stuk interessanter dan de term doet vermoeden! Om jou als potentiële nieuwe collega meteen te laten zien wat we doen hebben we speciaal voor jou een selectie gemaakt van een aantal leuke security challenges. Are you ready for a challenge?
Cybersecurity Trainer / Streamer
Toe aan een nieuwe nieuwe job waarmee je het verschil maakt? In de Certified Secure trainingen laat je deelnemers zien hoe actuele kwetsbaarheden structureel verholpen worden. Ook werk je actief mee aan de ontwikkeling van onze gamified security challenges. Bij het maken van challenges kom je telkens nieuwe technieken tegen, van Flutter tot GraphQL, van Elastic Search tot Kubernetes.
