Onderzoekers schakelen Intel Management Engine uit via ongedocumenteerde functie

Onderzoekers van het beveiligingsbedrijf Positive Technologies hebben een manier gevonden om de Intel Management-functie uit te schakelen op cpu's van de chipmaker. Zij ontdekten een ongedocumenteerde functie die in het leven was geroepen in het kader van een NSA-programma.

Het onderzoek richt zich op de Intel Management Engine 11, die wordt toegepast op processors vanaf de Skylake-generatie. Deze aparte processor werkt los van de cpu zelf en is daarom toegankelijk als de cpu zelf is uitgeschakeld. Volgens Intel kan deze voor beheer op afstand worden gebruikt. De processor biedt functies als het opnieuw opstarten van een systeem en heeft volgens de onderzoekers toegang tot vrijwel alle gegevens op een systeem. Als een kwaadwillende toegang tot de engine krijgt, betekent dit dan ook een groot risico. Critici van de functie hebben deze doorgaans dan ook aangeduid als een backdoor.

Het uitschakelen van de functie is niet mogelijk, al hebben verschillende projecten geprobeerd dit voor elkaar te krijgen. De onderzoekers noemen onder meer het 'me_cleaner'-project, waarmee de functie grotendeels is uit te schakelen. Maar ook deze methode heeft tekortkomingen, zo is het mogelijk dat het systeem na 30 minuten opnieuw opstart. Dit jaar bleek bovendien dat er lange tijd een kwetsbaarheid in een onderdeel van de Management Engine, de Active Management Technology, aanwezig was. Dit liet aanvallers toegang krijgen tot systemen.

De onderzoekers schrijven dat analyse van de engine tot nu toe onmogelijk was, omdat de executable modules gecomprimeerd waren met Huffmancodering zonder dat de gebruikte tabellen bekend zijn. De onderzoekers zeggen niet hoe ze achter de nodige tabellen zijn gekomen, maar hebben een tool op GitHub gepubliceerd waarmee de images uitgepakt kunnen worden. Dit stelde hen in staat om verdere analyse uit te voeren.

Ze vervolgen dat ze in verschillende tools, die Intel normaal gesproken aan hardwaremakers ter beschikking stelt om enkele parameters van de engine in te stellen, een grote hoeveelheid xml-bestanden vonden. Deze bevatten een veld met de naam 'reserve_hap', waarin bovendien werd verwezen naar het zogenaamde High Assurance Platform. Dat is een aan de NSA verbonden platform dat zich richt op informatiebeveiliging. Door deze functie in te schakelen, lukte het uiteindelijk om de Management Engine vroeg in het bootproces uit te zetten. De onderzoekers vonden tot nu toe geen code waaruit blijkt dat de engine zelf uit deze modus kan 'ontsnappen'.

Intel reageerde op vragen van de onderzoekers: "Als reactie op verzoeken van klanten met speciale eisen onderzoeken we soms het aanpassen of het uitzetten van bepaalde functies. In dit geval zijn de aanpassingen doorgevoerd op verzoek van hardwaremakers om kun klanten te ondersteunen bij het High Assurance Platform. Deze aanpassingen hebben beperkte validatie ondergaan en het gaat niet om een officieel ondersteunde configuratie."

De onderzoekers schrijven dat ze ervan uitgaan dat dit een 'typische eis' is van overheden om side channel leaks te voorkomen.

Reacties (77)

[WhatsappHack]

Mooi is dat altijd eigenlijk. Iedereen mekkeren over opensource vs closed source enzo, maar t maakt eigenlijk allemaal geen reet uit als je CPU vol met backdoors zit. :’)

[Olaf van der Spek]

Daarom willen we eigenlijk ook open hardware.

[WhatsappHack]

Dat snap ik, al biedt dat echt geen enkele garantie op meer veiligheid of het ontbreken van backdoors (het is ook nooit aangetoond dat OS veiliger is dan CS, of vice-versa); en loopt men het risico op een false sense of security. Maar dat gaat denk ik niet zomaar gebeuren... Althans niet als je dezelfde prestaties wil. Tot de tijd dat het misschien wél een keer gaat gebeuren zul je t hiermee moeten doen, helaas!

[kimborntobewild]

het is ook nooit aangetoond dat OS veiliger is dan CS

Voor een optimale veiligheid is het simpelweg een voorwaarde dat je Open Source gebruikt. (En ja, hardware met ingebakken software valt daar uiteraard ook onder.)
Geen garantie, maar wel een voorwaarde. Bij Closed Source kan je het simpelweg niet controleren of de boel veilig is geprogrammeerd en of er geen backdoors in zitten.
Sterker nog, als je dat probeert (reverse engineren, wat gigantisch veel tijd kost), kunnen ze je misschien zelfs in 't gevang stoppen (omdat bepaalde typen van reverse engineering illegaal verklaard zijn.

Althans niet als je dezelfde prestaties wil.

Wat hebben prestaties ermee te maken?

Net zoals wielen onder je auto een voorwaarde is om vooruit te kunnen komen; maar geen garantie (als je motor stuk is, kom je ook niet vooruit).

Bij tegenstanders van Open Source wordt vaak het verschil tussen de betekenissen van voorwaarde en garantie genegeerd.

Een voorwaarde voor Security by Obscurity is Closed Source. Maar we weten inmiddels allemaal (hoop ik) dat Security by Obscurity geen optimale veiligheid biedt, ondanks dat overheden / security agencies je dat willen laten geloven.

[Reactie gewijzigd door kimborntobewild op 23 juli 2024 06:50]

[WhatsappHack]

Dat kan je ook niet als je werkelijk elke opensource tool wil gaan doorlichten. Kijk eens naar je gemiddelde Linux installatie inclusief alle tools, wil jij beweren dat je elke regel broncode van elk stukje software hebt doorgenomen; inclusief de complete kernel code en alle modules en drivers? Zo nee, waarom niet en waarom heb je wel blind vertrouwen in de community maar niet in prof auditing bedrijven die onafhankelijk CS code nakijken?
Ik zie niet in waarom de openbaarheid van de source een voorwaarde zou moeten zijn. Security by obscurity is geen security, en de beveiligingsonderzoekers op deze wereldbol hebben nooit perse een bron nodig gehad; het helpt alleen soms om sneller fouten te vinden. (En soms helpt het niets en zit er jarenlang een gapend megagat in dat duizenden mensen over het hoofd hebben gezien. Zie heartbleed.)

Prestaties als in: er kan een partij komen die alles geheel open maakt, maar dat zal geen Intel of AMD zijn. De kans dat die hardware zich dan kan meten is nogal klein. Corporate secrets is nogal een dingetje zegmaar.

