Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , 61 reacties

Beveiligingsonderzoekers hebben een ernstige kwetsbaarheid gevonden in uefi, de opvolger van de bios. In tegenstelling tot bekende beveiligingsproblemen met uefi is de nieuwe bug eenvoudiger te misbruiken en niet beperkt tot bepaalde fabrikanten van chips.

Dankzij de bug kunnen aanvallers de firmware van de uefi-chip herschrijven, waardoor ze vergaande toegang krijgen tot het systeem van een slachtoffer. Dat ontdekten beveiligingsonderzoekers Rafal Wojtczuk en Corey Kallenberg, die hun bevindingen uit de doeken deden op de CCC-beveiligingsconferentie in Hamburg.

Door de bug te misbruiken konden de onderzoekers beveiligingsmechanismen om de tuin leiden die moeten voorkomen dat software naar de uefi-chip wordt geflasht die niet van de fabrikant afkomstig is. In tegenstelling tot eerdere beveiligingsproblemen in uefi is het nieuwe probleem eenvoudiger te misbruiken; er is geen speciale apparatuur voor nodig. Ook gaat het om een probleem dat bij alle uefi-chips en zelfs oude bios-chips aanwezig is, beweren de onderzoekers.

Een van de manieren waarop de onderzoekers de chip om de beveiligingsmechanismen om de tuin wisten te leiden, is het herhaaldelijk uitvoeren van een schrijfoperatie naar het flashgeheugen. "Je kunt het miljoenen keren proberen, en op een gegeven moment lukt het", aldus onderzoeker Kallenberg. Daarvoor moet een aanvaller twee threads openen op een systeem met minimaal twee cores.

"Dankzij dit beveiligingsprobleem kunnen we firmware flashen naar de uefi-chip, maar ook in system management mode terechtkomen", aldus onderzoeker Wojtczuk. In system management mode kunnen vergaande wijzigingen worden aangebracht in een systeem, doordat processen met hoge privileges draaien. Doordat ook de firmware kan worden geflasht, kan door deze kwetsbaarheid malware worden aangebracht op een systeem die ook na herinstallatie van een besturingssysteem aanwezig blijft.  

In november vonden onderzoekers van Mitre al kwetsbaarheden in uefi. Daarbij ging het om twee kwetsbaarheden in de reference implementation van uefi-chips die door Intel is opgesteld en door veel bedrijven werd overgenomen. Daardoor waren uefi-chips van Phoenix, AMI, HP en Intel zelf kwetsbaar; ook toen kon persistente malware worden geïnstalleerd.

Moderatie-faq Wijzig weergave

Reacties (61)

Zoals ik het lees hebben ze toegang tot de hardware en gebeurt dit niet remote. Op het moment dat je toegang hebt tot de hardware wordt het heel lastig om dit voloende te beveiligen. Maar pfffff, wat een stemmingmakerij, als iemand bij mij thuis dit probeert heb ik wel grotere problemen aan mijn hoofd dan dit
Zoals ik het lees moeten ze 2 processen/threads draaien op je PC in usermode, iedere malware kan dit.

[Reactie gewijzigd door tomvleeuwen op 29 december 2014 00:12]

De titel is dan ook onjuist en het zou moeten zijn: "Beveiligingsonderzoekers vinden nieuwe kwetsbaarheid in uefi implementaties"

Nu stelt de aanhef dat het niet specifiek is "tot bepaalde fabrikanten van chips", maar als je leest hoe ze het doen blijft het een truc om UEFI implementaties om de tuin te leiden, geen lek in de specificatie.

Ik betwijfel dan ook dat alle implementaties vatbaar zijn. Zeker omdat er ook implementaties voor ARM zijn, welke flink anders zullen zijn dan eventuele reference implementaties voor x86.

Verder vraag ik me af of of deze truc om schrijfbeviliging uit te zetten ook de secure boot uitschakeld. Immers UEFI bied bescherming tegen flashen, maar ook bescherming tegen gemodificeerde binaries. Nu kan het zijn dat de EUFI implementatie wel de binary checksum controleert en niet een checksum van zichzelf, maar dat hoeft ook weer niet universeel te zijn.

Heeft iemand een link naar details?

