Intel bevestigt dat uitgelekte broncode Alder Lake-uefi echt is

Intel bevestigt dat de uefi-broncode voor zijn Alder Lake-processors is uitgelekt. Afgelopen weekend verscheen 5,86GB aan biosbestanden en tools om biosimages voor die processors te maken. Het bedrijf verwacht niet dat dit tot beveiligingsproblemen zal leiden.

Intel bevestigt het lek tegenover Tom's Hardware. "Onze besloten uefi-code lijkt te zijn uitgelekt door een derde partij", vertelt een woordvoerder van het bedrijf. "Wij geloven niet dat dit nieuwe veiligheidslekken blootlegt, aangezien wij niet vertrouwen op obfuscatie van informatie als veiligheidsmaatregel", claimt het bedrijf. Het bedrijf geeft aan dat de code onder zijn bugbountyprogramma valt en roept gebruikers die eventuele beveiligingsproblemen ontdekken op om deze te melden. "We nemen contact op met zowel klanten als de beveiligingscommunity om hen op de hoogte te houden van deze situatie."

De broncode van Intels Alder Lake-uefi verscheen dit weekend op 4chan en GitHub. Het gaat om een bestand dat 2,8GB groot is bij compressie en 5,86GB als het is uitgepakt. Het is niet bekend waar de code vandaan komt, maar hackers hebben al aanwijzingen gevonden naar externe leveranciers. In de uitgelekte code zouden daarnaast meerdere verwijzingen naar Lenovo zijn gevonden, schrijft Bleeping Computer.

Securityonderzoeker Mark Ermolov doet momenteel onderzoek naar de code. Hij stelt onder meer dat geheime model-specific registers zijn uitgelekt. Ook een private signing key van Intels Boot Guard lijkt te zijn uitgelekt. Het is echter niet bekend of die key momenteel gebruikt wordt in productie. Het is daarom nog niet duidelijk wat de exacte gevolgen van dit lek zijn. Gezien Intels claim dat het niet leunt op obfuscatie, is het aannemelijk dat het meest gevoelige materiaal uit de uitgelekte tools zijn verwijderd voordat deze worden gedeeld met externe leveranciers. Tweakers heeft hierover vragen uitstaan bij Intel.

A very bad thing happened: now, the Intel Boot Guard on the vendor's platforms can no longer be trusted... ☹️ pic.twitter.com/K5mXcp5ipW

— Mark Ermolov (@_markel___) 8 oktober 2022

Reacties (16)

[Z100]

Wat ik respect waardig vind is de reactie van Intel. I.p.v. de opdracht te geven voor de PR afdeling om damage control uit te voeren (afdoen dat het niets is), zegt Intel inprincipe "doe wat nuttigs met de broncode, en voor gevonden zwakheden betalen wij".

Ik denk dat het echt niet zo heel eng is als hardware fabrikanten hun broncode zelfs openstellen.

Software fabrikanten willen liever DRM through obscurity en dat broncode van elk klein onderdeel geheim wordt gehouden, maar het maakt de wereld onveiliger. Open firmware is de weg voorwaarts. Ook in het vooruitzicht van Right to Repair. M.i. heb je ook het recht om te weten wat exact draait op je systeem.

[d3burt]

Intel is nou niet de eerste naam die bij mij naar boven komt als ik aan "eerlijk en open" denk. :-) Ik denk dat de PR afdeling snel heeft ontdekt dat hier niets aan te ontkennen valt. Zodra je dat weet worden de opties voor damage control een stuk simpeler.

[Z100]

Intel is nou niet de eerste naam die bij mij naar boven komt als ik aan "eerlijk en open" denk. :-)

Idem. Toch zie je dat Intel een andere toon voert sinds ze in een underdog positie weer zitten. Iets meer humble. Je ziet dat vooral terug in hoe Intel Arc op de markt zet, met opensource componenten.

Ik zou willen dat Nvidia ook door zo'n periode gaat. Het is goed als bedrijven die aan de top zitten, om de zoveel tijd hun positie verliezen.

[ari3]

Wat ik respect waardig vind is de reactie van Intel. I.p.v. de opdracht te geven voor de PR afdeling om damage control uit te voeren (afdoen dat het niets is), zegt Intel inprincipe "doe wat nuttigs met de broncode, en voor gevonden zwakheden betalen wij".

Het zou respectwaardig zijn als Intel bij voorbaat alle broncode ter beschikking had gesteld en dan mensen zou aanmoedigen om er "iets nuttigs mee te doen en te betalen voor gevonden zwakheden." Nu komt deze uitspraak pas nadat de code gelekt is. Ze hadden helemaal nooit de intentie om deze broncode openbaar te maken, dus hebben ze er maar een PR-spin aan gegeven.