Ik vind het geen voorwaarde. Er is zat geweldige CS software die beter en veiliger is dan haar OS tegenhanger, ge-audit en wel. Ik ga dan niet alsnog de FOSS versie pakken “want open is een voorwaarde”. Daar knal je enkel jezelf mee in de voet. Alles open is een utopië dat, ben ik bang, er gewoon niet gaat komen. Mijn VOORKEUR gaat uit naar open, maar het is geen stricte voorwaarde; zeker niet als de gesloten bron software zich prima bewezen heeft en ge-audit is. Of ik nou op de community vertrouw of op meerdere onafhankelijke auditors; weinig verschil. “Ja maar dan KAN je de bron zien als je wil”, ja prima maar ik ga liever af op ‘t oordeel van meer gekwalificeerde personen en bespaar me de tijd om miljoenen regels code door te nemen; daar heb ik geen tijd voor.

[kimborntobewild]

prof auditing

Geen enkel prof auditing bedrijf heeft de onderzoekskracht zoals in de Open Source wereld (nl: de hele wereld kan dan meekijken). Verder is zo'n prof auditing financieel afhankelijk van de opdrachtgever, en niet 100% onafhankelijk.

wil jij beweren dat je elke regel broncode van elk stukje software hebt doorgenomen; inclusief de complete kernel code en alle modules en drivers?

Dat hoef ik niet te doen; maar de hele Open Source community in zijn totaal kan dat wel. Bij Closed Source kan dat niet (reverse engineering kost simpelweg veel teveel tijd. Voor zover al mogelijk).

Als je Closed Source gebruikt, weet je zeker dat de code niet door grote groepen gerenomeerde programmeurs/veiligheidsspecialisten bekeken is. Daarom is Open Source een voorwaarde voor optimale veiligheid.

Als Closed Source ook door een prof auditing bedrijf laat bekijken (en niet alleen door de community), da's natuurlijk nog beter.

[Reactie gewijzigd door kimborntobewild op 23 juli 2024 06:50]

[SunnieNL]

Het is toch ondertussen wel bekend dat open source niets uitmaakt. Al kan de hele wereld meekijken, dat doen ze niet. Gaten blijven ook bij open source gewoon jaren en jaren on-ontdekt door de wereld. Zelfs gaten in de modules die juist extra veiligheid horen te geven en waarvan je verwacht dat ze juist extra door derden zijn gecontroleerd.

[Step5]

Dan gaat het om bugs, niet om moedwillig ingebouwde backdoors

[WhatsappHack]

En bij closed source gaat het standaard om ingebouwde backdoors en kan het niet ook gewoon een bug zijn? Ik vind dat altijd apart om te zien. Bij een closed-source app als er een (potentiële) bug of window of opportunity inzit dan is het meteen een backdoor, maar als bij FOSS hetzelfde aan de hand is dan is het opeens een bug die gewoon gepatched moet worden en ligt niemand er wakker van.

Overigens, bij open source zijn ook vaak zat moedwillig backdoors ingebouwd. Soms zonder medeweten van de auteur/community, maar soms ook door de auteurs zelf. FOSS is echt niet heilig...

[dasiro]

volgens jouw definitie is windows dan geen closed source, want er zijn genoeg partijen (overheden en hardware-leveranciers) die de source mogen inkijken (met NDA's en andere restricties, maar het mag)

[Verwijderd]

Je moet natuurlijk lezen wat hij schrijft:

Geen enkel prof auditing bedrijf heeft de onderzoekskracht zoals in de Open Source wereld (nl: de hele wereld kan dan meekijken).

Die overheden en hardware-leveranciers in totaal zijn niet met zo velen als de hele open source wereld (nl: de hele wereld kan dan meekijken).

[WhatsappHack]

De hele wereld kan meekijken, maar het leeuwendeel kijkt niet mee zoals @SunnieNL ook al opmerkt; of kijkt wel maar heeft er de ballen verstand van en weten niet waar ze nou naar kijken. Er zijn relatief niet zo superveel mensen die écht weten waar ze t over hebben en dan bijdragen. Sure, er zijn grote projecten waar veel experts aan bijdragen; maar ook die auditen vaak delen en niet ‘t geheel dus ALLES wat er bij komt kijken. Dat gebeurt weinig, en dan kan je ‘t ook omdraaien: die groep die dat doet, doet dit vaak in eigen tijd als t uitkomt en hebben niet speciaal hiervoor financiële middelen, terwijl een professioneel bedrijf werknemers heeft die niets anders doen dan auditing, hebben daar t geld voor en investeren tevens in krachtige computers om vele simulaties en geautomatiseerde pentests en behaviour analysis uitvoeren. De werknemers worden getraind.

Dus tja, ik denk dat t elkaar weinig ontloopt eigenlijk. De POTENTIE van opensource is, helaas, niet wat we terug zijn in de praktijk. De hele wereld kijkt niet mee, zo simpel is het helaas.

Dat hoef ik niet te doen; maar de hele Open Source community in zijn totaal kan dat wel. Bij Closed Source kan dat niet (reverse engineering kost simpelweg veel teveel tijd. Voor zover al mogelijk).

Dat kan, maar dat t ook echt gebeurt is een tweede, en wat de kwaliteit is (van hun kennis em hoe diep/ver ze gaan) is de derde factor.
Decompilen kost niet al teveel, maar t klopt dat niet iedereen ernaar kan kijken; in hoeverre dat gegeven echter de veiligheid beinvloedt is NOOIT bewezen. In alle onderzoeken komt naar voren dat qua veiligheid en aantal problemen CS en OS niet tot nauwelijks schelen van elkaar, en dat zegt wat.

Als je Closed Source gebruikt, weet je zeker dat de code niet door grote groepen gerenomeerde programmeurs/veiligheidsspecialisten bekeken is. Daarom is Open Source een voorwaarde voor optimale veiligheid.

Nee, dat weet je niet zeker... Dat ligt eraan wie eraan werken en wie het allemaal auditen. En andersom kan ik die stelling ook maken: bij opensource weet je t ook niet zeker dat het door grote groepen, etc. etc.. Dus wederom scheelt dat niet van elkaar. Nogmaals, de potentie van opensource en OS auditing mag je niet 1 op 1 doortrekken alszijnde “dit is ook de situatie in de praktijk.”. Als je t OS project niet vertrouwt, en enige skepsis is altijd gezond, dan moet je...? Het laten auditen! Als je t CS project niet vertrouwt, en enige skepsis is altijd gezond, dan moet je...? Het laten auditen!
Same shit, different day.

Als Closed Source ook door een prof auditing bedrijf laat bekijken (en niet alleen door de community), da's natuurlijk nog beter.

Optimaal is langdurig open source, veel vanuit de community bekeken en vervolgens nog een audit.

Kijk, in perspectief: je hebt verschillende scenario’s:
1) FOSS en niet geaudit
2) CS en niet geaudit
3) FOSS en geaudit
4) CS en geaudit
5) Hybrides, maar die vergeten we ff