UPDATE: Bing was mijn vriend:

https://www.youtube.com/watch?v=k7MEYMFN54o

Vanaf ongeveer 12 minuten. Het gaat dus om een bug in de implementatie, maar eentje die generiek is voor alle Intel gebaseerde systemen omdat de beveiliging van UEFI op de Intel-basis leunt. (Ik kon zo snel niet vinden of AMD gebaseerde systemen ook kwetsbaar zijn.)

Overigens is het wel een trage hack én de bug is inmiddels gefixt. De onderzoekers vonden de bug omdat Intel de bug gefixt heeft in de laatste versies van de laatste paar jaar. Zie iets voor 19 minuten voor wie kwetsbaar zijn en wie niet. Wat wel erg is, is dat veel fabrikanten de fix van Intel dus niet implementeren ook al is de bug dus al ruim twee jaar gefixt!

[Reactie gewijzigd door Armin op 29 december 2014 20:00]

En het moet veel toegepast zijn ook. Die macbookpro hier heeft het hier dan ook onder de grote hoeveelheden malware/spyware begeven. Toch een laptop van 2800 euro - zonde.
Het gaat niet alleen om je thuis-pc, maar ook die op je werk, bij de overheid of je vereniging. En dan is afluisteren of gegevens stelen niet zo'n probleem meer (als ze weten wat ze doen en het de moeite waard is)
Ja idd, bijv googles random number generator beinvloeden :), dan is ssl/https dood zonder dat je het door hebt.
Ligt er volledig aan of het flashgeheugen vanuit het OS te flashen of benaderen is. Als dat zo is zou het theoretisch vanaf afstand kunnen (malware).
Dit is natuurlijk niet eens nodig. Een nietvermoedende gebruiker kan heel goed om de tuin worden geleid om de benodigde handelingen zelf te verrichten op welke manier dan ook. 95% van de keren dat ik benaderd wordt i.v.m. particuliere ict-problemen zijn de gebruikers zelf de oorzaak van hun probleem, doordat zij onbewust 'slechte' software hadden geïnstalleerd. Zoals ik het nu begrijp kan een verkeerd vinkje in een installer binnenkort resulteren in het flashen van je uefi. Wel degelijke een ernstige zaak dus.

[Reactie gewijzigd door DEVoTi0N op 29 december 2014 00:16]

Dit is niet een attack vector, maar een persistent vector. Dus je dropt een 0-day of een usb rubber ducky, zorgt in iedergeval dat je binnenkomt en daarna wacht je op de meest veilig plek op bijv. een externe activatie zoals een ping. Enige manier om hem echt te verwijderen is alle geheugens die met de bios verbonden zijn te wissen met externe hardware of gewoon alles nieuw.

"DEF CON 22 Hacking Conference Presentation By Corey Kallenberg & Xeno Kovah - Extreme Privilege Escalation On Windows 8 UEFI Systems - Video and Slides.m4v" geeft hier ook veel uitleg over.
Maar pfffff, wat een stemmingmakerij
Waarom vind je dit stemmingmakerij? Zo'n artikel verwacht je toch bij Tweakers en dit is juist keurig geschreven vind ik.
Had een keer een modified UEFI BIOS geflashed waar apple powermangement in zat zodat OS X draaien op m'n PC. Dus je kan toch sowieso de BIOS/UEFI flashen?
Het punt is dat jij dat bewust deed (goeie feature). Dit artikel gaat erover dat het flashen ook mogelijk is zonder dat jijzelf dat wilt (oeps...).
dus, met andere woorden:

