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

Permalänk
Melding Plague

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

Eclypsium hittade buggen, som drabbar alla Intel-processorer från 6:e till 14:e generationen, med hjälp av AI.

Läs hela artikeln här

Visa signatur

Observera att samma trivselregler gäller i kommentarstrådarna som i övriga forumet och att brott mot dessa kan leda till avstängning. Kontakta redaktionen om du vill uppmärksamma fel i artikeln eller framföra andra synpunkter.

Permalänk
Medlem

Hur går det för intel egentligen? Börjar bli dags för en ny sandy bridge modell och att de fixar till alla dessa "hål" de ramlar ned i.

Visa signatur

Ryzen 5900X @ Stock, MSI Suprim X 3080 @ game mode.

Permalänk
Medlem
Skrivet av Aka_The_Barf:

Hur går det för intel egentligen? Börjar bli dags för en ny sandy bridge modell och att de fixar till alla dessa "hål" de ramlar ned i.

Det har gått dåligt bra många år för Intel.

Permalänk
Hedersmedlem
Skrivet av Aka_The_Barf:

Hur går det för intel egentligen? Börjar bli dags för en ny sandy bridge modell och att de fixar till alla dessa "hål" de ramlar ned i.

Detta hålet ser ju dock ut att vara från Phoenix Technologies, inte Intel. Ett enkelt kodfel som inte påverkas av CPU-tillverkaren, men just detta BIOS kanske bara har använts för Intel.

Visa signatur

Asus ROG STRIX B550-F / Ryzen 5800X3D / 48 GB 3200 MHz CL14 / Asus TUF 3080 OC / WD SN850 1 TB, Kingston NV1 2 TB + NAS / Corsair RM650x V3 / Acer XB271HU (1440p165) / LG C1 55"
NAS: 6600K/16GB/Debian+ZFS | Backup (offsite): 9600K/16GB/Debian+ZFS

Permalänk

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.

Visa signatur

"Den säkraste koden är den som aldrig skrivs"
"Visste du förresten att det är ett mångmiljardbolag?"
"Jag lever inte för att koda utan kodar för att sen kunna leva"

Permalänk
Medlem
Skrivet av WebbkodsFrilansaren:

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.

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.

Permalänk
Medlem
Skrivet av WebbkodsFrilansaren:

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.

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å.

Visa signatur

Desktop: Ryzen 5800X3D || MSI X570S Edge Max Wifi || Sapphire Pulse RX 7900 XTX || Gskill Trident Z 3600 64GB || Kingston KC3000 2TB || Samsung 970 EVO Plus 2TB || Samsung 960 Pro 1TB || Fractal Torrent || Asus PG42UQ 4K OLED
Proxmox server: Ryzen 5900X || Asrock Rack X570D4I-2T || Kingston 64GB ECC || WD Red SN700 1TB || Blandning av WD Red / Seagate Ironwolf för lagring || Fractal Node 304

Permalänk
Medlem
Skrivet av perost:

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.

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

Visa signatur

Desktop: Ryzen 5800X3D || MSI X570S Edge Max Wifi || Sapphire Pulse RX 7900 XTX || Gskill Trident Z 3600 64GB || Kingston KC3000 2TB || Samsung 970 EVO Plus 2TB || Samsung 960 Pro 1TB || Fractal Torrent || Asus PG42UQ 4K OLED
Proxmox server: Ryzen 5900X || Asrock Rack X570D4I-2T || Kingston 64GB ECC || WD Red SN700 1TB || Blandning av WD Red / Seagate Ironwolf för lagring || Fractal Node 304

Permalänk
Medlem
Skrivet av evil penguin:

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.

Permalänk

Hur ser attackvektorn ut då? Jag antar att man behöver fysisk access till maskinen då det är kod som körs innan TPM kickar in?

Permalänk
Medlem
Skrivet av perost:

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.)

Visa signatur

Desktop: Ryzen 5800X3D || MSI X570S Edge Max Wifi || Sapphire Pulse RX 7900 XTX || Gskill Trident Z 3600 64GB || Kingston KC3000 2TB || Samsung 970 EVO Plus 2TB || Samsung 960 Pro 1TB || Fractal Torrent || Asus PG42UQ 4K OLED
Proxmox server: Ryzen 5900X || Asrock Rack X570D4I-2T || Kingston 64GB ECC || WD Red SN700 1TB || Blandning av WD Red / Seagate Ironwolf för lagring || Fractal Node 304

Permalänk
Medlem
Skrivet av Maximo:

Det har gått dåligt bra många år för Intel.

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

Skrivet av Thomas:

Detta hålet ser ju dock ut att vara från Phoenix Technologies, inte Intel. Ett enkelt kodfel som inte påverkas av CPU-tillverkaren, men just detta BIOS kanske bara har använts för Intel.

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

Visa signatur

