Inom datorsäkerhet är PaX (pron. "Pax") en patch till Linux-kärnan , som ger möjlighet att konfigurera minsta åtkomsträttigheter för applikationer till minnessidor. Detta ger en finkornig inställning som gör att program endast kan utföra de åtgärder som är nödvändiga, baserat på den funktionalitet de tillhandahåller, men inte mer. PaX släpptes första gången 2000. Sedan 2014 har den endast delats ut som en del av grsäkerhetsprojektet [1] , som har blivit betalt sedan april 2017 [2] .
PaX markerar datasegmentet för program i minnet som okörbart (eftersom det per definition inte kan innehålla programdirektiv som behöver exekveras), och kodsegmentet som icke-skrivbart och allokerar dessutom minne till programmet från godtyckligt platser på varje begäran (randomisering av minnessidor). Alla program som försöker överföra kontroll till kod som finns i ett okörbart minne tvingas avsluta [1] .
Den här tekniken är effektiv mot användningen av olika exploateringar med till exempel en sårbarhet baserad på ett minnesbuffertspill. Ett sådant skydd förhindrar initialt helt direkt exekvering av kod från minnet, och gör samtidigt, ur tillämpningssynpunkt, de så kallade return-to-libc (ret2libc)-attackerna svåra att utföra (de blir mer slumpmässiga, utan en förutsägbart resultat). Men samtidigt förhindrar PaX inte fel som leder till möjligheten att omdefiniera variabler och pekarvärden.
PaX skrevs av utvecklingsteamet med samma namn. Grundaren av PaX föredrar för närvarande att vara anonym av skäl som är okända för allmänheten.
En ganska stor del av det totala antalet sårbarheter i datorsystem orsakas av fel i program som gör det möjligt att omdefiniera sina funktioner genom att skriva om dem i farten (direkt i RAM). Funktionsprincipen för många maskar, virus, såväl som många metoder för direkta försök att hacka system bygger på att ändra innehållet i minnet genom att injicera och sedan exekvera skadlig kod, på att exekvera en del av innehållet i ett minnesområde genom att medvetet ändra pekare, etc. Om sådana åtgärder blockeras på något sätt , blir den totala skadan ganska obetydlig, eller kanske inte alls, även om viruset har trängt in i systemet. Dessutom kommer många maskar (som till exempel Sasser ) inte att kunna infiltrera systemet alls i det här fallet.
PaX skapades för att förhindra sådana attacker och för att göra det på ett så generaliserat sätt som möjligt, det vill säga att förhindra exekvering av olaglig kod genom att kontrollera minnesåtkomst (för läsning, skrivning, exekvering och deras möjliga kombinationer), dessutom, utan att direkt röra själva den körbara koden. Till en så låg kostnad gör PaX systemet mer motståndskraftigt mot hackning, minskar antalet utnyttjanden som leder till programnedläggning ( DoS ) eller fjärrövervakar framstegen i kodexekveringen; utnyttjar som använder sådana sårbarheter för att ge en angripare rotåtkomst, komma åt känslig information på ett system eller på annat sätt orsaka skada. Istället kan ärendet begränsas till att avbryta funktionen av någon process eller program, med minimala konsekvenser för hela systemet.
Oftast är skadan som orsakas av en DoS-attack förlust av tid och resurser på grund av att det attackerade objektets funktionalitet inte fungerar. Men i det här fallet förhindrar PaX olaglig åtkomst och distribution av känslig systemdata på grund av en attack, och förhindrar inte själva attacken. Samtidigt är de direkta konsekvenserna av DoS också mycket oönskade, särskilt för system där alla avbrott i tjänsten är kritiska, och penetrationen av en inkräktare uppenbarligen orsakar mindre skada än uppsägningen av tjänsterna. I det här fallet kommer PaX inte att vara den bästa lösningen, men ändå är det en ganska acceptabel metod för att skydda viktig information.
Många (men absolut inte alla) utvecklares misstag gör att deras program missköter minnet. Detta ger den hypotetiska möjligheten att få ett program att göra något det inte är tänkt att göra (till exempel utfärda ett privilegierat skal). Syftet med PaX är inte att hitta och åtgärda sådana sårbarheter, utan snarare att förhindra att de utnyttjas av attackerande applikationer. Konsekvenserna av fel kommer att minimeras - exekveringen av programmet kommer helt enkelt att avbrytas, vilket ur PaX synvinkel är bättre än dess komprometterade funktionalitet.
Det bör förstås att PaX inte direkt förhindrar buffertspill, utan försöker endast effektivt undertrycka potentiella utvecklarfel som är associerade med det, vilket kan leda till att till exempel tillhandahålla oavsiktlig åtkomst till systemet. Det finns dock utvecklingar som Stack-Smashing Protector och StackGuard som försöker upptäcka exakt själva buffertspillet och stoppa exekveringen av program som äventyrar systemet. Denna teknik kallas stack-smashing protection . Den är inriktad på att direkt blockera direkta attacker, om möjligt. Även om både PaX och stack-smashing skydd i huvudsak tjänar samma syfte, är de inte utbytbara. Men införandet av båda teknikerna kommer säkerligen att göra systemet säkrare. Vissa Linux-distributioner inkluderar redan båda komponenterna samtidigt (PaX och Stack Smash Protection) [3] .
I oktober 2006 har PaX ännu inte slagits samman med kärnans huvudlinje , eftersom patchutvecklarna tror att den fortfarande inte är mogen nog. Men trots att PaX har använts framgångsrikt på många arkitekturer, stöds det fortfarande bara delvis, eller inte alls, på ett antal andra. Således har PaX framgångsrikt använts på IA-32 ( x86 ), AMD64 , IA-64 , Alpha , PA-RISC , 32 och 64 bitars MIPS , PowerPC och SPARC .