Koop een mobo met hardware-matige dual/tripple UEFI ROM switching (ik weet dat dit een veel voorkomende feature is op mid/high end mobos) en doe elke week een backup van je UEFI flashen naar je primary ROM tot er een betrouwbare manier is om te checken of je firmware geïnfecteerd is?...
Heb toch echt wel belangrijke en leukere dingen te doen dan wekelijks (of in andere frequentie) mijn uefi te backuppen, na te lopen en eventueel te herstellen...
De kans dat er malware nu al misbruik van maakt lijkt me zeer klein, de kans dat ik die malware binnen zou krijgen lijkt me ook erg klein, iig kleiner dan de kans dat ik uberhaupt malware binnenkrijg.
Snap niet dat de fabrikanten niet gewoon een schakelaartje op het moederbord plaatsen waarmee het geheugen wel/niet beveiligd wordt tegen overschrijven, dat een deel voor configuratie beschrijfbaar is, maar het firmware deel niet, dan heb je fysieke toegang nodig, op het moment dat de aanvaller je kast opent en aan je moederbord rotzooit zal het iig niet de schuld van uefi zijn, vind het raar dat dat soort maatregelen nog steeds niet genomen worden...
vind het raar dat dat soort maatregelen nog steeds niet genomen worden...
Sterker, toen lang geleden de eerste moederborden met softwarematig te updaten biossen geïntroduceerd werden was dit de standaard methode.

Die zijn later verwijderd vanwege gemakzucht, het moest vooral simpel zijn voor de gebruiker, in combinatie met de wens producten zo snel mogelijk te lanceren, inclusief bugs die dan later wel door een bios update gefixed konden worden.
Een houding die je nu bijvoorbeeld extreem sterk in de game industrie ziet.
tot er een betrouwbare manier is om te checken of je firmware geïnfecteerd is?...
Los van RGAT's punt (waar ik het helemaal mee eens ben), zodra je UEFI (of, wat dat betreft, BIOS) geïnfecteerd is, dan heb je twee gigantische problemen:
  • Je kunt niet betrouwbaar vaststellen óf er een infectie is. De BIOS chip kan namelijk "liegen" als je probeert de code terug uit te lezen en de originele code (zonder infectie) teruggeven, in plaats van wat er daadwerkelijk in staat.
  • Je kunt de infectie niet meer verwijderen. Er is al een keer, ik geloof op BlackHat, een demo geweest van een BIOS-virus dat, zodra nieuwe BIOS-code geflashed werd, die update on-the-fly met zichzelf kon infecteren. Het lijkt of de update gelukt is (als je echt een nieuwe versie wegschrijft, dan zal het nieuwe versienummer en nieuwe features netjes worden geüpdate), maar als het doel van de update is om een geïnfecteerde BIOS te vervangen door een schone, dan heb je mooi pech; dat werkt dus niet (en... helaas is er geen manier om te controleren of dat zo is, zie het eerste puntje).
TL;DR: "voorkomen is beter dan genezen" telt dubbel voor malware in je BIOS!
Zijn er eigenlijk moederborden waarop je een fysiek knopje moet omzetten om de mogelijkheid tot UEFI flashen aan te zetten? Dat lijkt mij de meest voor de hand liggende oplossing.
Ja, bijna alle server moederborden hebben een jumper. Veel Intel moederborden hebben dat ook. Vaak staat die jumper dan al wel op flash toestaan, maar die kan je dus verwijderen/ompolen. Wat die in principe doet (dacht ik) is de RW lijn onderbreken die standaard aan +5v moet hangen om schrijven mogelijk te maken. Dat is dus hardwarematig de flashchip niet beschrijfbaar maken. Kan je niet met software omzeilen om dat het niet software-beheerd is. Op z'n best kan je als er goede power controls hebt op je moederbord je chip proberen heel precies te undervolten, en dan kan je nog wel eens net de beveiligingscircuits spanningsloos maken terwijl de rest blijft werken. In de praktijk met normale moederborden niet haalbaar om dat alles aan dezelfde rail hangt.
Hmm goed om te weten. Dan zouden ze beter de verbinding echt fysiek kunnen verbreken, door b.v. een veertje al dan niet tegen geleidend metaal aan te drukken, zoals een AA-batterij stroom geeft als hij tegen het veertje aandrukt.
Een jumper doet dat al :) Het is in feite een header met 2 of 3 pinnetjes waarbij een jumper twee pinnetjes kortsluit. Als de RW lijn (soms een die in de flash chip al hoog gehouden wordt) dan dan dus omlaag (of omhoog naar 5v, hangt dus van de chip af) getrokken wordt kan software iets schrijven, en anders niet. Het verschil tussen moederborden die dat hebben en die het niet hebben is eigenlijk alleen dat bij de borden die het niet hebben de verbinding gewoon ononderbroken doorgetrokken is naar de juiste rail of ground en dus altijd actief is.

