Sårbarhet upptäckt i UEFI-mjukvara på Intel-moderkort

Av ren nyfikenhet så undrar jag om Gemini (gratisversionen) gav ett korrekt lösningsförslag.

Jag gav den först koden:

void Function_0000537c(void){
...
  ulonglong data_size;
 char buffer [8];
...
 EVar1 = (*gRS_2->GetVariable)
                    ((CHAR16 *)TCG2_CONFIGURATION, &gTCG2_CONFIG_FORM_SET_GUID,
                     (UINT32 *)0x0, &data_size, buffer);
  if (EVar1 == EFI_BUFFER_TOO_SMALL) {
    EVar1 = (*gRS_2->GetVariable)
                      ((CHAR16 *)TCG2_CONFIGURATION,&gTCG2_CONFIG_FORM_SET_GUID,
                       (UINT32 *)0x0,&data_size,buffer)"

och bad den ändra i den lilla utsträckning som behövdes för att skydda mot buffer overflows.

Då spotta den ut:

void Function_0000537c(void) {
  ulonglong data_size;
  char* buffer; // Use a pointer instead of a fixed-size array

  // First call to GetVariable to determine data size
  EVar1 = (*gRS_2->GetVariable)
      ((CHAR16*)TCG2_CONFIGURATION, &gTCG2_CONFIG_FORM_SET_GUID,
       (UINT32*)0x0, &data_size, NULL);

  if (EVar1 == EFI_BUFFER_TOO_SMALL) {
    // Allocate memory based on retrieved data_size
    // Check for allocation failure (not shown here)
    buffer = AllocatePool(EfiBootServicesData, data_size);

    // Second call to GetVariable with allocated buffer
    EVar1 = (*gRS_2->GetVariable)
        ((CHAR16*)TCG2_CONFIGURATION, &gTCG2_CONFIG_FORM_SET_GUID,
         (UINT32*)0x0, &data_size, buffer);

    // Free the allocated memory after use (not shown here)
    FreePool(buffer);
  } else {
    // Handle unexpected return values (not shown here)
  }
}

där den först gjorde om buffer till en pekare istället för en fast array. Bra/dåligt?

Sen kör den något som heter AllocatePool() vilket jag inte vet om det är bra/dåligt i sammanhanget?

Till sist la den till ett else-block för oväntade returvärden. Bra/dåligt?

Brukar det vara som så att buffer overflows oftast beror på avsaknaden av fastställda variabelstorlekar och/eller kontroller av hur mycket de innehåller jämfört med tillåten maxstorlek? (alltså hur mycket de får rymma som mest)

Men det jag inte förstår då är att om jag först tillåter obegränsad minnesallokering för att sedan kontrollera om det är inom tillåten storlek, så måste jag ju lagra den där obegränsade minnesallokeringen någonstans innan jag kan kontrollera den. Under lagringen så kan den väl då hypotetiskt talat råka skriva över andra variabler i minnet om det är tillräckligt stort? 🤔

Mvh,
WKL.

void Function_0000537c(void){
...
  ulonglong data_size;
 char buffer [8];
...
 EVar1 = (*gRS_2->GetVariable)
                    ((CHAR16 *)TCG2_CONFIGURATION, &gTCG2_CONFIG_FORM_SET_GUID,
                     (UINT32 *)0x0, &data_size, buffer);
  if (EVar1 == EFI_BUFFER_TOO_SMALL) {
    EVar1 = (*gRS_2->GetVariable)
                      ((CHAR16 *)TCG2_CONFIGURATION,&gTCG2_CONFIG_FORM_SET_GUID,
                       (UINT32 *)0x0,&data_size,buffer)"

void Function_0000537c(void) {
  ulonglong data_size;
  char* buffer; // Use a pointer instead of a fixed-size array

  // First call to GetVariable to determine data size
  EVar1 = (*gRS_2->GetVariable)
      ((CHAR16*)TCG2_CONFIGURATION, &gTCG2_CONFIG_FORM_SET_GUID,
       (UINT32*)0x0, &data_size, NULL);

  if (EVar1 == EFI_BUFFER_TOO_SMALL) {
    // Allocate memory based on retrieved data_size
    // Check for allocation failure (not shown here)
    buffer = AllocatePool(EfiBootServicesData, data_size);

    // Second call to GetVariable with allocated buffer
    EVar1 = (*gRS_2->GetVariable)
        ((CHAR16*)TCG2_CONFIGURATION, &gTCG2_CONFIG_FORM_SET_GUID,
         (UINT32*)0x0, &data_size, buffer);

    // Free the allocated memory after use (not shown here)
    FreePool(buffer);
  } else {
    // Handle unexpected return values (not shown here)
  }
}

I det första anropet till GetVariable så används NULL som buffer-argument, vilket signalerar till GetVariable att sätta data_size till storleken som buffern behöver vara för att kunna lagra resultatet. Efter det så allokeras en buffer av den storleken, GetVariable anropas igen med den buffern, och till sist avallokeras buffern igen.

Så upplägget ser korrekt ut, att först fråga hur stor buffern behöver vara är ett vanligt sätt att undvika buffer overflows. Koden i sig är inte riktigt korrekt, AllocatePool returnerar inte buffern utan tar den som ut-argument och data_size borde initialiseras till 0 enligt dokumentationen, och resultatet måste förstås också användas till något innan buffern avallokeras.

void Function_0000537c(void){
...
  ulonglong data_size;
 char buffer [8];
...
 EVar1 = (*gRS_2->GetVariable)
                    ((CHAR16 *)TCG2_CONFIGURATION, &gTCG2_CONFIG_FORM_SET_GUID,
                     (UINT32 *)0x0, &data_size, buffer);
  if (EVar1 == EFI_BUFFER_TOO_SMALL) {
    EVar1 = (*gRS_2->GetVariable)
                      ((CHAR16 *)TCG2_CONFIGURATION,&gTCG2_CONFIG_FORM_SET_GUID,
                       (UINT32 *)0x0,&data_size,buffer)"

void Function_0000537c(void) {
  ulonglong data_size;
  char* buffer; // Use a pointer instead of a fixed-size array

  // First call to GetVariable to determine data size
  EVar1 = (*gRS_2->GetVariable)
      ((CHAR16*)TCG2_CONFIGURATION, &gTCG2_CONFIG_FORM_SET_GUID,
       (UINT32*)0x0, &data_size, NULL);

  if (EVar1 == EFI_BUFFER_TOO_SMALL) {
    // Allocate memory based on retrieved data_size
    // Check for allocation failure (not shown here)
    buffer = AllocatePool(EfiBootServicesData, data_size);

    // Second call to GetVariable with allocated buffer
    EVar1 = (*gRS_2->GetVariable)
        ((CHAR16*)TCG2_CONFIGURATION, &gTCG2_CONFIG_FORM_SET_GUID,
         (UINT32*)0x0, &data_size, buffer);

    // Free the allocated memory after use (not shown here)
    FreePool(buffer);
  } else {
    // Handle unexpected return values (not shown here)
  }
}

Vad jag förstår så är APIet att data_size vid anropet skall ange buffertstorleken. Om värdet som läses ut är längre så sätts data_size till den längd som behövs och EFI_BUFFER_TOO_SMALL returneras.

Så vid första anropet får du veta vad som behövs (du kan ju välja att helt skippa att ha en buffert första gången, bara för att få veta längden), och kan då välja om du kan/vill skaka fram en så stor buffert eller om du vill skippa det och hantera det som ett fel istället.

Tycker AI-"lösningen" verkar skapa ett nytt problem eftersom den inte verkar sätta några gränser, vilket väl är lite i linje med vad du är inne på.

Jag förutsätter att det snarast är att data_size är för litet som är signalen

Dokumentationen säger att det tänka sättet att ta reda på storleken är att sätta buffern till NULL och data_size till 0. Rimligtvis kontrollerar funktionen båda dessa villkor var för sig, ursprungskoden initialiserar t.ex. inte data_size utan förlitar sig enbart på buffer = NULL, men det är ju dumt att chansa.

Jag skulle inte säga "rimligtvis", men kanske.

Det jag ville åt är ju främst att om man kollar om data_size är för litet så fångar man redan samtliga fall. Att undersöka buffer-argumentet kan bara fånga ett enda fall, som givet korrekta argument ju ändå redan fångats.

Och vad gäller "men tänk om man gjort fel m.a.p. data_size och buffer", ja då är det ju designat på ett sådant sätt att man ändå är rökt i alla fall utom det ända där man kan identifiera att buffer är NULL om man väljer att göra den extra kollen.

Så jag tycker inte alls att det känns självklart att det kommer finnas någon extra kontroll av buffer, det känns mer som en bonus om det finns...

(Och vi vet inte vad ursprungskoden gör i detalj eftersom det bara är några utvalda små utdrag för att visa att de inte anpassar buffer-argumentet när det blir EFI_BUFFER_TOO_SMALL utan bara kör igen med samma data_size som returnerats. Jag tycker det ser ut att ha varit upplagt för att de skulle ha satt data_size=8 från början, men vem vet.)

När ryzen släpptes trodde jag att intel inom ett par år skulle komma igen men de verkar inte ha lyckats riktigt.

Kan ju vara bra att ha koll på ens partners så dessa saker inte händer.

Hej WKL, har läst en hel del bra skrivet av dig.

I C/C++ så är buffer en pekare i sig, så det har inte gjorts om någonting. I exemplet nedan så är alla fyra varianterna att komma åt innehållet i "buffer" giltliga och det handlar i samtliga fall om pekararitmetik. Sedan görs en "AllocatePool" som väl får ses som en sorts "malloc()", där denna kod förutsätter att vi faktiskt får ett rimligt värde returnerat i "data_size" (och inte bara 0). Då vi sedan gör om anropet till samma funktion så har vi underförstått accepterat att den ansvarar för all rim och reson.

Det som jag ser är att "data_size" initialt är odefinerat med ett random-värde, så beroende på hur den funktionen är skriven så riskerar vi att den släpper igenom vissa värden? (Om data_size råkar bli 100 t.ex.) Rimligen borde man sätta data_size=0 så att vi inte får slumpartade händelser med felkoder i EVar1. Detta är något som kompilatorn gcc är tyst om, om man inte slår på "-Wuninitialized".

Språket C har ju inga gränser för vad du får adressera så till slut gör vi en access utanför vår buffer och hämtar vad som finns där. Denna frihet är förmodligen vad som gjort C till det lämpliga språket att skriva linux-kärnan då man måste "prata" med hårdvara som adresseras på samma sätt som "overflow". (Kärnan körs i fysiskt minne, inte virtuellt minne.)

#include <stdio.h>	// printf
#include <string.h>	// strcpy
void ds()
{
	unsigned long data_size;
	printf("Data size: %ld\n",data_size);
}
void main()
{
	unsigned char	value, *one, *two, *three, *overflow, buffer[8];

	one = buffer+1;
	two = &buffer[2];
	three = (&buffer[0])+3;
	strcpy(buffer,"olle");
	printf("%c %c %c %c\n",buffer[0],*one,*two,*three);

	ds();

	// Do a random memory access outside of our buffer.
	overflow = buffer+99;
	value=*overflow;
	printf("%d %c\n",(int)value,value);
}

Utskrift, med lite olika värden varje gång koden körs:

o l l e
Data size: 139653966983888
250 ú

Även AMI, Insyde och Intel är drabbade sedan tidigare.

"This vulnerability also extends to several other UEFI BIOS vendors, including Lenovo, Intel, Insyde, and AMI. Phoenix is the latest to join the list."

Artiken här på Sweclockers nämner även Dell, men hittar ingen källa på det.

Så på vanlig svenska så är mitt ASUS z490-F Gaming moderkort fucked?
Jag antar att det inte är så allvarligt när man gått ut med nyheten innan tillverkarna hunnit patcha det? typ, att jag som användare fortfarande måste göra nått otroligt dumt för att någon ska få tillgång att kunna köra koden in the first place.

Verkar som att man måste ha fysiskt tillgång till någons dator för att ta sig förbi TPM:
https://hothardware.com/news/bios-security-vulnerability-affe...

Illa för företag med laptops ute på vift, men som privatperson kan man troligtvis vara lugn. Däremot ger TPM en falsk trygghet tills ens UEFI är patchad.

"The good news is this vulnerability is only exploitable with physical access to the system."

tack tack

Nu är jag nog totalt ute och cyklar men är det bra i alla lägen att en AI letar buggar som en människa kanske aldrig någonsin skulle ha hittat?
Kanske inte i de thär fallet men med tex Spectre och Meltdown så ledde ju patchandet till märkbart sänkt prestanda i vissa lägen.
Om det nu i fortsättninen skulle leda till att AI blir så skicklig att den hittar så osannolika "kryphål" och metoder som en människa aldrig kommit fram till och det i sin tur leder till ett patchande som sänker prestandan, något som då inte skettt utan AI, är det väl negativt?
Eller ska allt som någonsin, hur osannolikt det än är , kan ställa till det försöka hittas med AI och sen patchas även om prestandan skulle bli extremt lidande?

Eller blir det ett race mellan good guys och bad guys som alla använder AI?

Ska good guys vänta med tillkännagivande tills det börjar "Brännas"?

Ja, alltså, alternativet är väl typ att illasinnade typer blir först med att hitta hålen. AI finns där, vilket man nog helt enkelt får acceptera, och kommer garanterat användas på det viset av någon. Bättre då att lite mer etiskt sinnade personer hinner först.

Det hjälper absolut inte att blunda och hoppas att ingen kommer använda AI till dumheter i alla fall

De allra flesta säkerhetshål som patchas påverkar inte prestandan alls, att Spectre och Meltdown blev så uppmärksammade var just p.g.a. hur mycket de första patcherna påverkade prestandan. Men de är mer ett undantag än en regel, och det finns ingen anledning att tro att prestandan skulle bli extremt lidande bara för att det blir enklare att hitta säkerhetshål.

Nu är ju iofs inte detta en bugg som en människa aldrig någonsin skulle hitta, faktum är att den borde ha hittats ganska mycket tidigare för den är ganska uppenbar.

Spectre och Meltdown stökar till det för prestandan därför att felet ligger fundamentalt i hur spekulation i en CPU fungerar och vad som gör att spekulationen genererar snabbare exekvering och är därmed också hyfsat stora undantag i vad för effekt som patchar mot sårbarheten får när det kommer till prestanda.