Kees Cook, en tidigare chefsadministratör för kernel.org och ledare för Ubuntus säkerhetsteam, som nu arbetar på Google för att skydda Android och ChromeOS, har släppt en uppsättning patchar som randomiserar kärnstackförskjutningar vid hantering av systemsamtal. Patchar förbättrar kärnsäkerheten genom att byta stackplats, leller att det gör stackattacker mycket svårare och mindre framgångsrika
Den ursprungliga idén för patchen tillhör PaX RANDKSTACK-projektet. Under 2019 försökte Elena Reshetova, ingenjör på Intel, skapa en implementering av denna idé, lämplig för inkludering i huvudsammansättningen av Linux-kärnan.
Därefter togs initiativet av Kees Cook som skickade in en lämplig implementering för den stora kärnversionen och vars patchar är planerade för Linux version 5.13.
Läget kommer att inaktiveras som standard och för att aktivera det erbjuds kärnans kommandoradsparameter "randomize_kstack_offset = på/av» och inställningar CONFIG_RANDOMIZE_KSTACK_OFFSET_DEFAULT, plus omkostnaderna för att aktivera läget uppskattas till en prestandaförlust på cirka 1 %.
Kärnan i det föreslagna skyddet är att välja en slumpmässig stackoffset för varje systemanrop., vilket komplicerar bestämning av stackens layout i minnet även om adressinformation tas emot, eftersom stackens basadress kommer att ändras vid nästa samtal.
Till skillnad från genomförandet av PaX RANDKSTACK, i de patchar som föreslås för inkludering i kärnan, randomisering görs inte i det inledande skedet, men efter att ha ställt in pt_regs-strukturen, vilket gör det omöjligt att använda ptrace-baserade metoder för att bestämma en slumpmässig offset under ett långvarigt systemanrop.
Eftersom Linux-kärnstackskydden ständigt har förbättrats (vmap-baserad stackmappning med skyddssidor, borttagning av thread_info, STACKLEAK), har angripare varit tvungna att hitta nya sätt att få sina utnyttjande att fungera.
De har, och fortsätter att förlita sig på kärnstackdeterminism, i situationer där VMAP_STACK och THREAD_INFO_IN_TASK_STRUCT de var inte relevanta. Till exempel skulle följande senaste attacker ha hindrats om stackoffset inte var deterministisk mellan systemanrop
Syftet med funktionen randomize_kstack_offset är att lägga till en slumpmässig offset efter att pt_regs har skjutits till stacken och innan resten av trådstacken används under systemanropsbearbetning, och ändras varje gång en process utfärdar ett systemanrop. Källan till slumpmässighet är för närvarande definierad av arkitekturen (men x86 använder den låga byten av rdtsc()).
Framtida förbättringar är möjliga för olika entropikällor, men utanför omfattningen av denna patch. Dessutom, för att lägga till mer oförutsägbarhet, väljs nya förskjutningar i slutet av systemanrop (vars timing borde vara mindre lätt att mäta från användarutrymmet än vid systemanropsinmatning) och lagras de i en variabel per CPU, så värdets livslängd förblir inte explicit knuten till en enda uppgift.
Det finns inga synliga ändringar av detta på x86 eftersom stackspararen redan är ovillkorligt inaktiverad för kompileringsenheten, men ändringen krävs på arm64. Tyvärr finns det inget attribut som kan användas för att inaktivera stack saver för specifika funktioner. Jämförelse med PaX RANDKSTACK-funktionen: RANDKSTACK-funktionen randomiserar platsen för toppen av stacken (cpu_current_top_of_stack), dvs den inkluderar platsen för pt_regs-strukturen på stacken.
Initialt, denna patch följde samma tillvägagångssätt, men under de senaste diskussionerna har det bedömts vara av ringa värde, eftersom, om ptrace-funktionaliteten är tillgänglig för en angripare, kan de använda PTRACE_PEEKUSR för att läsa/skriva olika offset i pt_regs-strukturen, observera beteendet hos åtkomstcachen pt_regs och ta reda på den slumpmässiga stackförskjutningen.
Slutligen nämns det initial implementering stöder ARM64- och x86/x86_64-processorer.