Eigenlijk maakt het niet zo veel verschil voor gebruikers als er een header op zit qua gemak: iemand die z'n firmware wil gaan updaten zal waarschijnlijk niet bang worden van een jumpertje plaatsen of verwijderen om dat mogelijk te maken. Iemand die dat wel eng vind gaat waarschijnlijk ook geen firmware updates doen, want dat is net zo 'eng' ;)
Ja OK, ik doelde op wat jij beschreef van dat ondervolten: als je op zo'n manier toch in bepaalde gevallen de jumper kunt omzeilen is het niet écht een fysieke beveiliging! Of in elk geval geen waterdichte. Maar als je de stroom zou onderbreken naar een onderdeeltje dat als enige schrijfacties kan uitvoeren op de chip of zoiets, dan zou dat wellicht immuun zijn.
Dat is dus wat een jumper doet :) Je hebt 1 chip, een flash geheugen, en die heeft een aantal pinnen. Hij moet stroom hebben om te kunnen werken, want je moet hem kunnen lezen om op te kunnen starten. Die pinnen moet je dus aangesloten hebben. Dan heb je er een paar voor data uitwisseling, dat is 1 set die voor zowel lezen als schrijven gebruikt wordt. Dan zijn er vaak nog een paar losse pinnetjes voor beheer, zoals write enable. Die kan je fysiek onderbreken en dan kan je niet meer schrijven.

Undervolten is iets wat bij microcontrollers bijvoorbeeld gebruikt wordt om te leesbescherming te omzeilen als iemand z'n code geheim wil houden, en kan in theorie met andere chips gebruikt worden om bepaalde delen van de chip gewoon buiten werking te stellen. In theorie kan dat dus ook met flash chips als ze intern een los circuit gebruiken om te bepalen of schrijfacties wel of niet mogen. Misschien dat ze zo ontworpen zijn dat dat niet het geval is, bijvoorbeeld door dat de write enable pin een rechtstreekse verbinding is naar een circuit dat ook gebruikt wordt voor lezen en daarmee dus zodra het werkt ook kan controleren of er of wel niet geschreven mag worden. Hangt dus sterk van het interne ontwerp af :)
Ah, dat is precies wat ik bedoel: zo'n soort failsafe-mechanisme moet je hebben, dat het écht niet kan zonder dat een bepaald onderdeeltje stroom heeft, en dat het die stroom alléén kan krijgen als het hardwarematige dingetje in de juiste stand staat.
De AA batterij staat altijd onder spanning, ook als je er niet tegen drukt. Natuurlijk kan er wel pas stroom gaan lopen als je verbinding maakt tussen de batterij en de verbruiker. Misschien bedoelde je dat maar schreef je het wat onduidelijk op.

Wat je in dat geval zou beschrijven, bestaat al en wordt hierboven genoemd: een jumper.
Ik maakte eigenlijk twee punten in één, waardoor het niet zo duidelijk was. Enerzijds reageerde ik op John Keats' opmerking dat jumpers in bepaalde gevallen omzeild kunnen worden. Anderzijds vind ik jumpers onhandig en heb ik liever een schuifje o.i.d. waarmee je de verbinding verbreekt of zoiets, waarvoor ik met dat batterijveertjesverhaal kwam: als het schuifje de veer terugduwt heb je misschien wel een handig en simpel systeempje.
Een variant op dat contactje dat je met een schuifje bedient bestaat ook al voor dit soort toepassingen en heet het een DIP-switch. Die zaten vroeger wel op moederborden. Was inderdaad iets minder gepruts dan met jumpertjes en lijkt me een goed idee van je om die weer in te voeren.

[Reactie gewijzigd door mae-t.net op 30 december 2014 22:49]

Jee! Dan vraag ik me af waarom ze zijn overgegaan op jumpers.
Om dat jumpers goedkoper zijn ;) een verschil van 1 cent is al voldoende om over te gaan. Daarnaast is het ook niet alsof je ze vaak gebruikt :p in veel gevallen zal er nooit een firmware update gedaan worden en dan is het dus weggegooid geld. Nu lijkt 1 cent niet veel, maar op een bill of materials voor massaproductie telt elke cent.

