Navorsers van Stanford Universiteit, UC San Diego, en die Universiteit van Texas in Austin gereedskap , wat as 'n bykomende isolasielaag gebruik kan word om kwesbaarhede in funksiebiblioteke te blokkeer. RLBox poog om die sekuriteitskwessie van onbetroubare derdeparty-biblioteke aan te spreek wat nie onder die beheer van ontwikkelaars is nie, maar kwesbaarhede waarin die hoofprojek in die gedrang kan kom.
Mozilla Maatskappy gebruik RLBox in Linux-geboue van Firefox 74 en macOS-bou van Firefox 75 om biblioteekuitvoering te isoleer Verantwoordelik vir die weergawe van lettertipes. Terselfdertyd is RLBox nie spesifiek vir Firefox nie en kan dit gebruik word om enige biblioteke in arbitrêre projekte te isoleer. RLBox onder die MIT-lisensie. RLBox ondersteun tans Linux- en macOS-platforms, met Windows-ondersteuning wat op 'n later datum verwag word.
Die werk van RLBox kom daarop neer om die C / C ++-kode van die geïsoleerde biblioteek saam te stel in 'n laevlak WebAssembly-tussenkode, wat dan as 'n WebAssembly-module geformateer word, waarvan die toestemmings slegs met betrekking tot hierdie module gestel word ( byvoorbeeld, 'n biblioteek vir die verwerking van stringe sal nie 'n netwerksok of lêer kan oopmaak nie) . Die omskakeling van C/C++-kode na WebAssembly word gedoen met behulp van .
Vir direkte uitvoering word die WebAssembly-module saamgestel in inheemse kode met behulp van 'n samesteller en loop in 'n aparte "nanoproses" geïsoleer van die res van die toepassing se geheue. Die Lucet-samesteller is gebaseer op dieselfde kode as die JIT-enjin Die gebruik deur Firefox om WebAssembly uit te voer.
Die saamgestelde module werk in 'n aparte geheue area en het nie toegang tot die res van die adresspasie nie. As die kwesbaarheid in die biblioteek uitgebuit word, sal die aanvaller beperk word en nie toegang tot die geheueareas van die hoofproses kan kry of beheer buite die geïsoleerde omgewing kan oordra nie.
Vir ontwikkelaars, 'n hoë-vlak , waarmee jy biblioteekfunksies in isolasiemodus kan oproep. WebAssembly-hanteerders benodig byna geen bykomende hulpbronne nie en interaksie daarmee is nie veel stadiger as om gewone funksies op te roep nie (biblioteekfunksies word uitgevoer in die vorm van inheemse kode, en oorhoofse koste vind slegs plaas wanneer data gekopieer en gekontroleer word in die proses van interaksie met 'n geïsoleerde omgewing) . Geslote biblioteekfunksies kan nie direk opgeroep word nie en moet verkry word met behulp van
invoke_sandbox_function() laag.
Op sy beurt, as eksterne funksies vanaf die biblioteek opgeroep moet word, moet hierdie funksies eksplisiet gedefinieer word deur die register_callback-metode te gebruik (by verstek bied RLBox toegang tot funksies ). Om geheueveiligheid te verseker, is isolasie van kode-uitvoering nie genoeg nie en dit is ook nodig om die verifikasie van teruggekeerde datastrome te verseker.
Waardes wat in die geïsoleerde omgewing gegenereer word, word as onbetroubaar gemerk, beperk deur en vir "skoonmaak" vereis en kopieer na toepassinggeheue.
Sonder opruiming lei die poging om besmette data te gebruik in 'n konteks wat gereelde data vereis (en omgekeerd) tot samestellingstydfoute. Klein funksie-argumente, terugkeerwaardes en strukture word oorgedra deur middel van kopiëring tussen prosesgeheue en sandboxgeheue. Vir groot datastelle word geheue in 'n geïsoleerde omgewing toegewys, en 'n direkte "sandbox-verwysing" wyser word na die hoofproses teruggestuur.
Bron: opennet.ru