Undersikers fan Stanford University, de Universiteit fan Kalifornje yn San Diego en de Universiteit fan Teksas yn Austin ark , dy't brûkt wurde kin as in ekstra isolaasjelaach om kwetsberens yn funksjebiblioteken te blokkearjen. RLBox is rjochte op it oplossen fan it feiligensprobleem fan net-fertroude biblioteken fan tredden dy't net ûnder de kontrôle fan ûntwikkelders binne, mar waans kwetsberens it haadprojekt kinne kompromittearje.
Mozilla Company brûk RLBox yn Linux-builds fan Firefox 74 en macOS-builds fan Firefox 75 om biblioteekútfiering te isolearjen , ferantwurdlik foar it werjaan fan lettertypen. RLBox is lykwols net spesifyk foar Firefox en kin brûkt wurde om alle biblioteken te isolearjen yn willekeurige projekten. RLBox ûnder MIT lisinsje. RLBox stipet op it stuit Linux- en macOS-platfoarms, mei Windows-stipe letter ferwachte.
It wurk fan RLBox komt del op it kompilearjen fan de C/C++-koade fan in isolearre bibleteek yn leech-nivo tuskenlizzende WebAssembly-koade, dy't dan is ûntworpen as in WebAssembly-module, wêrfan de tagongsrjochten allinich ynsteld binne yn relaasje ta dizze module (bygelyks in biblioteek foar it ferwurkjen fan stringen sil net by steat wêze om te iepenjen in netwurk socket of triem). It konvertearjen fan C/C++-koade nei WebAssembly wurdt dien mei .
Foar direkte útfiering wurdt de WebAssembly-module kompilearre yn masinekoade mei in kompilator en rint yn in apart "nanoprocess" isolearre fan 'e rest fan' e applikaasje syn ûnthâld. De Lucet-kompiler is basearre op deselde koade as de JIT-motor , brûkt yn Firefox om WebAssembly út te fieren.
De gearstalde module wurket yn in apart ûnthâld gebiet en hat gjin tagong ta de rest fan it adres romte. As in kwetsberens yn 'e bibleteek wurdt eksploitearre, de oanfaller wurdt beheind en sil net by steat wêze om tagong ta ûnthâld gebieten fan it haadproses of oerdracht kontrôle bûten de isolearre omjouwing.
Ynformaasje op heech nivo wurdt levere foar ûntwikkelders , wêrmei jo bibleteekfunksjes oproppe kinne yn isolaasjemodus. WebAssembly-behannelers fereaskje hast gjin ekstra middels en ynteraksje mei har is net folle stadiger as it oproppen fan gewoane funksjes (de bibleteekfunksjes wurde útfierd yn 'e foarm fan native koade, en overheadkosten ûntsteane allinich by it kopiearjen en kontrolearjen fan gegevens by ynteraksje mei de isolearre omjouwing). Isolearre bibleteekfunksjes kinne net direkt oanroppen wurde en moatte tagonklik wurde mei
layer invoke_sandbox_function ().
Op syn beurt, as it nedich is om eksterne funksjes út 'e bibleteek op te roppen, moatte dizze funksjes eksplisyt definieare wurde mei de metoade register_callback (standert jout RLBox tagong ta funksjes ). Om ûnthâld feiligens te garandearjen, isolemint fan koade-útfiering is net genôch en fereasket ek it kontrolearjen fan de weromjûne gegevensstreamen.
Wearden generearre yn in isolearre omjouwing wurde markearre as ûnbetrouber en beheind gebrûk en foar "skjinmeitsjen" se nedich en kopiearje nei applikaasje ûnthâld.
Sûnder opromjen resultearret besykjen om fersmoarge gegevens te brûken yn in kontekst dy't reguliere gegevens fereasket (en oarsom) resultearret yn flaters dy't wurde generearre op it kompilearjen. Lytse funksje arguminten, werom wearden, en struktueren wurde trochjûn troch kopiearjen tusken proses ûnthâld en sânbox ûnthâld. Foar grutte datasets wurdt ûnthâld tawiisd yn in isolearre omjouwing en in direkte sânbox-referinsjewizer wurdt weromjûn nei it haadproses.
Boarne: opennet.ru