Dat is ook de reden dat we van schakelaars naar jumpers naar contact pads naar 'haal-de-batterij-er-maar-uit' zijn gegaan om je NVRAM te wissen als je je BIOS of andere firmware wil resetten. Een drukknopje is veel makkelijker dan een jumper omdraaien of verwijderen, maar ook duurder, net als dat een jumper duurder is dan contact pads, en pads ruimte gebruiken terwijl je dan net zo goed de batterij even uit de houder kan halen :p Alles voor kostenbesparing.
Ja dat begrijp ik wel, helaas. Voor mij zou het die ene cent wel waard zijn, ook al doe ik het maar één keer!
Dit is niet zo heel spannend, klinkt meer als een platform probleem dan een UEFI probleem. Hell, misschien is het wel x86 specifiek, dat maakt het nog minder een firmware probleem dan het eigenlijk al is.

Wat ze hier beschrijven is eerder een aanval op code die op 1 core tegelijk kan reageren. Door 2 cores of meer te gebruiken kan je dan dus blijkbaar van een soort van race condition winnen wat in de praktijk niet zozeer betekent dat UEFI slecht is, maar dat het platform dus iets laat doen wat in user mode wel kan maar in een hogere (of, lagere, de ring nummering gaat vanaf daar naar beneden, niet omhoog ;) ) mode niet? (Met meer cores werken)

Het feit dat er in het artikel ook al staat dat in conventionele BIOS implementatie hetzelfde probleem bestaat zou toch al duidelijk moeten maken dat dit niet zozeer een systeemfirmware issue is, maar een ISA probleem.
Maar onder de streep is UEFI daardoor dus wel kwetsbaar en daar gaat het om... maar je zou inderdaad op Tweakers wat meer in-depth uitleg daarover verwachten. Ik vermoed dat dit dicht bij de waarheid zal liggen.

Want idd, je kan het duurste en beste slot op je voordeur zetten, maar als de scharnieren van papier mache zijn gemaakt dan zal dat slot ook niet veel helpen.
Onder de streep is.. ALLES kwetsbaar. Als je in SMM zit is de complete stack kwetsbaar. Van low level microcode tot aan high level applicaties. Hypervisors, besturingssystemen, embedded systemen (zoals AMT), firmware in je opslag apparaten, usb controllers, wifi chipsets, je aangesloten toetsenborden, printers, webcam, monitor, en toevallig ook je BIOS/UEFI. Onder de streep is ALLES kwetsbaar en niet specifiek UEFI.
Vraag me af of ook hier de NSA een rol in heeft gespeeld net als dat het kraken van https voor hun erg handig is?
Er zitten trouwens meer functies in het UEFI bios waar ik vraagtekens bij zet. Zoals bijvoorbeeld de keybot functie? Even via een druk op de knop je keyboard updaten met wat....BadUSB? ;) Zal wel niet zover gaan maar toch.
Mooie brug naar het vorige nieuwstopic! ;)
Ik zou zeggen: Hiep hiep hoera! Deze functionaliteit dient samen met secure boot namelijk om systemen mogelijk te maken waar jij als eigenaar niet de baas over bent. Het besturingssysteem is prima in staat om te voorkomen dat malafide programma's bij kritische hardware zoals de firmwareflashfuncties kunnen komen. Het moederbord zelf hoeft daar niet op te beveiligen: De moet gewoon uitvoeren wat zijn meester hem beveelt.
Helaas is het OS daar niet toe in staat, aangezien er voor praktisch ieder OS rootkits en soortgelijke troep bestaat. Je zal iedere laag afzonderlijk moeten beveiligen. Het idee dat je met 1 of 2 beveiligde lagen afdoende beschermd bent is al jaren lang achterhaald.
maar waarom zullen er mensen precies belang hebben bij het flashen van jou hardware? pc's hacken en daar bankgegevens of wachwoorden aftappen kan ik mij voorstellen omdat je daar als dader geld mee kan 'winnen'. maar wat schiet een dader hier mee op? Reclame in je bios/efi/eufi?
Hoewel OS-en niet perfect zijn, zijn ze tegenwoordig steeds beter beschermd. Een rechtstreekse aanval is dus steeds minder succesvol. Een geslaagde aanval op de hypervisor of hardware laag kan gebruikt worden om de beveiliging op een hoger niveau te omzeilen.

