Forskare från Stanford University, University of California San Diego och University of Texas at Austin verktyg , som kan användas som ett extra lager för att blockera sårbarheter i funktionsbibliotek. RLBox syftar till att lösa problemet med osäkra tredjepartsbibliotek som inte kontrolleras av utvecklarna, men vars sårbarheter kan kompromettera huvudprojektet.
Företaget Mozilla att implementera RLBox i Linux-versioner av Firefox 74 och macOS-versioner av Firefox 75 för att isolera körningen av biblioteket , som ansvarar för renderingen av teckensnitt. RLBox är dock inte specifikt för Firefox och kan användas för att isolera alla bibliotek i valfria projekt. RLBox under MIT-licens. För närvarande stödjer RLBox plattformar som Linux och macOS, medan stöd för Windows förväntas senare.
för RLBox fungerar genom att kompilera C/C++-koden från det isolerade biblioteket till lågnivå WebAssembly-intermediärkod, som sedan paketeras som en WebAssembly-modul med behörigheter begränsade till just denna modul (till exempel kan inte ett bibliotek för stränghantering öppna ett nätverksuttag eller en fil). Översättningen av C/C++-koden till WebAssembly sker med hjälp av .
För att köra WebAssembly-modulen kompileras den till maskinkod med hjälp av kompilatorn och körs i en separat "nanoprocess", isolerad från övrig programminne. Kompilatorn Lucet baseras på samma kod som JIT-motorn , som används i Firefox för att köra WebAssembly.
Den sammanställda modulen arbetar i ett separat minnesområde och har ingen tillgång till det övriga adressutrymmet. Vid en exploatering av en sårbarhet i biblioteket kommer angriparen att vara begränsad och kan inte komma åt minnesområdena i huvudprocessen eller överföra kontroll utanför det isolerade miljön.
För utvecklare tillhandahålls ett hög nivå API , som gör det möjligt att anropa bibliotekets funktioner i ett isolerat läge. WebAssembly-hanterare kräver nästan inga extra resurser och interaktionen med dem är inte mycket långsammare än anrop av vanliga funktioner (bibliotekets funktioner körs i form av nativen kod, och overhead uppstår endast vid kopiering och verifiering av data under interaktionen med den isolerade miljön). Isolerade bibliotekets funktioner kan inte anropas direkt och för att komma åt dem måste man använda
lager invoke_sandbox_function().
För sin del, om externa funktioner behöver anropas från biblioteket, måste dessa funktioner uttryckligen definieras med metoden register_callback (standardmässigt ger RLBox åtkomst till funktioner ). För att säkerställa säker hantering av minne (memory safety) är det inte tillräckligt med kodens exekveringsisolering, utan det krävs också verifiering av de returnerade dataströmmarna.
Värden som genereras i den isolerade miljön märks som icke-betrodda, begränsas med hjälp av och för att "rensa" dem krävs och kopiering till applikationens minne.
Utan rensning kommer försök att använda tainted-data i en kontext som kräver vanliga data (och vice versa) att leda till kompileringserrorer. Små funktionsargument, returvärden och strukturer överförs genom kopiering mellan processens minne och den isolerade miljöns minne. För stora datamängder allokeras minne i den isolerade miljön, och en direkt pekare "sandbox-reference" returneras till huvudprocessen.
Källa: opennet.ru