Als Intel meeleest: ik wacht nog steeds op de documentatie en broncode van jullie CPU en GPU microcode. Bedankt alvast voor het openbaren. Ik zal mijn best doen om er iets nuttigs mee te doen en zie graag jullie betaling voor gevonden zwakheden tegemoet.

[PolarBear]

Securityonderzoeker Mark Ermolov doet momenteel onderzoek naar de code. Hij stelt onder meer dat geheime model-specific registers zijn uitgelekt. Ook een private signing key van Intels Boot Guard lijkt te zijn uitgelekt. Het is echter niet bekend of die key momenteel gebruikt wordt in productie.

Maar het is toch niet zo heel complex om uit te vinden of de gelekte key ook daadwerkelijk een productie key is of domweg een dev key? Zeker van een securityonderzoeker zou ik verwachten dat hij dat als een van de eerste dingen checkt voor een tweet de wereld in te sturen met dat Intel Boot Guard niet meer vertrouwd kan worden.

Hij stelt onder meer dat geheime model-specific registers zijn uitgelekt.

Als ik dan het gelinkte Wiki artikel er bij pak:

Documentation regarding which MSRs a certain processor implementation supports is usually found in the processor documentation of the CPU vendor. Examples for rather well-known MSRs are the memory type range registers (MTRRs) and the address-range registers (ARRs).

Ik lees in sidereal niets over dat het per se een enorm geheim gegeven is. Itt het lekken van het mogelijk lekken van private keys lijkt mij dit veel minder een issue.

[Reactie gewijzigd door PolarBear op 24 juli 2024 23:25]

[bartje]

er wordt niet benoemd of er een key bij de code zit, dus ik vermoed van niet.
en zowel, dan zullen ze deze met een update wel bijwerken denk ik.
Daarnaast zou het dan ook alleen om de lenovo key gaan lijkt me
wat deze security onderzoeker gaat doen is de code zelf doorspitten op security bugs.

Ik neem aan dat dit voor Intel een minor issue is als het gaat om code die met partners gedeeld wordt. Dan moet je ondanks dat het niet mag rekening houden met de mogelijkheid dat eea op staat komt te liggen.
Je geeft immers informatie weg die je zelf niet meer kunt controleren.

[Qwerty-273]

Zeker van een securityonderzoeker zou ik verwachten dat hij dat als een van de eerste dingen checkt voor een tweet de wereld in te sturen met dat Intel Boot Guard niet meer vertrouwd kan worden.

Tja, als je te veel gaat verifiëren dan is een ander eerder op de twitter, en wordt je naam niet meer wereldwijd opgepakt. Hij zit nu in de spotlight met zijn beweringen en die kan hij later een beetje afzwakken na dieper onderzoek.

[hooibergje]

Nog best indrukwekkend dat je daar 5.86 GB mee kan vullen.
Ik zou wel verwachten dat dat allemaal kleine compacte code is en kleine tooltjes zijn.
Valt dan toch weer tegen.

[markjanssen]

Het is een subversion (versiebeheersysteem) dump... dus basically zit alles er (minstens) 2x in, mede daarom was de compressie ook redleijk.
De genoemde key zit er minstens 8x in....

[aikebah]

Het is een subversion (versiebeheersysteem) dump... dus basically zit alles er (minstens) 2x in, mede daarom was de compressie ook redleijk.
De genoemde key zit er minstens 8x in....

Waarom zou alles 2x in een subversion dump zitten? Ik gok dat je een subversion dump (content van de volledige svn repository history) verwart met een subversion workspace (lokale checkout van een svn branch inclusief de 'pristine copy' in de .svn map)?

[PolarBear]

Dit soort tools nemen veel ruimte in, veel (gegeneerde) debug informatie etc.

[Tsjilp]

node_modules niet in de .gitignore

[Gronaldo]

Zijn de TMP2.0 modules nu ook overbodig geworden?

[jaaoie17]

Dat zijn ze toch al een hele tijd.

[habbekrats]

Toch kan hier een risico inzitten, stel een kwaadwillende maakt een bios betstand. Zet dit ergens op het web neer, een nietsvermoedende gebruiker zoekt op google bios update bla bla. En hup je je krijgt een bios met malware op je PC.

[Pinkys Brain]

Even aangenomen dat de signing key voor testen is en de echte in een Hardware Security Module zit, wat je wel mag hopen, zal dat niet lukken.