Stel je voor je gebruikt 3 verschillende OS-en: Je standaard Linux desktop omgeving, een oude XP installatie voor een paar games en een BSD-bootcd voor internetbankieren. Het onveilige XP wordt aangevallen en je merkt iets vreemds op, boot naar Linux en zet een image terug op de XP partitie. Probleem opgelost denkt je. Maar de aanvaller heeft je hardware laag kunnen overnemen waardoor hij ook je de beveiliging van je Linux desktop en je bootcd kan omzeilen of verzwakken.

Voor zover we weten is zo'n scenario nog niet in de praktijk gebracht, maar voor de makers van Stuxnet zou dit een potentieel zeer interessant scenario zijn.
Omdat het niet zo eenvoudig is: Het is niet zo makkelijk een code te schrijven die compatibel is met de firmware van een willekeurig moederbord en tevens is het niet zo makkelijk om actief te blijven nadat een besturingssysteem gestart is. De Linuxkernel schopt gewoon alles uit het geheugen nadat hij gestart is.

Om het met succes te kunnen doen doen de malafide software de hardware moeten virtualiseren en als hypervisor functioneren. Maar dat is niet genoeg: Alleen het besturingssysteem kan met de buitenwereld communiceren en alle hardware in de computer aansturen. De malafide hypervisor moet daarom toch weer met besturingssyteem gaan communiceren, maar heeft geen idee welk besturingssysteem met welke versie de gebruiker gebruikt.

Je zou een stuk software van monsterachtige complexiteit krijgen, en dat zou allemaal in overgebleven ruimte in een BIOS-chipje moeten passen?

[Reactie gewijzigd door dmantione op 29 december 2014 09:59]

Naja stel je een botnet van een slordige 200.000 voor welke in de uefi geïnfecteerd zijn en zelfs na herinstallaties weer beschikbaar zijn voor het botnet, dat zou een krachtige, en vrij griezelig idee zijn...
het gaat niet alleen om geld. Sommige mensen zoals Edward Snowden worden ook gehackt om ze te vinden, of om de mensen waardoor hij gesteund wordt te sabotteren

Het is oorlog Galinsky.
Liever een rootkit in je OS, dan in je BIOS. Als die derde beveiligingslaag onbetrouwbaar is, dan is dat erger dan wanneer hij er simpelweg niet is, lijkt me toch. Omdat je bovendien zelf minder op je computer kan (zoals het verwijderen van een virus, maar ook een eventuele beperking van de vrijheid om met je hardware te doen wat je wilt), lijkt het me duidelijk dat de balans in het negatieve doorslaat.

[Reactie gewijzigd door mae-t.net op 29 december 2014 03:10]

Die redenering klopt niet: Een rootkit doorbreekt geen beveiliging en bestaan daarvan heeft dus niets te maken met of het OS in staat is zich te beveiligen. En als er een hardwarebeveiliging nodig is dan weet ik een hele simpele: Een jumper op het moederbord. Als die complexe UEFI-troep doet meer kwaad dan goed.
Unified Extensible Firmware Interface. Iets teveel extensible dunkt me.
Op zich een goed punt, waarom moet je bijvoorbeeld met een muis je instellingen kunnen wijzigen? Is toch nergens voor nodig?
Het kan beter zo simpel mogelijk gehouden worden en die kernsoftware zo veilig mogelijk gemaakt worden.
Vind zelf inderdaad ook die muisinterfaces nogal halfbakken aanvoelen, dit kan natuurlijk ook komen omdat ik nog op een P67 van ASRock zit (ontwerp uit 2011, hoewel hun enigste tussentijdse toevoeging geluidjes lijken te zijn die je een retrogevoel geven uit 1993). Gigabyte en ASUS lijken beter te zijn, heb ze zelf niet uit kunnen proberen.

Het zou leuk zijn als er een mogelijkheid komt om gewoon naar een kale Aptio Setup Utility te gaan. Naar een UEFI kijken is niet echt een dagelijkse bezigheid voor mij.