Ryzen 5900X @ Stock, MSI Suprim X 3080 @ game mode.

Permalänk
Datavetare
Skrivet av Aka_The_Barf:

Hur går det för intel egentligen? Börjar bli dags för en ny sandy bridge modell och att de fixar till alla dessa "hål" de ramlar ned i.

Följer man länken i artikeln till där sårbarheten beskrivs hittar man

"This type of low-level exploitation is typical of firmware backdoors (e.g. BlackLotus) that are increasingly observed in the wild.

D.v.s. denna typ av attacker har ökat och detta är långt ifrån den första sårbarheten man hittat just med Eclypsium Automata.

Det unika denna gång är att sårbarheten fanns på i kod som är specifik för Intels CPUer, de flesta andra liknande sårbarheter påverkade i praktiken alla system som använder UEFI.

Rätt säker att en artikel som innehåller "sårbarhet + Intel" genererar betydligt mer intresse än "nästan alla är sårbara", för hade själv läst väldigt lite om de andra liknande sårbarheterna som listandes.

Just denna har ju faktiskt ett rätt lågt CVE "severity value" värde på 7,5. Skulle gå att skriva minst en artikel per månad om CVE:er i konsumentprodukter även om man bara tog de med en poäng på minst 9,0.

En sak som ändå är positivt kring detta är att det satt fokus allt mer på hur en stor andel av dessa sårbarheter faktiskt skulle kunna elimineras genom att använda existerande teknik.

Denna (och ca 70 % av alla CVE i Windows enligt Microsoft) skulle helt kunna elimineras om man skrev om programvara i moderna "memory safe programming languages", t.ex. Rust. Denna fel skulle inte ens kompilera i Rust (tror även Zig tar detta vid kompilering) , det skulle ge runtime-error i Go, Swift, Java, C#, m.fl.

Men inte realistiskt att skriva om all existerande kod. Rätt spännande om "AI" kan plocka en stor andel av dessa!!!

Skrivet av The_beast*:

Hur ser attackvektorn ut då? Jag antar att man behöver fysisk access till maskinen då det är kod som körs innan TPM kickar in?

All den informationen finns med i beskrivning, dock i ett format som bara säger något om man använt det tidigare. I detta fall är informationen denna

CVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:C/C:H/I:H/A:H

Svaret på din fråga finns i "AV:L", d.v.s. "Attack Vector: Local". Så man behöver "lokal access", inte fysisk access, så fungerar även med t.ex. SSH.

Ovanpå det ser vi "PR:H", vilket står för "Privileges Required: High", d.v.s. man måste vara root/admin för att utföra attacken. Och ungefär där kommer frågan: vad är poängen om man redan har root-access?

Är mycket p.g.a. av dessa två saker som denna "bara" fått 7,5 i poäng. Den kräver också "mycket hög tekniskt kompetens" att utföra. AC:H -> Attack Complexity: High.

I fallet UEFI är huvudpoängen att sårbarheter som körs här ligger på en nivå som gör det väldigt svårt för antivirus och liknande skydda och upptäcka en attack.

Visa signatur

Care About Your Craft: Why spend your life developing software unless you care about doing it well? - The Pragmatic Programmer

Permalänk
Medlem
Skrivet av WebbkodsFrilansaren:

....
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.

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 ú

Permalänk
Medlem

Ä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.

Permalänk
Medlem

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.

Permalänk
Medlem
Skrivet av Jagers:

Jag antar att det inte är så allvarligt när man gått ut med nyheten innan tillverkarna hunnit patcha det?

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."

Permalänk
Medlem
Skrivet av Jagers:

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.

Om jag förstår diskussionen så behöver man adminrättigheter för att utnyttja hålet.
Har någon onda avsikter så borde deras adminrättigheter vara huvudproblemet.
Men jag kan ha missförstått.

Permalänk
Medlem
Skrivet av walkir:

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."

Skrivet av JMWT:

Om jag förstår diskussionen så behöver man adminrättigheter för att utnyttja hålet.
Har någon onda avsikter så borde deras adminrättigheter vara huvudproblemet.
Men jag kan ha missförstått.

tack tack

Permalänk
Medlem

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"?

Permalänk
Medlem
Skrivet av Magnus303:

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

Visa signatur

Nu lurade jag dig att slösa bort ett par värdefulla sekunder av ditt liv på att läsa denna fullständigt poänglösa signatur!

Permalänk
Medlem
Skrivet av Magnus303:

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"?

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.

Permalänk
Medlem
Skrivet av Magnus303:

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"?

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.

Visa signatur

|Ryzen 5800x3d|RX 7900XTX Hellhound|Asus Prime X370 Pro|32GiB Corsair 3200MHz CL16 Vengeance|Corsair HX1000i|Fractal Define R5|LG 45GR95QE|Corsair K100|Razer DeathAdder V3 Pro|Ubuntu 24.04|