Intels zakelijke processors bevatten al sinds 2008 ernstig lek

Intels Active Management Technology bevat ernstige kwetsbaarheden waardoor aanvallers de beheerfuncties kunnen gebruiken en zo toegang kunnen krijgen tot hele systemen en netwerken. De kwetsbaarheden zitten in firmwareversies vanaf 2008.

Intel waarschuwt voor de kwetsbaarheid in Active Management Technology, Intel Standard Manageability, en Intel Small Business Technology. Het lek zit in firmwareversies van 6.x van de Nehalem-generatie van processors tot en met 11.6 van Kaby Lake. Aanvallers kunnen via het lek toegang krijgen tot de beheerfuncties van AMT, ISM en ISB, en dankzij dit low-level-beheer ongemerkt hele systemen en netwerken beheren.

De kwetsbare beheerfuncties maken deel uit van Intels vPro-platform voor zakelijke processors. Intels consumentenchips zijn niet getroffen door het lek volgens de maker. De cpu's van onder andere bedrijfs-pc's, zakelijke laptops, workstations, nas-systemen, servers enzovoort, kunnen wel getroffen zijn, mits ze met AMT geleverd zijn. Het bedrijf heeft een handleiding uitgebracht met uitleg hoe gebruikers er met een detectietool achter kunnen komen of een systeem een zakelijke processor met AMT heeft.

De firmwarekwetsbaarheid, die de aanduiding CVE-2017-5689 heeft gekregen, is in maart ontdekt door onderzoeker Maksim Malyutin van Embedi. Nieuwe firmwareversies moeten het probleem verhelpen. Intel verwijst hiervoor door naar de oem's, die de bijgewerkte firmware versienamen geven waarvan het laatste viercijferige nummer met een '3' begint, à la X.X.XX.3XXX. Intel werkt samen met de systeembouwers om zo snel mogelijk nieuwe firmware te verstrekken. Als alternatief beschrijft Intel in een document hoe gebruikers zelf kunnen voorkomen dat de kwetsbaarheid misbruikt wordt, onder andere door de Local Manageability Service uit te schakelen en bepaalde restricties voor lokaal beheer in te stellen.

Er zijn al langer vraagtekens over de veiligheid en integriteit van Intels AMT, onder andere omdat Intel de code voor het Intel Management Engine-subsysteem gesloten houdt.

Reacties (93)

[Verwijderd]

Beveiligingsexperts hebben het al heel lang over de kwetsbaarheden en ondoorzichtigheid van de Intel Management Engine en AMD PSP. Ik hoop dat er hierdoor nog meer aandacht aan wordt geschonken.

Er is geen enkele manier is om Intel ME/ AMD PSP compleet uit te schakelen op een computer. Ook niet als het een consumenten pc betreft die deze features totaal niet nodig heeft. Terwijl het altijd draait op een compleet separate processor die toegang heeft tot je complete systeem (ja, inclusief netwerkkaart).

Er zijn wel projecten om een compleet vrije (open-source) bootfirmware op je systeem te plaatsen (zoals libreboot) welke ook de Intel ME uitschakelt. Deze ondersteunen alleen geen nieuwere machines omdat intel en amd niet willen meewerken en totaal geen informatie willen verschaffen over dit gesloten en versleutelde systeem. Op dit moment zijn ze dus afhankelijk van reverse engineering. Er is wel een project om intel ME ook op modernere machines uit te schakelen, de software hiervoor heet ME cleaner.

De vulnerability die nu naar buiten is gekomen heeft alleen effect op machines waar AMT is ingeschakeld. Op de high-end consumer pc's en business pc's is dit ingebouwd en bij mij stond dit standaard aan (lenovo x220). Check hiervoor je BIOS!

[N8w8]

Er is geen enkele manier is om Intel ME/ AMD PSP compleet uit te schakelen op een computer.

Niet voor de gemiddelde digibeet, maar het schijnt hiermee wel te kunnen!

[Verwijderd]

"Currently me_cleaner DOES NOT WORK on platforms with Intel Boot Guard set in Verified Boot - Immediate shutdown (FVE or FVME). This technology is available from Haswell onwards."

Dit betekend dat Haswell/Broadwell, Broadwell, Skylake en Kabylake dus vulnerable blijven ondanks bovenstaande patch / methode. A.K.A. alle Intel CPU's van de afgelopen 4-5 jaar.