Ben voor de rest gewoon voorstander van UEFI, en hoop dat historische rotzooi als BIOS en MBR gauw verdwenen zijn.

[Reactie gewijzigd door field33P op 29 december 2014 00:50]

Dus liever moderne rotzooi dan historische rotzooi? Die laatste heeft zich inmiddels ruimschoots kunnen bewijzen en is volwassen. Tel uit je winst.
Dus liever VGA dan DVI? Die eerste heeft zichzelf inmiddels ruimschoots kunnen bewijzen en is volwassen. Tel uit je winst.
Ik had het in deze context zeer specifiek over UEFI versus een traditioneel BIOS om je erop te wijzen dat nieuwer niet per definitie beter is en zich nu kennelijk als onbetrouwbaarder bewijst dan het systeem dat het moest vervangen, en niet over VGA versus DVI. Al zie ik wel wat je probeert te doen.

Overigens zou ik normaal het woord rotzooi niet gebruikt hebben omdat ik dat kort door de bocht vind (zoals jij kennelijk nu ook als ik het gebruik?), maar haalde dat van jou aan om het tegenargument een beetje op dezelfde manier neer te zetten zodat het duidelijker overkwam.

Overigens ben ik ook wel benieuwd wat er zo slecht is aan een traditioneel BIOS en een MBR dat het nu echt zo snel mogelijk moet verdwijnen. Waarschijnlijk ben ik het met een aardig deel van je argumenten wel min of meer eens (16 bits, limitaties aan schijfgrootte enzo), alleen de gepassioneerdheid en veronderstelde zaligmakendheid van de opvolger die ik in je reactie lees kan ik - zeker omdat UEFI ook niet zaligmakend blijkt te zijn - niet helemaal volgen.

Nog een leuke te-kort-door-de-bocht als uitsmijter: Juist omdat het traditionele BIOS-systeem al langere tijd aardig verouderd is, is in de praktijk bewezen dat je bijna alles aan je OS kunt overlaten en dus niet alleen geen traditionele BIOS maar ook geen uitgebreide UEFI nodig hebt.

[Reactie gewijzigd door mae-t.net op 30 december 2014 06:11]

off topic: Heb hetzelfde model. Was er na enige tijd zodanig door geïrriteerd dat ik een soldeerbout genomen heb en het eens goed in de "speaker" van het bord heb geduwd. Geen last meer van. Topidee. Hopelijk gaat er nooit iets mis want die piepcodes zijn weg.
Heerlijk, zo'n speaker met een plugje. Én een debug display.
De AMI winbios uit begin jaren 90 kon je ook geheel met de muis bedienen. Niet bepaald een innovatie.
"Miljoenen keren". Hmm. Is zo'n operatie richting het flash geheugen normaal? Op het eerste gezicht lijkt dit opvallend genoeg om aandacht te trekken.
Processor draait op 1Ghz+

Miljoen keer naar de RAM schrijven gaat binnen de seconde...
Hoi,

Dat kan ik me indenken. Echter, flash geheugen is niet-vluchtig (permanent) geheugen. RAM is vluchtig. Lijkt me dat de firmware van de uefi-chip veilig zou moeten zijn, tenzij er een update nodig is. Die update zou wegens omstandigheden natuurlijk een aantal keer kunnen failen. Maar een miljoen keer binnen een seconde naar dat geheugen proberen te schrijven is wel out of the ordinary, imo.

Had men daar rekening mee kunnen houden? Geen idee. Coding is sws ingewikkeld in de zin dat de kracht van de code in grote lijnen afhankelijk is van de skills van de programmer. Of zie ik dit verkeerd? Iig blij dat beveiligingsonderzoekers hier (op tijd) achter zijn gekomen.

2 cores - 2 threads. Niet dat ik het hele proces nu direct snap, maar in principe zegt die chip dus op een gegeven moment (na een paar miljoen attempted schrijfacties): "Alright, access granted. Heb koppijn." (metaforisch natuurlijk)

Tilt?

Als de software impenetrable zou zijn voor black hat hackers, is er niets aan de hand. Toch?
Maar een miljoen keer binnen een seconde naar dat geheugen proberen te schrijven is wel out of the ordinary, imo.