1 en 2; Gelijkwaardig, maar mild voordeel voor FOSS
1 en 4: Gelijkwaardig, maar mild voordeel voor CS.
2 en 3: FOSS wint
3 en 4: Gelijkwaardig, maar FOSS heeft een voordeel als de expert community, hopelijk, ook meekijkt. Doen ze dat niet tot nauwelijks dan is het gewoon gelijkspel tussen deze twee.
Noot: dit zegt niets over de veiligheid, enkel iets over risico’s. Immers, een niet-geaudit CS project kan best super veilig zijn terwijl een compleet geaudit FOSS project zo lek als een vaatdoek kan zijn. Het zegt dus enkel iets over risicovermindering dat een lek over t hoofd wordt gezien, maar garanties zijn er niet op veiligheid noch onveiligheid. (Derhalve mijn eerdere punt: CS kan super veilig zijn en FOSS super onveilig; en vice versa, je weet het gewoon NOOIT zeker en daarom ontlopen ze elkaar qua algemene veiligheid totaal niet. Hoe groter het project, hoe groter de gok; zowel bij foss als cs.)

Wat zien we? In optimale omstandigheden wint FOSS vaker op het gebied van laag risico dat een lek over het hoofd wordt gezien. (Wederom: GEEN garanties! Onthoud dat altijd.). Maar drie belangrijke voorwaarden:
- De community MOET actief meedoen en je moet dat kunnen controleren
- De optimale situatie doet zich lang niet zo vaak voor als we willen binnen FOSS
- Zelfs in de optimale situatie worden zaken over het hoofd gezien, waardoor het geen garanties biedt. Dit terwijl in suboptimale situaties bij audits soms juist niets is gemist. (Sure, ook daar worden zaken over t hoofd gezien, maar we moeten t eerlijkheidshalve wél vermelden dat de situatie zich kan voordoen. Het werkt netjes twee kanten op. )
- Een cop-out, maar ik moet hem noemen want het is een feit: FOSS levert niet enkel voordelen op risicobeperking, maar kan ook een risicovergroting zijn! Opensource kan juist averechts werken omdat een aanvaller ook de gehele source kan zien, kan besluiten niets te zeggen en t lek exploiten. Dit kan bij CS 100% ook (vandaar dat ik ook zei dat in de itsec wereld de bron als bonus wordt gezien ipv vereiste , alleen zal daar meer werk inzitten omdat je niet het lek direct kan zien. Dit klinkt haast als “security by obscurity is security!” maar dat zeg ik expliciet niet, want t blijft een beveiligingslek, het is eerder “staying obscure/unnoticed (for a longer period of time than with source access) due to obscurity”. Dus in de ene situatie is FOSS beter en CS vervelender omdat bij CS veiligheidslekken meer moeite kosten om te vinden zonder dat je bron toegang hebt (zoals een audit bedrijf); maar andersom in een andere situatie kan CS beter zijn en FOSS vervelender, juist omdat het makkelijker is om sneller lekken te vinden terwijl dat bij CS meer tijd kost. Snap je wat ik bedoel?

Waardoor je in zijn algemeenheid concluderend, en nogal complex, kan stellen: opensource en closed source doen niet per definitie aan elkaar onder qua veiligheid/betrouwbaarheid, en verlaagd risico is enkel van toepassing als de optimale situatie behaalt wordt, maar zowel bij foss als cs, geaudit of niet, heb je altijd risico en nul garanties.
Zowel FOSS als CS hebben hun voor en nadelen, en je kan derhalve nooit stellen dat FOSS per definitie veiliger of betrouwbaarder is dan CS; want andersom kan t ook prima t geval zijn. Beiden kunnen zowel veilig als onveilig zijn, zonder dat je dat per definitie zeker kan weten of zekerder kan zijn van je zaak (doordat de bron open is). Dat mensen meekijken levert geen substantiële extra veiligheid op by design, en als dat t wel doet dankzij optimum situatie: dan nog komt t weer in evenwicht door de mogelijke nadelen die diezelfde openheid als neveneffect kent. Kortom: ja, open heeft wat mij betreft ondanks de nadelen de voorkeur. Nee de een is nooit per definitie veiliger dan de ander. En als t dus de keuze is tussen een random FOSS project zonder audit en/of weinig community activity: dan is een CS programma gelijkwaardig qua veiligheid, en na audit zelfs superieur. Kies dus altijd met wijsheid en veel research welke software je gaat gebruiken, of t nou FOSS of CS is: bekijk t bewijs, de aanwijzingen en de track record qua veiligheidsproblemen, en maak daarna pas je keus voor t juiste pakket. Is de uitkomst toevallig dat je closed source app wss veiliger is? Kies dan niet voor de open variant puur omdat die open is!!

Ik val in herhaling een stukje hierboven, maar ik kan niet hard genoeg benadrukken dat men zeer voorzichtig moet zijn met de aanname dat FOSS per definitie veilig is of een voorwaarde moet zijn om veiligheid te kunnen behalen.

Dit standpunt zie je trouwens in vrijwel alle onderzoeken naar FOSS vs CS terug. Om verschillende redenen wijzen de statistieken uit dat ze niet onder doen aan elkaar qua veiligheid/betrouwbaarheid, en dat is heel logisch verklaarbaar met o.a. de punten hierboven genoemd. De conclusie is dan ook altijd: foss vs cs? Indefinite. Er kan geen winnaar gekozen worden, het ligt aan meerdere factoren; zoek dus altijd t beste via onderzoek, ongeacht bron toegang of geen bron toegang. En laat het open zijn van de bron je geen vals gevoel van veiligheid geven, en t ontbreken van de bron je geen vals gevoel voor onveiligheid. Je moet gewoon altijd paranoïde zijn en onderzoeken, en dan pas t juiste kiezen; ongeacht de bronstatus.

[Reactie gewijzigd door WhatsappHack op 23 juli 2024 06:50]

[archive23]

Je vergeet wel dat na een audit van een open source codebase, (veel makkelijker) een vervolgaudit kan plaatsvinden door een andere partij omdat de bron open is. Met CS zou je toestemming moeten vragen aan diegene die de sleutels tot de broncode heeft (of een blackbox approach doen, maar dat is natuurlijk veel moeilijker).

[kidde]

Ik vind het geen voorwaarde. Er is zat geweldige CS software die beter en veiliger is dan haar OS ... ge-audit en wel

OK, 'open source' is dus een voorwaarde om het goed en in korte tijd door te lichten. Precies zoals u zegt is er goede CS die gecontroleerd is, juist omdat de 'source' 'open' was voor de 'auditor'.

Dat lijdt tot de vraag "kan een auditor zijn werk doen als het ontwerp voor hem / haar niet in te zien is"? Want als dat ook kan, dan is open source geen voorwaarde. Op zich kan dat, want ook mensen die de open code van Windows / Java / Flash / Adobe Reader en andere kazen met gaten niet konden inzien, vonden vaak zat gaten. Dat leidt dan weer tot de vraag, of u het een voorwaarde vindt, dat men die controleerde of het vliegtuig waar u in vliegt veilig is, of die de dam controleerde van de polder onder NAP waar u kan wonen, inzage had in het ontwerp. Dit kan zeer goed leiden tot filologische praat over het woord "voorwaarde", dit laat ik maar aan de lezer over, dus waarvan akte. Ik als simpel mens, zou echter wel heel blij zijn als men controleert met 'open' ontwerp.

[SoundByte]

Men kan direkt talloze articles vinden over de mogelijkheid van backdoors in bekende Linux distributies. En inderdaad wie vertrouwt die zooi blind al is het opensource. Nouja leken als ik moeten wel want ik schrijf nog geen code. En zelfs programmeurs laten het erbij zitten. Het idee van opensource geeft ze een false sense of security helaas.

[Verwijderd]

het is ook nooit aangetoond dat OS veiliger is dan CS, of vice-versa

Het is een harde eis dat je OS nodig hebt voor veiligheid. CS is per definitie niet veilig.

[WhatsappHack]

Dat is echt de grootste onzin die er is. Closed source per definitie onveilig noemen is wat mij betreft veel te kort door de bocht en gewoon pertinent onwaar. Dat je het als onveilig wil beschouwen is een ander verhaal en een persoonlijke keuze.

In de hacking en research wereld is het uitgangspunt altijd dat je de bron niet kent, maar de bron erbij hebben is louter een bonus. Je kijkt altijd maar de compoled binaries en gaat die onderzoeken, decompilen, etc: dat de bron er is, dat is soms mooi meegenomen maar verre van een voorwaarde.
Wie garandeert immers dat de bron die je ziet ook gebruikt wordt in de compiled binary? Bij software die je zelf kan compilen is dat een optie, maar dat is lang niet altijd zondermeer mogelijk. (Plus veel succes om sommige megaprojecten eerst zelf helemaal door te lopen alvorens het te compileren. Of vertrouw je dan de community? En waarom die wel, maar professionele auditors van CS-software niet?)

Er is zat closed source software die enorm veilig is en zeer goed in elkaar steekt, vaak geaudit en wel, en zat opensource software die zo onveilig als de pest is; soms ondanks audits. Kijk naar heartbleed, shellshock, poodle, et cetera.

Don’t get me wrong, ik ben groot voorstander van opensource, draag bij aan meerdere foss projecten en beheer ook een groot foss project. Maar ik maak me geen illusies en schrijf CS absoluut niet standaard af als onveilig; dat is gewoon onzinnig. Opensource is geenszins per definitie veiliger dan closedsource software.

[Reactie gewijzigd door WhatsappHack op 23 juli 2024 06:50]

[sab]

Onveilig is misschien het goede woord, maar het is wel per definitie onbetrouwbaar - je hebt immers geen garanties over backdoors die je bij open source wel hebt.

[WhatsappHack]

Sorry maar dat is schijnveiligheid. Ook in opensource projecten kunnen, soms verrekte slimme, backdoors zitten. Is het risico groter om gepakt te worden? Sure, maar dat is geen reden om aan te nemen dat die backdoor ook (snel) gevonden wordt. Er bestaan geen garanties dat opensource software backdoor of veiligheidslek vrij is. Nogmaals, zie heartbleed. Dat was, voor zover we weten, geen backdoor: maar neem voor de lol eens aan dat dat het wel was. In hoeverre heeft het open zijn van de bron je dan al die jaren dat de bug er in zat beschermd? Dat kan je toch geen garantie noemen? Het is uiteindelijk gelukkig gevonden, maar men vindt ook fouten en beveiligingslekken in closed source software, ook zonder directe toegang tot de bron.

[Verwijderd]

Niemand claimt dat open source altijd veilig is. Dat maak jij ervan. Ik zeg alleen dat het hebben van open source 1 van de eisen is voor veiligheid.

[WhatsappHack]

Nee, maar er wordt wel geclaimd dat closed source altijd onveilig is en op die stelling reageerde ik, nu draai je het om. Ik heb louter gezegd dat opensource niet altijd veilig is, en closed source niet altijd onveilig; dat zwart wit beeld is gewoon extreem kort door de bocht.

Dat het een van jou persoonlijke eisen is, dat mag uiteraard.

[sab]

onbetrouwbaar. Niet onveilig.

[SoundByte]

search: debian backdoors en je krijgt gelijk dit:

https://www.google.nl/amp...-is-owned-by-the-nsa/amp/

RedHat en Debian dus uit den boze.

[sab]

Dat lijkt mij juist het grote voordeel van Open Source aantonen. In het geval van Closed Source was je hier nooit achter gekomen. Nu is het aan het licht gekomen en gepatched. Beetje jammer van de clickbait titel in dat artikel, dat wel.

[Olaf van der Spek]

al biedt dat echt geen enkele garantie

Ik zie open source projecten als Debian niet zo snel zaken toevoegen die tegen de belangen van gebruikers zijn.
Natuurlijk, garanties heb je nooit, maar dat is geen reden om dan maar niks te doen.

[WhatsappHack]

Doch kan iedereen bijdragen en als een fout over t hoofd wordt gezien kan er een backdoor/lek geintroduceerd worden. Dat de beheerder de allerbeste intenties heeft voor iedereen staat vast bij Debian, maar goede voornemens bieden helaas ook geen garantie op succes en waterdichtheid bij opensource.

Ik vind het zeer gevaarlijk om FOSS sneller of blind te vertrouwen, en CS standaard af te doen met onveilig. Mijn voorkeur heeft open, maar soms is CS de enige realistische optie en soms ook de enige veilige.

[Reactie gewijzigd door WhatsappHack op 23 juli 2024 06:50]

[Olaf van der Spek]

Wat biedt wel garantie?

Een vulnerability kan inderdaad over het hoofd gezien worden maar dat is toch geen reden om open source helemaal af te schrijven?
Feit blijft dat veel niet-open projecten keer op keer tegen de belangen van gebruikers in gaan.
En dat je er met niet-open projecten per definitie totaal geen zicht op hebt.

[Reactie gewijzigd door Olaf van der Spek op 23 juli 2024 06:50]

[WhatsappHack]

Niets, er is niets dat garantie biedt.

Maar ik schrijf opensource helemaal niet af Sterker nog, ik ben er groot voorstander van. Ik schrijf alleen closedsource niet af, want dat gaat nergens over naar mijn mening. Ik beschouw beide vormen als even onveilig.

[Glazenwasser]

(het is ook nooit aangetoond dat OS veiliger is dan CS, of vice-versa)

Oh, jawel: https://www.dwheeler.com/oss_fs_why.html#security

Althans niet als je dezelfde prestaties wil.

In ieder geval bij open SOFTware is de performance zelfs beter: https://www.dwheeler.com/oss_fs_why.html#performance

Daarnaast, als je eenmaal veilige, snelle OS hebt, dan mag je die ook blijven gebruiken, zodat je ook veilig blijft. Het gaat dus nadrukkelijk niet alleen maar om het open-aspect, maar zeker ook om het vrijheids-aspect. Er is een reden dat sommige de mensen de term Vrije Software verkiezen boven Open Source.

[Reactie gewijzigd door Glazenwasser op 23 juli 2024 06:50]

[SoundByte]

Ik ga er al jaren vanuit dat updates alleen dienen om backdoors te dichten die expres een tijdlang zijn opengelaten voor inlichtingen. Ze moeten gedicht voordat de derde partij/hacker community erachter komen.

[Reactie gewijzigd door SoundByte op 23 juli 2024 06:50]

[Zenety]

Precies, en daarom zou ook de hardware compleet open source moeten zijn.

[WhatsappHack]

Dat is firmware, ook een vorm van software. Maar ik begrijp dat je graag open-spec hardware zou willen hebben waavan alle firmware en routines opensource zijn. Ondanks dat dit geen enkele garantie op veiligheid biedt.

[kimborntobewild]

Ondanks dat dit geen enkele garantie op veiligheid biedt.

Nee, maar toch wil je het. Je wilt toch ook geen auto zonder wielen?

[WhatsappHack]

Een auto zonder wielen biedt een verhoogde veiligheid, omdat je er de weg niet mee op kan... Het resultaat is dat je minder weggebruikers tegenkomt en op veel minder hoge snelheid, en dus is een auto zonder wielen arguably veiliger dan een auto mét wielen.
Ja sorry hoor, maar dit is toch geen vergelijking?

Maar ik help je hem fixen. Een auto met airbag biedt me geen garantie dat ik bij een crash in leven blijft, maar ik wil het wel graag hebben.
Echter, dit kan je zo niet doortrekken naar FOSS. Een anekdote om mijn invalshoek uit te proberen te leggen: Een airbag biedt me als ie werkt de garantie dat ik minder risico heb om te overlijden. Als ie niet werkt helpt ie me niet. Het is echter Schrödinger’s airbag: hij kan zowel werkend als kapot zijn, je weet pas of ie t echt doet als je crasht en dan hoop je maar dat ie werkt; maar je hebt geen garanties dat ie werkt. Bij FOSS en CS (jep.) tezamen idem-dito: het is fijn om te hebben, absoluut, maar je weet gewoon niet of het wel echt goed nageplozen is door de community en/of auditor. Je hoopt er op dat het proces heeft gewerkt, maar garanties dat t zo is (“of je airbag wel of niet werkt”) heb je niet. Je zou kunnen stellen dat het risico minder is omdat FOSS als “airbag” fungeert omdat de kans groter is dat iemand ernaar gekeken heeft dan bij CS, alleen gaat die vlieger verre van altijd op en opnieuw is er geen garantie dat er werkelijk mensen goed naar hebben gekeken puur omdat t open is. Je weet dus niet in hoeverre het open zijn van de bron enige meerwaarde heeft geboden en of die “airbag” überhaupt wel aanwezig is in “je auto”, en dat kan helaas dus zelfs als gevaar hebben dat je ten onrechte een gevoel van veiligheid krijgt. (En dus moet je niet als je een airbag hebt opeens roekelozer gaan rijden “want ik heb toch een airbag”, neen: je moet nog steeds voorzichtig rijden, alleen als je onverhoopt toch een ongeluk krijgt én hij werkt: dan is dat louter erg mooi meegenomen, maar vooraf aan de crash heb je daar weinig aan omdat je in ‘t ongewis bent over de werkzame staat van de airbag.) Als je snapt waar ik heen wil en wat ik ermee wil zeggen?

Ik zie dus FOSS over t algemeen (niet altijd, zie nadelen in mn andere post) dus net als die airbag als een *luxe* (en dat is puur omdat ik zélf de bron kan begrijpen ALS ik de moeite neem om ernaar te kijken (en dat doe ik vaak niet, ik vertrouw vaak op anderen; net als bij CS .)), maar niet als iets dat per definitie en in alle situaties mijn veiligheid zeker weten vergroot en het risico op problemen verlaagt. Sure sure, de kans dat die airbag werkt is zeer groot (zeer strenge eisen en veel checks als je auto aangaat) en dus kan je er vanuitgaan dat ie het doet. Hetzelfd kan ik helaas niet zeggen over FOSS, want de noodzakelijke processen voor veiligheid worden daar lang niet altijd nageleefd en het is ook nauwelijks mogelijk allerlei checks uit te voeren om te zien in hoeverre de community ervoor heeft gezorgd dat t op dit gebied werkt dankzij de vele controles en ga zo maar door. Fijn? Ja. Meerwaarde qua veiligheid? Niet per definitie. (En dat geldt wederom in twee richtingen, zowel voor CS als FOSS)

Dus:
Vind ik het fijn dat mijn auto een airbag heeft? Absoluut.
Vind ik het fijn dat mijn software opensource is? Meestal zeker wel.
Maakt de airbag het gegarandeerd veiliger? Nee, enkel als ie werkt levert t 8% winst op.
Maakt opensource het gegarandeerd veiliger/betrouwbaarder dan closed source? Neen, in geen enkel geval; zeker omdat t ook kan zijn dat juist blijkt (hopelijk niet “achteraf” ) dat de CS software superveilig was, maar de FOSS juist niet.

Opensource is fijn om te hebben, maar ik zie het niet by default als toevoeging aan de veiligheid. Absoluut niet. Zoals eerder gesteld sterker nog: soms kan t juist afbreuk doen aan de veiligheid.

Daarom: ja, opensource is fijn. Ja ik wil graag opensource.
Maar wederom toch ook: Neen, FOSS biedt echter op geen enkele wijze meer veiligheid of betrouwbaarheid dan CS in de meeste gevallen. (Trouwens, voor leken die niet zelf naar de bron kunnen kijken maakt t al helemaal weinig uit: je moet altijd een ander blind vertrouwen.) FOSS en CS zijn qua veiligheid en betrouwbaarheid gelijkwaardig aan elkaar, en bij dat standpunt blijf ik vooralsnog gezien ik geen overtuigend materiaal heb gezien om me van zienswijze te doen veranderen. _{(Noot: just in case, daar bedoel ik niet mee dat ik jou visie niet respecteer. En ik vind t tof dat je zoveel tijd steekt om je standpunt helder te maken. Fijne discussie. Ik ben tot dusver gewoon nog niet overtuigd van jou mening en denk er anders over.)}

[Reactie gewijzigd door WhatsappHack op 23 juli 2024 06:50]

[kimborntobewild]

Ja sorry hoor, maar dit is toch geen vergelijking?
Maar ik help je hem fixen. Een auto met airbag biedt me geen garantie dat ik bij een crash in leven blijft, maar ik wil het wel graag hebben.

Je begrijpt de vergelijking niet.
Je hebt wielen nodig om de auto voort te kunnen bewegen.
Zo heb je ook Open Source nodig voor optimale veiligheid.
Je moet het niet moeilijker maken .
Zoals je niks aan een auto hebt zonder wielen, heb je óók niks aan Closed Source - àls je optimale veiligheid wilt.

Bij FOSS en CS (jep.) tezamen idem-dito: het is fijn om te hebben, absoluut, maar je weet gewoon niet of het wel echt goed nageplozen is door de community en/of auditor.

Deze redenatie is niet van toepassing, op mijn standpunt dat Open Source een voorwaarde is, en geen garantie, om optimale veiligheid te bieden.

Jouw anekdote geeft aan dat Open Source geen garantie is voor een veilig systeem. Terwijl ik dat ook nooit beweer.

...omdat FOSS als “airbag” fungeert omdat de kans groter is dat iemand ernaar gekeken heeft dan bij CS...

Ook hier slaat dat meer op vooral kijken naar 't woord garantie, en niet naar 't woord voorwaarde. Je weet doorgaans wìe de software gemaakt heeft; dus kom je er als progammeur simpelweg niet zomaar mee weg als je met opzet een backdoor in je software doet voor 'security agencies'. Je wéét je dat anderen eenvoudig mee kunnen kijken in je code, dus stop je ook niet zo gauw overbodige easter-eggs in je software, en wéét je dat iedereen je broddelwerk kan zien als je daadwerkelijk broddelwerk aflevert. Allemaal incentives om een beter (vooral qua security/backdoors) programma te schrijven, dan als je Closed Source schrijft.

(en dat is puur omdat ik zélf de bron kan begrijpen ALS ik de moeite neem om ernaar te kijken (en dat doe ik vaak niet, ik vertrouw vaak op anderen; net als bij CS .)

Bij CS vertrouw je op (doorgaans) één of twéé commerciële partijen. Eén, als de code niet is bekeken door prof auditing (en ik denk dat slechts een extreem klein deel van de software door prof auditing is bekeken), en twéé, als het dus wel door prof auditing is bekeken. Dus doorgaans moet je gewoon het softwarebedrijf zèlf 100% vertrouwen. Verder gaat het er níet alleen om of jij de code kan begrijpen, maar of er iemand is die dat wel kan. En bij Open Source is die groep 'iemand' vele malen groter dan bij Closed Source waar hooguit een collega van hetzelfde bedrijf - of bij hoge uitzondering een 'prof auditing' bedrijf - mee kan/zal kijken. Alleen al omdat het kan, bij Open Source, is Open Source een voorwaarde voor optimale veiligheid.

Maakt de airbag het gegarandeerd veiliger? Nee, enkel als ie werkt levert t 8% winst op.

Je negeert hierbij het verschil tussen voorwaarde en garantie. Twee verschillende begrippen.
En het is trouwens wel 100% zeker dat je meer kans hebt dat je airbag wel werkt, dan als je geen airbag zou hebben. En in dit geval héél wat meer kans (dat een airbag niet werkt, is maar een hele kleine kans. Dat je airbag niet werkt als je hem niet hebt: die kans is oneindig maar hoger).

...zeker omdat t ook kan zijn dat juist blijkt (hopelijk niet “achteraf” ) dat de CS software superveilig was, maar de FOSS juist niet.

Zolang iets Closed Source is, kan niet achteraf blijken dat die software achteraf superveilig was. Dan moet je blijven vertrouwen op één, twéé of hooguit een paar meer bedrijven, c.q. hun conclusies. Ik vertrouw die conclusies niet, zolang de code gesloten blijft. Sinds wanneer moet ik bedrijven vertrouwen? Die doen vooral handelingen om hun bedrijf voort te laten bestaan; niet vooral handelingen die gericht zijn op 'open zijn naar de consument'.
Verder kan je een Closed Source programma sowieso niet vergelijken met 'een Open Source programma die ongeveer hetzelfde doet'; simpelweg omdat je niet in de Closed Source versie kan kijken. Een goed vergelijk is niet mogelijk.

Zoals eerder gesteld sterker nog: soms kan t juist afbreuk doen aan de veiligheid.

Je bedoelt vast dat er in Open Source ook fouten kunnen zitten? Maar dat doet niks af aan mijn standpunt dat Open Source een voorwaarde is voor optimale veiligheid (niet: een garantie).

(Trouwens, voor leken die niet zelf naar de bron kunnen kijken maakt t al helemaal weinig uit: je moet altijd een ander blind vertrouwen.)

Da's m.i. een onjuiste opmerking; juist bij Closed Source gaat het om 'een (1) ander blind vertrouwen', bij Open Source juist niet; daar kan eenieder (niet 1) meekijken. Het kunnen er wel 10 of 100 zijn. Daarom kan je ook niet zomaar met opzet een achterdeur in je Open Source inbouwen. Uiteindelijk komt men er nl. toch achter. Bij Closed Source weet je 't gewoon niet. Je moet puur vertrouwen op het softwarebedrijf. Er is geen enkel softwarebedrijf die ik vertrouw. Als een softwarebedrijf gedwongen wordt er een backdoor in te bouwen, dan mogen ze dat ook niet vertellen. Daarom is elk vertrouwen in een softwarebedrijf (daar waar het om Closed Source gaat) m.i. een vals vertrouwen.

[tweaknico]

Aanvullend:
Als ik zelf opensource niet kan lezen/gebrijpen kan ik wel iemand inhuren (die ik vertrouw) omdat voor mij te beoordelen.
Desnoods door 2 of 3 onafhankelijke partijen die als het goed is tot dezelfde conclusie komen.
Ik kan closed source alleen laten beoordelen door de leverancier, of op voorwaarden van de leverancier.
Dit vereist 100% blind vertrouwen in de leverancier...., dat betekent dan ook dat die leverancier een rimpelloos trackrecord zou moeten laten zien.

Dat auto's zonder wielen inherent veiliger zijn dat klopt wel, bij dergelijke auto's is een discussie over airbags vrijwel zinloos, sterker nog de triggers die dan een airbag open laten gaan dan wel de zelf ontplooiende airback zijn veel gevaarlijker dan het niet hebben van een airbag.

[kimborntobewild]

Als ik zelf opensource niet kan lezen/gebrijpen kan ik wel iemand inhuren (die ik vertrouw) omdat voor mij te beoordelen.

Juist .

[OddesE]

Yup, geheime overheidsinstanties oefenen hun invloed uit waardoor de hardware waar de hele wereld op draait 'ongedocumenteerde functies' heeft...

Wanneer gaan we eens inzien dat deze instanties de wereld *onveiliger* maken?

[Verwijderd]

Verkapt "Ik wil ook hier graag de discussie starten, hoe offtopic dat ook is."

[WhatsappHack]

Nee hoor, gewoon een statement of facts. Als de hardware niet te vertrouwen is dan heeft je vertrouwen in de software, open of gesloten, weinig meerwaarde als je t over veiligheid hebt. Immers, je kan superveilige software hebben (open of closed, maakt niet uit.), vlekkeloos en zonder bugs en zonder backdoors. Maar als je CPU gebackdoored is: dan is de werkelijke veiligheid van het gebruiken van die software gewoon 0,0, omdat het alsnog op hardware niveau aangevallen wordt; zonder dat je daar iets van merkt en soms niet eens kán merken... En dat is helaas een probleem dat moeilijk te overbruggen is.

En dan kan de leverancier zelfs betrouwbaar zijn, we kennen allemaal het verhaal van Cisco routers die onderschept werden door de NSA, hardware aanpassingen werden gemaakt met backdoors en vervolgens doorgestuurd werden naar de afnemer.
Cisco kon daar niets aan doen...

Hardware tampering is een mega probleem. Als het een discussie op gang brengt over open vs closed, wat intussen gebeurt is, is dat louter een neveneffect van het benoemen van het probleem. Ik vind het zelfs jammer dat de focus van de discussie ligt op open vs closed op softwaregebied, maar m’n standpunt dat het grootste probleem in deze situatie de hardware is: dat werd op 2 mensen na verder niet geadresseerd; terwijl het gevaar eigenlijk veel groter is. Tegen software backdoors kan je je nog redelijk bewapenen. Hardware backdoors though...? Succes!

[3x3]

De V.S. heeft toch ook wel een op (bedrijfs)informatie gerichte economie. Waar informatie grote waarde heeft of van essentieel belang is voor de concurrentiepositie of bedrijfsvoering van veel bedrijven.

Waarom in hemelsnaam de overheid dan een backdoor voorschrijft die niet alleen door eigen geheime dienst, maar waarschijnlijk ook door die van andere landen eenvoudig te openen is begrijp ik niet.

De processor biedt functies als het opnieuw opstarten van een systeem en heeft volgens de onderzoekers toegang tot vrijwel alle gegevens op een systeem

Ik begrijp ook niet waarom welk Europees bedrijf nog Intel chips op hun systeem zou willen als er zulke grote risico's op Amerikaanse spionage in zitten.

[tweaknico]

Je zult naar een heel andere processor architectuur moeten zoeken...
AMD heeft het ook in de CPU's.
Je zult dus CPU's van voor 2005 moeten hebben (toen begon dit soort zaken).
Voor andere architecturen zullen CPU specs zeer zorgvuldig nagelezen moeten worden.

[mistige]

Straks een 80486 verkopen voor duizenden dollars

[Kalief]

Je zult dus CPU's van voor 2005 moeten hebben (toen begon dit soort zaken).

Bedoel je niet 2015? Dat was het jaar van de voorloper van de Skylake's, de Broadwell.

[tweaknico]

Nee de ME (ideeen ove ME) stammen uit 2005, toen waren ook de eerste implementaties bij Intel.

[SoundByte]

Oh nee hoor. De draft van 'poject for a new American Century'. Het voorstel van VS Dick Cheny, om van VS weer een leidende rol in de wereld te geven. Notabene had de voorpagina van dit voorstel de twin towers met een crosshairs eroverheen. Werd ver voor 9/11 gemaakt. Ook NSA praktijken waren al vol in ontwikkeling. Waarom men denkt dat hardware en software pas veel later werden aangepast voor inlichtingsdoeleinden. Is nogal naief.

[sapphire]

Tja je hebt ook zoveel andere keuze op het x86 platform...

Alle andere alternatieven komen niet in de buurt van de chips van Intel. Ja AMD nu in een bepaald segment maar dat veranderd niets aan de enorme hoeveelheid systemen die al in gebruik zijn. Daarnaast zit AMD HQ ook gewoon in silicon valley dus valt vast ook onder Amerikaanse wetgeving

[The Zep Man]

AMD heeft hun eigen AMD Platform Security Processor met dezelfde problemen.

Qua dat heb je gelijk. Er is eigenlijk überhaupt geen keuze voor x86. Dit is een probleem dat je krijgt wanneer processorbakkers ook hun eigen exclusieve chipsets eromheen ontwerpen. Er was een tijd dat aansturende chipsets nog van andere fabrikanten waren, en toen speelde dit probleem niet/minder mee.

Mogelijk gaat dit ook een probleem worden met SoC's. Die hebben een onboard Trusted Execution Environment, waar je niet zomaar meer vanaf komt. Dan zit het allemaal in een enkele package.

[Reactie gewijzigd door The Zep Man op 23 juli 2024 06:50]

[SoundByte]

Nou dat is niet waar. Want mischien bakte China weer backdoors in hun chipsets...

[Verwijderd]

[...]
Ik begrijp ook niet waarom welk Europees bedrijf nog Intel chips op hun systeem zou willen als er zulke grote risico's op Amerikaanse spionage in zitten.

Omdat we v.w.b. x86 compatible chipsets terug moeten vallen op AMD.
En die komen uit: de VS.

[The Zep Man]

[...]

Omdat we v.w.b. x86 compatible chipsets terug moeten vallen op AMD.

Een groter probleem is dat AMD hun eigen variant van de Management Engine heeft.

[The Zep Man]

Volgens mij gaat dit over Intel niet AMD.

Volgens mij noemt Davey400 in zijn reactie AMD als 'terugvaloptie', waar ik op in ga door te zeggen dat AMD ook geen optie is voor dit soort zaken.

[Reactie gewijzigd door The Zep Man op 23 juli 2024 06:50]

[Verwijderd]

Sterker nog: ik bedoel dat het belangrijkste alternatief voor x86 CPU's ook een Amerikaans bedrijf is.

[koen_92]

Gelukkig is voor open source software x86 geen vereiste: die kun je eenvoudig hercompileren naar een andere architectuur.

Er zijn niet veel, maar zeker wel wat alternatieven voor Intel/AMD als het om 'betaalbare high performance' chips gaat.

Zo heeft Raptor Engineering onlangs een compleet open hardware workstation met een PowerPC CPU gereleased dat qua performance met de nieuwste Xeons mee moet kunnen komen:
https://www.raptorcs.com/TALOSII/

Niet heel goedkoop, maar te betalen als je open hardware erg belangrijk vindt.

[Reactie gewijzigd door koen_92 op 23 juli 2024 06:50]

[dehardstyler]

Dat bedrijf ken ik niet, die maken wel mooie spullen zeg! En dan ook nog met ondersteuning voor PCI-e 4.0, zijn daar überhaupt al kaarten voor?

[SoundByte]

Is airgapping intel en Amd systemen geen optie?
En gewoon de wifi bluetooth en ethernet chips van het bord rukken?
Of aansluiten op een 'virtual internet'

[Reactie gewijzigd door SoundByte op 23 juli 2024 06:50]

[Dreamvoid]

Als ik het zo lees is het juist een eis van de overheid dat die backdoor uit te schakelen is?

[tweaknico]

Ja bij door NSA beheerde hardware, niet bij de rest....

[The Zep Man]

Dus de NSA vereist voor 'high assurance' dat de Intel Management Engine wordt uitgeschakeld? Goed idee! In de informatiebeveiliging gaat men uit van less = more. Schakel alle systemen die je niet gebruikt uit.

[Reactie gewijzigd door The Zep Man op 23 juli 2024 06:50]

[dehardstyler]

Schakel alle systemen die je niet gebruikt uit.

Volgens mij kun je ze gewoon aanzetten op afstand toch? Of kan dat alleen met de Vpro optie ( AMT )?

[The Zep Man]

Volgens mij kun je ze gewoon aanzetten op afstand toch?

Als je iets kan aanzetten op afstand, dan staat het niet uit genoeg.

[dehardstyler]

Nou ja, wat is voor jou uit genoeg? Ik begreep dat met AMT de enige workaround was dat het systeem niet aangesloten mocht zijn aan 230V / batterij als de computer is aangesloten via een ethernet verbinding. Of je moet dus elke keer je ethernetkabel eruit halen...

The Intel AMT Web Interface works even when the system is turned off, as long as the platform is connected to a line power and a network cable, as it operates independently of the operating system.

bron: https://thehackernews.com...el-amt-vulnerability.html

[PegOpDeWeg]

Misschien dan maar over op de ShenWei processor uit China?

[kimborntobewild]

De hele keten waarop je werkt moet veilig zijn; de CPU, een extra CPU in zoals in dit artikel, de andere onderdelen in je PC, je software, je provider, je internetverbinding. Als één van deze zaken niet Open Source zijn, ben je niet optimaal veilig / anoniem.
('t Is ook nog maar de vraag of er geen backdoor in zo'n chinese CPU zit.)

[Reactie gewijzigd door kimborntobewild op 23 juli 2024 06:50]

[mutley69]

Gelukkig dat het uitgezet kan worden. Gaat men dat nu veralgemeend doorvoeren via patches in linux/unix/windows/macOS?

[tweaknico]

Dat is te laat, het moet uitgezet worden in de BIOS. (of eigenlijk niet aangezet worden in de BIOS)

Zie ook:
https://puri.sm/learn/intel-me/
en:
https://puri.sm/products/

[Verwijderd]

Nou het hek is van de dam wat mij betreft.

[Yooo Kerol]

Iemand die in lekentaal kan uitleggen wat dit inhoud? Is iedereen met een nieuwe processor sinds vorig jaar dus gewoon te hacken? En heeft Intel dit deze functie in opdracht van de NSA laten inbouwen of begrijp ik het verkeerd?

[tweaknico]

De ME architectuur zit al sinds ~ 2005 in de Intel Processoren en kort daarna ook in AMD.
Voor een deel van de processoren was de ME min of meer disabled (of gewoon kapot) en dat weren in eerste instantie voor consumenten producten. Recente CPU's hebben allemaal een ME backdoor.
Die kan icm. een netwerk kaart Serial over LAN communiceren. Zelfs als de computer uit staat.

[Yooo Kerol]

Ik begrijp niet goed wat dit laatste betekend. Maar is er een mogelijkheid om je hier tegen te wapenen? Of is de gehele wereld nu zo ongeveer f****d door de NSA?

[Reactie gewijzigd door Yooo Kerol op 23 juli 2024 06:50]

[Yooo Kerol]

Say whut?
Zeker op de verkeerde gereageerd

[Flaat]

Dit is heel goed nieuws, erg knap dat ze dit voor elkaar gekregen hebben.

[SoundByte]

Er bestond sinds Ivy Bridge op mijn laptop al enige hardware (nieg processor geimplementeerd). Het heette iets van content management engine, en was volgends de website van intel, voor werkgevers en beheerders van systemen om je laptop van buitenaf te bereiken. Gelukkig(?) kon je dit uitschakelen als je de drivers voor deze management systeem gewoonweg niet installeerde en genoegen nam met de gele uitroepteken in je device manager. Overigens werden de drivers hiervoor ook niet meer beschikbaar wegens "veroudering". Of zijn ze nog wel besvhikbaar? Anyway this goes to show Big Brother only exists in the minds of tinfoil hat wearing graincircle admiring alien hunters

[The Only Wizard]

Naast uitzetten in BIOS gewoon power management op de NICs uitzetten zodat die uitgaan als je de PC uitzet, dan kun je er toch nevernooit niet meer "remote" bij, of zie ik dan iets over het hoofd ? Enigste consequentie is dat WOL dan ook niet meer kan, maar waarom zou je dat (enterprise situatie) uberhaupt aan willen hebben ? Ik zet al dat soort onnodig spul altijd volledig uit...