Mijn mening is dat intel (en AMD?) openheid van zaken moeten geven. Just my 5 cents..

[The Zep Man]

Dit betekendt dat Haswell/Broadwell, Broadwell, Skylake en Kabylake dus vulnerable blijven ondanks bovenstaande patch / methode. A.K.A. alle Intel CPU's van de afgelopen 4-5 jaar.

Yup, maar alleen als de betreffende instelling (Intel Boot Guard) op een bepaalde waarde staat (Verified Boot - Immediate shutdown (FVE or FVME). Dat is volgens mij niet zo voor alle machines. Zo is hier een voorbeeld van een Skylake machine waarop het werkt.

[Reactie gewijzigd door The Zep Man op 22 juli 2024 16:30]

[The Zep Man]

Let op dat ME hiermee niet compleet wordt uitgeschakeld. Het zal altijd in de CPU aanwezig zijn. Wel wordt het aanvalsoppervlak van ME sterk verkleind omdat additionele programmacode in het BIOS niet meer beschikbaar is voor ME, waardoor de implementatie effectief wordt uitgeschakeld. Er moet nog steeds een klein beetje ME code in de BIOS overblijven om ervoor te zorgen dat de CPU niet stopt tijdens het opstarten.

[Lennart-IT]

Er schijnt alsnog een 'knock' commando die van buiten af kan komen zodat de firmware zichzelf opnieuw ontplooit en opnieuw een "mogelijke" backdoor zou toelaten.

Nu nog steeds heeft men niet de gehele regie over de hardware die men koopt. Men wuift de zorgen van de consument weg onder 'closed source' maar iedereen weet inmiddels waarom men dit doet.

[cdwave]

Akelig hieraan is dat het om een "feature" gaat waar echt helemaal geen enkele consument om vraagt. Of dat "zakelijk" is of niet maakt daarbij helemaal niet uit.

Dit soort "security" subsystemen worden doorgaans gebruikt om systemen te locken voor alternatieve firmwares en dergelijke. Zoals je mobiele telefoon of tablet waar doorgaans uitsluitend de crap van de fabrikant op wil draaien, uit commerciele overwegingen. Uiteraard ook voor bijvoorbeeld medische apparatuur, waar je niet wil dat er "wilde" firmware op het systeem draait ook al zit er een gewone desktop PC in. Ik hou daarbij altijd ook mijn hart vast als de security firmware een binair gesloten dingetje van de chipfabrikant is.

[Xfade]

Waarom zegt Intel dan dat consumenten chips niet getroffen zijn ?
Verder is het wel matig dat het niet echt uit kan, ik kan er over meepraten met mijn Elitebook van HP. Niet geactiveerd maar wel "aan".

[Armin]

Op de high-end consumer pc's en business pc's is dit ingebouwd en bij mij stond dit standaard aan (lenovo x220). Check hiervoor je BIOS!

Als aanvulling, 'aan staan' alleen is gelukkig niet genoeg. Je moet ook een netwerkkaart hebben die compatible is. Nu zal dat bij enterprise workstations waarschijnlijk ook het geval zijn, anders zou men de moeite niet nemen om het aan te zetten in UEFI, maar dat wil ook zeggen dat als je WiFi gebruikt over je laptop je vaak weer wel goed goed zit. Immers AMT WiFi staat standaard - bij mijn weten - niet aan.

Ook is niet duidelijk of het ook werkt zonder dat de drivers/management tools geinstalleerd zijn. Het lijkt mij van niet, aangezien de workarounds het uitzetten van de tools behelst. Wie de tools dus nooit gebruikt heeft of zoals velen er meteen na afleveren door de OEM ervanaf gekiepert heeft, heeft effectief een systeem dat is zoals de workaround beschrijving.

Maar Intel is niet zo scheutig met details, dus het blijft giswerk.

[robj28]

Hier High end Medion laptop, waar AMT helaas niet uit te schakelen is. (Optie ontbreekt in de bios) ME frimware eindigt op .1XXX dus kwetsbaar.

[djiwie]

Volgens dit blog https://semiaccurate.com/...oit-2008-intel-platforms/ was het lek al jarenlang bekend en weigerde Intel tot nu toe om er iets aan te doen. Benieuwd wat ze dan uiteindelijk toch heeft getriggerd, wellicht wordt het inmiddels actief misbruikt?

[Richardus27]

Misschien dat dit een ingang was voor de veiligheidsdiensten, is niet de eerste keer dat die er vanaf dag 0 in zitten. Tegenwoordig heeft elk programma/apparaat er wel een, enige reden dat dit lek nu wordt gedicht is dat mensen er achter zijn gekomen.

Of het was gewoon een oversight van iemand tijdens de ontwikkeling, voor de niet-zo-skeptici onder ons

[BeosBeing]

Misschien dat dit een ingang was voor de veiligheidsdiensten, is niet de eerste keer dat die er vanaf dag 0 in zitten.

Misschien heeft de nieuwe generatie wel gewoon een nieuwe backdoor zodat dit al jaren bekende lek, waarvoor bedrijven dus op andere niveau's een afdichting hebben geregeld, nu dus gedicht mag worden.

Tegenwoordig heeft elk programma/apparaat er wel een, enige reden dat dit lek nu wordt gedicht is dat mensen er achter zijn gekomen.

Volgens djiwie's link is het al jaren bekend - zeker al 5 jaar-. Kortom dat mensen er achter zijn gekomen is niet de enige reden. Misschien de komst van Ryzen dat deze fout dus niet heeft. Het zou zomaar een reden kunnen zijn om op Ryzen over te stappen en dat wil Intel natuurlijk niet laten gebeuren.

Of het was gewoon een oversight van iemand tijdens de ontwikkeling, voor de niet-zo-skeptici onder ons

Het was al jaren bekend, dus had het best al in vorige generaties gedicht kunnen worden, tenzij men inderdaad eerst een nieuwe backdoor moest verzinnen.

[Reactie gewijzigd door BeosBeing op 22 juli 2024 16:30]

[WillySis]

Gezien dit bericht https://serverfault.com/q...interfere-with-the-tcp-ip is er inderdaad een vermoeden dat het gewoon een bewust ingebouwde feature is. Er wordt echter geen enkele informatie gegeven om de feature te gebruiken. Kennelijk is die dus voor zeer specifieke doeleinden (spionage) ingebouwd.

De TCP poorten 16992 en 16993 dichtzetten op de firewall (router) helpt om misbruikt te voorkomen. Veel bedrijven hebben gelukkig de policy dat alleen poorten die daadwerkelijk nodig zijn open worden gezet en de rest dicht blijft.

[Fermion]

Wel, als Stuxnet lukte, dan ga ik ervan uit dat elk gemiddelde bedrijf appeltje eitje is. Want het netwerk waar Stuxnet naar binnen glipte was al air gapped.

[scsirob]

Leg ergens strategisch in een hotel, op een parkeerplaats of in een restaurant een paar onbeheerde USB sticks neer, en de eerlijke vinder overbrugt die gap wel voor je.

[YangWenli]

Ja fysieke beveiliging is iets waar vaak niet meer over nagedacht wordt. Er lopen hier iedere dag toch een paar honderd mensen binnen, is die man echt een DHL bezorger of niet niemand die het vraagt.

[Ge Someone]

Er is wel eén en ander te vinden over Intel's SCS en AMT maar dat is niet erg duidelijk. Ik heb het iig. nooit nodig gehad.

[Verwijderd]

LMS.exe is een performance hogger op een groot aantal Lenovo consumer systemen, waar het dus in bepaalde (wellicht alle, mits AMT ondersteund is) gevallen standaard aanstaat. Daar krijg je toch wel een paar rillingen van over je rug als bewuste consument.

TLDR: google eens op 'lenovo lms.exe'

[Yoshi]

consumer systemen met vpro?

[Verwijderd]

Inderdaad, zo heeft bijvoorbeeld de Lenovo T510 notebook VPro ondersteuning en is de LMS service actief.

[The Zep Man]

Inderdaad, zo heeft bijvoorbeeld de Lenovo T510 notebook VPro ondersteuning en is de LMS service actief.

De T510 is een Thinkpad T series notebook. Dat zijn notebooks gericht op professioneel gebruik, niet op consumenten. Zie ook dit:

Our flagship laptop series builds upon superior design with the performance and durability professional users demand.

De gemiddelde consument koopt geen T510. Als het niet zakelijk is, dan zijn het power users (tweakers) die hiermee rondlopen.

[Reactie gewijzigd door The Zep Man op 22 juli 2024 16:30]

[locke960]

vPro is een feature voor groot-zakelijk gebruik.
De T510 is voor professionele gebruikers.

De termen professioneel en groot zakelijk overlappen wel (hopen we dan toch, maar dat terzijde), maar betekenen niet hetzelfde.
Er zijn heel veel klein-zakelijke, professionele gebruikers die vPro niet gebruiken maar wel een goed systeem willen.

[Cerberus_tm]

Hmm dus het kan ook actief zijn op mobiele versies van de processors. Maar kan het ook actief zijn op b.v. een gewone i5-7600, als je deze los koopt? Eerlijk gezegd wist ik niet eens dat er ook echt firmware in de processor zelf kon zitten (al verbaast het me ook niet zo).

[Commendatore]

Het zit in de chipset, niet zozeer in de processor zelf. Getroffen chipsets kun je zelfs tegenkomen op gaming-moederborden.

[Reactie gewijzigd door Commendatore op 22 juli 2024 16:30]

[Cerberus_tm]

O, aha! In het moederbord dus, dat klinkt ook eigenlijk wel logischer. Maakt het dan deel uit van de gewone firmware/BIOS die je kunt updaten voor je moederbord? Ik ben ook benieuwd hoe je kunt zien of jouw moederbord kwetsbaar is voor de hack op afstand.

[Commendatore]

Klopt. En je kunt dat testen aan de hand van de detection guide waarnaar in het bericht gelinkt wordt.

[Cerberus_tm]

OK dank u.

[Verwijderd]

Dat was ook de eerste gedachte die in mij op kwam.
Ik geloof niet dat dit soort dingen per ongeluk gebeuren.

[Jeroen]

Dit lek kan worden gedicht omdat er intussen een ander lek is voor de veiligheidsdiensten.

[Verwijderd]

Ik denk inderdaad dat dat er mee te maken kan hebben.

Nooit heb ik duidelijk kunnen krijgen wat ik er als consument aan heb, enkele malen geGoogled, ze raden het aan om te installeren, maar ik heb het gelukkig nooit gedaan. Dan maar een vraagtekentje overhouden in mijn apparaatbeheer. Als alles toch al goed werkt, waarom zou ik die boel dan installeren? Het is een aardig aantal MB's groot ook nog. Ik zag het alleen als iets dat in de weg kan zitten of misbruikt kan worden, ik zag er geen voordeel in.

[raro007]

Veiligheidsdiensten die vooral technologie stelen van andere landen.
of zouden Amerikanen zo iets nooit doen?

[cavey]

Verschil wellicht is dat het nu gewoon is aangemeld als bug, na een bepaalde "reageer erop, want we hebben nu een security advisory + PoC staan" timeout. Meestal iets van 90 dagen. Wellicht wat meer. Mijn vermoeden is dat Semiaccurate geen PoC had voor deze bug, waardoor er dus geen reden was voor Intel om te reageren. In de hele rant van Semiaccurate kom ik namenlijk niks tegen over PoC's, alleen maar "we hebben het al jaren aangegeven, en niemand luistert whine whine whine".

Zonder PoC, dan zeggen ze "ja, leuk voor je. We doen er niks aan. Het is een theoretische aanval".

[kidde]

Volgens dit blog https://semiaccurate.com/...-2008-intel-platforms/...

Heb ik gister ook zitten lezen, en in tegenspraak met het Tweakers artikel: Volgens Charlie zijn consumenten-desk/laptops ook kwetsbaar, maar alleen voor lokale aanvallen.

[Verwijderd]

Een snelle scan op je subnets naar TCP poort 16992 en 16993 zou moeten laten zien of je AMT gebruikt. Onder Linux kun je bovendien met lspci controleren of je een device hebt met "MEI" of "HECI" in de omschrijving. Het gaat hierbij om fysieke servers. Als dit allemaal niet het geval is, dan ben je (als Linux gebruiker) veilig.

http://mjg59.dreamwidth.org/48429.html

[jj71]

Het dichtzetten van poorten 16992 en 16993 op de computer zelf met een firewall heeft blijkbaar geen zin, omdat het zodanig zit ingebakken dat data wat op die poorten binnenkomt helemaal om de hoofd-CPU en het operating system heen gaan en direkt worden doorgeleid naar de ME (de Management Engine, de aparte processor waar Intel's AMT op draait).

Je zou dan in het netwerk op je router die poorten dicht moeten zetten.

[bzzzt]

Alleen als je AMT ingeschakeld hebt. Het staat standaard uit op bijna ieder systeem.

[Reactie gewijzigd door bzzzt op 22 juli 2024 16:30]

[roller12358]

Er zijn nog een paar extra poorten:

https://software.intel.com/sites/manageability/AMT_Implementation_and_Reference_Guide/default.htm?turl=WordDocuments%2Fmanageabilityports.htm

[WhatsappHack]

Nog een interessant stukje hierover:
https://mjg59.dreamwidth.org/48429.html

[Derk S]

Natuurlijk ontzettend slecht dat het doodgezwegen is door Intel, en pas naar buiten komt wanneer externe partijen doordrukken (SemiAccurate).

Patches worden uitgegeven, en snel ook door grote partijen zoals HP, Lenovo en anderen. Maar als deze exploit al jaren beschikbaar was, is het de vraag hoever deze fabrikanten terug gaan om te patchen. Lijkt me namelijk dat ze gewoon binnen de garantieperiode blijven.

In ieder geval goed het document van Intel lezen als je dit iets boeit. De oplossing is vrij simpel om remote exploits te voorkomen. Lokaal blijft het probleem bestaan, alhoewel daar ook oplossingen voor worden geboden.

[tzunix]

En daar zou je nog aan toe kunnen voegen: als leveranciers geen oude systemen patchen, wordt het voor gebruikers van soms nog prima functionerende systemen een vernieuwingsslag die ze niet zagen aankomen. Hopelijk pakt iedereen dit netjes op.

[Keypunchie]

wanneer externe partijen doordrukken

Lees: er zijn exploits "in the wild" ontdekt.

Intel zou anders nooit tot publieke disclosure zijn overgegaan zonder dat er lang en breed patches waren van de grote OEMs.

[0xygen500]

Is het normaal dat zulke beveiligingslekken pas na 9 jaar worden ontdekt?

[Giblet_dono]

Nouja, geen enkel product is 100% veilig, ik denk dat juist het feit dat het 9 jaar geduurd heeft spreekt voor dit product.
Het heeft immers 9 jaar aan extra ervaring, kennis en testen genomen voor er een probleem werd gevonden.

[Verwijderd]

Denk niet dat je het zo moet zien.
Het is vooral een product die door een veel kleiner publiek bekend en gebruikt is.
Minder blootstelling is over het algemeen ook minder kans op critische ogen.
Of misschien werd er juist te pas of te onpas vertrouwd op Intels kundigheid.

Dat er niets mee gedaan werd terwijl het schijnbaar in de praktijk (mis)bruikbaar is zou dat vertrouwen kunnen beïnvloeden.
Maar soms zijn exploits dusdanig onpraktisch/onuitvoerbaar of slechts theoretisch dat het weinig prioriteit geeft.

[Reactie gewijzigd door Verwijderd op 22 juli 2024 16:30]

[Verwijderd]

De V-PRO richt zich hoofdzakelijk op zakelijke klanten, dat lijkt me juist wat een dergelijk lek zo kwetsbaar maakt. Wie zegt er niet dat deze exploit doelbewust ingebouwd is, juist om deze doelgroep te kunnen benaderen.
Ik zeg niet per definitie dat dit bewust door Intel gedaan is, mogelijk wel door betrokken bedrijven/medewerkers.

[SunnieNL]

Het richt zich op zakelijk klanten, maar in de 10 jaar dat ik bij zakelijke klanten kom, heb ik het nog maar weinig ingezet zien worden.

[Verwijderd]

Dat je het niet waargenomen heeft wil dat zeggen dat het niet gebruikt/misbruikt is?
Mogelijk werd deze exploit enkel gericht en/of beperkt gebruikt.
Het lijkt mij niet ondenkelijk dat een dergelijke exploit alleen op kleine schaal gebruikt is, anders had het waarschijnlijk niet zo lang onder de radar kunnen blijven.

[SunnieNL]

Ik heb het niet over de exploit. Dat hele vpro platform heb ik nog nooit gebruikt zien worden. Het zit wel in de pc's maar de management backend aan de achterkant heb ik nog nooit geïnstalleerd gezien.

[Verwijderd]

Yep, mee eens. Vind het ook verdacht.

Je weet het niet zeker maar met wat je leest ook over het NSA gebeuren dan lijkt het aannemelijk dat er mogelijk deals zijn en worden gesloten met grote spelers op hardware en software gebied.

[Reactie gewijzigd door Verwijderd op 22 juli 2024 16:30]

[Wannial]

Het was al heel erg lang bekend, er wordt alleen nu pas wat aan gedaan, dat spreekt ook wel erg voor het product ja.

[Giblet_dono]

True dat..
Zo zie je maar weer dat (whitehat) hackers nodig zijn om dit soort "reuzen" in toom te houden.
Mensen die lekken publiceren en proof of concepts er voor schrijven waardoor het gevaar dat andere (blackhat) hackers hier iets vuils mee gaan uithalen groter wordt en de "reuzen" dus wel moeten reageren

[kozue]

Of misschien hadden de black hats het na een jaar al gevonden en lachen die al 8 jaar lang Intel uit met complete bedrijfsnetwerken in hun botnet.
Dat het zo lang niet gevonden werd door de good guys kan ook een gebrek aan interesse zijn geweest.

[BeosBeing]

Nouja, geen enkel product is 100% veilig, ik denk dat juist het feit dat het 9 jaar geduurd heeft spreekt voor dit product.

In tegendeel. Het lek is al minstens 5 jaar bekend. Dat men dus al 5 jaar geen maatregelen heeft genomen is schokkend.

Het heeft immers 9 jaar aan extra ervaring, kennis en testen genomen voor er een probleem werd gevonden.

Nee het is na 4 jaar gevonden, o.a. door SemiAccurate. Mogelijk was het elders dus al langer bekend. In principe is het zelfs niet uit te sluiten dat het er bewust in is gebracht. AMD was immers verslagen en op dat moment geen bedreiging meer.

[Reactie gewijzigd door BeosBeing op 22 juli 2024 16:30]

[BeosBeing]

Volgens djiwie's link hierboven is het al jaren bekend - zeker al 5 jaar.

SemiAccurate has known about this vulnerability for literally years now, it came up in research we were doing on hardware backdoors over five years ago. What we found was scary on a level that literally kept us up at night. For obvious reasons we couldn’t publish what we found out but we took every opportunity to beg anyone who could even tangentially influence the right people to do something about this security problem. SemiAccurate explained the problem to literally dozens of “right people” to seemingly no avail. We also strongly hinted that it existed at every chance we had.

Daarin wordt o.a. verwezen naar dit artikel van 15 mei 2012 De vraag is hoeveel langer anderen hiervan op de hoogte waren.

Dat Intel dit pas nu heeft onderkend spreekt boekdelen.

[P1nGu1n]

Er zijn beveiligingslekken die meteen worden ontdekt, sommige worden nooit ontdekt. Ja, dat is normaal. Er moet maar net iemand zijn die het tegen komt.

[raro007]

Huh die lek was 9 jaar geleden ontdekt...
Dus ontdekt maar niet gepatched en dat is niet normaal.

[Yucko]

toch maar eens opnieuw de tekst lezen:

...De kwetsbaarheden zitten in firmwareversies vanaf 2008...

"...De firmwarekwetsbaarheid, die de aanduiding CVE-2017-5689 heeft gekregen, is in maart ontdekt door onderzoeker Maksim Malyutin...

Dus dat de kwetsbaarheid er al sinds 2008 in zit is niet hetzelfde als al sinds 2008 bekend en niet gepatched.

[raro007]

en volgens mede tweakers en hun bronnen is het jaren bekend..
@BeosBeing @djiwie
djiwie bron = https://semiaccurate.com/...oit-2008-intel-platforms/

[AJediIAm]

Het is zeker niet ongebruikelijk dat sommige hele specifieke exploits pas jaren later naar boven komen. Ik heb de details niet bekeken, maar vaak heb je een hele specifieke set van omstandigheden nodig om van het lek gebruik te kunnen maken. Dat maakt zowel het gebruik als het vinden erg lastig.

[BeosBeing]

Is het normaal dat zulke beveiligingslekken pas na 9 jaar worden ontdekt?

Het is 5 jaar geleden al ontdekt en dus na 4 jaar. Verder heeft P1nHu1n gelijk, sommige worden nooit ontdekt. Dat het lang duurt is niet zo erg, maar dat het zeker 5 jaar na ontdekking pas gepatcht wordt is schokkend.

[Verwijderd]

GSM was de eerste 20 jaar ook veilig, domweg omdat de benodigde rekencapaciteit om het te kunnen kraken er niet was. Je gaat niet iets zo veilig maken dat het zelfs met hypothetische rekencapaciteit niet te kraken is. Zolang je maar voor blijft lopen op de omgeving is er niks aan de hand.

[CAPSLOCK2000]

Is het normaal dat zulke beveiligingslekken pas na 9 jaar worden ontdekt?

Ja, dat is heel normaal, zeker bij closed source. De meeste broncode wordt één keer geschreven en dan nooit meer teruggelezen of gecontroleerd en wordt dan jarenlang gebruikt en van systeem naar systeem gerecycled.

Alle software bevat fouten, hoe meer software, hoe meer fouten. Het enige wat daar tegen helpt is meer controles (door mensen of door software). Bij closed source ben je daarvoor helemaal afhankelijk van de leverancier. Als de leverancier al weet dat er fouten in zitten dan is het nog maar de vraag of het in het commercieel belang van die leverancier is om het zo snel mogelijk te dichten. Misschien zijn ze liever lui dan moe en doen er niks aan tot iemand komt klagen. Misschien hebben ze de ernst van het gat verkeerd ingeschat. Misschien vinden ze oplossen te duur. Misschien vindt een of andere tussenbaas beveiliging helemaal niet belangrijk. Misschien heeft een geheime dienst wel gevraagd om het gat open te houden. Je weet het niet, het zou allemaal kunnen, je moet de leverancier maar vertrouwen en geloven. In veel gevallen (zoals bij veel Intel processoren) zijn er eigenlijk ook geen alternatieven.

Daarom pleit ik er al jaren voor dat alle software "open source" moet zijn en het liefst zelfs "free software". Inzicht in de broncode maakt software nog niet automatisch veiliger, maar het geeft je in ieder geval een kans om de situatie objectief te beoordelen en problemen zelf te (laten) verhelpen. In 99 van de 100 gevallen zal je daar geen gebruik van maken, maar die ene keer kan het veel verschil maken. Niet dat ik denk dat de bakker om de hoek de broncode gaat nalezen, dat is helemaal niet de bedoeling, maar IT-bedrijven onderling kunnen dat wel degelijk.
Stel dat de broncode van deze firmware beschikbaar was, dan denk ik dat clubs als Microsoft en RedHat er wel iemand naar hadden laten kijken, hun eigen product is er namelijk direct van afhankelijk. We weten dat verschillende regeringen en geheime diensten al hun licht hebben laten schijnen over de broncode van Windows, Linux en een aantal andere belangrijke systemen. Voor firmware lijkt me dat ook wenselijk.

[kozue]

Bij gesloten software is dat helaas inderdaad normaal. Dit soort incidenten geven vooral aan waarom je alleen open source zou moeten willen gebruiken voor kritieke componenten in je infrastructuur (vooral zaken waar je direct vanaf het internet bij kunt, zoals netwerkapparatuur en -services).

[Zer0]

Ook met open source blijven dergelijke gaten soms lange tijd on-ontdekt. Zo zat de Heartbeat bug al enkele jaren (4) in de code, net als de GHOST bug (8 jaar) en Stagefright (5 jaar)

[BeosBeing]

Bij gesloten software is dat helaas inderdaad normaal. Dit soort incidenten geven vooral aan waarom je alleen open source zou moeten willen gebruiken voor kritieke componenten in je infrastructuur (vooral zaken waar je direct vanaf het internet bij kunt, zoals netwerkapparatuur en -services).

En dus ook open source firmware ook al ligt dat een stuk moeilijker.

[batjes]

Het ligt bij zowel open als closed source gewoon aan de partij die de code schrijft en beheerd.

[Rolfie]

Ik mompel even snel iets over bash en openssl......

[BeosBeing]

Overal kunnen fouten in zitten. Echter ze worden in de opensource wereld niet bewust jaren stil gehouden. Dat is iets dat Microsoft in het verleden wel gedaan heeft en nu Intel ook.

In de gevallen waar het Microsoft betrof begon men pas maatregelen te nemen nadat er voor de vulnerability ook daadwerkelijk een exploit in het wild was ontdekt.
(Daarna was de patch ook heel snel beschikbaar.)
Of dat hier ook het geval is heb ik nog niet terug gevonden maar ik sluit het zeker niet uit zoals ik evenmin uitsluit dat deze vulnerability er bewust is ingebouwd.

[Reactie gewijzigd door BeosBeing op 22 juli 2024 16:30]

[SuperDre]

Och, och, bij opensource is dat net zo vaak het geval. hoe vaak is de afgelopen tijd wel niet naar voren gekomen dat er een ernstig lek zat in OSS waarbij dat lek er al jaren in zit.
Het is juist eerder dat bij gesloten software je nog de kans hebt dat niemand het lek heeft ontdekt, want in OSS is het juist dat een hoop lekken dus ontdekt worden door hacker (omdat ze gewoon simpel toegang tot de code hebben), maar dit dus nooit melden en al die tijd gewoon blijven gebruiken.

[Verwijderd]

Het is dan ook meer een feature voor 'bepaalde entiteiten'.

Edit, dit is echt geen baseless claim: Verwijderd in 'nieuws: Intels zakelijke processors bevatten al sinds 2008 ernst...

[Reactie gewijzigd door Verwijderd op 22 juli 2024 16:30]

[The Zep Man]

De 'Intel(R) Management and Security Application Local Management Services' kan wel uitgeschakeld worden, maar malware kan deze alsnog weer inschakelen. Dit is een waardeloze mitigatie voor malware die dit expliciet gaat misbruiken.

Het is veiliger om toegang tot de Management Engine/Active Management Technology (AMT) in de BIOS uit te schakelen, indien mogelijk. Als het BIOS niet goed beveiligd is dan kan malware dit in theorie weer inschakelen, maar dat maakt een aanval al een stuk gerichter en moeilijker.

Ik ben benieuwd of deze kwetsbaarheid door onderzoekers gebruikt kan worden om de Management Engine verder te bestuderen. Mogelijk kan het van binnenuit permanent uitgeschakeld worden, aangezien het voor praktisch alle computers niet van belang is.

[Reactie gewijzigd door The Zep Man op 22 juli 2024 16:30]

[litebyte]

Zoiets noemen ze geloof ik ook een backdoor.

[segil]

Het bedrijf heeft een handleiding uitgebracht met uitleg hoe gebruikers er met een detectietool achter kunnen komen of een systeem een zakelijke processor met AMT heeft.

Heel user vriendelijk is de handleiding en tool niet, maar als je de tool download en uitpakt, voer dan in een elevated cmd prompt het volgende uit:

SCSDiscovery.exe SystemDiscovery

Dit duurt een aantal minuten, waarna de resultaten worden gedumpt in een log file in dezelfde directory. In mijn log file staat bovenaan:

2017-05-02 12:51:07:(ERROR) : ACU Configurator , Category: Error message: Failed to connect to the Intel(R) Management Engine Interface PTHI client. (0xc000001c)

Dan mag ik er vanuit gaan dat ik geen AMT support heb in mijn systeem.

[ibodar]

Zojuist mijn consumenten desktop gecontroleerd met de opgegeven detectie tool en voilà: ook kwetsbaar dus! Dit gaat echt niet alleen op voor zakelijke processors....

Hardware details (systeem uit 2011 alweer):

• Moederbord: Intel DQ67EP
• CPU: Intel Core i7-2600 (Sandy Bridge)
• AMTversion: 7.1.52
• FWVersion: 7.1.52.1176
• <IsAMTKVMSupported>True</IsAMTKVMSupported>

Gebruikte command line commando:

SCSDiscovery.exe SystemDiscovery scs.xml /noregistry

[Reactie gewijzigd door ibodar op 22 juli 2024 16:30]

[Armin]

Je moet de <AMTSKU> waarde zoeken, niet AMTKVM.