Het is geen software, maar hardware die gekraakt wordt. Er is dus niets om te controleren hoe vaak je schrijft. En besef dat een 1MB flash volschrijven ook al een miljoen transacties is, dus een miljoen is niet bijzonder veel.

De truc zoals beschreven is als volgt: Een kwaadaardig programma probeeft te schijven maar moet daarvoor de "write bit" eerst op 1 zetten. Op moment dat de write bit op 1 gezet wordt wordt de security module via een hardware interrupt geactiveerd. Deze controleert of de aanroeper geautoriseerd is. Dat is niet zo en dus wordt de bit weer op 0 gezet waardoor de schrijfactie van het kwaadaardige proces geblokeerd word. Omdat de hardware interrupt elk software process onderbreekt is dit in principe veilig.

Echter bij multicore systemen zou een tweede process parallel kunnen proberen te schrijven zonder die bit te activeren. In principe zou die schrijfactie dus altijd falen, maar er is een hele kleine kans dat de schrijfactie precies plaatsvind tussen het activeren van de bit door de eerste CPU, en het nog niet resetten van de security module. Door heel vaak te proberen kun je zo langzaam byte voor byte schrijven.

En dat is de bug.

Intel heeft die bug echter al reeds twee jaar geleden (!!!) gefixt door een nieuwe extra security methode (weer een extra bit _/-\o_ ) die ervoor zorgt dat alle CPU's in een systeem geauthenticeerd moeten zijn. Deze beveiliging is echter opt-in (naar ik vermoed omdat het potentieel compatibilietitsproblemen kan opleveren met oude BIOS/UEFI software) en niet alle fabrikanten hebben deze beveiliging ingeschakeld. Dat laatste is dus het probleem.

(En daarnaast beschrijven de onderzoekers nog een andere method eom EUFI te kunnen hacken, maar maar ook deze wordt geblokeerd door die nieuwe opt-in security methode.)
Heya Armin,

Ahh, dank je voor die uitleg. Ik had al een vermoeden dat er iets in die richting ad hand was. Je uitleg bevestigt dit.

Hardstikke bedankt. You've saved me a ton of thinking time.
Overigens blijft mijn eerdere gedachte hetzelfde. Een miljoen keer de write-bit op 1 proberen te zetten is, mijn inziens, (nog steeds) opvallend. Ik begrijp dat 1 MB wegschrijven in principe natuurlijk niet direct abnormaal is, maar een miljoen keer proberen voorbij de interrupt te komen is toch weird? Als ik 5000 keer achter elkaar op iemand's deurbel druk gaan de meeste mensen denken "What the falafel?" (lijkt mij).
Ik snap wat je bedoelt, maar het is dus een hardware controller. Op hardware niveau is geen concept van software processen. Immers dat is een abstract kunstmatig concept dat het OS bedenkt, maar op dat diepe hardware niveau letterlijk niet bestaat.
Alle schrijfacties worden gedaan door de CPU(s) of andere controllers. Er is dus geen verschil tussen een process dat X schrijfacties doet of talloze verschillende processen. De flash controller ziet immers enkel de CPU (of andere hardware unit) waar het schijf/lees commando vandaan komt.

Dus men kan niet weten of de schrijf operatie N en N+1 van hetzelfde process komen. Men ziet schrijf-signaal lijn X qua spanning omlaag gaan, en op adresseerlijnen A1 t/m A32 een bitpatroon vormen. Meer 'weet' een hardware controller niet. Abstractie zoals processen is iets wat veel en veel hoger zit.

Dat afhandelen is de taak van de security module, en die blijkt dus asynchroon te werken per CPU ipv over alle CPU's hetgeen de bug is.
Ik snap het Armin. Dank je wel, nogmaals. Het probleem zit hem in de security module dus. Duidelijk.

Excuses late reactie.

Op dit item kan niet meer gereageerd worden.



Apple iOS 10 Google Pixel Apple iPhone 7 Sony PlayStation VR AMD Radeon RX 480 4GB Battlefield 1 Google Android Nougat Watch Dogs 2

© 1998 - 2016 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Carsom.nl de Persgroep Online Services B.V. Hosting door True